next »

[ChevyRay]

You know, I didn't know that.

[ஒழுக்கின்மை (Paul Eres)]

Granted it won't be noticeable 99% of the time -- most of the cause of slow games in GM has nothing to do with how you code something, but just the total number of objects and how much you're drawing to the screen at once. But it does have a minor, tiny effect.

[jeb]

It's not even converted to byte code?

[Evilish]

Code:

if(condition){
  statement;
}
else{
  statement;
}

The way I code, and I love it. Never been a fan of having newlines for starting braces.

Lil info though, YYG is apparently planning to release Mac and Linux runners, so GM games will become cross-platform

EDIT:

It's not even converted to byte code?

The game has about a 1mb (depending on versions of GM) runner attached to the executable file., that does all the interpreting of code. Hobbyists probably won't notice a speed drop and some pretty amazing looking games have been made, it's just not for all games.

[ஒழுக்கின்மை (Paul Eres)]

it is, but i would assume that brackets and parenthesis have equivalents in bytecode. another thing is that it's converted to bytecode *every time you run the game*, it's not stored as bytecode, so at the very least, removing excess brackets and parenthesis will cause the startup of your game (and every time you test it while making it) to process faster.

[jeb]

it is, but i would assume that brackets and parenthesis have equivalents in bytecode. another thing is that it's converted to bytecode *every time you run the game*, it's not stored as bytecode, so at the very least, removing excess brackets and parenthesis will cause the startup of your game (and every time you test it while making it) to process faster.

Ah but in that case it doesn't matter. Parsing one extra bracket is insignificant, so I'd vouche for better readability.

I've made my own byte-code compiler as a part of a course. Code that looks like

Code:

if condition statement;

and

Code:

if condition then statement end

produce identical byte code.

[ஒழுக்கின்மை (Paul Eres)]

It might be significant depending on the total amount of code. In one script it's not important, but what if your game has 30,000 lines of code? It'd add up.

But that's good to know about the identical bytecode thing, but I'm not sure it's safe to assume that's true of GM just cause it was true of your bytecode, since different bytecodes might work differently. And Overmars is a college professor, not a professional programmer, so I'm not sure he always does things the best way -- from what I know of how he codes in general he's competent but often makes seemingly silly mistakes. For instance, the reason GM7 doesn't work in Windows 98 anymore is a simple .rtf library incompatibility or something. His tileset / map tile system is also incredibly slow compared to other tile systems I've seen, because it doesn't make a new image for the tile layers, but instead treats them as individual objects and puts them together again over and over.

[Hideous]

Code:

whatever = no;

if (whatever == 5)
{
    awesome();
    whatever += 1;
}
else
{
    whatever -= 1;
}

That's how formatting should be done, for readability purposes.

[ஒழுக்கின்மை (Paul Eres)]

The thing is, that's only more readable to people who are used those conventions (even though that's most programmers). For me, other formats are more readable. Sometimes I've used things like this:

Code:

if whatever == 5
   then { awesome(); whatever += 1; }
   else { whatever -= 1; }

Or I might just do this:

Code:

if (whatever == 5) awesome(); 
if (whatever == 5) whatever += 1;
if (whatever != 5) whatever -= 1;

Those are just as objectively readable as your formatting if you're used to them.

The fastest in terms of bytecode conversion would be something like

Code:

if whatever == 5 { awesome(); whatever += 1; } else whatever -= 1;

Fastest execution might be (though least readable)

Code:

whatever -= 1; if whatever != 5 exit; awesome(); whatever += 2;

[Derek]

I think those are okay until you start having nested if statements or loops!  Which is when it becomes very handy to see where the brackets are.

[ஒழுக்கின்மை (Paul Eres)]

I'm not sure that's true either -- I have written code which is readable to me which uses nested if statements and loops. Here's an example:

Code:

if (mouse_x >= 0 and mouse_x <= 1024 and mouse_y > 0 and mouse_y <= 768) and 
   (room != room_SDpreview)
{
   f100 = math_limitto(0, 200, friendship(100));
   if (f100 == 100)
      then c_mouse = 2869514;
      else if (f100 > 100)
         then c_mouse = merge_color(2869514, global.tower_color[6], (f100 - 100)/100);
         else c_mouse = merge_color(2869514, global.tower_color[12], (100 - f100)/100);
   draw_set_color(c_mouse);

   if (global.phase == LEVEL and mouse_y < 621)
      then drawcursor_level();
      else drawcursor_normal();
      
   if (global.partice_id == 0) and (global.phase == LEVEL)
      if (global.level_phase == PLAYING or global.level_phase == STARTING)
         if (holding_type >= 0) and (holding_type <= 11)
            if (global.tower_number[global.level, holding_type] > 0)
               then print_pointhelp(mouse_x, 690, makestring_pointhelp());

   if (global.level_phase == WINNING)
      {color = c_lime; print_victory(mouse_x+10, mouse_y+10, string_int(kills));}
   
   if (cursor_charging) and (not global.chargeless) and not (global.option_mouseless)
      draw_cursorcharge();
}

That's part of the code to draw the mouse cursor in Immortal Defense.

