Monthly Archives: August 2012

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 →