This past month, I focused on the third and final area of the game, the castle area. Having done the Forest area the month before and the Cave area the month before that, helped me plan for the Castle area. 

I got a bit sick by the end of the month (still am), but fortunately, I was a bit ahead of my planning. I can't stress this enough, but planning will save you from overthinking. It is hard to do, but if you want to get good at making games, get good at planning and estimating before anything else.

All Castle Stages Improved

The castle area has one unique hazard, which is the spike trap. It is the only hazard that not only you can't destroy, but it also changes the navigation path depending on its state. 

For the most part, I was able to design different stage layouts without creating any big issues. Some bugs did pop up though. For example, if a samurai dashes when the spike is down, then the spike comes up, and the samurai gets stuck. But again, the focus was on improving all stage layouts and enemy count. This is not the final version of the stages.

It is important to work to a specific level of quality. Especially when it comes to stages because it might seem like endless work if you want to go from 0 to the final/perfect version. So yes, the bugs will be worked on, but for this month they are not the priority. 

Castle 6 - BEFORE/AFTER

Castle 7 - BEFORE/AFTER

Stage Designer Tool

With all the stage changes, I started to see more friction with the structure I had for balancing stages. This is the setup that I had: 

1. The stage is on a spreadsheet (so I can see the numbers)
2. Export spreadsheet to JSON
3. In Unity, the stage inspector converts the JSON to a scriptable object
4. I can then tweak the stage on the inspector

You can see that for iterating, this is not practical. 

The reality is that I would keep tweaking the level in Unity and eventually copy the numbers over to the spreadsheet. The advantage of the spreadsheet is to compare the stage's enemy counts. It's also nice to spot enemies that are being underused or overused. 

New Attribute Drawers

I didn't want to spend too much time on this. I decide to make some changes to my inspector to ease the stage changes. I created an attribute drawer that has an up and down arrow. In reality, I only spawn 1 or 2 enemies per wave item. 

Then I created another attribute drawer that I give it a range and it will draw as a series of buttons. Almost like a tab. I used it for selecting the spawn points. It saves a couple of clicks.

The final result for the inspector was quite a big change.

Editor Tool

That all helped but I still need to quickly glance at the enemy count per wave. I build a simple tool to do just that. Nothing more. It helped me go back and forth to identify enemies that were being used or used too much.

Closing

My devlogs will probably become shorter moving forward. The plan is to get the game done by June. After that, I want to just polish and try harder to get a publisher. At the same time, try and get more wishlists on Steam. 

Yurei has been a labor of love. I never started making the game with a plan to make money. So in reality my goals were: to learn and personal satisfaction. I learned a heck of a lot. And I am satisfied with the project. I always wanted to do something with Samurais in this specific setting.

That being said I don't want to stop here. I want to use everything I learned in terms of organizing myself and game development, and do it for more projects. If I can make projects with a shorter scope I am sure I can get better faster with each new game.

If you feel like helping out, please wishlist Yurei on Steam.

---

Thanks for reading all the way. Keep an eye out on Twitter @brightflask.