Note that GM has no 'breaking away' in if statements, which compiled languages tend to have, so if you have tons of conditions in a single if statement it's faster to break it up into multiple if statements than include them all in a long string of and's, so if you're wondering about that if if if if if part, that's why.

[Derek]

Yeah, I agree that that's readable, although personally I find it much less readable than it could be.

The "then-else if" notation is just confusing as heck, imo:

Code:

if (f100 == 100)
   then c_mouse = 2869514;
   else if (f100 > 100)
      then c_mouse = merge_color(2869514, global.tower_color[6], (f100 - 100)/100);
      else c_mouse = merge_color(2869514, global.tower_color[12], (100 - f100)/100);

Versus:

Code:

if (f100 == 100)
{
   c_mouse = 2869514;
}
else if (f100 > 100)
{
   c_mouse = merge_color(2869514, global.tower_color[6], (f100 - 100)/100);
}
else
{
   c_mouse = merge_color(2869514, global.tower_color[12], (100 - f100)/100);
}

Or even:

Code:

if (f100 == 100)
   c_mouse = 2869514;
else if (f100 > 100)
   c_mouse = merge_color(2869514, global.tower_color[6], (f100 - 100)/100);
else
   c_mouse = merge_color(2869514, global.tower_color[12], (100 - f100)/100);

Just because, to most people (I think), an indent usually signifies a shift in the hierarchy of the block, and "if," "else if," and "else" should all be on the same level.  I like to be able to see all the conditions first, by scanning down, and the way you have it I need to look through the whole block to find all the conditions.  Also, if you have to add anything in there you're sort of boned.

(And you're still enclosing that whole thing in brackets to start with! )

But actually, I go back and forth, too, mostly out of laziness.  And yeah, also to save space!

P.S. It really boils down to personal preference, but it's fun to argue about them a bit.

[ஒழுக்கின்மை (Paul Eres)]

I think the hierarchy thing for if then else if then else makes more sense to me since I came from QBasic -- in there, they didn't have anything like brackets at all, so the hierarchy way was the only way to do it. But I can understand how that'd be confusing for someone who wasn't used to it. It also makes some degree of logical sense -- I read it as "if the mouse isn't near a love or a hate point, color it green; if it's near a love or a hate point, color it pink or red depending on how close it is to it". Which is a kind of hierarchy.

So my point was more like: I don't think there's one best way to format code, what's readable to someone isn't readable to someone else, so people should just use what's most readable to them, especially if they're the only person coding the game and the only person who will read the code.

I think my own style emphasizes saving space, I like to use as few lines as possible. For instance your

Code:

// Controls
if (keyboard_check(vk_up))
{
    y -= 2;
}
else if (keyboard_check(vk_down))
{
    y += 2;
}
else if (keyboard_check(vk_left))
{
    x -= 2;
}
else if (keyboard_check(vk_right))
{
    x += 2;
}

Looks terribly messy to me, I'd just do:

Code:

// Controls
y -= (keyboard_check(vk_up))*2;
y += (keyboard_check(vk_down))*2;
x -= (keyboard_check(vk_left))*2;
x += (keyboard_check(vk_right))*2;

16 lines into 4!

[Derek]

Sounds good.  Agreed.

[TeeGee]

It all totally doesn't matter, as long as you can read your own stuff and are the only persona that has to do it.

However, cooperating with other people is a completely different thing. That's why it's good to know the most popular ways of formatting the code and be used to them.
I had my personal way of putting stuff together and it was perfectly clear and convinient to me. But it backlashed a lot at the start of our work on ArcMagi, resulting in me having to rewrite all the basic code from scratch.

 

[moi]

LESS NERD, MORE TUTORIAL
DON'T TURN THIS THREAD INTO FAIL

[Matt Thorson]

Game Maker Protip:

AND and OR never short-circuit, so don't expect them to.  It sucks, but it's a minor annoyance.  No idea why they don't

Example:

Code:

if x and y 
{
    do_stuff();
}

if x is false, you'd logically think that the interpreter wouldn't bother resolving y, because the condition already failed.  Nope!  Keeps going, like a dumb monkey.

It's mainly annoying if you want to do something like:

Code:

a = instance_place( x, y, object );

if instance_exists( a ) and a.x == 2
{
    a.x += 1;
}

Because if the instance doesn't exist it'll still evaluate the second half of the and, meaning ERROR because a.x doesn't exist.  You have to resort to nesting.

Code:

a = instance_place( x, y, object );

if instance_exists( a ) 
{
    if a.x == 2
        a.x += 1;
}

Pisses me off every time I'm the readable code nazi.

[ஒழுக்கின்மை (Paul Eres)]

That's what I just mentioned :D

And yes, that's one of the most annoying parts of GML.

[Alevice]

I like the way game maker is designed for the most part, but I really want a revamp of gml, an slightly stricter and optimized version. Like forcing you to declare instance variable on creation or something, and have it more OO. That way most of is api could work as object methods and the like. Oh, and ditch scripts in favour of "libraries", that is, libraries would blocks of code where one or more functions are declared (although i'd prefer static members for that).

[moi]

Block the decompilers and I would consider switching to GM