Improving Game Design Process
Game designers don’t seem to realize it, but the tools available to them are very poor. The process of game design is filled with difficulties and road blocks. I’m not talking about games as software development — I’m talking about games as rulesets design. The wants and desires of software developers are entirely separate from the wants and desires of a game designer, yet both use many of the same tools. Game ruleset designers need better tools if they want to push the boundaries of the medium.
When I say game ruleset designer, I mean a game designer concerned primarily with rulesets and interactive systems: I’m talking more about board games or strategy games and less about walking simulators or heavy execution games. The experiences of the latter are inseparable from the software, while games based on rules are not. For example, chess can be played with rocks on a beach, while StreetFighter can only be played on a computer which can run StreetFighter.
Current Typical Process
The game design process starts with ideas in the head of a designer, who then usually writes these ideas down into a design document, creating a more concrete ruleset. To prove the quality of these ideas the designer has two options. They can either make a paper prototype, or they can program the game into playable software. Both options are inherently problematic and a drain on the design process.
One option is to move from a design document to programming the rules into software. The biggest issue here is that this requires the designer to know how to write code. This is a massive time commitment: Acquiring the programming knowledge necessary to quickly iterate on a game design can take years. Even once acquired, game programming is entirely different from game design and it requires a different headspace. A game designer should not be required to also be a programmer.
Game designers often don’t program in their own game engines, because that is an even bigger time commitment, instead they use off-the-shelf packages like Unity or UnrealEngine. However, this makes the designs dependent on another software package: Without maintenance the game designs will be broken and unplayable in a few years.
If the designer decides they don’t want to spend years becoming a programmer, then they’ll then decide to prototype their ideas using paper. Though paper prototypes have their own major problems.
Creating a paper prototype is finicky and annoying. The designer must cut out paper in specific shapes and glue them onto other paper or cardboard shapes and sometimes print out grids or even draw the grid and then to play the game the designer must simultaneously run the game and play the game. Ideally the designer should be only playing the game while the rules should be managing themselves. Further, randomness is very annoying to simulate in a paper prototype. The designer must manage each varying type of randomness that the games mechanics require.
Even worse, some rulesets are impossible to paper prototype. A traditional fog of war mechanic is a good example here. Everybody knows what fog of war is, but managing it with paper is impossible since the player cannot know what is hidden by the fog of war. This discourages designers from working on certain mechanics, which is obviously a huge problem.
The real deal breaker with paper prototypes is the difficulty in playtesting. The designer must be in the same room as the playtester. This completely destroys the feedback loop inherent in design iteration and improvement.
While paper prototypes have unique problems, both prototyping solutions do have some similar problems. They both take the designer out the design head space since writing software or cutting paper require different skills than designing a game. This pulls designers away from the actual design itself and into thinking about cutting, gluing, or coding. An ideal toolset allows designers to focus entirely on the design.
All current prototyping tools completely lack archive-ability. Ideally a game prototype is reliably archivable. A designer must be able to explore an idea, put it away, and come back months or years later when something sparks their interest. Both systems fail in this goal. Paper prototypes require a complete accompanying rulebook to play. Because the rules are not enforced by the medium, it’s very easy to incorrectly play a paper prototype, especially when returning to it from some time away. Similarly, software rots over time: without constant maintenance, the life of a program is only a few years at best.
These problems are entirely unique to game design. No other artistic medium would allow these kinds of drains on their process. Writers and painters get to write and paint. They don’t have to learn an entirely separate skill before they’re able to create. Within minutes a musician can create a full listenable piece. At best a game designer can only fully test their idea after a few days.
Why should you care
I see this as a huge problem in game design. The medium of game design is weighed down by an anchor of poor process. Designers are unable to quickly and efficiently iterate on their idea which leeches the creativity and momentum of the entire process.
Also, these process problems scare away potentially outstanding game designers. It’s not hard to imagine someone filled with ideas, but lacking the technical programming skills necessary to implement them. This is a tragedy that will continue to slow the progress of game design until it is fixed.
Additionally, this lack of strong process slows the progress of games theory. I often read game design articles, claiming that games should do this, or games shouldn’t do that. But they almost never cite current games. That’s because it’s very difficult for designers to prove their theories. I can take years to build a game exemplifying your ideas. Again, this slows the entire medium. Game designers need a quicker iteration process if we want to increase the rate at which the games medium improves.
We’ve identified a problem. How are we going to fix it? Here are some solutions which have potential. These solutions help facilitate the strategy design process at the expense of games as software production. Thus these solutions are happy to sacrifice the typical software quality metrics for design expressiveness and iteration speed. The goal of these solutions is not a shippable piece of software but instead something different.
I’ve outlined those goals below. These metrics are ideals. Achieving every one of these with one tools is quite a difficult task, but it is important to be clear about what we want from our tools. Here are, what I think to be, the three most important metrics.
Designers must be able to archive what they create. They must be test out an idea, put it away for months or years, and open it up again to resume work. They must be able to do this with a minimal time cost. This means the tool must be future proof. Anything created in the tools must be able to live forever into the future (this isn’t as hard as it sounds).
The tools must be light and simple yet powerful. Designers need to be able to quickly and simply express ideas of complexity. This means very little ‘boiler plate’ work.
This tool should allow designers create games in an exploratory way: testing, modifying and deleting need to be done quickly and easily. This means the software must be quick and light. Designers should never be waiting for the tool to do something. The tool should always be waiting for the designer.
Alright, we have some ideal metrics and we know the problems with our current tools. Lets look at some possible solutions. As a warning, the solutions below are quite technical. I’ll do my best to explain them in a way anybody can understand. I also omit further in-depth explanation because of the complexity.
One solution is to simply write and package the code which is used most commonly. This would speed-up the design process as the designer would be writing less code. Ideally the designer would have a visual editor which allows them to connect different pieces of this library into something meaningful. This would be something like Unity except explicitly focused on the design iteration process while ignoring the production of shippable software.
This is the most straight forward solution but is far from perfect. This solution does not solve any of the archival issues since the designs are necessarily dependent on the library in which it was produced. The nail in the coffin here is the lack of expressiveness. The only features your design can include are ones which were already thought of and implemented. This solution would speed the design process, but it would strangle designer’s creativity, producing a lot of very similar games.
Another promising avenue is the Game Description Language (GDL). GDL is a language which can rigorously encode any set of rules. It was developed to entirely encapsulate a game in a way that could be played by an artificial intelligence. Below is an example of the Monty Hall door game written in GDL-II.
GDL has many advantages. Because of its mathematical roots, it has been proven to express all possible games. This provides a sound theoretical foundation which truly unleashes the designer’s creativity. The language is quite simple which keeps the cost of entry low.
Importantly, GDL is completely uninterested in the computing necessary to run the game. It only declares the rules of the game, not how the rules are to be implemented on a computer. It is up to an entire different piece of software to run the game. This means GDL is completely future proof and perfectly archivable. A designer just needs to keep the GDL rules and the game will always be playable at any point in the future.
GDL has one big issue: it’s too minimal. Even creating something small requires a very large amount of writing — designing even basic board games in GDL is prohibitively difficult. The language is too verbose and too rigorous. It might be possible to solve this by extending the language with common design patterns but I think this gap is too large: So many new features are required that the result would effectively just be a different language.
ASP and Event Calculus
Another possible solution, which has a lot of promising research to behind it, is Answer Set Programming (ASP). Put simply, ASP is a programming paradigm focused on logically declaring problems in a way that can be solved by another program. Event Calculus is then built on top of that, and it allows for these problems to change through time. All of that is very complicated, and unfortunately, using this kind of prototyping tool would require knowledge of these complications.
This solution has many of the same problems as GDL, though not to the same degree. Expressing a game in ASP can come somewhat easily (though not as easily as I would want) however; there is no ASP language designed for games so they all have many unnecessary annoyances. For example, the language has no concept of time, or turns, so every line of the program has an annoying variable to manage the passage of time. ASP is a step in the right direction, but it is not quite there entirely.
Currently, there is no good solution. Though that isn’t surprising since nothing has been designed with games ruleset iteration in mind. I think the best solution is to design a new language with all the good and none of the bad. Obviously that is easier said than done. Complications always arise — however; it certainly seems possible.
This new language would be designed specifically for strategy game ruleset development. It would have an AnsProlog like semantics and syntax, but it would drop much of what is irrelevant, instead adopting features helpful for designers. Finally this new language would be declarative, so it will also be archivable. I’m happy to say I’m in the early stages of designing such a language. I don’t yet have anything demonstrable, but I’m making progress based on the goals and direction outlined above.
Creating a new programming language sounds like the best solution, and that’s because I’ve defined it as such. There are no good tools for strategy games ruleset design. All current solutions are fraught with problems and none of them come close to achieving the metrics I outlined above. Part of the reason is because nobody has set out to specifically fix this problem. All current solutions are too abstract and general — game designers need a focused solution aimed at solving only their problems.
I think this is a big problem with the industry, yet it isn’t talked about enough. Game designers desperately need improved design tools. Such a tool would empower game designers, their ideas, and the entire industry.