OOP Stand Alone Complex

Posted on by


Don’t get me wrong, I’m not against object-oriented programming (OOP). More often than not, it’s a valuable method for modeling data and logic in games. However, because of its near-total dominance of thinking regarding programming in games, I often find myself playing the anti-OOP advocate in conversations at work.

You see, there are times when designs that look “right” when viewed through an OOP lens turn out to be ill-suited to solving certain problems in game programming. One of the major causes of this is the tendency of OOP to encourage thinking of problems in terms of single data objects. Often this works because handling multiple instances of an object is a natural extension once you know how to handle a single instance. This isn’t always the case however and it’s common for OOP-oriented programmers (OOPOP?) to overlook cases in which it would be better to think of processing data as a gestalt as opposed to as lists of stand-alone objects.

To clarify this idea, I’ll share a recent experience with some code at work. Continue reading →

Three Slices of Useful Code

Posted on by


While it’s the big problems in game programming that get all the press, there are plenty of small problems that show up day-to-day. Most of these problems can be solved by an equally small bit of code, it’s just a matter of figuring out what that code should be.

With that in mind, I’d like to share a few bits of utility code that I find invaluable in my daily game making. Continue reading →

Benchmark Before You Optimize, Dammit!

Posted on by


Donald Knuth said it best:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Every programmer knows this in their head, but getting that through to their heart can be surprisingly difficult. When it comes to applying lessons like the one above, it’s easy to find yourself in the middle of a conflict between doing what you know you should do and doing what you want to do. Continue reading →

Game Design Tips

Posted on by


As the cliche goes: game design is more of an art than a science. As such, there are no hard, fast rules that dictate how a game should be designed. There are, however, mountains of guidelines and examples that provide insight into how to make a better game.

In this article, I’d like to present a few of the game design guidelines that I’ve found useful in my work. Again, they aren’t absolute rules but they are a great way to sanity check game designs to make sure you’re heading in the right direction. Continue reading →

Most Programmers Can’t Read Code

Posted on by


Any technically-inclined person on the net should be familiar with the acronym RTFM which stands for the phrase “Read the Freaking Manual” (the non-family-friendly version is more colorful, of course). It’s the standard response to a question that you think wouldn’t have been asked had the asker read the (freaking) manual in the first place.

For the programming set, a natural variant for RTFM is RTFC, “Read the Freaking Code”. For any given program, the source code is, by definition, the most accurate description of how a given program will behave. Barring inaccurate comments and misleading variable names, source code is the only form of documentation guaranteed to be 100% accurate. What keeps source code from being great documentation is that it is so hard to read. It’s so hard in fact that:

Most Programmers Can’t Read Code

Programmers can’t read code? But isn’t that their job? Strange as it may seem, it’s true and there are reasons for this. Read on to learn more. Continue reading →

Shooting Game Algorithm Maniacs

Posted on by


It seems I’m not the only one who suggests designing games enemy-first.

Recently, while reading some game dev books, I ran across a bit of advice with sentiments similar to one of my previous blog posts. The text in question is from “Shooting Game Algorithm Maniacs”, a Japanese game dev book focussing on SHMUPS (shoot-em-ups).

For folks who may not be able to read Japanese, here is my translation of the advice from the conclusion of Chapter 2 (called “Stage 2″ in the book.): Continue reading →

Player 2, Press Start

Posted on by


Multiplayer in video games is almost as old as the medium itself. It’s at least as old as Pong, right? As such an old institution in games, you’d think we’d have all the issues related to implementing multiplayer in games figured out by now. Of course, you’d be wrong. Otherwise, I’d have nothing to write about in this article.

In terms of handling multiplayer from a game design perspective, there are several issues that tend to slip through the cracks until they show up during actual implementation. In large teams, the late discovery of these issues can cause disproportionate amounts of time being spent to fix them as they wind their way from the discover’s desk to the people responsible for game design decisions and back to the feature implementor. Continue reading →