On this page I will be looking at one of the major problems I faced during this project, I will look at how I handled it, my thought process and how I came to a solution.
Example Problem Breakdown: Designer tool kit & procedurally generating levels
Throughout this project I faced an untold amount of problems that required research, fixes and workarounds. In this section I will be breaking down one of the larger issues I faced to give an idea as to the mentality and thought process behind solving complex problems.
​
Aim: Have a tool that allows for easy level creation for designers, allowing for a any number of level layouts to be created with ease. Then allow for these pre-set level layouts to be added to a list so that any level can occur in a procedurally generated order when progressing through the game.
​
Breakdown
​
Designer Tool Kit
​
Problem: Designers in the team are struggling to make levels due to blueprints being changed and requiring references to be set manually in editor, which wastes a lot of their time trying to figure it out and my own time in trying to help and fix the bugs it's causing.
​
To begin with for this problem I communicated with and proposed to the design team that "if they wanted to work on something else for a small while, I could develop a level tool kit that would hopefully remove the back and forth for simple referencing issues so our times could be better spent elsewhere in the project". They agreed and I got to work.
​
I created a blueprint called BP_Level_Base, this would be the core blueprint throughout the creation of this tool. From here I proceeded to add function buttons within the editor to run on construct which would generate and automatically reference other blueprints. (see fig 1). The buttons were modular and simply just needed to be renamed due to all relative blueprints having the BP_Level_Actor parent class. Meaning any BP could be easily added to the list. These blueprints would come attached to the level allowing for designers to move it if they required.
​
(Fig 1)
​
​
​
​
​​
​
​
​
​
Problem: Other team members developed blueprints which required to be added to the level base, everyone has a different style and methodology to scripting, meaning understanding others code can be time consuming and difficult.
​
This was resolved through clear communication and workflow, as technical lead I ensured and stressed from early in the project that all code was commented on and if there was ever an issue or question the team culture was always open to discussion and help.
​
Problem: This particular blueprint touched on a lot of areas that other team members were working in, this could potentially cause conflicts through the source control on github.
​
To avoid any lost work or issues with source control the team was in constant communication, using Jira to assign tasks and manage the project as well as (due to it only being a technical team of 4) asking if anyone else is using the blueprint before it was touched. Also from early in the project I stressed the importance of source control and when to push & pull changes, ensuring the team is as up to date as possible.
​
Problem: Designers were drop and dragging blueprints from the content browser despite the toolkit being created.
This was resolved through throwing together a quick one sheet of instructions as to how to use the tool as well as a quick demonstration from myself ensuring everyone was able to use it.
​
Problem: The character can run through each one of the levels from one door to another without spending time in each level.
​
This was resolved through the toolkit having a manager spawned alongside each level to check for "Level Complete". If all level complete actors were set to true then the door would open. Functionality was built into the tool kit for this through a list that the designers simply needed to use the eyedropper tool to pick and mix which actors needed to be completed to progress through the level (Fig 2). This allowed for design decisions to be made later down the line that didn't need hard code to be changed, just a list of actors in the toolkit. This actually happened during development as originally resource nodes and enemies needed to be completed to proceed to the next level, this was later changed to just enemies.
​
(Fig 2)
​
​
​
​
​
​
​
Level Generation
Once the toolkit had been created designers were free to create levels (from now on I will refer to these as level layouts). It was now up to the technical team to make the levels come together into one experience. The design was "as the player progressed through an exit door from one level layout to another, a system would randomly pick from a list of potential layouts and generate this as the next cave." This was to ensure that each playthrough was different.
​
Problem: How are the doors going to link and initialize, along with the other BP_Level_Actors, in the correct order?
​
Initially the scale and scope of the game was much smaller. This meant that all of the layouts were created within the main unreal level. Therefore the idea was then to take each one of these level layouts and dynamically spawn a copy of a random layout taken from a list held within a manager as soon as the player reaches the exit door and interacts with it.
This worked, some of the time.
​
Problem: Sometimes the doors do not seem to link and initialize correctly
Problem: This can get very demanding and expensive very quickly due to having an extra copy of every level layout included in the unreal level.
​
Both these problems left me stumped for a while on how to fix it. They also felt linked somehow. I came to the conclusion that it was the initial method that was causing the issues, it's the fact that all these level layouts were in the main unreal level and spawning them was getting expensive as the game grew and artwork was added.
Therefore I set out to research as well as workout ideas with the team and supervisors as to how I might get around the two of these problems. I eventually learnt of and settled at level streaming. It would mean moving the layouts into their own unreal level each and repurposing the spawning code into a level stream and initialisation code. This was a lot of work but I believe it saved a lot more future headaches as it was caught this early.
​
Problem: The doors now don't link.
​
As one problem was fixed another was created. The doors now went from working some of the time to not at all. As the level layouts were steamed now I decided to create a manager that would track the BP_level_base as they were streamed in. This then would hold references to the previous layouts exit door and the new layouts entrance door, allowing for these to now be dynamically set as and when they are needed. This system now worked all of the time.
​
Problem: Sometimes the level layout selected for the next cave is the same as the current cave. This was not great design, can we fix it?
​
Using the previously mentioned level manager we now can track the levels that are streamed. Therefore I simply added a function that stopped the same layout from occurring twice in a row. Otherwise it was randomly spawned as and when it was needed, procedurally.
​
Problem: All the resource nodes are the same and don't level up as the player proceeds deeper into the cave.
​
The design for the game was that as the player progressed deeper within the cave rarer and different crystals would spawn. This was an issue with the way that the level layouts were streamed in as there was no telling what order the layout would appear. This therefore meant that the crystals rarity and type needed to be set dynamically.
To do this I created a rarity manager, through communication from the level manager, the rarity manager would increase the "rarity level" once the appropriate amount of progression has occurred (player progressed deep enough into the caves). This was just a simple interger that ticked up for each complete level. A resource node blueprint was created which then, when initialised through the level manager (as it is a child of BP_level_actor) the crystal would update based on the current rarity level. Different rarity levels would equal different crystal percentages. For example crystal A = 70% and crystal B = 30%. The system would search for and set each crystal individually, where there is a 70% chance that the crystal turns out to be crystal A and a 30% chance of being B.
Problem: Levels are now have a chance of spawning with not even one of a specific crystal. This means in a very unlucky run the game where one type of crystal doesn't spawn, the game cannot be completed.
​
For this the script was changed for the spawning to ensure at least one of each crystal type per level layout was set, for the rest to be determined by the percentages.
​
The Result
​
Note: Different aspects that have been mentioned are throughout the video. Level generation & tool kit are at 2:30 within the video.
​