Naming conventions in GameMaker

T

The Bard

Guest
I was wondering, what naming convetions do you use. I know everyone has his preferences, but I wanted to hear several opinions of what worked and what didn't work for you guys in your projects.

In my current, project: FAR, I am using the following naming convetions:
sprites: spr_sprite_name
backgrounds: bck_backgroundname
scripts: scr_Script_Name
fonts: fnt_fontName
objects: obj_objectname
rooms: room_name
variables: varnamepart1_varnamepart2_varnamepart3, etc., for example: chamber_Size_H or spr_shdw_X_offset
I tried to use _ in the naming of all my stuff in this new project, but I'm starting to have doubts if it was a good idea. What do you think, is it better to name them like this:

for objects:
objEnemyOrc
or
obj_Enemy_Orc

for variables:
chamberStartX
chamber_Start_X
?

Sorry for the long post and for a question that has more to do with programming good practices in general rather than GameMaker, but maybe some of you more experienced guys can tell me what works better in GameMaker projects?

Thank you! :)
 
M

MonikerHart

Guest
I like to use upper camel case for my resources.

ObjInit, SprMonkeyFeces, RmMain.

Scripts I experimented with a lot, like prep-ending them with the type of return value they had like "iReturnInteger" but now I tend to use upper camel case again, normally prep-ended by "Get" or "Set", if it isn't one of those then its probably a check.

Some scripts I use snake case, but only if I'm making a script that's sort of like an extension to current GM behaviour, like "ds_list_remove" (sort of like ds_list_delete but uses value instead of index).

I use lower camel case for variables. thisIsAVariable. I put an underscore in front of a local variable to denote that it is temporary only, _thisIsALocalVariable.

Finally, in shaders I try to keep as close to what the naming conventions are for GLSL ES as seen in the specification written by Kronos (the developers).

I would not be surprised if other people hated my conventions, and it does make me wonder what it would be like to work with other people with vastly different ways of naming things.
 

SuperSlim

Member
I usually do the same as you in all of those cases except I make a point of never using uppercase. I dont know why. The only time I ever use uppercase is to note a slight difference like spr_walkU and spr_walkD for up and dow respectively.
 

Yal

GMC Memer
GMC Elder
I find camelcasing ugly as heck, I generally only use lowercase and underscore for my names.

  • Sprites: spr_descriptivename
  • Backgrounds: back_descriptivename for backgrounds and GUI elements, tileset_descriptivename for tilesets.
  • Sounds: snd_descriptivename or bgm_descriptivename depending on if it's a music or sound effect.
  • Scripts:
    • Utility function: descriptivename
    • Menu Event: mev_descriptivename
    • Conversation initialization: npc_descriptivename
  • Objects:
    • Parents: parent_descriptivename
    • Other: obj_descriptivename
  • Rooms: descriptivename for small games, areaname_descriptivename for large games.
  • Constants: for indexes: purposeabbreviation_DESCRIPTIVENAME (e.g. ani_ATTACK for an animation), for ordinary constants DESCRIPTIVENAME, e.g. NONE for my custom null value or PLAYERS_MAX.
As for variables, I have the following conventions:
  • I use state, cntr, [menuvalue, menuvaluemax], [ang, angchang], and n a lot and for very specific purposes.
  • Anything I'll only ever use in a single object and never change once it works should have a short but unique name.
  • Anything that is referred to from multiple places should have a name that is inversely proportional in length to how often I use it (e.g. global.crystals_collected is a decent name for a variable I refer to in crystals and crystal doors that are all over the place, but a WAY more specific global might be named something like global.ghost_house_broken_mirror_seen)
 
M

MonikerHart

Guest
I find camelcasing ugly as heck, I generally only use lowercase and underscore for my names.
I find snakecasing ugly as heck ^_^

Like for creating custom NULL constants, so, damn, useful.
 

2Create

Member
For sprites, backgrounds, objects and paths I use the following:
abc_camelCaseName
In which abc is spr, bgd, obj, pth respectively.
For timelines and rooms I use 2 letters, tl and rm respectively.

For scripts I don't use a prefix at all most of the time. It's sort of a pain when writing code with them.
I really don't like doing the prefix thing, but with GM it's basically a must.
 

Yal

