A database-driven engine for strategy games

13 March 2015

You know strategy games, right? You start with a few units; they harvest resources with which they build buildings; those in turn make more advanced units that can engage the opposition and hopefully win. All while gathering even more resources, upgrading your settlement and so on.

If you thought Starcraft or Settlers of Catan when reading the above, you're on the right track.

But strategy games didn't begin with those. They didn't even begin with Dune 2. One of the earliest such games — the first great hit — was called Hamurabi and could be played with a teletype. Yes, it was a text game, much like the original Adventure and Rogue, and almost as addictive as them. Other famous strategy games were born during that era, such as Star Trek and Trade Wars.

You'd think all of them belong in history books, but during this century a new crop of browser-based multiplayer games have been eschewing graphics again in favor of an interface some people have derisively called "playable Excel documents". In all honesty, it's hard to fault them when you look at OGame; at least its competitor Travian still bothers to have a map.

But the joke's on them, because these games are enormously popular.

I always loved strategy games, especially the turn-based kind, but for some reason I was never inspired to make one. The one time we tried, in my days at a web agency, it turned out to be a daunting task that we had to back away from. In time, the idea was pretty much shelved.

Until, that is, a chat with friends reminded me of PuzzleScript, an intriguing little tool for making puzzle games in the vein of Sokoban and Supaplex. It got me thinking: for interactive fiction there's Inform 7 and Twine; for RPGs, RPG Maker. Adventure gamers have AGS, and so on. But for strategy games... there's nothing of the sort. Sure, you can always make new scenarios in Battle for Wesnoth (though reportedly it's not very easy), or new nations for FreeCiv (only you can't customize everything). Some roguelike games, too, have so-called info files you can edit to put in your own monsters, weapons, spells... you get the idea. But nothing lets you create a whole new game.

From that to starting to design such a system was just a step.

Imagine, if you will, an authoring tool that allows you to define a strategy game not unlike the examples given above. For simplicity's sake, let's stick to the map-less type. You can use it to describe what kinds of units you can have — workers, archers; what buildings you start with — town hall? — and what others you can build; the kinds of resources used in the game, like wood and gold you can gather to pay for all the building work. You can also have end goals and/or enemies to fight, unless you want a playground like SimCity. Then an interpreter program takes all this data and referees the game for you, much like a dungeon master in Dungeons&Dragons.

Here's how a particular implementation of Hamurabi might be encoded in the database (imperfectly):

Not depicted: many more needed fields, such as messages for every little happening. Also buildings and end states, because Hamurabi doesn't have any. Random or regular events that allow you to make one-off choices. More features I can't think of right now.

Note how the game's description is purely abstract. Presentation would be the engine's job. In practice, I'd also want the ability to add graphics, for those platforms that can show them. There's a world of possibilities out there; in this write-up I'm focusing on the basics.

The expression language shown is just for illustration purposes. In the actual software, I'd favor an abstract syntax tree stored in a suitable format, say JSON — or Lisp, for that matter. (That would be symbolic expressions for the pedantic reader.)

This choice requires an explanation. When I wrote Jaiffa, it was easier to encode the entire game state in Javascript objects. Moreover, all the event handlers were simple JS functions... that could be replaced on the fly. And that made saving and undoing impossible.

Data, you can serialize without a problem. Code, not so much — unless it's also data. Oh, you can make code segments read-only, like in the Z-Machine, but that still leaves the problem of specifying a virtual machine. A non-trivial task to say the least, error-prone and a criticism magnet even if you get it right.

An abstract syntax tree on the other hand keeps its structure. It can be eyeballed, decompiled without losses, transformed and analyzed with tools. It can be represented in the same format as the rest of the game database, and therefore saved along with it. Want to edit code visually, like in Scratch? An AST is the natural back-end for that.

But enough geeking out about metaprogramming.

I don't yet know what an authoring tool for this format would look like. It could be anything from a glorified spreadsheet program to a domain-specific language the likes of which I proposed before. Come to think of it, I don't know what the format itself would be. An SQLite database? JSON files in a ZIP archive, together with assets? Both have pros and cons, and in fact I'd like to see a variety of approaches being tried out.

Either way, this system could be used for both single-player or multiplayer games, with a variety of timing systems: turn-based, real time, action point-based, you name it. You could have stories. Not so much travel, at least not easily, but the gaming world is full of Elite clones anyway. Why not make the DS9 of space trading games instead?

Now that's an idea...