#0 Character Controller
About the game
Once again, I started a new project. This time I am building a 3D platformer and adventure game: hammer-time. In this title, players control a character whose main feature is a hugmongous hammer that can be swung around to send objects flying away or to stomp on foes.
The scope of the project is to build a MVP prototype, and test whether the idea is actually fun to play and whether it could be turned into a complete game in the future. In terms of content, I am aiming to include:
- The player character controller and some of its visuals
- A couple of different enemies for the player to interact with
- Some level of environment interactivity (elements that can be hammered around)
- A single level that ends in a boss battle
I chose the Godot to develop this project, as I am already quite experience with Unity3D and I want diversify my skillset using other game engines.
The character controller
The first task I decided to work on was the moveset for the player character, as I felt it was the most important element. If controlling the character didn’t feel fun, the game wouldn’t feel fun either.
First, I created some placeholder visuals using a capsule and some cylinders to represent the character and its hammer. Then I made a drawing of the different actions I wanted the moveset to feature. Once that was done, I created some animations to represent them.
As most people usually do, I began coding the common stuff: running, jumping, falling… As I moved on to work on the different attack actions, I realised my code was becoming difficult to understand and very prone to bugs.
Before I added more attacks and further complicated things, I took some time to research how other game developers usually structure their code in these scenarios. After considering different solutions, I decided to build my own Finite State Machine, as it seemed to fit my needs the best while being straightforward to implement.
My implementation could have been better for sure, but it solved all the issues the controller had before. Adding the remaining actions (states) to the controller was now a simple task, and the codebase was easier to maintain as each state was self contained.
The code of most states is less than 50 lines long, and this is because those elements that are common to many states have been refactored into either:
- A shared, standalone component outside the FSM (e.g. the node that handles the
Coyote Timemechanic) - A parent state out of which other states extend from, creating a sort of hierarchy between them (e.g.
LightAttackStateandHeavyAttackStateboth of them extendingBaseAttackState)