GMC Memer
GMC Elder
I've seen some people (and by "some people", I mean one or two guys several years ago) advocate using suffixes instead, e.g. the resources for your snake object would be snake_spr, snake_obj, snake_die_sfx, snake_attack_sfx and so on. It feels kinda alien to me after a decade of prefixes, but I guess it might appeal to some people.
 

Nexusrex

Nexusrex Games
Well, i use this:
  • Sprites: spr_player
  • Backgrounds: bckgrnd_home
  • Objects: obj_player
  • Paths: pth_enemy
  • Rooms: rm_home
  • Variables: canshoot
  • Sounds: sfx_shot
  • Music: mus_home
 

2Create

Member
Using suffixes? That... actually solves nothing. It's just as clumsy to type, and when reading you only find out at the end what kind of argument the thing you're doing actually takes. It reads just a little nicer, but has less utility for me. And unless you type from right to left (which you don't), it's usually easier to swap out resource names when using prefixes if you suddenly want to change which one you use.
 
Z

Zekka

Guest
While we're at useful tips, this thing blew my mind and has totally changed the way I code stuff forever.
View attachment 221
For those who don't immediately see it, Yal is storing the index of a script in a variable. This is a really versatile technique and state machines are just one application. (Another good application is using it to let people replace just one aspect of an object's behavior without creating a whole new object type. Suppose a monster does script_execute(move_ai) each step, where move_ai is one of its variables.)
 
S

Snail Man

Guest
Here's what I use

spr_sprite_name
bgd_background_name
snd_sound_name
or
mus_music_name
pth_path_name
tml_timeline_name
obj_object_name
script_name
room_name (this varies greatly from project to project: if it is heavily level based, I prefix with level_ or lvl_, if it's a metroidvania with an extensive map, I usually go with row_X_column_Y or rXcY. Otherwise I just use no prefix)

The key thing is just to be consistent, and make sure everything is readable. Beyond that it's just preference.
 

seanm

Member
I just do some kind of camel case for most of my stuff,

Assets
Code:
sprPlayer
bkWall
sndShoot
rmBoss1
Variables
Code:
shootTimer
canShoot

probably not the best way to do it but it works.

edit:
I mostly just hate typing _ which is why I never use it in names lol
 

Coded Games

Member
I like how little variety there is in our naming conventions. Here's what use:

Sprites: spr_
Objects: obj_
Fonts: fnt_
Scripts: scr_ OR none if the script acts like a function.
Sounds: snd_
Rooms: rm_
Backgrounds: bg_
Tile Sheets: tile_
Paths: pth_
I honestly have never used timelines.

And then after the _ I use camel case for the name.
 
F

faissaloo

Guest
Underscore spaces:
Sprites: *_spr
Objects: *_obj
Fonts: *_fnt
Scripts: *
Sounds: *_snd
Rooms: *_rm
Backgrounds: _bg
Tile Sheets: _tile
Paths: *_path
 
I use different prefixes for different variable types:
str_something
int_something
bool_something
list_something
map_something

I know you're gonna say "but int=bool=list=map in gamemaker it's all int!!1" but this also helps me remember what's actually stored. For example "int_inventory" from an old project script is probably the number of inventory items while list_inventory is the ds_list of them :)
 

Kepons

Lost The Bet
I do it this way, almost always using CamelCase:

Sprites: sName
Objects: oName
Fonts: fName
Scripts: I don't prefix them because I find it more convenient that way.
Sounds: sndName
Rooms: rName
Backgrounds/Tilesets: bgName
Paths: I don't use them.
 

Bluetail7

Member
Sprites: gfx_*
Sounds: SFX_* / BGM_*
Backgrounds: bckg_*
Tilesets: tsl_*
Paths: pth_*
Scripts: whattheydo
Fonts: fnt_*
Timelines: tl_*
Objects: orb_*
Rooms: rm_* / rom_*
Variables: Initials or property_function
 

Yal

GMC Memer
GMC Elder
What does it mean? If state is smaller or bigger than "nothing", execute the state script?
So as long as my state = something, the script will always execute? I think I totally don't get it....
The important part here is script_execute() executing the contents of variable. AKA, very, very, VERY customizable behavior.
 
Mine for giggles!

Sprites: spr_player
Backgrounds: bg_water_level
Fonts: font_level_up
Objects: obj_boss
Rooms: rm_title_screen
Variables: variable_name, don't really have a naming convention, but if its part of a system, I'll usually prefix it with the system name, eg: 'input_player_control_enabled'
Scripts: Depends on what the script is for, as follows:
Generic Function: is_between(), basically, a short but descriptive name with little structure
System Function: input_init(), for example, my input handling system, starts with a short description or acronym, then the function of the script.
Object Script: player_step(), the name of the object (without the 'obj' prefix), followed by the event the code is for, or a more general description if it can be used for multiple events. Code for Objects that aren't directly tied to a specific event (eg: 'player_damage()') will be named similar to System Functions.

As you can see, I don't use camel case, mostly because of fringe situations where normally all uppercase names get smooshed together (can't think of a good example), plus I just find camel case to be less readable. I don't use other resources, so I don't have prefixes for them. I have only rarely gotten as far into a project as to need sounds, but haven't used any audio in Studio, but I'll likely prefix them as 'snd' for effects, and 'mus' for music.
 
