Without proper formatting and decent naming conventions, programming code can become incredibly confusing. And, of course, this is starting to happen to me all over again. A particularly annoying problem in Torque occurs when you use the same name for several things. It has happened a few times before that I used the same same for a sprite and a code class. You don’t get any error messages when you compile, but it can lead to very unpredictable behaviour. That’s why I decided to design a system for naming all the stuff that goes in a game. Not only will it prevent things like this from happening, it will also make it more obvious what a certian thing exactly is.
First of all, there are sprites and animations. For making everything a bit easier, I consider them the same thing. In Torque, a sprite is an image wich contains one or more frames. Even a sprite with multiple frames is still considered a static sprite. Only when you use a sprite with multiple frames to create an animation object, the animation will play. The naming convention I will use for sprites is this:

spr_*_(S,M,A)

What the hell does this mean? The name will always start with “spr_”, so I know it’s a sprite, followed by the name of the image file. After that, an S is placed for a static sprite (single or multiple frame), M for a multiple frame sprite that is used for an animation and A for an animation. Example: I have an image file named “player.png”, wich contains a set of frames for an animated player sprite. The sprite object will be named “spr_player_M”, and the animation object will be named “spr_player_A”.
Next, sounds. For me, there are two types of sounds: sound effects and background music. Similar approach here:

snd_*_(E,M)

That’s “snd_” for sound object, the name of the sound file and E or M for effect or music.
Finally, there’s a whole bunch of object types that use a more or less similar system. These are classes, particle effects, tilemaps and triggers. Here’s the naming convention for those:

class: cls_*
particle effect: pfx_*
tilemap: tmp_*
trigger: trg_*

So that’s my naming system in a nutshell. For local variables, it doesn’t really matter what you call them, since you only use them in a small piece of code. I’ll probably come up with more rules later, so updates will follow.