How I Design Games — A Deep Dive into the Creative Process of an Indie Game Developer
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.
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.
Depending on your playstyle, this might be something you want to prioritize, or not, as more inventory slots would be useful if you wanted to play the game in a more sandbox manner, i.e, build structures and what not, but not as useful if you wanted to maximize speed for more combat options. I felt that this system fit in much better with the evolution mechanic, and I didn’t completely have to get rid of the idea of the hand to speed trade-off.
Movement and Interaction
The simple addition of this inventory led to a massive rework of two core systems — movement and interaction. Previously, the player moved with the directional or WASD keys on the keyboard, and interacted with resources in the world, with the ‘E’ key. This was perfectly adequate until the inventory was added, and it forced interaction to be more than just the simple case of moving up to an interactable item and pressing E on it to fill up a resource. What happened now was that the interaction between the resource and the player was broken up into two steps, rather than one step, i.e from harvesting it, to consuming it. First it needs to be interacted with, which places the corresponding item stack in the inventory, and then using it in the inventory consumes the stack.
What I could have done to solve this problem quickly was to simply add another key to consume the item in the inventory. However, this would have been a lazy solution and would need to be reworked later because what if, an item needs to combine with another item to turn a resource into a consumable? A simple example would be using food on a fire, and then eating it. Also, having a player stand in the area of multiple resources and hope that the correct one would be interacted with, is simply annoying and creates too much ambiguity.
Good design should try to move away from ambiguity and move towards intentionality, whether that is through detecting the intention through context, or simply making the interaction so explicitly obvious that the ambiguity does not exist.
There was also the issue of creating multiple keys for similar interactions, which would lead to more mental overhead for the player, by having them focus on which button to press, rather than what they want to do next in order to survive, and break up the flow of the gameplay.
The solution I came up with was to change the movement and interaction from just to the keyboard, to also include the mouse. I got the idea from Don’t Starve, which is also a survival game in which you can interact with items in your environment and in your inventory. The way that Klei Entertainment, the developers of the game, have solved this issue, is by using the mouse for movement as well as interaction, while not completely removing control from the keyboard. A mouse click is much more targeted and directed than a button press, and is a perfect candidate for a key that can be used to interact with specific items and resources in the environment.
Due to this change, the movement had to be altered as well, because during playtesting, I realized that moving with the keyboard while trying to interact with a resource in the world was too jarring, since the movement also changed the position of the resources on the screen, and the player had to keep up with it using the mouse. So I changed the movement so that the player could also move with mouse clicks, and if they were out of range of an interactable resource that they had just clicked on, they would move to its position automatically and then interact with it. I left in keyboard movement and didn’t remove it completely because of situations in which the player was moving but wanted to avoid clicking accidentally on things that they did not want to interact with, for example, moving through a crowd of passive mobs that could turn hostile if you attacked them.
After I was sufficiently happy with these combinations of changes, I worked on the inventory to implement some quality of life features such as being able to move items from one slot to another, dropping items with a mouse click, automatically switching to another item slot that contains the same type of item when an item stack runs out during consumption and being able to select a particular item slot in your hotbar without having to scroll to it, by pressing a number key on the keyboard.
I also changed resources so that they break down upon several mouse clicks and then the resultant item drops can be picked up off the ground, as opposed to the previous approach in which the items were just placed in the inventory directly. This made resources appear more harvestable rather than just be sources for item stacks. This is something that I am still experimenting with.
How does this tie into evolution?
Since the game is primarily about evolution, I often consider how all these systems tie into that concept. The idea here is that these systems in of themselves don’t involve evolution directly, but interact with each other to create events that result in evolution. For example, if a chimp finds certain resources or technologies, that allow it to survive in icy temperatures, then it would adapt better to living in those icy temperatures and face different threats than chimps adapted to a warmer savanna biome.
I want the evolution to result through player choices, and each playthrough would have a diverse set of evolutionary outcomes based on available resources, player choice, and the world generation. This would only come about through progression in these different systems that I am setting up, and for the evolution mechanic to shine through, I’d need to create these basic systems first before I can fine tune their individual interactions.
Final Thoughts
I hope this was a useful insight into what makes game systems tick and how changes in the core loop of a game cascade out into all the other systems, and vice versa.
—
About Me
Thank you for reading! I am Kabir, founder of Overcome Studios, an indie game development studio based out of New Delhi, India.
If you want to keep up with development and provide feedback, then you can join our discord server and participate in the development process and chat with me!
If you’d like game development videos, I upload a semi regular devlog on my YouTube channel in which I go over the process of making and marketing my second indie game.
You can also check out my last game Overcome, a 2D platformer about beating your inner demons without attacking them, based on my own experience with cancer and heartbreak.