Sprint 3

Sprint 3

Week 1

This week saw the rework of the Despair to be able to flee from the character when it takes any damage from a light source, be it a hand-held torch or lantern or a ceiling light.  The first step to the implementation was to have the Despair drop breadcrumbs when it is chasing the character, this gives it a way to flee again once it gets hurt at all.

The video on the right shows the Despair dropping breadcrumbs as it chases after the player.

The next step was to implement the fleeing of the Despair. This means anytime it takes damage, it will flee to the previous breadcrumb that was dropped whilst chasing the player.

We can see the Despair dropping the breadcrumbs like before, but now also fleeing when it is damaged by the ceiling lights. Each time it is damaged it flees again, but will continue to attempt to chase the player.

The procedural generation system was also fleshed out more with the system now attempting to spawn the rooms that will be used to populate the game. A lot of the code for the procedural generation has been implemented within C++ with the external rooms being generated within blueprints. This allows for the game to create automatic level designs, but also assign pre-existing designed rooms to give a bunch of extra detail. Problems can be caused by this linkage of blueprints and C++ though as we found out. In this case there was an issue with the C++ code that only became apparent when attempting to spawn items.

Week 2

Week 2 saw the introduction of the players Hope ability. The Hope ability is something that is used to combat Despair as well assist the player in discovering loot items that are not immediately apparent. The first steps was creating a spawnable item when the player presses the Hope key.

In the video here we see the player spawning assets each time the button is pressed. This is just a stand-in item but shows the system spawning assets as required.

In a test of the system, there was a need to test the navigation system to the location of loot items. Instead of doing the search, we first implemented a way of moving towards the Despair.

This video shows the Hope “ability” running towards the Despair, it also brought up discussion on possible other uses for the hope ability to possibly chase away Despair – this maybe a future feature we will add a later date.

The next step was making the Hope run to the closest container that contains a loot item. This is not precisely what we wanted though, and a few iterations to make the character disappear and instead utilised footprints.

The video here shows our initial system of spawning the Hope as well as placing the footprints on the ground as it runs to the nearest container.

In addition to the work on the Hope ability, further work on the procedural generation system was completed. Specifically, work on the item spawning system within specific rooms as well as ways to traverse between levels of the house have been completed.

Working within the blueprints system of Unreal found real limitations on how to spawn things, so the decision for spawning specific items was pushed out into the C++ system.


Small issues did occur with the room spawning system though, with items being offset incorrectly spawning outside the room or into the floor.

The image here shows the lights and items that should be inside the room, even the light switch is floating in the doorway instead of on the wall as expected.


The system is really getting there. We have the major features of the game implemented and some of the minor features are really coming together nicely. Our aim to get the entire game to be complete by the end of this sprint is really looking like it will happen!

Week 3

This week work on the system continued to progress, but issues with the procedural generation pushed some features back. The decision to move item spawning into C++ for performance reasons, became an issue with the system crashing the environment. Even when you debug, Unreal doesn’t protect itself from those crashes, so had to restart the software multiple times so we pushed it back again into blueprints and instead created an array to hold the objects to spawn.

In regards to the work completed on the modelling side, the following items have been created over the last few weeks. For this sprint we gained a new modeller and she was able to really push out some decent models for use within the game.

Week 4

We have it all working correctly, spawning the world and then spawning the rooms and the items inside. At this point we are ecstatic about getting it all finalised, and so the code is pushed to the Git repo and our game designer started configuring the system in preparation for our supervisor to sign off on the progression of the project.

We went over each of the different sections and a recorded video was shared about the major functions that were worked on during this sprint.

So when attempting to demonstrate the functionality of the procedural generation, the random level blueprint was opened and we are presented with a really random error message. The assumption was that the Git repo broke the connections from the compiled variables to the internal blueprint variables that were assigned in the Random_Level_BP within Unreal. Luckily the coder was on hand to work through all the changes and re-link everything back to the blueprint.

So far so good, and demonstration of the player spawning and being able to navigate around the newly generated world was working perfectly.

One problem, each time the software was closed, the links to the blueprint would break down again and they would have to be resyncronised. We also couldn’t export the game in its current format out to a pre-built application as it broke the links when an export was started.

Major issues! But something that can definitely be overcome, but it does mean our aim of being feature complete has fallen by the wayside and we are going to have to work hard to catch up.

Leave a Reply