I find that it is very useful to see what someone else’s process of content creation and design looks like, and to figure out how people make decisions and iterate throughout the creative process.

This would be a very useful article if you’d like to see how an indie game developer makes design decisions about game systems and how they affect the design of other systems in the game.

I am currently working on a procedurally generated survival game, in which you play as chimps going through evolution, which I have code-named Project Comedy Evolution. I am the sole developer of the game and I am developing it in Unity.

Throughout November, I changed several game systems that lead to a lot of design changes. The following systems received a lot of love:

AI

I rewrote the AI system entirely in Playmaker. The reason I chose Playmaker, which is a visual scripting addon for Unity, was because I find it much easier to write finite state machines visually rather than with code, and Playmaker is an extremely good tool for that purpose. Its also used for the same purpose in one of my favourite games, Hollow Knight. It was also very convenient since Playmaker was available in the Humble GameDev Bundle, which was an insanely good deal, if only just for Playmaker.

The AI works like this — a chimp checks which “need” it needs to satisfy first in a certain order of priority — water, food or breeding. Then it looks for the nearest source of said need, and if it finds it, it starts moving in that direction. If not, it moves in a random direction and reorients itself until it comes across a resource that would satisfy that need. It then starts to consume it, and once it is satisfied, it moves onto the next need in the priority queue and seeks to satisfy that in the same way. The way this works is that the chimp switches between states which represent various behaviours such as moving, consuming or searching, and only transitions between them when certain conditions are met. For example, it would switch from moving to consuming, if it is in the range of a consumable resource which would satisfy its current need, i.e it would stop moving if it is thirsty and within range of a berry bush.

This sort of system is called a Finite State Machine, and it is probably the most common way of building relatively simple AI systems in the games industry.

Inventory

I wanted to do something quite different with the inventory system, since almost every survival game has pretty much the same system. They either have a hotbar with item slots, or a listed inventory which can be accessed by bringing up an interface that puts the core gameplay loop in the background, or some variant of the two approaches. After a lot of iteration, I found out that innovating a system like this is much easier said than done, and there is a reason why.

Since the game is predominantly about apes going through evolution, I thought it would be a good idea to have a system that deals with using hands for movement as well as carrying things, and the trade-off that that system comes with. The idea actually came from an incident in which an actual monkey entered my home and ransacked my fridge. As I drove it away, I noticed that it was running on two feet and carrying an apple in each hand, and as a result, was moving considerably slower than it was when it entered on all fours.

I designed a system where the player would have two hands, which would influence their movement speed based on whether the hands were occupied or not. There would be a dominant hand and a non-dominant one, and one would have certain advantages on using the dominant hand to interact with the world, for example, tools would work more efficiently from the dominant hand and you could carry more in that hand.

Prototyping and designing on paper is extremely useful to test systems before implementing them.

Now, I could either implement this in a way in which the choice of deciding which hand to use to interact would lie with the player, or I could implement it in a way in which the choice is taken away in favor of the system automatically prioritizing the dominant hand for interaction. For example, when the player moved up to a resource, and pressed ‘E’ to interact with it, the item from the resource would be placed in their dominant hand first, if it was empty, otherwise it would switch to the non-dominant hand. It the player wanted to drop an item, it would drop it from the non-dominant hand first.

The problem with this approach was that the player would have to keep track of which hand would be used in any given interaction in the world. The issue lies in the fact that two hands are not distinct enough from each other that it is actually fun to keep track of which hand would be involved in an interaction, and it would simply lead to a lot of confusion, even if there was a good enough UI that conveys the information. There was also the issue of control schemes — how would I let the player have individual control over each hand, while at the same time have keys left for other interactions in the game? This was not an easily solved issue. I also realized at this point that this system was simply too complicated — and not in a fun way — it seemed to be complicated for the sake of being complicated. So, in the interest of keeping things simple and accessible, I decided to scrap the system, and go with something more much rudimentary, but with a slight catch.

The next iteration of the inventory was much more easy to understand. You would start the game with two hotbar slots, and you could carry a stack of an item in each slot. As you explore the world, and evolve, you have the option to gain more inventory slots, and that is where this system differs from lots of other games’ implementations.