Coding style.

So, I dont really have a problem, just a question. I'm kinda new to game maker, I just started like 4 months ago, but I feel like I have a bad coding style, or that I act way to much like a huge noob sometimes, I do realize I am new but is being considered good at gamemaker writing all this code in one script like, and I literally just took this out of one of yoyogames blogs

// @function Textfield(string:name, real:x, real:y, string:value)
function Textfield(_name, _x, _y, _value) : GUIElement() constructor {

// passed-in vars
name = _name;
x = _x;
y = _y;

/// @function set(string:str)
static set = function(str) {

// value hasn't changed; quit
if (value == str) return;

value = str;

show_debug_message("You set the Textfield named `" + string(name) + "` to the value `" + string(value) + "`");

}

/// @function click()
static click = function() {
set_focus();
keyboard_string = get();
}

/// @function listen()
static listen = function() {
set(keyboard_string);
if (keyboard_check_pressed(vk_enter)) remove_focus();
}

/// @function draw()
static draw = function() {

draw_set_alpha(has_focus() ? 1 : 0.5);

// bounding box
draw_rectangle(x, y, x + width, y + height, true);

// draw input text
draw_text(x + padding, y + (height * 0.5), get());

draw_set_alpha(1);

}
// set value
set(_value);
}

and now what all of this means?! is that the level I should be able to code at by now? I do realize that everybody learns at a slow pace, but I tried studying the manual and everything but I still only write with and if statements for the most part, and thats it. I know this is kinda an odd question, but if anyone could reassure me I would greatly appreciate it.
 

kpenrose92

Member
As someone who is self-taught and only a few years into coding, this is what I constantly ask myself:

1. Can I make what I want to make?
2. Does it work?
3. Can I make more stuff without breaking what I've already made?

Any time I run into trouble with one of these questions, I hit google and the manual until I figure out what the problem was.

Don't worry about coding style in the beginning. Just focus on making your visions a reality above all else. Soon enough you will encounter all the ways to do things better, faster, and stronger. Those will always exist. But you need a base level knowledge of coding engrained deep in your system if you want to get anywhere. That starts with getting to know yourself, your IDE, and your computer. The only way to get to know these things is deep, meaningful practice.
 

Mr Magnus

Viking King
This isn't a race. It's a marathon in which the only contestant is yourself. There is nobody that's watching you nor giving you a grade, certainly not here in the GMC.

Just pick a pace that suits you and learn according to that. Maybe that's slower than average, maybe it's faster, but it definitely doesn't matter as long as you're still learning something. I've been doing this for years and I write code for a living and I still get the sense everyone else is much better than me despite the degree hanging on my wall and a paycheck arriving monthly saying that I probably am doing just fine.

You'll get "there" eventually, wherever "there" is in your head. It may take a long time, but it'll happen if you just keep at it. Don't be afraid to try new things or push the limit of what you know you can do and see if you can't figure out the problems that pop up along the way using the manual and that squishy tofu in your noggin.
 
Last edited:

kburkhart84

Firehammer Games
One thing to note about this specific script they have there...it actually is made up of a few different functions. Previously you couldn't put multiple functions in the same file, but with 2.3 now you can. The only glitch to that is it makes things a little harder to understand for newer coders. Just so you can learn what's going on(if you are analyzing that code for example), I'd figure out where functions start and stop(you can use brackets to help figure it out), and then put some kind of divider. This may help you better break the code down.
Code:
//..............................................................
All code is simply bits and pieces stuck together. If you break it down into those pieces, its easier to learn. This applies not only to code, but to ALL things related to game development(and many other areas of life as well).

I don't know where you are in your learning journey, so I can't try to tell you where you should be. But I CAN tell you that if you don't understand it now, if you keep at it, you will eventually. I highly recommend you check tutorials and stuff out. But I also recommend you do not copy/paste code at this stage. One, you are better off typing it out for the muscle memory. Two, it gives you a little more time and is easier to analyze and learn what is actually happening if you type it out. And 3. If you still don't understand after typing it, you have more a grasp than if you simply copy/pasted it. Sometimes you won't get some code right away, but you can move on if it is working, and come back with some more experience and learn.

