09-28-2012, 07:04 AM
[spoiler=Excursion on coding style]
I'm sorry but I want to go a little bit off-topic here to have a word on coding standards. If you ever happen to get to work together with other programmers on code that is not your own and which others will have to work with, you'll need them (and trust me, you'll expect your partners to follow them, too, as you all will have to work with the code and it needs some consistency). Of course, code style may vary between companies (the worse ones may not care at all), but there are a few things that are pretty much consistent.
It's never to early to start coding with proper style, the longer you drag it out, the harder it will be to learn.
It's nothing major, but I'd like to address a thing or two. Or maybe three.
Whitespace. Use them, it doesn't cost much, but makes your code look less stuffed.
I see you already use two whitespaces before comments after the line end, which is great (Google standard, even), but you should also have one after the double slash.
Braces around conditions. Many languages require them and I don't think they'd hurt GM (if they do, that'd be dumb).
This will make it easier adjusting to C++, C#, Java and the like later.
A last thing that may be worth considering is line length. A common limit is 80 characters per line (don't as me why, something about old consoles / terminals only having that much), it may not be neccessary today, but many code style standards still require it.
If you'd write code for Google, for example, they have a strict coding style guide. We had to abide by their C++ style for our C++ course last semester (we were given a style checking python script which was required to run through our code files without finding any style errors).
[/spoiler]
Aside from that, I'd assume your code - if not just the idea - may come in handy for other GM users. Being an interpreted script language, GML tends to have performance issuesm and any larger game is prone to lag without such optimisation tricks.
I'm sorry but I want to go a little bit off-topic here to have a word on coding standards. If you ever happen to get to work together with other programmers on code that is not your own and which others will have to work with, you'll need them (and trust me, you'll expect your partners to follow them, too, as you all will have to work with the code and it needs some consistency). Of course, code style may vary between companies (the worse ones may not care at all), but there are a few things that are pretty much consistent.
It's never to early to start coding with proper style, the longer you drag it out, the harder it will be to learn.
It's nothing major, but I'd like to address a thing or two. Or maybe three.
Whitespace. Use them, it doesn't cost much, but makes your code look less stuffed.
Code:
wallsurface=0; // okay
wallsurface = 0; // better
draw_sprite(sprite_index,-1,x,y); // okay
draw_sprite(sprite_index, -1, x, y); // betterBraces around conditions. Many languages require them and I don't think they'd hurt GM (if they do, that'd be dumb).
Code:
with (objWall) { // With all of the walls in the room...
if (object_index == objWall) { // If it's not inheriting from anything (you may want to handle slopes with their own combined slope object, for example...
// ...
}
}A last thing that may be worth considering is line length. A common limit is 80 characters per line (don't as me why, something about old consoles / terminals only having that much), it may not be neccessary today, but many code style standards still require it.
If you'd write code for Google, for example, they have a strict coding style guide. We had to abide by their C++ style for our C++ course last semester (we were given a style checking python script which was required to run through our code files without finding any style errors).
[/spoiler]
Aside from that, I'd assume your code - if not just the idea - may come in handy for other GM users. Being an interpreted script language, GML tends to have performance issuesm and any larger game is prone to lag without such optimisation tricks.