I’m deep in the game script at the moment. Oddly enough, what I’d planned as a science fiction story about a clash of cultures on a distant gas giant world is turning into a 19th century drawing room comedy. It’s still set on a distant gas giant world, though. I hope that doesn’t confuse anyone.

On the technical side, one new approach I’m trying out is paying off. In the games I made previously, most objects were “smart”—that is, they contained all the game logic that concerned them. The player object knew about damage tables. A state machine for determining when an antagonist would break off an attack would be found in the object that maintained the antagonist, and so on. Each object maintained its own state and its own business logic.

This seemed logical to me until a couple months ago, when I was going over the source code for Easy Does It and realized that the game logic—code that describes how the game actually works—is all over the codebase. Hard to understand, hard to debug.

For the new game, I dipped into design patterns and came up with a model-view-controller like pattern to use. All drawable objects are dumb, knowing only how to create and draw themselves, rather like views. The game logic is maintained in one source file, broken up into several different modules. These are the controllers. And the tables that drive the game—the models—are maintained in another source file.

It feels right, and I’m finding it very easy to develop and make changes. I’m never wondering where a given feature or mod should go anymore. Every code function has a definitive place where it belongs.

Back to the drawing room. More tea, vicar?