Wake Up Devlog Week 5

The first thing I noticed this week is that ‘Monday.com’ (the site I was using for my Gantt chart until now) was using a pro trial which ended at the beginning of this week, stopping me from accessing my Project timeline. Because of this, I had to find a new Project Timeline builder to remake my plan on.

I found a site called ‘teamgantt.com’ which let me use a feature-limited free version of the site.

From this, I learned that in future I should check the terms of the free versions of resources / tools on websites to avoid situations like this where I had to dedicate (an admittedly small amount of) time to remaking my Project Outline plan.

Having a project timeline for months ahead has proven very useful in this project so far, it has allowed me to immediately know what I need to work on next, and what I can spend some time researching / getting an early start on if I finish my sprint early.

This week, my two main tasks involved Items and preparing a short pitch presentation with market research for class next week.

Implementing Items proved quite easy; even the item effects I thought I would have trouble with, which included ones which activated under specific circumstances (deal more damage to enemies on full health, chance to create explosion on killed enemy etc.)

For these specific effects, I used a combination of Blueprint Components and event dispatchers to call these without pointless checks when the Player doesn’t have the item.

The items work with the Interact system I created in an earlier sprint; their ‘OnInteract’ event from the ‘BPI_Interactable’ Blueprint Interface calls a function defined in the Item Base called ‘ItemEffect’ before destroying itself.

The ‘ItemEffect’ Function is declared so I can easily overwrite it in children for specific items, without having to change any other logic.

This made a lot of the common items (the ones that just change a stat on the Player) incredibly quick and simple to implement, as all I had to do was overwrite the function for item base to change a value.

The rare and epic items often took a bit more work to implement; many of these (specifically ones with effects that activate under specific circumstances) required their own blueprint component that could be added to the player.

For Example:

The ‘Cosy Blanket’ item adds a 10%(+2% per stack, max 24%) Damage reduction when on full HP; the way this is achieved includes:

BP_PlayerCharBAse has a variable of type object reference to a Blueprint Component called “BPC_CosyBlanket” with a default value of nothing.

When picking up the Cosy Blanket item, it will check if this variable is valid:

If not, then it will add the BPC_CostBlanket component to the Player and set the aforementioned variable to the return value.

If so, then it will minus 0.02 from the Component’s ‘DamageReduction’ float (which has a default value of 0.9 for 10% less damage, and 2% more per stack); this value is clamped at a minimum of 0.76 (24% damage reduction).

The Logic in the Blueprint Component is quite simple:

When created, it binds a custom event to the built-in ‘EventOnTakeAnyDamage’ event dispatcher in Unreal Engine’s Actors (so the bound event will call whenever the player takes damage with the Component attached).

This event checks if the Player’s Current HP is equal to their Max HP; and if true, then it will multiply the Player’s ‘DamageToTake’ float (I will explain this float in a moment) with the ‘Damage Reduction’ float and set this result as the new value of ‘DamageToTake’.

The ‘DamageToTake’ Variable I mentioned before is used as an input for the ‘AnyDamage’ event on the Player Character Base. Upon taking Damage, the amount of Damage inputted will be set to ‘DamageTotake’ before a Delay of 0.0 seconds, which allows the event on the Cosy Blanket component to calculate if the Damage should be reduced, and if so, to reduce it. After this, DamageToTake is inputted into the ‘AnyDamage’ Event’s ‘Damage’ input.

In the Span of a couple days l, I managed to implement 11 Items

6 Common Items

3 Rare Items

2 Epic Items

This gave me plenty of time to work on my Pitch: which I spent the rest of this sprint doing, alongside research for my GAM600 Dissertation research.

My pitch slides included:

Summarisation of the Game and its Genres/Subgenres

The main USPs of the Game

Market insight from Data from sources such as Steam

Key Drivers and Restraints on the Roguelike Market to keep in mind

Market Trends, and how I will take advantage of these to play into the strengths and alleviate the weaknesses of my Project

My main takeaway from this research was that while the Roguelike genre has exploded in popularity, it still occupies somewhat of a niche audience, due to their general inaccessibility for a general/casual audience.

The main Market trend I noticed was that a lot of Roguelikes gained attention / popularity for Hybridising the Roguelike genre with other Genres / Subgenres.

The most successful Roguelike Third-Person shooter is by far Risk of Rain 2, which has fallen out of favour with fans recently after Hopoo Games was bought by Gearbox Games who released a DLC with Underwhelming content and Game-breaking bugs a couple of months ago; and with not many other popular Roguelikes of this specific Subgenre, this means it may be a good time to fit into that niche.

The Narrative tone and themes of my Game are an additional Hybridisation that can help expand my audience within the niche Market.

As I finished my Sprint a day early, I decided to look more into Level Streaming in Unreal Engine. As mentioned in Week 3, I had previously done a bit of research into this system while researching methods of procedural level generation, and that extra knowledge gained during that was now paying off.

In a new persistent level, I made Sub-Levels of:

“SL_Main Menu”: Empty Level which spawns a Widget Blueprint called ‘WB_MainMenu’. Clicking on the ‘Start Game’ button in here loads the next level before unloading this one

“SL_TestDungeon” is created using the level I made previously to test my procedural generation system. When the start game button is pressed in the main menu widget, this sub-level is loaded before unloading the “PL_MainMenu” level.

Before the loading occurs, another widget Blueprint called “WB_LoadingScreenBase” is created and added to viewport with a zorder of 1 so it appears above all other widgets. This Loading Screen has a throbber so that players can tell their game isn’t frozen, just loading.

Out of the “Completed” node on the Load Test Dungeon sublevel node, this widget is removed from parent. I put an extra delay of 1.0 secs before this, just so the loading screen appears for a visible amount of time (this may change later when each room has more decoration etc.) and so the doors and walls spawn after the screen disappears.

I plan to revisit this so that the loading screen disappears when the dungeon has finished generating instead.

Previous Week

Next Week