Wake Up Devlog Week 3

My goal for this week was to Define the Scope for my Game more clearly and make a Gantt Chart timeline, add missing details from the previous week to my GDD; research how to do Procedural Dungeon Generation for combat encounters and create a base interactable and item blueprint class.

I attempted several Trello 'Power Ups’ to create a Gantt chart straight from my Trello board; however, I was unable to get any of these working sufficiently. I decided to use ‘Monday.com’ to create my Development Timeline as I have used it in the past to quickly and easily make a simple Gantt chart.

After this, I filled in some missing logic descriptions I missed from last week in my GDD. This included describing in detail the logic for stunning the Player and Enemies, and everything declared in the 'BP_EnemyCharBase' class. Documenting these systems means that I will always have a resource to refer to when I need to tweak / edit a mechanic.

The most exciting part of this week was researching potential techniques to procedurally generate my Game’s combat encounter dungeons.

Going into this research, I had a small handful of ideas about how I could do this, including using some kind of scatter plotted along a grid (or BP coded to create a grid) to spawn from a pool of level instances which would be grid-shaped rooms

The problem with this, was that I wasn’t sure what kind of logic I would use to ensure that rooms connect and that all exits leading to nowhere were closed off.

Researching level instances led me to several materials explaining ‘Streaming Levels’ in Unreal Engine 5, which was a concept I previously didn’t know about.

Streaming levels involves having multiple smaller “sub-levels” within one “persistent-level”, that could be loaded and unloaded in blueprints, which means that things like Music could keep playing when switching between these; Player Stats which vary based on a run don’t need to be pulled from a Game Instance whenever the Player switched between these levels. Additionally, it allows levels to be loaded asynchronously to other logic, which means that a loading screen can be utilised rather than just the Game freezing then unfreezing on the new level (which is what happens when simply opening a new level).

As useful as the information is (and I will certainly find ways to use it later on in development) I didn’t think it would be what I was looking for.

Luckily, just after this I found a video describing the exact type of dungeon generation logic I was looking for.

It involves using a Blueprint actor to spawn an actor at 0,0,0 location. This actor is a room, which will have exit points set as scene components.

After spawning this room, the Spawner blueprint will generate another room from an array fed into it at a random exit point, and will keep doing so until it hits the limit of rooms (int value is decreased by 1 every time room is spawned and value is checked to see if it is over 0 before spawning a room).

After all rooms are spawned; any exits left open will be plugged up by a wall actor.

This system is far simpler than I was expecting, and allows for easy customisation (Spawning specific rooms after a certain value of amount of rooms is true etc.); so I will spend next week creating and playing around with this system.

Previous Week

Next Week