Posted February 12, 2023 by Bright Flask
#unity #samurai #unity 3d #action game #combat #fsm #localization
I recently took some time to look at all that I had done in 2022 on Yurei. I was surprised by how much and how impactful the changes were. Here are some of the highlights.
Reworking my FSM
If you are making a game, then it's inevitable that you will use an FSM. You will struggle to create and maintain complex behaviors if you don't use something similar to it.
With a good FSM, it's easy to tweak how the enemies behave. Just add more states if the behavior is more specific. This way, each state is responsible for one thing only.
My old FSM worked great, but it was terrible to debug. There was nothing visual to check which state something was in. The new FSM is built on top of Unity's animator. Having the visuals is fantastic.
The new FSM worked so well for enemies that I ended up also using it for my Game FSM and Battle FSM. The game itself has an FSM, so it knows where you are in the game. The Battle FSM is responsible for spawning enemies and so on.
Implemented the Boss logic
Implementing the boss without the FSM change would have been a struggle. He has more attacks, and the attacks he can perform change when his HP drops. With the reworked FSM, it was super simple to implement.
Of course, it would have worked with the old FSM as well. When you have to debug and iterate on the behavior, that is when the issues start to appear.
Debugger for everything
I already had a simple debugger that I just called cheats window. I could kill the player, spawn enemies, and give money. It was helpful, but it wasn't enough.
As the game grew and more systems came in, I decided to repurpose the cheats window. I created separate files and used partial classes to split the logic. So each tab seen here is implemented in a different file.
With that done, I decided to take it a step further. For the localization, I wanted it all to be separate. My localization debugger shows all the values loaded, all the IDs, and everything. I can quickly look at it and fix something if needed. This will continue being useful until release.
The same goes for the boss. I had to open the inspector to check a specific behavior every time. So similar to the localization, I made a separate boss debugger window. It's super helpful to be able to dock a window on Unity. Whenever the boss appears in the game, the window loads the info I need there.
Organizing by Domain Instead of Type
I changed how I organized my UI prefabs from type to domain.
My UI is divided into two types: Windows and Elements. A window is what most people call a Screen or View in their game. It's a complete screen like a title screen or options screen.
An element is a piece of a window. Unity has a bunch of them already: text, buttons, and sliders, for example. Sometimes you need a specific behavior. Like when the user clicks here, the text will change, and the element will scale. Or if you have enough money, show an icon here. The idea behind writing your own elements is so that they can handle that logic.
For the longest time, I had my windows organized by type. So all Windows were under a folder and all Elements under another folder. But I was constantly going back and forth between these. Usually, a window will have specific elements made just for that window.
For example, my Shop Window uses a list of gear elements. Each gear element knows how to display a gear, meaning it knows when to show a lock icon, and so on. This way, the window can be responsible for general logic, while the element can deal with the specifics.
It drastically reduced the back-and-forth when implementing or changing a window.
List of Other Things That Made in 2022
Closing
I wish I had started doing this sort of stuff earlier. It's great to look back after some time has passed. I encourage all of you working on a game to look back at your project from time to time.
Here are some tips on how to do that effectively:
---
Thanks for reading all the way. Keep an eye out on Twitter @brightflask.