Component Documentation

[Cheeseness]

I'd like to create separate issues (and eventually wiki pages) as we move forward, but an overarching issue to discuss what's needed here feels worthwhile.

To aid contribution, it's important to document what we've done and particularly where assets are concerned, offer workflows and best practices for implementation of future contributions, as well as helping describe what to expose via #106 .

Here are some items that I think we should look towards stabilising and documenting in the short to near future:

• Cart model implementation (requires stable cart prefab suitable for sharing between online and offline modes? Golf Cart Model #2 )
• Player body model implementation (requires stable player prefab? everything must use the same rig? Player Model #1 )
• Ball model implementation (requires stable ball prefab?)
• Player head implementation (requires stable player prefab? use named blendshapes for facial animation? Basic Player Facial Animations #59 )
• Cart simulation variables ( Car Simulation #21 )
• Golf simulation variables ( Golf Simulation #22 )
• Hole/course implementation (requires that we iron out what course contributions need in them? Detect ball reached hole #135 )
• Music implementation (title and lobby tracks should be loopable and synchronisable? Some metadata to describe "style" might be helpful for creating consistent "sets" of music for in-game playback? Title Music #8 Lobby Music #9 In-game Music #10 )
• Networking system (we already have some documentation for this, but I get the feeling that it's not finalised Entity state/location network synchronisation #20 )
• GUI implementation (right now we're maintaining two techniques for our menu widgets - getting something that would allow for custom UI "skinning" would be a nice way to allow for some UI theme contributions, but at the very least, documentation here will help us keep consistency with new menu type screens that are added in the future)
• Colour texture mask implementation (how we're handling the player colour changing should be documented so that we can do similar implementations for carts, balls and minimap icons, and so that texture contributors know what's going on Player Model #1 )

Anybody got anything else?

[thegsm]

Files should be named in a consistent way to make it easier to swap and use.
For audio we should name based on the type.
Prefix the name with title_ for a title music score and level_ for a level music score.

[Cheeseness]

One other thing on the music front to keep in mind is that we'll want title and lobby tracks to be paired, so they'll need to be identifiably linked (whether that be via file name or other means)

[thegsm]

Could be done by making sure the suffix is the same. We could consider adding info in the file tags, but that will be easier to read via a script.
Also, need to ensure the names are unique among contributors, so we won't get "title_bad_golf" from everyone. Either need to name the work to something unique or more simply add the github username right after the first prefix (like tite__metal)

[Cheeseness]

We've got some initial notes on file naming which include names and stuff over on the naming conventions doc. They put the username last, but in this case, perhaps suffixes are more readable.