Ten programming hints. For Christmas (part1/3)

Although this blog is about making a game, and then mainly the nonsense & technical aspects of it, I rarely write purely programming articles. Because I think (but I could be very wrong) half of the readers doesn't really have a programming background to begin with and well, it's hard to make a readable story of bits and bytes.

But maybe some of you programmers are curious how I deal with certain things. In case you'd like to make your own game or engine someday. Or beyond that. Everything we learn while making games, is also valuable in other programming-area's. Writing clean code for example, or caring about performance / efficiency. Or when starting something *bigger*, whether that's a communication library or database + various tools, game-engine design strategies can provide priceless background knowledge.

This topic is so wide and abstract that's it hard to explain from A to Z, so instead I just grabbed ten "Programming Advises" from the top of my head, that can be applied on game-programming but also on pretty much else.Being a bit long for one post, I spreaded this over three posts by the way.

 

1. Don't be over-ambitious. Expect to start over. Many times.
2. Picking the right programming tool
3. Eyes and ears open, keep in the game
4. Efficiency versus Readability

5. Readable code // Commenting
6. Keep it small, Size matters
7. Resuable code & Modular design

8. Multi-Threading, be Multi-Carefull
9. Debugging. Don’t blame your computer. Even if it did it
10. Be consistent

1. Don't be over-ambitious. Expect to start over. Many times.

Unless you're making a small or very to-the-point application, code tends to become a proliferation of patches, added stuff, side-routes and fixes sooner or later. Eventually to a point that the code skews like the Tower of Pisa. Keep throwing weight on it, or restart with a clean sheet?

I restarted Engine22 almost two years ago, and although I've surpassed the "old" (nameless) engine on several areas, there is also a lot still missing. Doesn't matter as long as you're hobbying, though for work-related code, your chief and users are probably less excited about a reboot. Which is why people tend aim for "the ultimate code", raising the bar way higher than they can jump.

There is no such thing as "perfect code". Everything will crack at some point. It's impossible to anticipate on every possible future request, new-technique, platform or trend. Also, as you get other work, projects or hobbies over time, the dedication and deep-knowledge level of your own code will decrease. And moreover, your current skills are simply not as good as they will be over four years.

Trying to get better is a healthy ambition. Trying to do the impossible will bring you nothing but stress, frustration, an unclimbable wall of work, and eventually quitting. I restarted my game-engines (also prior to the whole Tower22 adventure) multiple times, and also approach projects at work very different each time. But I don't regret that past "wasted" work. If I didn't attempt to, I wouldn't be at my current level either. Learn by doing.

 

Big Bang Theory.

2. Picking the right programming tool

Long discussion short, -not trying to start any flame wars here- just pick whatever you're comfortable with. I remember fellow students telling all those Fisherman Tales about Delphi being slower because of some non-existing virtual machine, Java compiler being more clever than C++, that the Nintendo is three times faster than the Sega because of 64-bit displaced-shadow-fog matrix techniques, and so on. 10 opinions, and 9 of them are based on the opinion of somebody else, who heard something from yet another guy, which interpreted some-other-paper wrong. Not that the word of another is useless, but if you want to know things, don't forget your own research as well.

I would be lying if I say all tools are equally good. Functional-programming, Java, Eclipse, Linux... they all give me the shivers. I think HTML, Perl, CSS, JavaScript and everything involved in making websites, is a big collection of donkey dung. But that doesn't mean you have to hate it as well, and it doesn't mean you can't make awesome websites with it. Some prefer blondes, other brunettes. I prefer Delphi. And Qt. And Visual Studio. And... Doesn’t matter. What matters is that you use the tools you like. Because chances of success are simply higher then. Especially when you are still in the learning/student/hobby phase, actually *finishing* something should be considered a great success.

Don't forget the end-user will judge end-results, not how you got there. And as told in point#1, there is always time to evaluate, retry, eventually with another tool, and sharpen your skills. A bit more on this in point #5. 

When needing a CV next time, I'll use this picture.

3. Eyes and ears open, keep in the game

In addition to #2, one warning though. Do not bite into a single tool and swear on your mother’s grave you'll never switch. Stay open for other languages, programs, environments, ideas and approaches. Delphi is great for making desktop applications (and I admit, less great for games. Not because it can't, but the community behind it is thin). But not so great for making an Arduino microcontroller, or a webserver maybe. It simply can't do everything, and that counts for pretty much any tool.

