Yeah, I know software engineering is boring. On the other hand, game development is exciting. But there’re some good reasons why game development needs to look a bit at software engineering.

Game development is growing every day even more technologically complex. No matter how good SDKs and middleware (i.e., game engines) may become. No matter how many people we put into a single project. Game development productivity is very low. Games are long to develop and cost a lot of money. We need to improve our software development process in order to focus on our unique characteristic: building better games.

In software engineering, a typical software life cycle includes requirements, design, implementation, verification and maintenance. In the game development life cycle, ideation (requirements) and design are performed by game designers. With a concrete game design specification, programmers and artists step in for implementation. Programmers manually translate the game design specification into source code that can be compiled and executed in the target technology (i.e. PC, console, mobile, etc). Artists create the art assets used by the game. Once the game is implemented, it’s playtested for verification. And here comes the BIG mistake. Game design refinements are not updated in the high level game design specification. Instead, they’re updated directly in the low level implementation source code. In software engineering, this mistake is commonly known as the programmer’s shortcut. A low level maintenance not only makes the design documentation completely obsolete and useless. It makes maintenance an extremely error-prone and expensive task. We are lost in a dangerous journey and we’ve lost our only map. Chances are we won’t make it alive.

And there are some other game development specific problems derived from the programmer’s shortcut. We all know that iterative game design means better games: finding the fun factor through incremental gameplay refinements. But how can we iterate over an increasingly complex source code? It’s a growing mess. We need to make gameplay readjustments at design level and then, re-translate the game design specification into code. But we can’t do that again. The manual transformation from game design concepts to game implementation concepts is very expensive. It took the programmers some precious time to do it once, and I’m sure they’re not willing to do it again.

Wouldn’t be great to have a game design compiler that automatically translates game design high level concepts into code, just like a source code compiler automatically translates source code into binaries? We can just forget about source code as much as we have forgotten about binaries. But before that, we need a precise specification language for game design.  

How can we precisely specify games?

The traditional solution is to use written natural language. Of course, we can fill pages describing how our game will be. But natural language is vague and imprecise. And specially describing interactive systems, it grows short of expressiveness. So it’s a very bad specification language for game design.

In software engineering, there’s a thing called Domain-Specific Languages (DSL). ADSL is a language designed to be useful for a specific domain task. So we need a DSL for game development. More accurately, we need a DSL for game design.

I’m not going into details, but there’re two major issues when we’re dealing with a DSL for game design:

The first issue is about videogame design abstraction level. Some people can’t think of a videogame outside a concrete technology implementation. I prefer to think about a videogames at a high level of technological abstraction, with independence of their implementation and target technology details. So we need a high level DSL for game design in order to talk about Pac-Man without going into Atari memory slots. In software engineering this is called a Platform-Independent Model (PIM). Don’t worry about technology specific details, we will address them with a Platform-Specific Model (PSM), at a lower level of abstraction. So we can specify Pac-Man as a high level PIM and translate it into many PSMs for many target technologies.

The second issue is about game genres. Some people prefer a genre-specific DSL that expresses game design concepts in such a concrete way that all genre conventions are easily represented. For instance,a RPG DSL should provide concepts such as experience points, health, weapons, spells, etc. The problem arises when the genre is so vast that different sub-genres coexist or when the genre is evolving and genre conventions change. The DSL becomes incomplete or obsolete. That’s why I don’t like genre-specific DSLs. A genre-independent DSL will provide those game design concepts that are generic to all videogames.

But what are these technology-independent and genre-independent game design concepts, anyway?

That’s my initial proposal, based on Crawford’s interactivity cycle. Games can be seen from multiple perspectives or views of interest. Gameplay, Graphical User Interface (GUI) and control are the three main perspectives that all games should have.

Talking about gameplay we can specify how many players interact with the game. We can also specify different game entities that exist inside the fictional game system. A game entity can be controlled by a player (being a player character) or by the AI of the game (being a non-playercharacter). There’re also passive game entities which show no intelligent behavior. Gameplay rules are precisely defined using these concepts. I’ll talk about game rule definition some other day. It’s a topic on its own.

Talking about GUI, a game is composed of screens. Don’t think on screens as levels or stages but as graphical information layouts. Each screen represents different game entities or game information using display primitives such as images, progress bars, numbers and text. All screens can be static or have horizontal scroll, vertical scroll or bidirectional scroll.

Talking about control, each player uses a controller such as a keyboard, mouse, joystick or gamepad. Each controller is formed by different control elements such as buttons, triggers or joysticks that respectively send 0-dimesional, 1-dimensional and 2-dimensional information to the game system. More accurately, each player interacts with a control element in order to perform a player character’s action. Control element interactions may be pushing or releasing a button, holding a trigger above or under acertain threshold or moving a joystick in a certain direction.

And that’s a high-level genre-independent DSL for game design. I know it’s fairly obvious, but it works pretty well. We can specifyany game using these three simple perspectives. Of course there are other perspectives we can add: audio, story, AI or level design. But that’s just a starting point.

Pac-Man is a game played by 1 player. It features a single player character (Pac-Man) and many NPCs (the ghosts). There are some passive game entities such as the marbles and the power pills. Pac-man GUI has a single static screen where all game entities are displayed by images. Additionally, the player character score is displayed in numbers and the player character lives are displayed with an icon progress bar. The player uses a joystick or a keyboard with 4 buttons to move Pac-Man.

The first advantage of DSLs is that they’re precise. There’s no ambiguity, so anyone can understand what the specification means. Even a compiler can understand what it means.

 Another advantage is that DSLs are easily diagrammed. Each primitive concept has a visual representation, making the whole game design specification pretty intuitive and easy to understand. So we have a precise specification with a clear and concise representation.

OK. My DSL is cool. But, is it useful? Can game designers really use this DSL in order to express their game designs? Probably not ALL their game designs. But I’m sure it’s useful form SOME game designs: the simpler ones. It’s still an academic tool. It works well on Pac-Man and Defender and lots of simple old games. But again, that’s only a starting point.