Levels of Abstraction in Game Design

This article was originally posted in my personal blog.

Game design is often perceived as an idea-driven discipline in game development, and many people tend to fall into the trap of thinking about it in terms of pure creativity, neglecting the technical aspect. While having ideas is nice and useful, it is important to remember that everyone has them, and that an idea per se does not have any value. What counts is the implementation, and while writing a concept document or pitching a game may seem like an exciting task, it constitutes a relatively small fraction of the actual work a game designer has to do on any given project.

I am not going to go into more detail about ideas, concepts, team brainstorming and creativity, as this is a broad subject that deserves a separate post. What I would like to talk about here is the technical aspect of game design, various production techniques that can be applied in different situations and help the designer solve complex problems with less effort and more precision. The real game design work begins after the team (even if it is a team of one) has agreed on the concept, and yet I feel like we are barely scratching the surface of production techniques.

If you are anything like me, you are in constant search for game design cookbooks, opinion pieces and postmortems, and are probably familiar with the brilliant work of Jesse Schell, Brenda Romero (Brathwaite), Ian Schreiber, Daniel Cook and others. I am not going to try and rethink game design as such in a short blog article. In fact, everything that I am going to say is compatible with and relies upon these groundbreaking works from before. What I would like to do here is share some of the thoughts on the subject of methodology that I accumulated over the last few years, compiling them in a unified theory that I like to call Levels of Abstraction (LOA).

Perhaps the best analogy for LOA is a YouTube video that me and my teammates used to watch daily while working on Paradis Perdus. It’s a half-mocking that-part-of-the-internet kind of thing which demonstrates the “cuil theory” through text pieces that become more and more abstract as the number of “cuils” (or levels of abstraction from reality) increases.

In simple terms, LOA is a framework that allows the game designer to apply their analytical skills in the most useful way possible. Abstraction is important to understand and balance the game system correctly, and different situations demand different levels of it. The game designer chooses the LOA which is most suitable for them at any given moment, thus ensuring the effectiveness of their work. For example, sometimes the best way to describe a mechanic is drawing a simple sketch and talking to the concerned team members, while in other cases a spreadsheet, a text memo, a flowchart or even programming code will be the best medium.

Suitable LOA for any given situation can vary based on the team, budget, production timeline, development phase, game type and dozens of other factors. Each LOA is a tool that lets the game designer formalize and communicate a game system better, thus giving them more control over it. All and all, I am going to discuss five LOA that I have most often encountered myself while working on various solo and collaborative projects. It is also important to note that multiple LOA can (and should) be combined within the same project and often even the same mechanic.

Discussion is highly encouraged, and, if you have something to contribute to the list or have something to say about one of the LOA, don’t hesitate to drop me a line or leave a comment. This post is reference material, so I am fully prepared to update and improve it if need be.

Level 1: Empirical

This is the level of abstraction that manifests itself as a an explanation in plain words. It is probably the most common way of explaining a game mechanic, often used in introductory sections of game design documents, on websites and in communication between team members.

Often this kind of explanation is accompanied by a simple illustration that shows how the game mechanic works, making the description clearer. These images are rarely very detailed and usually look like simple mock-ups of the game scene with some additional graphics for explanation.

LOA1 does not include any formulas or values and can be applied in situations where something has to be written down, usually because the game designer wants to remember something and come back to it later or to explain a mechanic in simple terms when no technical information is needed.

If LOA1 is used as the only way of explaining a game mechanic, it is the programmers who define how the mechanic actually works, finding the correct formulas and dummy values that the game designer comes back to later. This method of work often demands reiteration, but can be a good idea in case of small teams (including teams of one) with team members wearing different hats and having significant control over multiple aspects of the game. In a medium to big team, however, this may become a problem, due to the time it takes to reiterate.

Level 2: Schematic

This level of abstraction goes further and represents a game mechanic or a gameplay element in form of a graph or table. Thus, the level of abstraction is higher, and the gameplay is described more formally. It is common to see the second LOA in combination with the first one as a way of formalizing the system. Some mechanics and game situations are also better represented using the second LOA and don't need LOA1 at all.

This is a common way of representing level design on a local (mission) or global (world) level without doing any 3D modeling. It is also often used for balancing skills and actions using numeric values without changing the underlying formula.

It is generally a good idea to use LOA2 if you want to show and/or compare large arrays of data that would take too long to explain or write down empirically. Like LOA1, LOA2 does not allow for direct control of game mechanics using designer-made formulas. However, it may use the existing formulas for data representation and calculations.

Level 3: Maths

This is similar to LOA2 in that numeric values are being used, but apart from that the designer creates their own formulas to represent game mechanics, making the level of abstraction even higher than before, which gives them a higher level of control and a better perspective.

This level of abstraction is something that demands extensive testing before being implemented: either on paper or using a digital prototype of the mechanic that allows to modify the formula and different variables on the fly. The advantage of this method is that the game designer can achieve exactly the result they want by describing the mechanic in this way, allowing for more fine tuning and precise balancing. The downside, however, is that it may take some time before the programmer will start actually coding the mechanic, since the prototype must be tested before the implementation of the mechanic begins.

In general, LOA3 is good when maths matters: all kinds of logic puzzles, role-playing elements, and in general games that can be easily prototyped on paper without significant changes in their gameplay. It is probably an overkill for things like jumping, movement and everything else involving velocities, accelerations and other conventional physics variables.

Level 4: Algorithmic

The fourth LOA takes into account the ones that come before it. The game designer formalizes the game mechanic writing it down in form of a flowchart, pseudocode or simply as a sequence of actions with precise instructions.

It is hard to use this LOA for balancing things because of the nature of data representation, however, it is good for checking if the logic of the game mechanic works and making sure that things happen in a correct order. If this is not checked early in a complex game system, things can go very wrong later, and it will cost much more to repair them when they do.

LOA4 can point to specific values and formulas or not—this is entirely up the the designer. One should take into account the reason for using LOA4. If the goal is to test the whole mechanic on paper exactly the way it is going to work once implemented, then it is generally a good idea to use the real formulas and variables. In this case, automated finite state machine tools such as Playmaker for Unity may help. On the other hand, if LOA4 is used to determine whether the logic behind a specific mechanic works and to mitigate the risk of a wrong order of actions, a simple flowchart or an algorithm sequence can be used without getting too deep into the specifics of each state.

In my experience, both small and big projects can benefit from LOA4, but the designer should use it with caution, because it generally takes a long time to formally write down an algorithm for a complex system.

Level 5: Programming Code

It is often a good idea to write a mechanic (or a part of a mechanic) down in code directly, bypassing LOA4, because producing formalized algorithm structures for complex systems may take a significant amount of time, not necessarily justified by the usefulness of the final result. This is usually the case when the algorithm in question includes a lot of of small and/or simple actions which could easily be represented in code, taking up less space and demanding less effort and debugging. The image below shows that sometimes one line of code can replace a whole bunch of finite state machine actions.

It is generally a good idea to write down either very specific or very isolated mechanics this way, unless the game designer codes the game on their own, in which case writing everything in code is the only option anyway. Otherwise, the utility of this approach should be considered in terms of the formalization of the mechanic and its explanation to people who are going to implement it, so programmers. That is to say that you should consider it if you think that it is the easiest way to write a mechanic down.

Oh, and by the way, haven't you heard? As a game designer, you need to know how to code, period.