Weekly Summary

So, this week started off great: I managed to get a ton of work done on Monday - completing basically all the goals I had set for myself for this week. Despite this, again, the rest of the week was full of stress and late days at work. I had to get creative and work late-nights to make steady progress on the game (which meant sacrificing some hobby time) but I’m pretty happy with the time spent. I think all of this means that I need to be a bit more ambicious next week (let’s try not to set a goal I can accomplish in a day) and I need to be careful and not burnout like I’ve done many times in the past.

Daily Log

Monday - 14/02/2022

Time Spent: 3 Hours

Remember that “artistically-inclined friend” I told you about last week? Well, his name is Llibert and his work is absolutely ridiculous. On Sunday he asked me if I wanted to have a quick call to check the work he had done so far for the “cover art”. Being totally honest, I wasn’t great at telling him what I wanted but, he perfectly captured the spirit, theme and story of the game. You can find his mockups and WIP below - I’m absolutely floored by what he’s done so far and think this could easily be the start of a very fruitful partnership.

In terms of game dev progress, as you can see above, I managed to work 3 hours! I got an early start to coding and continued work on the morale modifier work that I started last week. I managed to breeze through the remaining 7 modifiers though there are a few more that will need to be added later (because they require completing work in other features). Once that was done I started work on actually applying those modifiers to units in the game, rolling for morale checks and applying morale buffs/debuffs. I was expecting this to be a complex process but, to my surprise, I got it done pretty quick too! This meant that all goals for the week were accomplished in the first day of work (woops), however, it’s not like there’s not enough work to go around.

Working on the morale system highlighted a few things:

• A pre-existing issue with Random and Random.next(), more specifically: the RNG package provided by Unity has an issue by which multiple executions happening close to each other result in the same number. This is far from ideal since RNG is what we use to role morale checks, calculate critical damage and determine action execution order; examples of this bug are: all units (enemy and player) getting crits at the same time and all units failing/passing morale checks simultaneously. Far from ideal (obviously) but not a blocker for the time being, I carded the task up in my scrum board and moved on.

• Buffs and debuffs resulting from the morale system aren’t working as I was envisioning them: currently, the only difference between having high or low morale is damage output. This is not a very visible, satisfying (it feels like units that are doing poorly are punished) or noticeable change and I think I need to come up with some more specific status changes. The original idea was to do something similar to the Darkest Dungeon sanity system so I carded that up too.

• The need to fine-tune damage values (for both morale and regular hp): I want units to work in a rock-paper-scissors kind of way but currently units with the most damage output simply obliterate those with less. I want to get the all the game-dev work out of the way first before getting to game design and feel. All values are easily modifiable via Unity and I don’t want to get bogged down refining specific mechanics since it can easily bring progress in the game to a screeching halt. The goal right now is to have all mechanics necessary for the vertical slice in place before refining and improving how the game feels.

That’s it for the day! Honestly, I didn’t expect to get the entire morale system done in one day but that’s a good thing. I have the rest of the week to work on more functionality, fixing issues with RNG or creating an “undo” button (since debugging and play-testing is starting to get pretty annoying and it’s a vital functionality for the vertical slice either way).

Tuesday - 15/02/2022

Time Spent: 1.5 Hours

Managed to get an early start on Tuesday too (which was great), however, since I was pretty happy with the previous days’ work, I decided to cut down the time spent on AIW on Tuesday and relax for a bit. In hindsight, this was a bad idea since the week would turn out far more stressful than I was anticipating and I really could have used a few hours more on Tuesday, nevertheless, I think rewarding yourself for a job well done is an important part of indie - and more specifically solo indie - dev.

In the past, I’ve over-worked on the project and spent hours upon hours for consecutive days; working until late at night and spending all my free time doing game dev. While this meant that the project seemed to be progressing incredibly fast (seemed being the key word there), it also meant that I burned myself out: I would work on the project non-stop for 2 months and until I’d decide to take “one relaxing day” (which would turn into two, then three, then a week, then a month…). I’m trying to get to a healthier place with this project and get myself to work in a more sustainable manner that generates more steady progress: thit is a marathon, not a race.

Anyway, I decided to start work on the actions menu: I want to start adding actions/abilities to units and that means that I need some way to select them first. The action menu will show up whenever a player right-clicks a unit and will contain a list of the action the player can execute for said unit along with some detailed information; more specifically, the idea is that this will be a dossier/folder on the unit in question (I want all UI to be diagetic).

I started by adding a new Type[] to all unit types (which is basically a list of the Action a unit can perform). Once that was done I created a getter called AvailableAction within the Squad class that checks all units inside the squad, gets the actions they can perform and returns an array of unique actions available for said squad. Finally, I create a GenerateActionOptionsFor function inside the UnitManager that receives a Squad, executes its’ AvailableAction getter and converts the resulting Type[] into a string[]. The idea here is that whenever a unit is right clicked, we will execute a DisplayPopup function (that hadn’t been created yet) that displays the popup and fills it in with a button for each of the actions available to the clicked Squad.

