In a previous entry - I realised how bad my patch notes were, so I decided to write down what I had completed as I completed it. It has since developed into a story of its own. I could distil this into a set of dot points but I think it is interesting as a month in the development of Illic. It is also a helpful reminder of how much I accomplished, so I can stop obsessing on what needs to be done and be happy.

My original goal for this patch was to completely clear my backlog. Since I had done such a good job sorting out and rescoping the game I figured it wouldn't take long.

First on my list is the threat display. It is something I use all the time in Fire Emblem and get annoyed that games like Disgaea don’t have. Yet I was more than content to leave in a broken state in my own game for years. Well no longer! You can now properly highlight the enemies threats and it will be persistent. I also have hopefully fixed the selection vanishing when the threat changed as well.

Second was the issue with blocking UI. In Illic I have had a system where some menus would take priority over others but… That is not what anyone wanted I think. You don’t want the options menu, the lore menu and the level menu visible at once. You do however want to be able to switch whether you send input to the inventory or to the shop. Now you can! It doesn’t matter much if you are playing with mouse and keyboard, but it is a big help with controllers.

Third was to improve the switching experience with the unit toggle. Previously you had to select two units and then hit the switch units button. Now you can remove units from being deployed and then add them again. I also improved the display of the UI to make it clearer when units are the commander or locked deployment. Just keep in mind that you need to deploy a full set of units to start the game. In the course of this fix I found a bug I had seen a lot of times, but hadn't registered - that is if one object doesn't display in menus all subsequent items won't. Fixed that unwisely in the morning before work. But it wasn't the last I would hear of that bug.

Fourth on my list was the problem with the resolutions not being set correctly. I had thought it would be a big pain, but I solved it in half an hour. I must be close, I thought to myself - only two items left.

Except instead of forging forwards I decided to improve how the chapter display works. It was at this point everything slowed down. I rescoped my patch so that I wouldn't worry about fixing my android build and adding in exp display. I did this by making a section to brainstorm future patches in my planned features document. It was a weight off my shoulders, but I still had a lot to do. It was around this point I started my previous blog entry and wanted to use what I had learnt. So I added some additional items to my board. I refactored the LevelMenuMaker to use the more generic displayable menu maker instead of being one. 

The refactoring did not stop there as I started to refactor the scriptable objects which held the level data which had become horribly bloated. I realised that by using a Mixin class similar to one I had developed last year (for my job) I could simplify the scripts a lot. Lines and lines of bloat and duplicated boilerplate code were deleted. That is a class which has all the code for read only access to a list of a given type stored in a scriptable object. With that done the shopUI was next in the firing line. Which revealed more refactoring of menus that was required. At this point I have run out of steam a while ago.

What has not helped is the realisation that the bug which I fixed in the morning before work wasn’t really fixed. My next solution to the problem was horrible… I don’t even want to describe it. Yet it was something I had to live through for a week at work, since I couldn’t work in the mornings (really coding before a day of coding is a bad idea… especially since 7 - 8 hours of coding is too much for one day anyway…). So I had to come up with a new idea and also incidentally really you should be able to select the buttons even if you can’t click them huh… Exhausted, I just played Fire Emblem Heroes dreaming of how I could make the interface consistent.

As the days blur together I bought Refactoring by Martin Fowler - a book recommended by Dave Farely and Gregor Hophe but the words and code blend together. My desire to improve Illic has far outstripped my stamina. So really there was only one thing to do. Play Mario Wonder. A traditional Mario 2d scroller where grabbing the wonder flower turns the whole level upside down. It is a beautiful and fun game. The controls however are also traditional (in other words terrible) on the other hand there is the elephant power up so it evens out.

Today I am cleaning up the code which has haunted my dreams. As always it is a case, creating tests and moving in small steps is the key. More than that though the important thing is to set aside time every week for working on your personal projects and let them have that time. Make sure that is quality time and defend that time. It is a lesson I already learnt, but I decided to forget as I felt so close to my goal. It is so easy to become obsessed with speed but… what is the point of getting that extra time in before work if it just adds work later? If I had just solved the problems when properly awake and able to focus I would be even farther but well… It is how it is. I have one more coding goal - to deal with non-interactable buttons. All I can say is why does making UI have to be so difficult in Unity? My requirements for menus are so simple - it makes you wonder what it would be like working with similar set-ups in Godot.

I’m not sure when the patch will be finished. I don’t want to fall into the trap of deciding arbitrarily when it will be after all. I’ll try to spend some time adding in more levels or art maybe? Either way, I hope to add a blog entry about what good choices I made in early Illic soon.

So until then.