Arcade idle games are a no joke development-wise. It can take up a lot of time and effort and understandably so. The day 0 playtime of arcade idle can reach up to 4 times higher than hypercasual in general which makes up for the higher CPI.
The development team needs to focus on the differentiating factors of their arcade idle and the game balance rather than creating everything from scratch. Hence, it’s important to understand how to create the modules in a modular way, so that they can be reused across projects. It will help the programmers save up a lot of time and if the whole development team is aligned on the framework, one team can get support from the other teams if needed easily as the new developers will already have some sort of familiarity with the system
In this article, I will discuss a few modules that are worth creating
Player
The most important module is the player. Most of the other modules rely on it directly or indirectly as the whole game revolves around it. We need to have the following sub-modules up and running
1. Player Movement:
This will dictate the movement of the player. It should be able to take input, show the input using the on-screen joystick, and move the player
Each of the functionalities above should be kept separate so that we can replace any of them if we need.
It’s a good idea to use interfaces to avoid direct dependencies. For eg: The player mover script can have an interface IPlayerMover.cs so that if at any point we want to change the way the player moves, we should be able to do so without breaking everything. But we will have a basic implementation of IPlayerMover.cs ready so that we don’t have to implement it every time.
2. Player Sensors:
The scripts in this sub-module will take care of all of the sensors. A sensor can be a trigger that senses a particular tag using OnTrigger callbacks. Or it can be a raycast going down which senses if there is ground under the player.
They can be base sensors of each type and then other specific scripts should be able to inherit them to sense specific types of objects. Some examples can be as follows:
Resource sensor: Senses if there are any resources within a specified area
Trigger sensor: Senses if there are any interactable triggers within a specified area
Land sensor: Senses the land the player is on and if there is any valid land in front to make sure the player does not fall
3. Player Storage:
This sub-module will track the collected resources by player and fire callbacks so that other scripts can listen to this and act. This can also host a UI script that takes care of showing the current player resources on the game UI
This should also be able to send resources to a target, and receive resources from a target preferably with animation.
It can also stack the collected resources. The stacking behavior should be yet again a separate script that can be extended. For example: IPlayerStack.cs which be extended to PlayerStackLinear, PlayerStackMultiLine etc
These sub-modules cover a basic player module and we can already understand how much it can do and how generic it can be
Triggers
What did I mean when I say trigger? A trigger is an object that is interactable in the game. By interacting with a trigger the player essentially activates an action. The action can be dropping resources, collecting resources, creating something, activating a powerup, and so on.
There are a few behaviors we will need to create a trigger.
It should be able to tell when the player enters or exits it.
It should be able to do the said action after its terms are satisfied eg filled with required resources
There can be a base trigger that has these behaviors and we should be able to extend these and create triggers which does specific tasks. Eg:
A resource trigger should be able to pull resources from the player until it’s satisfied or push resources to the player until it’s satisfied.
A timer trigger should activate an action only if the timer is ready
Resource
A resource should have its required data. It can be a base scriptable object that contains some basic data, such as its preview sprite, its prefab, id, and so on. Then developers can extend behaviors on top of these.
The aforementioned Player Storage and Resource Triggers can interact with this module to make things complete and connect everything.
There can also be a Resource holder base behavior that can increase or decrease the number of resources as needed. A resource holder can be a mine of resources that the player needs to break or a mine of oil that the player needs to collect.
Land
This module controls the area of play. In most arcade idles, there is a fixed area of play at the beginning from where the player starts and can unlock more areas gradually. This module can contain behaviors such as:
Activating, and deactivating items that reside on the land depending on if the land is locked or unlocked
It can pair up with a trigger and enable unlocking of it, only when a trigger is satisfied.
Save System
A save system is a must need for an arcade idle game. In hyper casuals, a base saves such as the PlayerPrefs was enough to save the score and level number. But it’s very different in arcade idles as there are long levels and saves the need to happen within a level that keeps all of the level states intact.
There should be a simple save module that takes care of it
Ideally what we want is a simple call to the save system by passing on the entity that we want to be saved. For example: let’s say we want to save the resources that the player has. We can create a PlayerData class that will contain the list of resources and their current values. Then ideally, we would call the Save system and ask it to update it with our PlayerData when the PlayerData is changed. The save system should take care of the Save when it’s the right time to save.
Our aim is to have a module that already saves the Player storage and trigger states.
Even with a basic implementation of the above modules, we should have something that saves up a lot of time. And in real life, time is the most valuable resource. Being aligned with the modules can not only help communication among the programmers but can also make the communication better between the programmers and the designers.
