1. Hello Guest! It's with a heavy heart that we must announce the removal of the Legacy GMC Archive. If you wish to save anything from it, now's the time! Please see this topic for more information.
    Dismiss Notice

Naming conventions in GameMaker

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

  1. hippyman

    hippyman Member

    Joined:
    Jun 20, 2016
    Posts:
    565
    Sprites: sSpriteName
    Sounds: snSoundName
    Objects/Rooms: ResourceName (similar to the way people tend to capitalize classes)
    Fonts: font_FontName
    Scripts: script_name() [lower cased and spaced]

    variables: variableName; [lower cased and camel cased]
    constants/macros/enums: ALLCAPS

    I've never really had a need for paths and timelines.
     
  2. Greenhawk

    Greenhawk Threatuna Agent

    Joined:
    Jun 20, 2016
    Posts:
    45
    It depends usually I do:

    Sprites: spr_blahblah
    Background: bg_water
    sound: snd_gun, mus_win, bg_title
    Fonts: fnt_font
    objects: obj_object
    rooms: rm_room

    I try to make it as distinct as possible so I don't mess up any variables and such.
     
  3. Mors

    Mors Guest

    Sprites: spr_player
    Sounds: snd_coin
    Backgrounds: bgr_hills
    Tilesets: bgr_tileset_cave
    Paths: I never use paths
    Scripts: Sometimes stuff like scr_player_main, sometimes stuff like player_jump
    Fonts: fnt_menu
    Timelines: I also never use timelines because I'm an idiot.
    Shaders: shd_bloom
    Objects: obj_player
    Rooms: Mostly rm_menu
     
    iTzCallumUK likes this.
  4. CoderJoe

    CoderJoe Member

    Joined:
    Jun 22, 2016
    Posts:
    166
    I use camel case like most people. For naming resources I use lowercase letters like so:
    sSpriteName
    oObjectName
    scrScriptName
    bgBackgroundName

    Makes it easy to tell what type it is in the code as I use a lot of similar names (eg. sPlayer, oPlayer)
     
  5. Zek

    Zek Member

    Joined:
    Jun 20, 2016
    Posts:
    74
    I do it like this:

    Sprites: spr_name
    Sounds: snd_name
    Backgrounds: bg_name
    Paths: pth_name
    Scripts: I never use prefixs for scripts
    Shaders: shd_name
    Fonts: fnt_name
    Time Lines: tl_name
    Objects: obj_name
    Rooms: rm_name
    Macros: No prefix, but captial letters.
    Variables: can_shoot
     
    iTzCallumUK likes this.
  6. iTzCallumUK

    iTzCallumUK Member

    Joined:
    Jun 20, 2016
    Posts:
    139
    I do it like this;

    Sprites: spr_nameNameName
    Sounds: snd_nameNameName
    Backgrounds: bg_nameNameName
    Paths: path_nameNameName
    Scripts: scr_nameNameName
    Shaders: sha_nameNameName
    Fonts: ft_nameNameName
    Time Lines: tl_nameNameName
    Objects: obj_nameNameName
    Rooms: rm_nameNameName
    Macros: NAME

    I pretty much just abbreviate what the type is and then the first word is lowercase and then after that, only the first letter the UPPERCASE.
    i.e. a script that I was to name "My name is Callum" would be called "scr_myNameIsCallum"


    But thats just me :p
     
  7. NeoShade

    NeoShade Member

    Joined:
    Jun 21, 2016
    Posts:
    166
    Sp_SpriteName
    Sn_SoundName
    Bk_BackgroundName
    Ts_TilesetName
    Sh_ShaderName
    Fn_FontName
    Ob_ObjectName
    Rm_RoomName
    name_of_script

    I've never had cause to use timelines or paths, so haven't allocated anything for those, though I guess I'd just prefix them with Tl and Pa respectively.
    I stick with 2 characters rather than three because it bothers me when I have a long recourse or variable name as an argument to a script or function.

    I try to write my scripts in such a way that they 'feel' (at least to me) as though they are standard GameMaker functions and name them as such.
    I'm also a bit bit different in that I use UpperCamelCase and an uppercase prefix for all of my resources.

    Finally, the first thing I usually do in a project is create a persistent object called "g". The object does nothing, but is the container for everything which would otherwise be a global variable. Again, this is simply a way of shortening my code a little bit.
     
  8. NightFrost

    NightFrost Member

    Joined:
    Jun 24, 2016
    Posts:
    2,008
    Like most responders here seem to do, I prefix my resources with two or three letters (like obj_UniqueNameHere) and camelcase my variables. Except I start even the first CamelCased word with a capital letter.

    As for other conventions, I follow stricter coding habits I've brought in from other languages, like properly parenthesing ifs and others (not mandatory in GML), ending lines with a semicolon (not mandatory in GML either) and putting curly braces on the same line as commands that open them. And of course I comment my code.
     
    ParodyKnaveBob likes this.
  9. Bart

    Bart Member

    Joined:
    Jun 21, 2016
    Posts:
    195
    Interesting topic. I always use underscores and prefixes for GM's built-in resource types:

    * spr_sprite
    * bck_back
    * pth_path
    * sha_shader
    * tml_timeline
    * snd_sound
    * rom_room

    I don't prefix scripts with scr_, I either don't use one or use a prefix to group a collection of scripts, like GM does more or less.
    The other things I usually prefix are data structures, surfaces and particles, e.g. map_, lst_, sf_, ps_, pt_, em_, ...

    In simple cases, i.e. for temporary variables and where the meaning is clear, I mostly use several short and simple variable names:
    var i, var n, var t, var count, var cnt, var fix, var ins, var buf, var tex, ...
     
  10. David Batty

    David Batty Member

    Joined:
    Jun 20, 2016
    Posts:
    8
    I always use PascalCase along with the standard Spr Obj Snd prefix.
     
    Lukan likes this.
  11. KurtBlissZ

    KurtBlissZ Member

    Joined:
    Jun 21, 2016
    Posts:
    200
    For my naming convection, I name them in a way so I can easily find it in the tool tips, like if I typed obj_ would list all of your object for you and for an idiot proof way of preventing naming conflicts.

    I also like my variables not triggering tool-tips to come up with a list of functions like a variable named inst, would bring up every built in function relating instance. There's been times that I have accidentally clicked on the tool tips and renamed my variable to a function name.

    I also use the upper camel case for all of my resourses and a lowercase previx for all of my varibles to avoid conflicts with game make's built in functions or constants, along with everything else I named.

    Sprite's
    Spr or Sprtex (For a sprite that's a texture)
    Sound's Sfx or Bgm
    Backgrounds Bac or Tile (for tile sets) or Tex (For a background that's a texture)
    Scripts Scr or Eve (For a script in place for an object's event) or sometimes more previxes for certain things.
    Objects Obj
    Rooms Rm

    Constants are all capitals with a previx for each one
    MENU_START = 0
    MENU_OPTIONS = 1
    MENU_GAME_END = 2
    DIR_RIGHT = 0
    DIR_LEFT = 180

    For global varibles

    global.gHealth = 100;

    For normal varibles (lower case L previx)

    lHealth = 100;

    For local varibles (lower case V previx)

    var vInst = instance_create;

    Then in the resource tree I like using groups for all my events scripts for each object, This is what my scripts look like

    _ReadMe
    ObjEnemy (Groupd)
    ---EveEnemyDraw
    ---EveEnemyInit
    ---EveEnemyStep
    ObjPlayer (Group)
    ---EvePlayerDraw
    ---EvePlayerInit
    ---EvePlayerStep

    I also right click every directory and pick sort by name. I use an underscore in the _ReadMe script to make it first when I sort.

    In my _ReadMe script I just use it to store comments, I will give an overview of the engine giving the names of resources. You can also middle click a commented resource name to edit it, or click it then press F12 to edit it.

    I actually haven't used this yet, but I been putting a lot of thought to into it as you can tell. :p
     
    Last edited: Aug 16, 2016
  12. Bentley

    Bentley Member

    Joined:
    Jun 18, 2017
    Posts:
    823
    Edit: question answered by your earlier post, nm.
     
  13. Fixer90

    Fixer90 Member

    Joined:
    Nov 17, 2016
    Posts:
    145
    Spites = spr_name
    Sounds = snd_name
    Backgrounds = bg_name
    Scripts = scr_name
    Fonts = fnt_name
    Objects = obj_name
    Rooms = rm_name

    I'm not sure what to use for paths, shaders, or timelines. If anyone has a good idea that would be consistent to my current prefix system, be sure to reply and share sed opinion.
     
  14. Kululu17

    Kululu17 Member

    Joined:
    Jun 25, 2016
    Posts:
    178
    I start with an uppercase two or three letter prefix like:

    OBJ_
    SPR_

    etc.

    Why? It helps with autocomplete.

    This way it will try to autocomplete with the right type of name. If you use lower case, and start typing spr...., then it might start giving you something like sprite_index() or the like. By using upper case you differentiate it from the built-in functions and names. Using prefix rather than suffix can also be a big help, depending on how you are organized, so once you have SPR_ it will start giving you a list of your sprites (which wouldn't work if you use suffixes) - then you could have objects, scripts, or anything else come up.

    The second part of the name I try to relate to a category that is important to my project. For example if I have a lot of monster spites, it would be SPR_ Mon_Zombie, so that once you hit SPR_M... it would come up with all your monster sprites.
     
  15. Lukan

    Lukan Gay Wizard Freak

    Joined:
    Jun 20, 2016
    Posts:
    397
    I name almost everything using the standard prefix+name.
    sprSpriteName
    rmRoomName
    and the like.
    However, my scripts are wildly unorganised most of the time.
    They never have a prefix, and are just named whatever I need them for.
     
  16. Thunder Lion

    Thunder Lion Guest

    I've adapted over the years, this is my usual:
    Sprites spr_name_purposeXX
    Backgrounds/Tiles
    bg_name_detailXX
    tile_name_detailXX
    script_name_detailXX
    Etc.
    The purpose or detail tells me the general point like enemy, control, hud and XX represents others like it but their number to keep them named together. In rare cases for very important resources I will use the prefix then a _0_name this would keep it at the top end of the list. For things look similiar, I use all CAPS at the detail end to make it popout.
    Sounds and music :
    Snd_ and music_,
    For rooms I use rm_
    For constants I create, I use cc_NAME_detail
     
  17. ThinPixels

    ThinPixels Guest

    I use a similar system to most, but I do it a little different so that intellisense doesn't show results for anything but my own resources. For example, if I use the naming scheme (obj_example), and then I get to typing (obj), I'll get results for all object functions such as (object_get_visible), as well as results for all my object resources. I understand that is the intent of intellisense, and some may prefer it that way. I don't prefer it that way, so I tend to start with capitals. The following shows how I name my resources, enumerations, macros, instance variables, and local variables within some code taken from a game of mine.

    Resources
    • Fn_ExampleFont
    • Ob_ExampleObject
    • Ob_ExamplePath
    • Rm_ExampleScript
    • Sc_ExampleScript
    • Sh_ExampleShader
    • Sn_ExampleSound
    • Sp_ExampleSprite
    • Tm_ExampleTimeline
    Enumerations
    Code:
    enum INPUT
    {
        UP, DOWN, LEFT, RIGHT, MENU, JUMP, INTERACT, COUNT,
    }
    
    // Example ...
    if (Sc_Input_CheckPressed( INPUT.UP ))
    {
        // Do something cool!
    }
    Macros / Constants
    Code:
    #macro EXAMPLE_MACRO 0
    #macro NONE -1
    #macro NULL ""
    Instance Variables
    Code:
    WindowCaption = "Untitled Window";
    WindowCenter = true;
    WindowWidth = 512;
    WindowHeight = 384;
    WindowSurface = NONE;
    Local Variables
    Code:
    // Draw the window's surface.
    var lSurfaceX = x;
    var lSurfaceY = y;
    
    if (WindowCenter)
    {
        lSurfaceX = (display_get_gui_width() * 0.5) - (WindowWidth * 0.5);
        lSurfaceY = (display_get_gui_height() * 0.5) - (WindowHeight * 0.5);
    }
    
    draw_surface(WindowSurface, lSurfaceX, lSurfaceY);

     
    Last edited by a moderator: Jan 24, 2018
  18. Yal

    Yal GMC Memer GMC Elder

    Joined:
    Jun 20, 2016
    Posts:
    3,930
    No. Just no. Scripts don't have prefixes because you want to call them all the time in your code. They should just have a name that describes what they do (init_character_vars, collision_sprite, eneai_patrolman, etc). If you're using prefixes for scripts, they should be there for other reasons, e.g. group together all AI scripts or all scripts belonging to a certain subsystem. (Aka compensating for GM's lack of scoping)

    ...that's just my opinion, though.
     
    Bentley likes this.
  19. Fixer90

    Fixer90 Member

    Joined:
    Nov 17, 2016
    Posts:
    145
    I use often scripts to do custom game-specific functions, but I guess it'd be a good idea to de-prefix some of the more universal ones.
     
  20. JackTurbo

    JackTurbo Member

    Joined:
    Oct 19, 2016
    Posts:
    827
    • Sprites: sSpriteName
    • Objects: oObjectName
    • Sounds: sndSoundName
    • Backgrounds: bgBackgroundName
    • Tilesets: tlTileName
    • Paths: Never used paths from the resource tree before
    • Scripts: what_it_does_as_its_name_with_underscores_between_the_words_but_usually_not_quite_this_long
    • Fonts: fFontName
    • Timelines: NA never used them
    • Rooms: rmRoomName
    • Variables: somethingDescriptive
    • local variables: _somethingShortYetDescriptive (underscore is so I know its throw away).
    • Macros: BLOCK_CAPS_WITH_UNDERSCORES
    I dunno... It might not be the most coherent set of conventions, but they work for me.
     
    Lukan and Yal like this.
  21. Dr. Wolf

    Dr. Wolf Member

    Joined:
    Jan 17, 2017
    Posts:
    72
    For spacing, I'll generally use snake_case, with some slight condensation, e.g. "global.wttf_current_kernmap" in place of "global.wttf_current_kern_map". There's a pattern to it-- it's predictable(ish) to me-- but not one I could put into words.

    Asset prefixes:
    • Sprites: spr_
    • Regular sounds: Either snd_ or sfx_ (consistent within the project, but, sometimes I'll use one, and sometimes the other)
    • Sounds used as music: mus_
    • Regular backgrounds: bck_
    • Backgrounds used as textures: tex_
    • Paths: path_ (rarely used)
    • Scripts: (no prefix)
    • Shaders: Either s_ or shd_ (consistent within the project, but, sometimes I'll use one, and sometimes the other)
    • Fonts: fnt_ if there are a lot of different types; no prefix if there are only one or two. Suffixed with size and formatting (bold, italic)
    • Timelines: tl_
    • Regular objects: obj_
    • Upper-level parent objects: par_
    • Objects that exist only to be used as labels for collision events that will be used exclusively through event_perform and/or event_perform_object: mtd_ (with a different icon depending on whether it's meant to be performed by the object that owns it or by another object)
    • Objects used exclusively to add nouns to my text parser: n_
    • Objects used to add verbs to my text parser: v_
    • Objects used to mark special words for the text parser: (no prefix).
    • Rooms: rm_
    • Included files: (I don't bother with a prefix for these)
    • Extension function names: ext_ (followed by the name of the actual function in the .dll)
    • Macros: (no prefix, but these are always in all caps, with relatively long names based on the expected context of usage)
    For variable names, I don't use any particular prefix, nor any conventions to represent scope.
     
  22. Rob

    Rob Member

    Joined:
    Jul 12, 2016
    Posts:
    710
    I didn't see these listed so far so I'll add my own:

    • ds_ (data structure)
    • a_ (local array)
    • ga_ (global array)
    • g_ (global variable)
    Apart from this I use the popular obj_/spr_/snd_/fnt_ etc

    I also started to capitalize any constants like GRID_SIZE, BUFFER etc
     
    Bentley likes this.
  23. abianche

    abianche Member

    Joined:
    Mar 18, 2018
    Posts:
    5
    Besides the amount of letters (e.g. "s" or "spr" or "sprite"), and besides using Underscore or CamelCase ("this_is_my_name", or "ThisIsMyName"), I believe naming conventions here, granted that you want to express the asset type in the name (you should), comes down to whether using a prefix or a suffix for its resource type.

    Recently, I've been writing down a "Code Convention" document with my team, and we got some discussion going on about asset naming conventions. Mainly, the arguments were the following:

    Prefix
    • code completion when writing, e.g.: spr_* lists all sprites; spr_player* lists all player's sprites
    • pretty much the whole community is using prefixing, code sharing might be easier to understand for a bigger audience
    • on bigger projects, code completion that groups all sprites together might lead to confusion (spr_* might produce a list of 50 sprites, where really just 5 are relevant)
    • it's easier to "swap" asset, as you would just remove rename e.g: snd_rocket to snd_bigrocket (maybe)

    Suffix
    • code completion is categorized by the "context" (or object), e.g.: player_attack_* lists all the relevant assets for the player attack action, be it a sprite, a shader or a sound effect.
    • in order to work properly, assets "must" share the same context "prefix", e.g.: player_dash_(spr, snd, shd, ...)
    • resembles the way how the filesystem are also categorizing file types with extensions: you don't have a "pdf.manifest", but a "manifest.pdf" file (for a good reason I believe)

    (Note: I originally categorized the list with PROs and CONS, but this didn't really fit as often times they would conflict based on personal preferences).

    I would really like to have a feedback from some experienced GM developers here, especially how asset naming conventions plays a role while developing in team (and/or big projects) - or if it does play a role at all actually!
    Most likely we'll end by deciding as time goes, but would be awesome to receive some feedback from you all!

    (on a personal note, I'm more towards suffixing :D)
     
  24. iCouch

    iCouch Member

    Joined:
    Apr 21, 2018
    Posts:
    1
    • Sprites: spr_
    • Tilesets: tls_
    • Sounds: snd_
    • Music: mus_
    • Paths: pth_
    • Scripts: No prefix, usually
    • Shaders: shd_
    • Fonts: fnt_
    • Timelines: tml_
    • Objects: obj_
    • Parents: par_
    • Rooms: rm_
    Code:
    // Variables
    variable_name = 0;
    
    // Macros
    #macro macro_name "Hello, world!"
    
    // Enums
    enum enum_name {
        enum_value_one,
        enum_value_two
    }
    
     
    Last edited: Aug 31, 2018

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