And no, there is nothing wrong with using someone else's code even if you don't understand exactly how it works. But it is much easier to actually integrate things into your project if you have a good amount of basic coding experience.
 

erayzesen

Member
I agree with other friends. You have to determine how you write according to your working system. It depends on what you do.

But I recommend that you familiarize yourself with programming patterns to help you a little more while determining this.

There is a site that I find useful as follows;

For example, the state machine pattern is one of the most used in game maker. On the other hand, with the main oop features that come with v2.3, there is no pattern that you cannot implement.

Another recommendation to you is that although there are some nice features that come with v2.3, I recommend using the built-in methods, I have tested this a lot and if your operations have a method built into gms, don't hesitate to use it.

For example, you have your own vec2 named object, so you will want to write special methods for it. but for example, a dot_product method you write will run slower than gms' built-in dot_product method. I have tried this and found it incredibly useful in multiple operations. Of course, these are a bit related to optimization.
 

Pixel-Team

Master of Pixel-Fu
Form follows function. Get the thing to work. Once that is there, you can clean up the code. The more you do this stuff, the better you'll get. And putting those comments over your code is for you to go back later and make heads or tails of what you wrote, so don't forget to do that, or you'll forget how you did things. Good luck!
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Moderator
As someone that has taken a lot of abuse over the years for my coding style* all I have to say is this... If your code is only for you, then the ONLY important thing you need to maintain is a consistent style. You can do what you want with braces and semi-colons and structure, as long as you do it all the time for everything. Why? Because consistently styled code is easy to read code, and easy to read code is easy to debug code. HOWEVER, if you are working with more than one person in a team, then you will need to ensure that everyone on the team uses the same style (for the same reasons outlined above), and that may mean you have to adapt or change your own personal styling to suit that of the rest of the tream.

So, tl;dr; consistent, readable style is more important than the actual style itself. :)



*I wrote the current GM manual and it uses Whitesmiths and everyone seems to hate on it though I've never understood why. I find it very clean and easy to follow and it was an ideal choice for the manual for those reasons, since it's blocked in such a way that beginners can follow it better IMHO.
 

EvanSki

Raccoon Jam Host
I used to always code like this
GML:
if (bob_has_the_big_sad)
{
    instance_Destroy(bob);
}
else
{
    with(bob)
    {
        the_big_sad = true;
    }
}
with GMS 2.3.1 and the fact im now currently using C++, im slowly transitioning to
GML:
var bob_x = bob.x;
var bob_y = bob.y;

if (bob_is_happy){
    with(bobs_gf){
        instance_destroy();
    }
}else{
    if !instance_exists(Bees){
        instance_create(bob_x,bob_y,bob_depth,Bees);
    }
}
 

Mr Magnus

Viking King
*I wrote the current GM manual and it uses Whitesmiths and everyone seems to hate on it though I've never understood why. I find it very clean and easy to follow and it was an ideal choice for the manual for those reasons, since it's blocked in such a way that beginners can follow it better IMHO.
If it makes you feel better Nocturne I preferred Allman/Whitesmiths too because of the fact the Game Maker manual used it when I was first learning to program way back in the day, and I think it is a very clean style. However it was very quickly beaten out of me when I started university programming. The automatic solution checker used in Programming 1 yelled at us in big red letters if we didn't follow the specified indentation style. The intention was naturally to get beginners to learn *any* style as it is good practice, but it didn't account for students who already knew programming with a different style.

I've never moved back because it's just going to be distracting having one style at home and one style at work, but I still like Whitesmiths even if it is from afar.
 

Stoic

Member
Hello!

I have been using GMS2 for ~3.5 years on and off. I had very limited Java experience from my Runescape Private Server days, but found myself having to relearn everything I thought I knew about coding.

My advice is really to pick a passion project concept. Concept is the key word here, it's best not to fully flesh out a game idea when you're new as your game - and your experience will evolve *dramatically*.

