Wake Up Devlog Week 7

My primary goal for my seventh sprint was to implement the base for the ‘Event Encounters’. A few Weeks prior to starting this project, I had been experimenting with creating a basic dialogue system that I could use in future game Projects, and this was already about to pay off for me. I migrated the DataTable used for Dialogue Data as well as the Widget that handled the progression of Dialogue into my Project which saved me having to copy/redo all of the code I had done previously, which helped save me some time to fine-tune and refine this system a little more than I had done previously.

The struct I used to create the DataTable for my Dialogue is easily modifiable. For example, after migrating the Dialogue system, I added a class reference to my Item Base to the struct. Then, in the Dialogue Widget I added a branch into the Macro that handles additional data inputted which checks if the ‘ItemtoGive’ on that row is valid (I.E. has one been set) and will run some additional logic to give the Player that item before continuing.

I was lucky to have made this part quick for myself, as some issues arose after implementing the Event Encounter sublevel. After progressing from the event encounter and progressing to the shop or combat encounter, the loading screen would not disappear. I spent a long time debugging, and found that somehow there were multiple instances of the Load Screen widget, which shouldn’t be happening as I was only calling the event which creates one once before removing it from its parent.

In the end, I decided to add a failsafe to fix this issue and stop it from popping up again, by adding a for each loop with an array from ‘Get all widgets of class’ of the loading screen; and removing each element from parent in the loop. Thankfully, this fixed the problem and should act as a reliable failsafe to stop this from happening anywhere else in the future.

After this, I still wasn’t done fixing up the Dialogue Widget, as clicking anywhere which wasn’t an element of the widget would cause the player to focus out of the widget and stop inputs in the Widget from being processed. After playing around with the focussing of the widget, I found that an easy fix for now was to add a transparent Border in the background of the widget, so that no matter where the Player clicked, they wouldn’t click out of the widget.

Later on in the week, as I had completed my tasks for my sprint, I thought a lot about the Design of my game and how well it complimented the core design pillars, and I came to the conclusion that the passive HP regen I had given the Player would lead to combat encounters not being threatening and the game being too easy, as the player could simply wait between rooms to regain their HP, which takes pretty much all of the risk out of the game which is incredibly detrimental to a Roguelike, which is built on the thrill of the risks that the Player takes.

Because of this, I removed the Passive HP Regen from the PlayerChar Base, as well as removing the HP regenerating Utility skills from the Bearer of Lust and Wrath Classes.

To compensate for this, I created some HP restoring items in the shop encounters; a common item called the ‘Hearty Mug’, a rare item called the ‘Hearty Broth’, and an Epic item called the ‘Hearty Platter’. There will always be 2 of these items available in each shop encounter, which will heal the Player for 10HP, 25% HP and 100% HP respectively. These items will be priced slightly lower than other items, however it adds some strategy to Players’ runs.

If a Player has taken a lot of damage, they might have to choose between a powerful combat item and regaining some HP due to currency constraints; furthermore, it rewards more skilled Players who won’t take as much damage, and can thus afford more combat items.

Something else I began to consider this week was accessibility, and how I could make my Game as accessible as possible.

The main areas of accessibility I identified that were feasible for me to implement were Remappable controls and Colour Blind modes.

Remappable controls would allow those using non-standard control schemes to Play, and Colour Blind modes would make the Game more appealing to those with some form of colour blindness, which is a surprisingly high amount, especially in men.

Previous Week

                                                                                                                             Next Week