I don’t wanna go into a lot of details right now (I'll probably right a deepdive on it in the future) but I do want to expand a bit on the `Manager` concept mentioned above. I’ve structured the codebase following the single responsibility principle, ensuring there is a Manager class for each of the features/functionalities/portions of the game, ex: CameraManager, UnitManager, MapManager, PhaseManager. This way all logic for a given portion of the game is in the same place and is easier to refactor and modify.

Finally, I started investigating how to create contextual menus in Unity at the precise point in which a user clicked. I found some interesting documentation and made some notes to ensure the next day I work on the game I can get straight to implementation. That was it for Tuesday (rest of the afternoon was spent catching pokemon).

Thursday - 17/02/2022

Time Spent: 1.5 Hours

I had a ridiculously long day at work on Thursday so I couldn’t code at all in the afternoon. Instead, I decided to squeeze in a few game dev hours at night. I started work on the actions popup using GUI.Window which was pretty straight forward: when a unit is clicked we call a GenerateActionMenuFor function in the UnitManager which appends said unit to a List<Squad>; then - within the OnGUI function - we display an action menu for each of the units in said list.

To display the action menu, I created a DisplayActionMenu function that calls the GenerateActionOptionsFor function and populates the resulting window with a series of buttons to perform the actions available to said unit. Managed to get all of this was working as expected: whenever a unit is right-clicked, the action menu appears beside the unit containing buttons for all actions available to said unit which print a statement on click (as a placeholder for actually generating whatever action was clicked). Having the display of the action menus depend on a List<Squad> also ment that we could have multiple menus on-screen simultanteously and manage all of them independently.

I did encounter issues with getting windows to be draggable (part of the idea of having all UI be diagetic) and with having the menu appear beside a specific unit (menu position was always relative to the unit so when a unit moved, the menu did too) but they both seemed easy enough to solve and it was getting late (almost 1:30 am). I decided to leave my future self some notes and call it a night.

Friday - 18/02/2022

Time Spent: 2 Hours

Friday, once again, I had a very long day at work and couldn’t code in the afternoon so, again, I decided to squeeze in some coding at night (since I didn’t have to wake up early the next day).

I started by fixing both of the issues from the previous day which, as I suspected, were pretty simple: window dragging issue was caused by not over-writing the displayed window with each call to OnGUI (it is stated in the docs but is very easy to miss) and the menu always being in a relative position to a unit was caused by setting the window position on each call to OnGUI (since that function works similarly to Update it meant that if the unit moved, the position of the window would automatically update too).

After that, I did some tweaking of the window functionality: added the unit name as the window title, ensured that clicking in player and non-player units resulted in different contents, etc… So, once all of that was done I could officially have called the action menu “done” but, I wanted to spend a “tiny amount of time” (sure, just lie to yourself) to improve the “diagetic” aspect of the menu: since the menus will be folders in-game I wanted to ensure that if the player moved the camera, the menu stayed in the same position "in-game” (rather than being stuck to the screen). It is a very silly “flavour” thing but I thought it was worth spending an “extra 15 minutes” (I just keep lying to myself) investigating it while I still had menus fresh in my mind.

I made some good progress on that and managed to get menus to move in the opposite direction to the camera movement just not at the exact same pace, ie: if the camera moves two pixels to the right, the menu should move two pixels to the left (which would cause it to appear to stay still), instead it was moving 209384750298 pixels to the left. I thought this was easy enough to fix (probably a minor issue with WorldPosition vs ScreenPosition) so I made some notes for future Jack again and went to bed (since I do need to sleep at some point).

Saturday - 189/02/2022

Time Spent: 1 Hour

I thought I wasn’t going to code on Saturday - just planning on taking a relaxing day of Pokemon-catching - however, I was obsessed with getting the diagetic menus working just like a wanted (see, I told you I was lying to myself before, I nerd-sniped myself). I played around with the WorldPosition vs ScreenPosition idea I had but, surprisingly, that didn’t fix the issue so I tried out a few things:

1. First I tried to use the Window’s Transform.Translate() to specify how much the window should move in a given direction. Turns out GUI doesn’t have a Transform in Unity so that was a bust.

2. Then I learned about Mathf.Lerp and tried to make use of it to no avail (it was again late at night so I think that didn’t help), I think I need to give this one another chance.

3. Finally, I remembered the issue I had on Thursday that caused Windows to always be relative to a units position. I used the unit the menu was related to as a point of reference and updated the window’s position every time the screen would pan in one direction.

That last option seemed to work but I encountered issues with the y-axis (it seems to be inverted somehow) and with keeping the window-dragging functionality (whenever the camera moves, the position of the window is over-written causing it to teleport to it’s original world position). I’m unsure as to why these two issues are happening and don’t really know how easy they’ll be to solve (they seem simple but I don’t wanna take anything for granted yet) but, I’m way to stubborn to stop trying now. I made some notes to myself and decided I’ll continue with this on the next session.

Progress

• Completed the entire morale system.

• Discovered a few issues and bugs (and pin-pointed the cause for most of them).

• Art mockups are looking very promising!

• Got action menus working (pending some flavor details that I will get working soon).

Issues

• I got way too obsessed with something that is objectively a minor detail. Like I mentioned above, I am going to get it working in this particular instance but, I need to be careful in the future not to spend a hole session (not a typo, credit goes to @sub_rov in twitter) in minor functionality like this.

• Time management strikes again.I did manage to spend more hours on the game this week but I need to be careful with work hours (and try to get back to a more predictable routine).

Next Week

Again, I think next week should be pretty stress-free when it comes to work and appointments but I don’t wanna take that for granted. I think I’ll try doing as much as I can whenever I can; that way, if something unexpected comes up it doesn’t break my whole schedule (and I don’t need to sacrifice some nights to the project).

Goals

• Get action menus to move as expected.

• Implement all remaining unit actions/abilities.

• Finish up the remaining morale modifiers that depend on said actions.

• If I finish all the above: create the “undo” button.