Posted January 21, 2023 by Bright Flask
#samurai #action #rpg #top-down #japan
This devlog covers the last three months of development of Yurei from October 2022 to January 2023.
I knew I wanted to tell a story in the game to motivate the player. I kept pushing it because it wasn't the priority. After completing the other systems, it was time to jump into this.
The game is not story-heavy. So I started the dialogue system with the basics. First, two characters speaking, then I added a simple effect when switching between speakers. I also wanted to use dialogue to explain mechanics and when rewarding the player. So I added an option to show an item in the dialogue.
To add more life to the dialogue I added an option to play sound effects. It wasn't a lot of work because the Audio System was already there. Finally, I added an option to skip the dialogue and another to autoplay. The autoplay might not be necessary since it's not a dialogue-heavy game, but it was a nice challenge.
In short, this is an achievement system. It compares values to certain targets to check if you have completed them or not.
I always like having an internal achievement system that ties into the actual game. This way it's not something completely external. In this case, each achievement is an "Honor". The characters talk about it, and it feels more grounded in the game
I created different stage layouts for all stages in the Cave area. I reworked what I had to use prefab variants. I thought it wasn't possible to change the tiles within prefab variants, but it turns out it is. It's helpful to have everything a stage needs on the base prefab and then let the variants change the layout.
At first, when the game is changing too much, prefab variants might actually slow you down. It is worth transitioning to a base prefab with variants once you have a better idea of your game structure. It helps with the consistency and maintainability of your game elements.
Bloodstone stages are optional stages that you can play. In each bloodstone stage, there is a stone at the center. The goal is to protect the stone from enemies and not get yourself killed.
It might seem straightforward but implementing this required some changes. All the enemies targeted before was the player. There was no abstraction there. I changed the enemies to have a different target depending on the wave type.
The difficulty will be a bit higher, and when completing the stage you unlock a Sin. Then, you can "confess" to a Sin which will give you a buff on the soul's drop rate at the cost of making the enemies stronger.
The tormented existed since the beginning of the game. The name changed until I settled on the Tormented. At any stage, you might have to fight a wave where a Tormented appears. When it does, you have a time limit to "feed" the tormented with blood. You do that by killing enemies.
There's a harder version called Gourmet Tormented. Instead of killing enemies anywhere on the level, you have to kill them at specific spots.
In the game, there are three types of things you can buy: gear, amulets, and sins. So far, I had the three separate because it was easier to maintain the screens this way.
Since they are all part of the shop, it made sense to unify them. Now it's one shop state, and I added a tab menu on top to switch between screens. This makes it easier for the player and allows me to control when each is available.
The loot dropper is a behavior that I had that instantiates something when a character dies. In this case, it is also used when you destroy a box. Internally you are "killing" the box, and the logic is the same.
I updated the behavior to allow multiple drop types to be set, each with different drop chances. This way I can make stronger enemies and give more souls.
With some shop items able to give different skills I needed a way to play VFX as I do with audio. I wanted to make it clear to the player what was happening. I also wanted to reuse the effects and not have to recreate them for each object.
It works almost identically to my Audio System. You call it and say "Hey, play this VFX here, at this location". I created a base VFX prefab and attach a Vfx behavior. Whenever you call the system, it fetches the right prefab, instantiates it, and calls the function play. The VFX instance has an animator with a play state in it.
Again, I wanted to keep this simple and for now, it covers all the cases I need.
Throughout the project, it's normal to use a variety of tools. I usually start with google docs for the initial concept. For general game design, I find that Notion is the best tool.
This time I made the mistake of defining things on Notion's spreadsheets. Once you get to the point where you have to balance the game, Notion spreadsheet's become a hassle. Reading the values of different sheets, and using formulas are more complicated. With google docs, you get a lot more flexibility.
So I removed all the tables I had from Notion in favor of only having them on google docs. Remember that most likely you will be changing the value in the game already. That is already two places to have a value on. Where is the real one? So now, if I change a value in the game I can go to google docs and update there.
The source of truth will be on google docs. For any change in the game, I have to reflect it on google docs. This way, when I am balancing the game I know I have the most accurate values.
---
As usual thanks for reading all the way here. If you like Yurei and want to keep track, please check out my Twitter at @brightflask.