L

leonfook29

Guest
I do this:

something_obj
something_spr
something_rm

Where the "something" are usually grouped, like a swordguy idle sprite would be swrd_idle_spr and so on. Can't break the habit of having to group something together. And using prefix confuse me even more.

The important part here is script_execute() executing the contents of variable. AKA, very, very, VERY customizable behavior.
wait, is there a different between script_execute() and just typing out the script(like script_move())? I read it up on the manual and it doesn't seems to have any difference.
 
Last edited by a moderator:

bojack29

Member
I tend to follow normal protocal as far as resources go. Anyone who has ever downloaded on of my HDTDT tutorials woild know that I tend to prefix variables a little differently (using lower camel case). I find that without prefixes it makes understanding variables more difficult

integers - int_thisValue
boolean - b_thisValue
id pointer - id_thisPointer
object index - OI_objectIndex
font - fnt_font
script - scr_thisScript
string - str_thisString
color - col_thisColor

And so on. Makes reading code far easier as you no longer have to guess the variables intention.
 
M

Mocgames998

Guest
Usually, sprites start with spr_
My backgrounds go by bg_
Fonts could either be font_ or ft_, or something else.
Objects go by obj_
Rooms usually go by rm_, or rmX, or sometimes room_
Textures use tex_
Scripts use scr_ (Except for certain scripts like playmus or playsound, making it easier to play music in game)
Almost all of my games use a "go" variable to determine what should happen next after an object does something.
Variables generally go by things like hp, jumpspd/jumpspeed, etc.
Sometimes I go by format like spr_walk_left, obj_enemy_1, or spr_walkleft and obj_enemy1
Parents usually have _parent or Xparent added at the end.
Sometimes I do uppercase every 2nd word though, but it's formatted closer to obj_playerCamera, or something like that.
 

csanyk

Member
I was wondering, what naming convetions do you use. I know everyone has his preferences, but I wanted to hear several opinions of what worked and what didn't work for you guys in your projects.

Thank you! :)
Good question!

Having strong naming conventions is very important in GM:S. Since new variables are declared by invoking them, if you are inconsistent with your variable names, it'll make it easier to accidently type a new variable name when you meant to reference an old one, and that can lead to aggravating bugs.

I also find that if I don't name something correctly, I end up needing to refactor it later, which is annoying. What I've found works for me is:

I don't like to mix case in variable names. I give everything lowercase names, with underscores separating words. Everything, that is, except for constants, which I give names in ALL_CAPS with underscores separating words.

I prefix assets, as follows:

sprites: s_
objects: o_
fonts: f_
scripts: no prefix. I give scripts a name that meaningfully describes what the script does, in a way that makes my code read more like natural language when reading it.
backgrounds: bg_
rooms: rm_
 

SuperSlim

Member
I'm assuming that the variable is holding the id of the script and check it? Then use script_execute to run that script that the variable hold if the check return true.
Oh I think I get it now. Basically instead of calling the script every time you just call that variable.
 
L

leonfook29

Guest
Oh I think I get it now. Basically instead of calling the script every time you just call that variable.
I do believe there's more than that. From the example Zekka provided, it seems you can use that script and hold it with variable like it was a weapon(or id of a weapon, which contain the attack stats and stuff). It's basically same as using state machine to check which weapon you're holding, except you can execute it using the variable. Correct me if i'm wrong tho.
 

