Game Code vs. App Code

Jeff Fulton has written a great article about optimized game code, including some pretty thorough performance tests. He also gives some great historical information about OOP trends in Flash gaming based on his personal experience programming games.

What makes Jeff's article rare is that you don't see a lot of game developers seriously considering and integrating OOP practices. There are performance hits associated with some OOP structures (getter/setters versus public variables, etc.) that turn a lot of game developers off. Someone that's just doing games doesn't always take (or think they have) the time to learn good system architecture.

Application programmers have no excuse. If you're building apps, you aren't concerned about performance hits that will drop your application from 90 to 60 frames per second. You could probably run your app at 30 fps and be just fine.

Applications also have potential for a more elaborate system architecture and an increased likelihood of revisions or updates by other team members. Good OOP code is crucial for those things. The only detraction to strict OOP practices in Flash is performance related and frame rate specific - and apps rarely come close to pushing those limits.

Before I get flamed by game developers, let me qualify that by saying that a good portion of any game should actually be considered application development. Typically a game is actually an application that houses a game engine. (Jeff essentially comes to the same conclusion.)

So really, nobody has an excuse. Game and app devs alike need to know good OOP practices. Gamers just have better excuses (in certain circumstances) for breaking the rules.

Little Bits of Finesse

Sometimes it's the subtle elements that can really make your work stand out. But those finesse elements are often the 2% of a project that require 50% of your time. It seems counter-intuitive (especially when a deadline is looming), but it's those scenarios where you're often best rewarded for putting a little extra into making reusable code. You invest a little up front for long term payoffs.

For example, plenty of games have a scoreboard. It's relatively easy to just populate a text field with the user's score, but if you spend a little extra time to make a more elegant, reusable solution, your game will feel just a bit richer. People that play it may not necessarily notice that your game has a "special" scoreboard. But they'll know something's just better about your game. And if you've encapsulated the functionality well, you may not need to build another scoreboard for a long time.

Here's an example. This isn't all that complex, and the effect is relatively subtle, but it's a bit more interesting than simple text field updates. I also built it for flexibility. A fast-moving game may have a lower tween duration and higher blur distance. A slow-moving game would have just the opposite. Need a 10-digit score? No problem. And altering the font is as simple as changing a library symbol.

My recommendation, if you haven't already: start developing your own class library, and keep it as a formal repository of all the bits and pieces you use all the time. If you find yourself creating something for the bazillionth time, give yourself some extra time to create a solid implementation of that piece. Don't build everything into it, just the essentials. That will give you a core version, a starting place for future implementations. You'll save yourself a ton of time and, if you go a little out of your way, you'll easily add a bit of finesse to future projects.

Pattern Extremists

It drives me a little crazy when people (including myself) become emotionally charged during an argument. It always dilutes the argument or kills credibility - or both.

Programmers have plenty of emotionally charged debates, and while design patterns is probably not at the top of the list of polarizing issues, it's one of them. Some programmers really work themselves up into a childish frenzy, and it sounds like it's the folks on the other end of the spectrum that they're ranting about.

These rants really aren't about the patterns, or the idea of patterns, but the people using the patterns. If people are cutting+pasting from the GoF book, that's really not an issue with the pattern concept. "But patterns encourage that behavior," says the pattern-hater. I'd say that laziness, lack of education, or a need to feign proficiency might encourage that behavior. If design patterns didn't exist, those people would be copy+pasting from other sources that would likely be less well thought out.

The other rant usually revolves around patterns promoting obscure terminology. I agree, but only a little. Throwing around pattern names to non-programmers communicates nothing. But if I'm reading a bit of technical documentation that identifies a class as a Singleton, that saves paragraphs of reading. (And if I don't know what a Singleton is, I've got a great learning opportunity on my hands.)

It's another tool vs. user argument. The tool is great when used effectively, and horribly destructive in the wrong hands. Don't blame the tool for the error.