For me, this came in the form of a top down, arcade style space shooter. I got started with a few youtube videos, and found myself quickly learning how to solve problems on my own.

You will add new content, break the game, fix it, and learn as you go. As for the style of your coding, that too will sort of come as you gain experience. However, try to stick with one style once you begin.

If op_has_read_this
{
draw_text(x, y, "This is how I like my curly bracers personally!");
}

Don't be afraid to scrap a project! They are learning experiences.

I worked on my first project on and off for several years, and a few months ago I totally scrapped it and started fresh.

It's essentially the same, but with much cleaner and more modular code.

Best of luck to you, and the GMC is always here to help!
 
Probably a silly question, but does GMS2 have an auto-formatter for the code editor? Once you've copy/pasted the code in, select all, ctrl+shift+F, and it's all nicely formatted. (with a configurable coding convention, of course)
 

FoxyOfJungle

Kazan Games
it uses Whitesmiths and everyone seems to hate on it though I've never understood why
Now that you mention it, I never noticed it, although I always end up reformatting the code (If I copy some code from the manual, like when I was learning to use layers). I don't hate this style, until it's easy to understand, but I still think it's better to do it the way @EvanSki does (my opinion) in the first example, because it's more readable, so it makes things easier.
 

curato

Member
I am not going to try to force an indention style on anyone, but the number 1 mistake I see people make is not having self documenting code. always pick descriptive variable names and use lots of comments. I there is no way to understate the value of coming back to a piece of code months or years later and understanding exactly what you did and what you were thinking.
 
Last edited:

Micah_DS

Member
I am not going to try to force an indention style on anyone, but the number 1 mistake I see people make is not having self documenting code. always pick descriptive variable names and use lots of comments. I there is no way to understate the value of coming back to a piece of months or years later and understanding exactly what you did and what you were thinking.
I agree and disagree. Descriptive names, yes, lots of comments, no.

Well-named variables and other general clean code practices should lead to mostly uncommented code. If your code needs lots of comments, it's very likely that the code is bad and is in need of refactoring.
Even when leaving a project sitting for a long time then coming back to it after forgetting how it all worked, I've found that good clean code with few comments makes for a quicker and less confusing refresh than a heavily commented project does.

Reasonings:
  • More often than not, comments clutter, making code less readable and slower to understand.
  • Writing comments and updating them to keep up with code refactors means slower coding at best. At worst, it can clutter a project to the point of hurting your very soul, ultimately causing you to drop a project, due to all the fluff you have to manage.
  • If your code tells the story, and you change the code, the story is automatically updated, since the code is also 'the comment'.
    On the other hand, if your code is given clarity by an accompanying comment, then you change the code but forget to update your comment, your code and comment may tell a conflicting or broken story, and now the comment does the opposite of what you wanted, creating confusion, not clarity.
    Thus, it's more work and can lead to more errors.
Just my opinion and experience, of course, though I picked up on a lot of this after reading Clean Code, by Robert c. Martin, so if someone wanted a more reputable source than me, that's a very good place to look for learning great coding practices.
 

EvanSki

Raccoon Jam Host
I agree and disagree. Descriptive names
always pick descriptive variable names
Lets look at my first ever project/time with game maker
GML:
  if (global.life > 0)
I have no idea what gt is

I had other stuff too but I cant seem to find where I used them like
Code:
if a = 1
if b = hgmt
I have no idea what any of those mean

now adays I use long variable names
Code:
if (bob_happiness_meter_level == 99)

if (karen_max_anger)

if (global.main_game_state_current_gamemode_easy)
 

kburkhart84