GMWolf

aka fel666
I think it depends on what you are doing, but lately i have been doing the following:
Sprites: spr_camelCase
Objects: CamelCase and par_camelCase (for parents)
Fonts: fnt_camelCase
Scripts: either scr_camelCase (for game specific code), camelCase (for libraries) and __snake_case__ (for internal library scripts)
Sounds: snd_camelCase
Rooms: rm_camelCase
Backgrounds: bg_camelCase
Paths: pth_camelCase (though much like kepons i dont use them)

I must mention that i am always changing the casing i use, and now that im working on an object / interfacing framework for GM, its changing again ...
 

Charyb

Member
Been using GM since it first came out.

Sprites: spr_*
Scripts: do_something, make_something, init_game (no conventions)
Sounds: snd_* (wav), mus_* (mp3, ogg)
Backgrounds: bg_*
Paths: pth_*
Shaders: shd_*
Fonts: fnt_*
Rooms: rm_*

I don't use camel case. If I want to separate two words I use an underscore _.
 

Yal

GMC Memer
GMC Elder
I do this:

something_obj
something_spr
something_rm

Where the "something" are usually grouped, like a swordguy idle sprite would be swrd_idle_spr and so on. Can't break the habit of having to group something together. And using prefix confuse me even more.


wait, is there a different between script_execute() and just typing out the script(like script_move())? I read it up on the manual and it doesn't seems to have any difference.
YES.
The idea is that if you script_execute() a variable, you can dynamically change what script is executed. Using its name will always execute the same script since you're using a constant reference to the script.
 

JimmyBG

Member
I use the *_asset-type convention similar to a few of the other posts, anyway here's mine:
Object: *_obj
Room: *_rm
Sprite: *_spr
Background: *_bg
Tileset: *_ts
Fonts: *_fnt
Path: *_pth
Sound: *_snd
Background Music: *_bgm
Generic Script - Not associated with a specific object & event: *_scr
Debug Script: *_dbscr
Object Event Script: objectname_event e.g. player_draw
Shader: *_shdr

I try to keep names to 3 letters if possible, e.g. instead of "player" I will use "plr"

I use a sort of hierarchical naming convention:
For a object that only has one type: object-name_event_asset-type
e.g. for "plr" I might have:
Sprites: plr_idle_spr, plr_walk_spr
Object: plr_obj
Object Event Scripts: plr_create, plr_step, plr_draw

If I have multiple types of an object, then I would do this: object-name_type_event_asset-type
e.g. for an "enemy"
enemy_red_idle_spr, enemy_blue_idle_spr, enemy_red_walk_spr etc...

For variables:
String: *_str
Colour: *_col
Data Structures : *_map, *_list, *_grid etc
File: *_file
Directory / File Path: *_dir / *_path
JSON: *_json - this is a string
Everything else is assumed to be a number

I use the same hierarchical convention with variables:
e.g. if want to store the width and height of a grid, I would use: grid_width & grid_height

Hope this helps, its just my way of doing things, but I've found it works well and avoids confusion about what things are.
 

RedChu

Member
My asset naming is as follows:

Sprites:
sSpriteName
Backgrounds: bgBackgroundName
Sounds: sndSoundName
Scripts: script_name (no prefix)
Fonts: fFontName
Objects: oObjectName
Rooms: rmRoomName

For variables, it fluctuates a bit. Sometimes I'll prefix based on the type of the value - sVariable for strings, iVariable for integers, bVariable for bools - but in most cases I'll just do something like variableContainsThisValue. A good example would be if I had to set a minimum and maximum value for an object's speed: I'd write the variables for those values as minMovementSpeed and maxMovementSpeed. I've actually tried shortening variable names like those to minMoveSpeed, but I naturally start finishing Move as Movement. It's quicker for me to type minMovementSpeed because I don't have to correct myself when I inevitably type Movement instead of Move. If this makes no sense to you, it does to my brain so it's all good.
 
S

sparksinfinite

Guest
While we're at useful tips, this thing blew my mind and has totally changed the way I code stuff forever.
View attachment 221
What exactly is the NONE datatype? And != would be possible too, right? Sorry, but I don't see how this code makes wonders ... I would be glad if you explain ... :)
 