Like a handyman, you'll need a well-filled toolbox. Hammer & spikes for woodcrafting, welding torch for metalwork. If there is only Visual Studio in that toolbox, you won't be prepared for all jobs. And the only way to fill that toolbox with GOOD tools, is to explore and try them.

Also don't forget that tools won't last forever. As I experienced with my beloved Delphi7, the world goes on. 64-bit? Telephone Apps? Cloud-based development? Touchscreen-Gestures? Raspberry Pi? With Delphi7, there is nothing you can't do really. But I felt I was falling behind more and more. Interns fresh from school would suggest to use Azure... Azure? That's that Caribbean beach right? Right...? No? Stupid intern. On your flying hover-board with self-lacing shoes...

I'm almost 33 now, and in some ways aging will make you wiser in a charming, George Cloony way. But I also feel it's getting harder to keep up, even though I'm not THAT old. As a Delphi Veteran, I would quickly have my opinion about all those new marketing terms. Internet-of-Things. Big data. Cubic databases...what the hell... But honestly I often have no clue what they are. So keep your nose outside for some fresh air. Not everything the intern brings in, is new-age nonsense. In fact, I enjoyed my trial Azure subscription quite a lot last month.

 

 Hahaha. But really. My "little" 8 year old girl never saw a fat CRT TV. Or a dial-up phone. Or a medium tower PC. Or a NES 8-bit. If you live in or nearby Belgium, take your kids to "Bokrijk" in Hasselt one day to go back the seventies, sixties, or far before that. Nostalgia.

4. Efficiency versus Readability

To the Bit-Mobile then. Having some 1kb RAM Microcontroller background, I always try to use optimized code. But hold on, I'm not talking about replacing everything with Assembler instructions, or squishing 20 lines of code into 10. A common mistake is that people heard something about optimization being important, and then raping their code into an unreadable mess.

The truth is, there is a 95% chance that your target platform is NOT a lousy microcontroller with 1 KB RAM. And even if it were, you are probably doing a relative simplistic sensor-measurement or robot/machine operation that doesn't require tons of resources then. Modern developers may say you shouldn't worry about resources at all. Just make your program, then optimize. If needed at all.

I half agree on that. Well (readable) written code is much easier to optimize, but probably more important, robustness weighs more than a buggy application that runs 5% faster. Highly optimized code is very sensitive to mistakes. Then again, I do think the modern programmer got spoiled with the powerful hardware we have today, and therefore has little knowledge of what happens under the hood of their muscle-car. As a result, they manage to make memory/CPU hogging monsters. Tower22 consumes ~450 MB at this point. Google Chrome with a few stupid webpages a gigabyte on my computer. Hell, pretty much any tool in the task list consumes at least 200 megabytes. And the start-up/load times are terrible as well. If I click the green "RUN" arrow in Delphi, the Tower22 world shows up within a six seconds or so. Then what the hell is taking Paintshop Pro X8 so long to boot? Something stinks here...

Efficient code is not something you'll add afterwards a bit here and there. It's a way of thinking. Knowing what kind of booby-traps we're facing. Your alarm-bells should ring when dealing with:

·         Loops - especially the long ones

Really needed? Can we shorten the loop by skipping items that don't need to be drawn/searched/updated at that time? Spread tasks over time?

               

·         Searching - (get itemX from a big list/array/collection/database)

Try to avoid anything that can't give a positive result anyway. Use grouping, sorting, caching, binary trees, or whatever suits your situation best.

               

·         Reserving many or large chunks of memory (arrays, bitmaps, ...)

Really needed all the time? Can multiple users share the same source? Worth some compression?

·         Heavy duty tasks

Avoid multi-threading if not really needed, it’s a source of headaches and hard-to-debug errors. BUT, if your main process is stalling because of big files to load, complex searches, or waiting-for-input, consider multi-threading.

 

Obviously, a game is doing LOT's of stuff, EVERY cycle. Drawing thousands of items, playing sound, calculating physics and collisions, updating A.I., pathfinding, loading new parts of the world, and so on. A single mistake will become a bottleneck, and can turn a smooth 60 FPS experience in a 1 FPS nightmare. You don't have to treat every line of code as a threat that needs to be optimized, but recognizing potential CPU-eaters and designing the software to deal with them smartly at forehand, separates the men from the boys.

 

That's what you get if the framerate stalls.