Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1368121 Posts in 64199 Topics- by 56137 Members - Latest Member: ProWeldingOrg

October 21, 2019, 08:55:12 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Game Maker For Beginners: Part I
Pages: 1 [2] 3 4 ... 11
Print
Author Topic: Game Maker For Beginners: Part I  (Read 294756 times)
ChevyRay
Guest
« Reply #20 on: October 16, 2008, 12:38:34 AM »

You know, I didn't know that. Lips Sealed
Logged
ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #21 on: October 16, 2008, 12:42:17 AM »

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.
Logged

jeb
Level 5
*****


Bling bling


View Profile WWW
« Reply #22 on: October 16, 2008, 12:44:32 AM »

Shocked

It's not even converted to byte code?
Logged

Evilish
Level 0
**



View Profile WWW
« Reply #23 on: October 16, 2008, 12:46:02 AM »

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:
Quote
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.
Logged
ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #24 on: October 16, 2008, 12:46:33 AM »

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.
Logged

jeb
Level 5
*****


Bling bling


View Profile WWW
« Reply #25 on: October 16, 2008, 12:51:36 AM »

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.

Logged

ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #26 on: October 16, 2008, 12:57:47 AM »

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.
Logged

Hideous
That's cool.
Level 10
*****


3D models are the best


View Profile WWW
« Reply #27 on: October 16, 2008, 01:17:06 AM »

Code:
whatever = no;

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

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

ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #28 on: October 16, 2008, 01:23:20 AM »

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;
« Last Edit: October 16, 2008, 01:31:48 AM by rinkuhero » Logged

Derek
Bastich
Administrator
Level 10
******



View Profile WWW
« Reply #29 on: October 16, 2008, 01:31:28 AM »

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.
Logged
ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #30 on: October 16, 2008, 01:33:40 AM »

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.
« Last Edit: October 16, 2008, 01:38:46 AM by rinkuhero » Logged

Derek
Bastich
Administrator
Level 10
******



View Profile WWW
« Reply #31 on: October 16, 2008, 02:11:53 AM »

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! Tongue)

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. Wink
Logged
ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #32 on: October 16, 2008, 02:14:44 AM »

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!
« Last Edit: October 16, 2008, 02:28:08 AM by rinkuhero » Logged

Derek
Bastich
Administrator
Level 10
******



View Profile WWW
« Reply #33 on: October 16, 2008, 02:18:03 AM »

Sounds good.  Agreed. Smiley
Logged
TeeGee
Level 10
*****


Huh?


View Profile WWW
« Reply #34 on: October 16, 2008, 03:38:54 AM »

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.

 
Logged

Tom Grochowiak
MoaCube | Twitter | Facebook
moi
Level 10
*****


DILF SANTA


View Profile WWW
« Reply #35 on: October 16, 2008, 04:01:04 AM »

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

subsystems   subsystems   subsystems
Matt Thorson
Level 7
**

c'est la vie


View Profile WWW
« Reply #36 on: October 16, 2008, 08:57:47 AM »

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 Huh?

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 WTF I'm the readable code nazi.
« Last Edit: October 16, 2008, 09:05:21 AM by YMM » Logged

ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #37 on: October 16, 2008, 09:23:07 AM »

That's what I just mentioned :D

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

Alevice
Level 10
*****



View Profile WWW
« Reply #38 on: October 16, 2008, 10:44:00 AM »

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).
Logged

moi
Level 10
*****


DILF SANTA


View Profile WWW
« Reply #39 on: October 16, 2008, 10:47:38 AM »

Block the decompilers and I would consider switching to GM  Well, hello there!
Logged

subsystems   subsystems   subsystems
Pages: 1 [2] 3 4 ... 11
Print
Jump to:  

Theme orange-lt created by panic