Naming conventions in GameMaker

Discussion in 'Programming' started by The Bard, Jun 20, 2016.

  1. The Bard

    The Bard Member

    Jun 20, 2016
    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:

    for variables:

    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! :)
    frog and ParodyKnaveBob like this.
  2. MonikerHart

    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.
    KurtBlissZ and ThunkGames like this.
  3. SuperSlim

    SuperSlim Member

    Jun 20, 2016
    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.
  4. Yal

    Yal GMC Memer GMC Elder

    Jun 20, 2016
    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)
    Neptune, Pyxus, Bentley and 6 others like this.
  5. MonikerHart

    MonikerHart Guest

    I find snakecasing ugly as heck ^_^

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

    Yal GMC Memer GMC Elder

    Jun 20, 2016
    While we're at useful tips, this thing blew my mind and has totally changed the way I code stuff forever.
    Kuro and ParodyKnaveBob like this.
  7. 2Create

    2Create Member

    Jun 20, 2016
    For sprites, backgrounds, objects and paths I use the following:
    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.
    DaMuffin likes this.
  8. Yal

    Yal GMC Memer GMC Elder

    Jun 20, 2016
    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.
    iTzCallumUK likes this.
  9. Nexusrex

    Nexusrex Nexusrex Games

    Jun 20, 2016
    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
  10. 2Create

    2Create Member

    Jun 20, 2016
    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.
  11. Zekka

    Zekka Guest

    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.)
    ParodyKnaveBob and ThunkGames like this.
  12. Snail Man

    Snail Man Member

    Jun 20, 2016
    Here's what I use

    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.
  13. seanm

    seanm Member

    Jun 20, 2016
    I just do some kind of camel case for most of my stuff,


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

    I mostly just hate typing _ which is why I never use it in names lol
  14. True Valhalla

    True Valhalla Full-Time Developer GMC Elder

    Jun 20, 2016
    I name my assets like this:


    I rarely use paths or timelines, hence the longer prefix. And for scripts, I'll just write the name of the function without any specific prefix.
    Last edited: Jun 26, 2016
  15. Coded Games

    Coded Games Member

    Jun 20, 2016
    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.
    Bentley and atxgamedesigner like this.
  16. True Valhalla

    True Valhalla Full-Time Developer GMC Elder

    Jun 20, 2016
    Pretty similar! The main difference is that I never use CamelCase.
  17. faissaloo

    faissaloo Guest

    Underscore spaces:
    Sprites: *_spr
    Objects: *_obj
    Fonts: *_fnt
    Scripts: *
    Sounds: *_snd
    Rooms: *_rm
    Backgrounds: _bg
    Tile Sheets: _tile
    Paths: *_path
  18. Aleksandar Gavrilovic

    Aleksandar Gavrilovic Member

    Jun 20, 2016
    I use different prefixes for different variable types:

    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 :)
    Bentley and ParodyKnaveBob like this.
  19. Kepons

    Kepons Lost The Bet

    Jun 20, 2016
    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.
    Bentley, Bingdom, Jett and 3 others like this.
  20. RangerX

    RangerX Member

    Jun 20, 2016
    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....
    SuperSlim likes this.
  21. Bluetail7

    Bluetail7 Member

    Jun 20, 2016
    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
  22. Yal

    Yal GMC Memer GMC Elder

    Jun 20, 2016
    The important part here is script_execute() executing the contents of variable. AKA, very, very, VERY customizable behavior.
  23. Zekka

    Zekka Guest

    (where `variable` is the id of any script defined in your game)

    I wrote up a little more on this technique for this topic: someone's weapon system.
  24. stainedofmind

    stainedofmind Member

    Jun 20, 2016
    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.
  25. leonfook29

    leonfook29 Guest

    I do this:


    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.
    Last edited by a moderator: Jun 21, 2016
    JimmyBG likes this.
  26. NazGhuL

    NazGhuL NazTaiL

    Jun 20, 2016
    Bentley likes this.
  27. bojack29

    bojack29 Member

    Jun 21, 2016
    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.
  28. Mocgames998

    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.
  29. SuperSlim

    SuperSlim Member

    Jun 20, 2016
    Yeah I'm lost too...
  30. csanyk

    csanyk Member

    Jun 20, 2016
    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_
    Bentley and ParodyKnaveBob like this.
  31. leonfook29

    leonfook29 Guest

    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.
    SuperSlim likes this.
  32. SuperSlim

    SuperSlim Member

    Jun 20, 2016
    Oh I think I get it now. Basically instead of calling the script every time you just call that variable.
  33. leonfook29

    leonfook29 Guest

    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.
    SuperSlim likes this.
  34. GMWolf

    GMWolf aka fel666

    Jun 21, 2016
    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 ...
  35. Charyb

    Charyb Member

    Jun 21, 2016
    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 _.
  36. Yal

    Yal GMC Memer GMC Elder

    Jun 20, 2016
    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.
    ParodyKnaveBob and leonfook29 like this.
  37. JimmyBG

    JimmyBG Member

    Jun 22, 2016
    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.
  38. RedChu

    RedChu Member

    Jun 21, 2016
    My asset naming is as follows:

    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.
    vicdotexe likes this.
  39. 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 ... :)
  40. Zekka

    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.

    /// Create
    state = scr_munch_bananas;
    bananas = 0;
    coconuts = 0;
    pineapples = 0;
    /// Step
    if (state != undefined) {
    /// scr_munch_bananas()
    if (bananas == 5) { coconuts = 0; state = scr_munch_coconuts; }
    /// scr_munch_coconuts()
    if (coconuts == 10) { pineapples = 0; state = scr_munch_pineapples; }
    /// scr_munch_pineapples()
    if (pineapples == 15) { bananas = 0; state = scr_munch_bananas; }
  41. @ 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_, ...).
  42. Zekka

    Zekka Guest

    The remaining arguments of script_execute actually get passed to the script.

    // 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
    ParodyKnaveBob likes this.
  43. Yal

    Yal GMC Memer GMC Elder

    Jun 20, 2016
    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.

    Indeed they do, and script_execute() also return the script's return value.
    ParodyKnaveBob and JimmyBG like this.
  44. Dlastons

    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.
  45. Wintery

    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_

    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.
  46. Drift

    Drift Guest

    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

    I would say, that 122% of performance gain over the script_execute() is more than enough to compensate for code organization.
    ThunkGames likes this.
  47. stainedofmind

    stainedofmind Member

    Jun 20, 2016
    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:

    ai_script = noone;
    if (script_exists(ai_script))
    ... And then with a helper script called 'enemy_create':
    /// 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:

    ai_script = undefined;
    ai_args = undefined;
    if (script_exists(ai_script))
        execute_script(ai_script, ai_args);
    /// 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.
  48. tafkatfos

    tafkatfos Member

    Jun 20, 2016
    Sprites: sprSpriteName
    Sounds: sndSoundName

    Backgrounds: bgBackgroundName
    Scripts: ScriptName
    Shaders: shdShaderName

    Fonts: fntFontName
    Objects: objObjectName
    Rooms: NameOfRoom
    Last edited: Jun 22, 2016
  49. Nehemek

    Nehemek Member

    Jun 20, 2016
    I do


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

    Tsa05 Member

    Jun 21, 2016
    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.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice