In this series, we will break down the game Crowd Evolution and create the core of the game in Unity. We will go through the modules of the core gameplay only.
Let’s see, we have a crowd of people moving forward. They are auto-shooting. The crowd and the shooting power can be modified using the modifiers. Sounds simple enough.
A game needs to provide the player with meaningful choices. What are the meaningful choices that we have?
- Modify the number of people in the crowd
- Modify the shootable strength (we will call the throwable weapon as shootable)
- Avoid modifiers
Nice! First things first. We need to understand the swerve input in hypercasual runner games from this blog post.
After going through that we are ready to have a simple Player that runs forward. We will create a simple MoveForward script
Combining, this with a simple forward run looping animation, we have the following.
Let’s create the shooting behavior now. We will start by creating the PlayerShooter script. We will have a basic timer that runs and whenever the timer reaches a certain value, it will reset and create a shootable object. We define the shootable object behavior as a new script named Shootable. The shootable will spawn from a certain transform point that we will assign to the inspector
The Shootable script will simply contain a variable containing damage per hit, which the PlayerShoot can set during initiating it.
It’s time to test it out. This is the layout of the Player that we have currently on the inspector. PlayerHolder contains the MoveForward script. Player contains the SwerveMovement script which we understood in the referenced blog post above.
After setting things up we will also attach the same MoveForward script that we used on the player to the Shootable prefab. Let’s increase its speed so that it’s significantly more than the player. At this point, we have this.
Visually, we can see that we are in the right direction.
It’s time to focus on the modifiers. To enable a modifier, we need to detect it first, hence we need triggers. Let’s attach a rigidbody and a capsule collider with the Player gameobject. Even though we will have a crowd of people, we will keep it attached to one parent as we will detect the modifiers using that.
Detecting with all of the people in the crowd can cause detection everywhere on all of the triggers. We don’t want that. Let’s also create and attach a PlayerController script that will take care of the detection
As for the modifier, let’s create a simple gameobjet with a collider trigger. Let’s also set the tag as Modifier and attach a new script named ModifierLog
Our PlayerController will simply detect the modifier and call its Modify function which will in turn do a simple log
Now, if we test it out, we can see a simple log popping up
Let’s do some quick refactoring. We create an abstract base class for Modifier with an abstract Modify function. This way, we can create modifiers as we like and we won’t need to touch the detection code.
This is an example of Open Closed Principle that says a class should be open for extension and closed for modification
We are at a nice place to wrap up this episode. Stay tuned for the next one!
