An arcade idle game can be thought of as an engine. Similar to an engine it has various parts and a resource flow between the parts.
In my previous blog post on arcade idle, I explained that an arcade idle game has a collection of timers that are connected together to create a process. This process is an engine. The play of the player is to optimize the engine. To understand how we can add more gameplay to the game we first need to understand the structure of the game.
We will start by analyzing Moon Pioneer and then we will compare it to other arcade idle games.
Let’s start simple. Here we can see an oil sourcethat extracts oil and saves it on the oil storage
Now, let’s make an abstract representation of it. We want to make an abstract representation because it shows us the bare skeleton structure and it will make things easier as we go on. We will use the Machinations diagram for this. But we’ll keep it simple so that it’s easy to understand. The details are not important. What is important, is to understand the concept. These kinds of flow graphs can be made using any other tool, even on paper. But to visualize the flow of resources, we are using Machinations here.
We can understand that the oil source is generating oil at a certain rate. From the graph, we can assume that the oil source is generating 1 oil every timestep (we consider 1 timestep as 1 minute, it’s merely a unit that we will follow)
So far so good. Now we will see how the oil is moving from oil storage to the player.
In the game, when you move to the oil storage, the oil automatically moves from the storage to the player stack. Let’s ask a question here. How long does it take for the player to acquire the oil? The answer looks like it’s the animation time of the oil from the storage to the player. But it’s not. It’s the time from the player’s intention to acquire the oil to the time the oil is acquired. Or we can say
Oil acquisition time = Time for the player to move to the storage + Animation time of the oil from storage to player
We will ignore the animation time for this particular use case for simplicity and say
Oil acquisition time = Time for the player to move to the storage
So we can finally conclude that the rate at which the player acquires oil is the same as the rate at which the player moves to the store which we will simply use as player speed. Let’s abstract it out
It’s worth mentioning that, player speed here is really a relative player speed. As more storages appear and more things to interact appear, the relative player speed decreases. For example: If there are a lot of interactable items on the map spread out, it’s likely that the player’s position will be much more spread out thus decreasing the speed to come to the storage. Also, if there are more things to interact with, instead of directly going to the oil storage, the user might intend to make a stop somewhere else first. But for now, we will call it player speed to keep things simple.
We already have an engine, albeit a simple one. Resources are flowing from one part to another at a certain rate. Instead of diving further into the game, let’s see if it’s possible to add more gameplay on top of this to make things interesting. We can let the player control the flow as that would let the player optimize the engine as they want and define it as they like.
First, let’s focus on Production speed. We can let the player invest the oil using which they can add more oil sources, which in turn will increase production speed. We can add a feedback loop that increases the production speed.
In the graph, we use 30 oil units to create 1 oil source which in turn increases production speed by +10. This is a positive feedback loop using which the player can alter the engine and define it as they like. Implementation of this in the game is similar to letting users place new oil sources.
In the game, we can see a different implementation, where the player invests in runners to provide energy to the oil source so that it can work faster
Graphing it looks like this
Can you relate it to the previous graph? It’s the same feedback loop, just a different representation
Similarly, we can allow users to improve the Player Speed flow with another feedback loop
Thus, if we can find the underlying structure, it’s easy to find out where to insert gameplay elements. How is then, just a matter of creativity. These feedback loops make the game more interesting and also increase the complexity and the depth.
We could, if we want, add a negative feedback loop that occurs randomly
This graph shows a negative feedback loop that halts production. We can show it in-game by letting a random disaster happen at a certain probability. Then, we can let the user fix that disaster by investing some resources. Although, in hypercasuals it might not be the best thing to do. But it can make interesting gameplay even if the probability of the disaster happening or the disaster impact is very low
Let’s quickly analyze one more arcade idle namely Healing Rush.
Here are the steps it takes to complete a loop
- Patients come in and wait
- The player carries the patient to bed
- The player brings meds to the patient
- The player gets money
If we graph it, it looks like this
Here, we can use the money that’s acquired to create different positive feedback loops with the flows to create interesting gameplay. Here are some examples
- These 2 flows can be increased by increasing the player stack so that the player can carry more patients and more meds at the same time. It can also be increased by hiring more staff who can do the same and so on. Which has been implemented in the gameplay
2. This number can be increased by treating high-profit diseases. One way to do it would be to increase medicine stalls from where the player brings medicine from where the new stall gives a supply of high-profit medicines.
3. We can improve this flow by improving player speed (as the 2 timestep indicates that it takes 2 timesteps for the player to go to the medicine cabinet and bring back medicine). Or we can improve it by creating new kinds of beds that have medicine cabinets included
4. We can of course improve all of the flows by letting the player create new rooms, where each room has the same engine. Or, by hiring staff who automatically completes all the flow.
5. We can also negatively impact this flow by giving a limit of beds. For example, the game starts with 1 bed, so it creates a bottleneck if the player can bring 2 patients at once. Then we can allow users to improve the flow by adding more beds.
These are not specifically bound with arcade idle games but work with most resource management games. So to sum up, look for flows in the game and find interesting ways to let the user impact the flow.