Firehammer Games
I prefer the Allman style of coding. I also came from the C world, so I don't generally like snake_case for things either. Of course I'm stuck with it for internal functions to GML, but anything I make is generally done nonSnakeCase style(I forget what that's called). In my input extension, I actually coded it my way, but every function has a snake_case counterpart just so it is more gml friendly, as I know many people prefer that style.

As far as reading others' code, as long as its consistent, its not an issue. I have my style preference, but it doesn't stop me from reading code in other styles, so each person should do whatever style they prefer, and do it consistently.

About variable names, comments, etc... I don't comment every single line. I've been using region headers to comment sections in longer scripts, and regular comments to document small bits of code(like one comment for the part that handles the ship thrusting, another for the turning, and similar). And my variable names are typically quite long as well, as descriptive names are great. Its much easier to get the autocomplete working and filtering correctly with good long names, and you need next to no comments in the actual code if this is the case as well. It also applies to method and function names.
 

FoxyOfJungle

Kazan Games
Currently, when the game is compiled, all comments are removed from the final code. So abuse comments! (but not so much, so as not to make the code too oversaturated).

I usually use comments like this:
GML:
/*--------------------------------------
Brief explanation of something important
--------------------------------------*/

// comment 1
if (bob_has_the_big_sad)
{
    // comment 2
    instance_Destroy(bob);
}
else
{
    // comment 3
    with(bob)
    {
        the_big_sad = true; //comment 4
        the_sad_big = true; //comment 5
        big_the_sad = true; //comment 6
    }
}
 
Currently, when the game is compiled, all comments are removed from the final code. So abuse comments! (but not so much, so as not to make the code too oversaturated).

I usually use comments like this:
[snip]
Don't abuse comments. @Micah_DS said it way better in his comment than I ever could. One thing I would like to add is that comments should describe the why, not the what. Your code as written will do the latter just fine, but it cannot do the former. An example of good vs. bad comments:
GML:
// --- LCD shader ---
var _shd = shdLCD; // Set a temporary variable to the shader

// Uniforms
lcd_uTextureSize = shader_get_uniform(_shd, "TextureSize");                 // Set TextureSize uniform
lcd_uColorSeparation = shader_get_uniform(_shd, "ColorSeparation");         // Set ColorSeparation uniform
lcd_uScanlineBrightness = shader_get_uniform(_shd, "ScanlineBrightness");   // Set ScanlineBrightness uniform
lcd_uLCDBrightness = shader_get_uniform(_shd, "LCDBrightness");             // Set LCDBrightness uniform

// Settings
lcd_colorSeparation = true;     // Set color separation to active
lcd_scanlineBrightness = 16;    // Set scanline brightness to 16
lcd_LCDBrightness = 4;          // Set LCD brightness to 4
// ------------------
GML:
// --- LCD shader ---
var _shd = shdLCD; // To avoid having to repeatedly write out potentially long shader names later

// Uniforms
lcd_uTextureSize = shader_get_uniform(_shd, "TextureSize");
lcd_uColorSeparation = shader_get_uniform(_shd, "ColorSeparation");
lcd_uScanlineBrightness = shader_get_uniform(_shd, "ScanlineBrightness");
lcd_uLCDBrightness = shader_get_uniform(_shd, "LCDBrightness");

// Settings
// (All set to defaults)
lcd_colorSeparation = true;     // Range: boolean
lcd_scanlineBrightness = 16;    // Range: 1-32
lcd_LCDBrightness = 4;          // Range: 1-12
// ------------------
 

FoxyOfJungle

Kazan Games
Don't abuse comments. @Micah_DS said it way better in his comment than I ever could. One thing I would like to add is that comments should describe the why, not the what. Your code as written will do the latter just fine, but it cannot do the former. An example of good vs. bad comments:
GML:
// --- LCD shader ---
var _shd = shdLCD; // Set a temporary variable to the shader

// Uniforms
lcd_uTextureSize = shader_get_uniform(_shd, "TextureSize");                 // Set TextureSize uniform
lcd_uColorSeparation = shader_get_uniform(_shd, "ColorSeparation");         // Set ColorSeparation uniform
lcd_uScanlineBrightness = shader_get_uniform(_shd, "ScanlineBrightness");   // Set ScanlineBrightness uniform
lcd_uLCDBrightness = shader_get_uniform(_shd, "LCDBrightness");             // Set LCDBrightness uniform

// Settings
lcd_colorSeparation = true;     // Set color separation to active
lcd_scanlineBrightness = 16;    // Set scanline brightness to 16
lcd_LCDBrightness = 4;          // Set LCD brightness to 4
// ------------------
GML:
// --- LCD shader ---
var _shd = shdLCD; // To avoid having to repeatedly write out potentially long shader names later

// Uniforms
lcd_uTextureSize = shader_get_uniform(_shd, "TextureSize");
lcd_uColorSeparation = shader_get_uniform(_shd, "ColorSeparation");
lcd_uScanlineBrightness = shader_get_uniform(_shd, "ScanlineBrightness");
lcd_uLCDBrightness = shader_get_uniform(_shd, "LCDBrightness");

// Settings
// (All set to defaults)
lcd_colorSeparation = true;     // Range: boolean
lcd_scanlineBrightness = 16;    // Range: 1-32
lcd_LCDBrightness = 4;          // Range: 1-12
// ------------------
Obvious things like what the variable itself says, I usually don't comment, I just used the EvanSki code example, but I don't comment on all variables, for example, this is how I do it:

GML:
// CLIMB COLLISION
var _collision = instance_place(x, y, obj_par_climb)
if !(_collision == noone)
{
    // grab the grid
    if (global.input_key_grab_pressed)
    {
        p_state = player_state.climb;
    }
   
    // move while on grid
    if (p_state == player_state.climb)
    {
        grav = 0;
        jump_speed = 0;
        vsp = input_v * move_speed;
           
        // leave climb [hold up + z pressed]
        if (global.input_key_up && global.input_key_x_pressed)
        {
            grav = grav_default;
            jump_speed = jump_speed_default;
            p_state = player_state.idle;
        }
    }
       
    player_can_bounce = true;
}
else
{
    // reset to default
    if (p_state == player_state.climb)
    {
        p_state = player_state.walk;
        grav = grav_default;
        jump_speed = jump_speed_default;
    }
}
It's a piece of code from my platform engine.
 
Obvious things like what the variable itself says, I usually don't comment, I just used the EvanSki code example, but I don't comment on all variables, for example, this is how I do it:

GML:
// CLIMB COLLISION
var _collision = instance_place(x, y, obj_par_climb)
if !(_collision == noone)
{
    // grab the grid
    if (global.input_key_grab_pressed)
    {
        p_state = player_state.climb;
    }
  
    // move while on grid
    if (p_state == player_state.climb)
    {
        grav = 0;
        jump_speed = 0;
        vsp = input_v * move_speed;
          
        // leave climb [hold up + z pressed]
        if (global.input_key_up && global.input_key_x_pressed)
        {
            grav = grav_default;
            jump_speed = jump_speed_default;
            p_state = player_state.idle;
        }
    }
      
    player_can_bounce = true;
}
else
{
    // reset to default
    if (p_state == player_state.climb)
    {
        p_state = player_state.walk;
        grav = grav_default;
        jump_speed = jump_speed_default;
    }
}
It's a piece of code from my platform engine.
I wasn't really talking about your code in particular, just clarifying because your "abuse comments" statement and example could be taken as meaning "every line needs a comment." You really can't use psuedocode when trying to relay effective use of comments.
 

FoxyOfJungle

Kazan Games
I wasn't really talking about your code in particular, just clarifying because your "abuse comments" statement and example could be taken as meaning "every line needs a comment." You really can't use psuedocode when trying to relay effective use of comments.
Oh yeah, it makes sense šŸ˜†
Besides, too much code can take time to compile, so that's why I told to not oversaturate. :)
 

curato

Member
You don't want to overdo anything, but you do want to think about it from the terms if another person had to look at it would they understand it because if it has been a while since you looked at it the other person can well be you.

I in no way meant to imply you should put an entire novel of comments in your code, but comments can add that at a glance understanding that the code may not offer. personally I like them on conditional blocks as I can be like oh that is doing this then look at the logic.

I did know someone that did that once. They would comment a whole header block with their name and such in it with the whole algorithm of the code below it. Sometimes there was more comment than code. It was insane.
 
Top