This. Good code is code that can withstand change. Remember to program to interfaces, rather than hard-coded implementations whenever possible, and to make systems that are easily extensible. So when you have to add a new enemy type or something it's easy and you only have to write new code, rather than modify old code just to get the thing to work because your system is poorly designed. Abstraction and generalization are your friends, and hard-coded stuff is your enemy.

I guess after the ninth time rewriting Depths from Scratch it would be fairly well written. :p

For loop/array?

You could omit those curly braces (please keep the indents though) and it would only be 3 lines long.

The points I was making don't really have anything to do with runtime efficiency, they have more to do with not fucking you over in the future due to poor choices, as well as making your code more easily readable to anyone else… as well as to yourself as well. I remember when I was 14 my code had no indentation and didn't have much whitespace, I figured it was pretty pointless. But now when I look bad on my code it looks like garbage, and it's harder to tell when logical blocks begin and end.

As an example:

Code form when I was ~14:

How I would re-format the style now:

Although that's just a syntax style change. If I were to actually re-write it, it would probably be written in a different way.

It becomes more noticeable when you have more advanced control structures and more nested stuff and blocks longer than 2 lines long.

I'm not trying to be an ass or anything, I just want to help you program better so Depths won't take longer because you designed some subsystem in a non-extensible way or something.

When you have "if if if" like that it's usually inefficient. 9 times out of 10 you want "if else if else if", "switch", "for" or "do".

Also, I would've cut it even shorter than Rob. You want the "runecount >= i" expression in the for statement, so if it fails you don't have to keep looping. i.e.

You might not even need the arrays, depending.

But yeah I'm just nitpicking. As Rob says, readability comes first. Although if you're trying to get this Game Maker project to run well on smartphones, you probably should be striving to be as efficient as possible, because I'm not sure how efficient Game Maker itself is.

You should write code half as smart as you are, because when debugging code, you have to be twice as smart.

-Mangled Brian Kernighan quote

Good code is readable code. However, if the area you're writing is somewhere where performance matters a lot, you can always be smart - just remember to comment the fuck out of it. It might not seem like you need to comment it because you entirely understand the entire thing when you're writing it… but when you wrote it a year ago, and then have to go back and debug it, you probably won't remember it all and will just think "wtf?"…. same goes if someone else has to read it.

As for the efficiency, it's often not small things that can make a difference, but changes in how your algorithms operate on a whole. Going from something that's O(n^2) to O(n log(n)) can be huge. Optimizing the O(n^2) to run in 80% of the time will still be massively slower than a O(n log(n)) algorithm without any optimizations. Although obviously you can't always do that. But you shouldn't just be prematurely optimizing everywhere, or else you'll never finish the damned game. Although that doesn't mean you should feel free to write inefficient code when you could just as easily write efficient stuff, just don't spent too much time on tiny things.

An example of this is when I had a bunch of equal-size objects to do collision detection on. Instead of settling for horrible O(n^2), I sorted the entire list of objects along one of the axes, ie O(n log(n)) with any decent sorting algorithm, and then went along each thing and traversed the objects in both directions along the axis to see which ones collided. This is theorhetically slower if every bullet is in the same position, so the worst case is O(n log(n)) + O(n^2), but on average it's O(n log(n)) + O(n) which is much better. I went from being able to have like <1000 of these things to 10,000+ or something at the same framerate, since 1,000,000 > 1,000 * 10 + 1,000 (ie 11,000)

And you have to take everything into consideration. If you're not in a language that can do compile-time inlining of trivial functions like min/max then the code Toast gave introduces a function call overhead. And an extra variable, in case you are writing it on an embedded system with 1MB of RAM or somethings stupid, although nowadays that's way less of an issue since even phones have fuckloads of memory.

However, like I said, this kind of efficiency is pretty meaningless compared to changes in your other, larger algorithms that could save thousands of calls every step because of restructuring, whereas the thing me and Toast are talking about is pretty much entirely trivial with only 4 runes. And originally I was just reorganizing it to make it more extensible/modifiable and to reduce code redundancy, rather than any kind of optimization, since DSG's code is actually slightly more efficient than mine with regard to operating time (although by a trivial amount that would be easily optimized away by any compiler) at the expense of a tiny bit of extra space.

tl;dr: make your code readable and extensible, and try to make optimizations where they matter before you go after tiny things, compilers optimize like mad for small things anyways.