Z

Zekka

Guest
You guys might get a kick out of it if you just play around with Yal's trick. The gist of the trick is that for any code that would ordinarily use one specific script, you can change it so you can replace that script with anything you want.

Code:
/// Create
state = scr_munch_bananas;
bananas = 0;
coconuts = 0;
pineapples = 0;

/// Step
if (state != undefined) {
  script_execute(state);
}

/// scr_munch_bananas()
bananas++;
if (bananas == 5) { coconuts = 0; state = scr_munch_coconuts; }

/// scr_munch_coconuts()
coconuts++;
if (coconuts == 10) { pineapples = 0; state = scr_munch_pineapples; }

/// scr_munch_pineapples()
pineapples++;
if (pineapples == 15) { bananas = 0; state = scr_munch_bananas; }
 
S

sparksinfinite

Guest
@ Zekka Thanks for this example! I was somehow distracted by that NONE, like I finally found a way to check for vars or any stuff that does not exists with one magic word ...
However, keep in mind that with this approach you cannot easily pass in arguments.

On Topic:
By the way, I use prt_ for sprites which are used as particles.
And if I am using Tiles, they are called tile_.
I mostly stick with the common prefixes (obj_, spr_, ...).
 
Z

Zekka

Guest
@ Zekka Thanks for this example! I was somehow distracted by that NONE, like I finally found a way to check for vars or any stuff that does not exists with one magic word ...
However, keep in mind that with this approach you cannot easily pass in arguments.

On Topic:
By the way, I use prt_ for sprites which are used as particles.
And if I am using Tiles, they are called tile_.
I mostly stick with the common prefixes (obj_, spr_, ...).
The remaining arguments of script_execute actually get passed to the script.

Code:
// scr_add(x, y, z)
show_message("The sum of the three numbers passed is: " + string(argument0 + argument1 + argument2));

// scr_mul(x, y, z)
show_message("The product of the three numbers passed is: " + string(argument0 * argument1 * argument2));

// test code
var act = scr_add;
script_execute(act, 2, 3, 4); // displays 9
act = scr_mul;
script_execute(act, 2, 3, 4); // displays 24
 

Yal

GMC Memer
GMC Elder
NONE is my own macro and is equal to -12341, a value that is easy to recognize in debug readouts and not equal to any of the built-in constants.
<> and != means the same, I just find <> easier to type and look more aesthetically pleasing.


EDIT:
The remaining arguments of script_execute actually get passed to the script.
Indeed they do, and script_execute() also return the script's return value.
 
D

Dlastons

