Clean game design principles

Hello everyone, my name is Artyom Volkov and I’ve been working as a game designer for about 13 years. In this article, I’m talking about clean game design principles. They can be quite useful when you want to explain to beginner game developers, particularly game designers, how to make a good game design.

The most frequent questions I’ve faced (and even asked at the very beginning of my career) are “How to make a good game?” or “How to make a good game design?”. The problem with these questions is that there are no right answers for them, except “Don’t develop a bad game, develop a good one”. The trick is that each game designer has their own opinion on how to make a good game because of their personal experience and approach. Moreover, the answer depends on the genre of the game.

It’s great, that you can find a lot of information about creating games in a particular genre. However, it can be extremely overwhelming for absolute beginners who have just started their game development endeavour. Not only is it difficult because they usually don’t know which game genre they want to develop but also because they still can’t make head nor tale of the game design basics. And it was a fairly challenging task for me to find an answer that would be genre-agnostic and easy to understand as well.

Ultimately, I found it in programming. While I was studying clean code principles, I noted that many approaches from these principles I use in game design (of course, a little bit differently, but the ideas are absolutely similar). At that moment the clean game design principles were born.

It’s essential to remember, that these principles aren’t strict rules. They’re general recommendations which can help to make better games and avoid the majority of game design sins about which I delivered a speech at DevGAMM Online 2021 last November.

Now it’s time to dip into these principles, which are:

1. KISS;
2. YAGNI;
3. SRP;
4. LCP;

KISS

Keep it simple, stupid. This principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.

I dare say that the majority of beginner game developers are prone to design convoluted game systems which are arduous to develop, maintain and update. It’s because they have a false notion that the more sophisticated the game system is the more fun it is for players, and the more “professional” it looks.

In my experience, it’s the most essential principle of all, as it drastically influences game design approaches. However, it’s also challenging to use, as with time you learn how to design quite complex game mechanics, and even after 13 years of experience, you can completely rethink the system you have designed in a more simple way.

Nonetheless, everything is good in moderation, don’t overuse KISS to a degree when your game becomes bland and boring as everything is overly simplified.

YAGNI

You aren’t gonna need it. This principle states that a game designer shouldn’t design a mechanic/system until deemed necessary.

Usually, beginner game designers strive to add as many game mechanics as they can. Most of the time it happens because beginners:

1. Think that the more mechanics game has, the better it is;
2. Tend to copy mechanics and systems from their favourite games blindly;
3. Try to cover all “what if” cases;

John Carmack has written about software development “It is hard for less experienced developers to appreciate how rarely architecting for future requirements/applications turns out net-positive.” This is also true in terms of game design. The less experience you have, the less you understand if you really need a mechanic.

To use YAGNI I strongly recommend writing a list of goals which you want to achieve by adding a new game mechanic/system. In my experience, not only will such a list help you to understand why you need this mechanic, but also it’ll help to explain it to your team. Sometimes, it can lead to a feature cut, as you can come to a conclusion, that you don’t need it. It’s essential to remember, that abstract “fun” isn’t a goal at all. A good game designer always must define what kind of fun they are going to bring to a player through the mechanic.

In the end, YAGNI works well with the KISS principle. The more mechanics you add to the game the more complex it becomes, and KISS says that it’s better to stick to the simple design. And vice versa, you aren’t gonna need overly convoluted systems in your game.

SRP

Single-responsibility principle. It states that every game system and a mechanic should have responsibility over a single part of a game and it should encapsulate that part. In fact, it sounds almost exactly like SRP in programming.

It’s quite usual when a beginner game designer tries to create a system which serves several purposes at the same time. As a result, they become overly convoluted and hard to maintain. You should monitor if a system/mechanic has excessive functionality and you should split it into several ones.

Not only does this principle help you to make less intricate game design, but also it helps programmers who will implement your game mechanics and systems. But remember, you must not do the programmer’s job, SRP in game design isn’t about program architecture, but about game design approaches.

LCP

Loose coupling principle. This principle states that game mechanics/systems should be weakly associated and have minimal influence on each other. Actually, this principle is almost identical to a similar one in programming.

You should perceive each game system as an independent building block which you use to design a game. This approach will definitely come in handy when you must do a feature cut, or redesign some parts of a game. Notably, this way of designing game systems also will help programmers.

Remember, in an ideal world, you effortlessly add and remove mechanics with ease without much trouble. However, in reality, this principle doesn’t guarantee that you won’t face any difficulties if you’ll stick to it, but it facilitates the process of adding or removing additional systems in your game.

Conclusion

First, you must keep in mind, that these principles do not work separately. I bet, that an attentive reader may notice that each principle reminisces the other one. Thus, they’re tightly knitted and once you start deeming about one, others come to mind without any invitation. In addition, they balance each other, if you try to use one religiously, you’ll definitely “violate” another one.

Second, everything is good in moderation. As I said before, these principles are recommendations, trying to use them as strict rules can lead to many problems with your design approaches and a game.

Lastly, if you are brave and dedicated enough to get to the bottom of clean game design principles. I strongly recommend you to spend some time learning basic programming outside the game development, especially SOLID and other clean code principles. As I mentioned before, studying programming inspired me to create these principles.

I hope this article will come in handy for beginners and even professionals who are eager to teach game design. Moreover, I hope to expand these principles in the future and add new ones which are designed specifically for game design. If you have ideas about new principles, feel free to reach out to me via email tricky.fat.cat@gmail.com