Valuable hints about GML

WARNING: Large post!

So you wish to learn something more about GML? Well, I'll share some of my tricks when it comes to coding.
The first thing you need to do, is to learn the language. This is very crucial, because then you don't have to look up in the help-file (ALWAYS KEEP THIS SOMEWHERE CLOSE) all the time. The syntax box under the code editor is also helpful, as it guides you towards the function you want.

Coding style
SYNTAX
But when you learned GML, you also want to know how to write it. There are many ways to do this, and GML is very "open", and it's not very strict. So to say this in other words,

Code:

var var1, var2;
var1=argument0
var2=argument1
return var1+var2

is just the same as

Code:

var var1, var2;
var1 = argument0;
var2 = argument1;
return (var1 + var2);

This is an example of a script that adds together the two numbers you feed into it. It's written in two ways here, one with a very sloppy syntax, and one that's more "correct". They both does the same, but since the second way is the easiest to read (and I'm using it), I'll use this coding style in all the examples I provide.


SPACING
Now that you understand a bit about the GML syntax, lets head over to how you space out you code. You DO NOT want to write everything on one line or write everything as close to the left edge as possible. Not only makes spaces the code easier to read, but also to locate syntax errors and bugs. Here's an example of how not to code, as it'll get hard to locate the errors:

Code:

var i,j,height;for(i=0;i<argument0;i+=1)
{
for(j=0;j<argument0;j+=1)
{
height=ds_grid_get(global.grid,i,j)if(height>10)
{
controller.heightdata[i,j]+=height+random(3);
}
}
}

Instead, you should space it more out like this:

Code:

var i, j, height;
for (i=0; i<argument0; i+=1)
  {
  for (j=0; j<argument0; j+=1)
    {
    height = ds_grid_get(global.grid, i, j)
    if (height > 10)
      {
      controller.heightdata[i, j] += height + random(3);
      }
    }
  }

Notice that I use gaps in between the arguments and a gap after every if and for word, which also improves the readability. If you notice how I place the { and }, I place the on two spaces after the if and for. Of course, there are plenty of ways to do this, but this is the style I'm using, so again; this is what I'll use in the examples.


COMMENTING
But now that you know how to write your code, you should really learn how to COMMENT your code too! In a game, the number of lines quickly goes far beyond hundreds of lines. In my game that I'm working on, the player object contains 1233 lines with coding. Imaging searching through that without something to tell you where your problem lies...
So, you should comment your code once a while, not every line. Preferably before every "block" or "paragraph" of code you include a comment about what this part does. Here's an example of this:

Code:


// Syntax:
//  GetHighestDepth(object)
// Returns:
//  The highest depth in the given object

var i, obj, MAX;
MAX = -999999;

// Run through all the objects and assign the highest depth to variable MAX
for (i=0; i<instance_number(argument0); i+=1)
  {
  obj = instance_find(argument0, i);
  if (obj.depth > MAX)
    {
    MAX = obj.depth;
    }
  }

return (MAX);

As you can see, there's no need to comment the obvious like this:

Code:

array[0, 2] = 23; // An array

Instead, you should give the comment a MEANING:

Code:

array[0, 2] = 23; // The height of the heightmap at (0, 2)

Also, when it comes to commenting, it's important to not OVER-COMMENT your code, because that makes the code harder to read as you have to search for the code you wish to edit among the lines of comments. Also, you don't want to comment every line, but as I said, only a block or paragraph. You should include a short, but describing comment about what the following code does. Useful places to place a comment would be in the front of a loop, before a single if-statement of before something complex. You should also include short comments directly into the code to better understand these parts.
Remember that when you work on a code, what you write here and now might be very obvious, but in a weeks time, you have no idea about what you though. That's why comments are helpful

And there's one more thing with comments; you can use them to separate two totally different codes. Let's say that you place the keyboard events in the step event, and you also included your collision and gravity system in there too, you can separate those to with a "comment block". They looks like this:

Code:

//////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////

(Only a lot larger)
You could also include some information inside this block to further improve the ability to locate specific places in your code.



Tricks and shortcuts
LESS LINES/CODES
So you’ve read all this, and now it’s time to learn more about the “shortcuts” in GML. Let’s take a look at the fact behind false and true. Both these are written in a red color in the code editing screen, that means that they are something called constants. They have a value, and that value can never change. false stands for 0, and true stands for 1. However, replacing your trues and falses with 1’s and 0’s can quickly confuse you, so you should be careful about these. Using numbers will make you unable to separate Booleans with other types of variables. (A Boolean is either 0 or 1, nothing else)
Also, when you wish to check a function, you don’t have to do any of these ways:

Code:

if (place_free(x, y+vspeed) == true)
If (place_free(x, y+vspeed) == 1)

You can simply write

Code:

if (place_free(x, y+vspeed))

which is the exactly same thing. The if statement takes the whole thing in between the parenthesis, the ( and ), and translates it into either a 1 or 0 (True or false). So when you say if (place_free(x, y+vspeed)), (place_free(..) returns either 1 or 0), you tell the program to run if you get a one. That’s why you don’t need a == true or false there. If you had one, it would be like this:
if (1 == 1)
And that would give out a “true” since 1 is equal to 1. GM will translate this to a 1, so in the end it will turn out to be “if (1)”.

Also, when you want to insert a boundary to a variable, you don’t have to use four lines. Let’s make an enemy which moves randomly, but we don’t want him to leave the room. Here’s how you’d normally want to write the code:

Code:

xspeed = choose(-1, 0, 1);
x += xspeed;
if (x <= 0) {x = 0;}
if (x >= room_width) { x = room_width;}

Instead, we could write

Code:

xspeed = choose(-1, 0, 1);
x = max(0 , min(room_width , x + xspeed));

Here you see we can write three lines in one line.
Here’s how this cool thing works:

Code:

<NEW NUMBER> = max(<MIN NUMBER>, min(<MAX NUMBER> , <CURRENT NUMBER>));

This can be very useful when you want to insert a max speed for your character, or when you want to limit a certain variable.

But after the IF statements, the brackets can be used in a special way. You don’t have to do it like this:

Code:

if (hspeed < 2)
  {
  y -= 1;
  }
if (jump == true)
  {
  vspeed = -6;
  }

This can be replace with

Code:

if (hspeed < 2) {y -= 1;}
if (jump == true) {vspeed = -6;}

That’s six line down to two, which is a lot better. When you have a long IF statement, you can place the brackets on the line below instead of the same line as the IF statement.


SMALL TRICKS
Often there are more ways to do a thing. But there’s always one way that’s easier or faster than the other ways.

First off, try to avoid the GM’s built-in variables like vspeed, hspeed, speed, gravity and these. They can be really in the way when you want to make advanced engines. Also, to make some similar variables, you could use xspeed, yspeed, velocity, grav, fric and so on. Using such variables instead will give you the ability to make your own collisions, moving when you want and a lot more.

So, here’s how to make a simple “move-at-command”-code:

Code:

if (can_move == true)
  {
  x += xspeed;
  y += yspeed;
  }

Simple, isn’t it?
In the same way, you can apply custom gravity, friction and everything you want. With time you can learn to manipulate “time” in the game, write your own laws of physics, create high-quality movement and a lot more.

<More to come here>


I hope you've been able to learn something about how to write your code and space it out. Happy commenting! In the next part, I will talk about coding style, and perhaps something about extensions and DLL’s. So stay tuned for more!

just one question: cant you just hit enter 3 times to separate two different sets of code?

thanks for that post hepolite. also, you are allowed to double post.

@ Wasted, of course you can hit enter three times or more, but then you won't be able to find this place if you quickly scrolls through the code.

@ 3D, No problem
I'll write some more when I get time, just had to reserve a post so I could format this a bit better later.

kk.

it just looks better, IMO

lol

very nice

Just added some more, feel free to request anything and I'll include it

nice, hepolite. please tell ur friends to join this site. i think we might be not getting more members. we need your help.

Nice info. Can I request teaching about operators. Like << or ^ or |. And what exactly is xor.