This is the naming system I have been developing to help me keep track of and find stuff. Suggestions welcome!
I am sure everyone has their own ideas for this, just thought I would post mine to make it a bit more solid in my own mind and possible help any interested people. This helps me avoid conflicting names, and find things with searches.
b_bitmap (as in b_ship, b_shot, etc.)
m_material
s_sound
ms_modelState
as_appState
array_array
t_timer
o_model (object gameplay)
fx_model (a model that has no collision and exists as an 'effect')
g_mesh (geometry)
i_repeat (iterator)
-these work for me as they are the names I use in my mind for these items.
a couple other helpfull techniques I have found include;
-when ever a collision is defined I add a comment like "powup vs player" makes them easyer to keep track of
-for sounds a comment like "ch3 nr88" for the Channel the sound is normaly triggered on, and its base Note Number.
a naming system,. .
Moderator: Moderators
- jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
a naming system,. .
iterationGAMES.com
Hi jph,
This is always a interesting topic to share idea's about Personally, in ZGE i use a naming convention similar to what Ville uses for the Component Properties. No underscores, capitals for each word, without any prefixes. So for example a Model I would just call "Carrot", it's material "CarrotMaterial", the bitmap "CarrotBitmap" etc. That way in the drop-down menu's everything "Carrot" related is right beneath each other.
K
This is always a interesting topic to share idea's about Personally, in ZGE i use a naming convention similar to what Ville uses for the Component Properties. No underscores, capitals for each word, without any prefixes. So for example a Model I would just call "Carrot", it's material "CarrotMaterial", the bitmap "CarrotBitmap" etc. That way in the drop-down menu's everything "Carrot" related is right beneath each other.
K