Guest
Sprites: sName
Objects: Name
Fonts: fontName
Scripts: script_name (so it's similar to normal functions)
Sounds: sndName
Rooms: rName / roomName (don't even know why i'm so inconsistent)
Backgrounds: bgName
Tiles: tile## (## = number)

I don't use paths or timelines.
 
W

Wintery

Guest
If your working on something by yourself your naming convention really does not matter, so long as you can remember how you naming everything. However if you start working with someone else or with a team team naming and code conventions become very important very fast.

With the project my team is currently working on we are using shorthand prefixes underscore camelCaseName. Being as we are not all in the same room together the use of prefixes really helps us all out when we are going over new code one of us has upload for the other to review and debug. Camel Casing lets you use far more descriptive naming of objects, functions & variables with a faster & easier readability.

Last I would say try to follow the conventions of any of the major coding languages out there. We are trying to follow the conventions from C++ being as we realize that in time we will want to move beyond GM:S and most major titles are made with engines based C++. Because bad habits are hard to break once they have become your defaults.

Sprites = spr_
SoundFX = sfx_
Music = mus_
Background = bgd_
Foreground = fgd_
Scripts = scr_
Fonts = fnt_
Objects = obj_
Rooms = rm_


NOTES:
For some assets like tile sets we use suffixes like spr_desert_tSet.

We do not use Paths, Timelines or Alarms, because they are limiting in many ways. We tend to create our own, which are connected with states on the enemy objects and also use a pool prime numbers multiplied by room speed to set internal countdowns. This way helps to make they appear to more organic in their switching between idle and patrolling and also cuts down on the likelihood of tons of calls all to the same set of scripts all hitting on the same cycle/step. We are trying to have as many enemies as we can, without slowdown, be on screen and behave in what seems like normal none patterned ways... for the most part.

Variables in objects are just camel cased.

If you or anyone else would like more detailed examples please let me know and I will post them.
 
D

Drift

Guest
The important part here is script_execute() executing the contents of variable. AKA, very, very, VERY customizable behavior.
Actually, I also made use of script_execute(), until I realized that a switch was much faster, at least with the YYC; check this benchmark:

3500 - VM Runner using switch statement

5220 - VM Runner using script_execute() -> 49% gain over previous

12720 - YYC using script_execute() -> 144% gain over previous

28240 - YYC using switch statement -> 122% gain over previous

http://www.8bitwarrior.com/?p=1517


I would say, that 122% of performance gain over the script_execute() is more than enough to compensate for code organization.
 
To further the performance topic, I have done a quick test in the past with in-line vs script calls, and it seems that while there is an overhead for calling a script, it's such a negligible amount of time, that unless you litterally need to squeeze every millisecond of time off execution, it's not worth compromising modularity. Plus, YYC has the gml_pragma("inline") (or whatever it is) to automatically do this for you!

My favorite example usage of the code Yal posted is to highlight enemies. For example, you can have a base enemy object with the following code:

Create:
Code:
ai_script = noone;
Step:
Code:
if (script_exists(ai_script))
{
    execute_script(ai_script);
}
... And then with a helper script called 'enemy_create':
Code:
/// enemy_create(x, y, ai_script);

var x1 = argument[0],
    y1 = argument[1],
    scr = argument[2];

var enemy = instance_create(x1, y1, obj_enemy_base);

enemy.ai_script = scr;
... Thus, with a single enemy frame work, you could have a large number of vastly different enemies with little extra work.

... And you can of course add other things. In the few cases when I would need to pass arguments to the dynamic script, I would put them all in an array and pass that along as well. Example:

Create:
Code:
ai_script = undefined;
ai_args = undefined;
Step:
Code:
if (script_exists(ai_script))
{
    execute_script(ai_script, ai_args);
}
enemy_create:
Code:
/// enemy_create(x, y, ai_script, *ai_args);

var x1 = argument[0],
    y1 = argument[1],
    scr = argument[2],
    args = undefined;

if (argument_count >= 4)
{
    args = argument[3];
}

var enemy = instance_create(x1, y1, obj_enemy_base);

enemy.ai_script = scr;
enemy.ai_args = args;
... Then all you have to do is have the dynamic script parse the array itself. Not really much different then passing the values directly to the script. In fact, it's potentially more useful because you are no longer limited to 16 arguments. I've even in the past used index 0 to hold the script ID, thus you wouldn't need a second variable.
 

tafkatfos

Member
Sprites: sprSpriteName
Sounds: sndSoundName

Backgrounds: bgBackgroundName
Scripts: ScriptName
Shaders: shdShaderName

Fonts: fntFontName
Objects: objObjectName
Rooms: NameOfRoom
 
Last edited:

Nehemek

Member
I do

spr_sprite
obj_object
sh_shader
rm_room
font_font
tl_timeline
snd_sound
mu_sound

Probably everybody has mentioned these before but I've not seen anybody mention the shaders x).
 

Tsa05

Member
Huh, interesting topic; definitely one that comes up a lot when using the marketplace.
I use snakamel syntax, as it appears many others do!
Resources: spr_nameOfSprite, ft_font, bg_bgName, snd_sound, obj_objName, tm_timeline

Except for scripts. sticking scr in front of everything gives me a crawling of the flesh. My scripts are purely snakish, and form english sentences:
one_does_not_simply_walk_into_mordor(hobbit, ring);

My variable names strictly loosely avoid snakes. That is to say, I use snakes for global things or cross-event things: current_enum_state and such.
Otherwise, all of my variables are kept as such: slicesOfPieRemainingInTheFridge

This is partly to avoid confusion with my similarly-explicitly-named functions and partly by habit. My freshman year, our Java programming class required us to name variables with a snake--the snake's head was a scope and the body was the name:
lo_iceCreamSandwich would, for example, represent the Local Object "iceCreamSandwich."

They had good intentions, what with keeping track of scope, but I was happy to drop the head and keep the habit of slamming the whole name into a camel's body.
 
Top