Section 1 - Concept
Section 1.1 - Prompt
For this project, my group and I were prompted to create a multiplayer survival game in Unreal Engine. The game's focus would be gathering resources and building a shelter on a deserted island after your plane crash landed, all while fending off hostile wildlife and trying to find a way to escape. Each lobby would host 4 players, although each player can decide for themselves if they would like to work in a group with their fellow survivors or try to make it out on their own. For the creation of this game, I worked as the sole game developer alongside Willow Dallimore as a game designer and Eden Smithbury as an asset and branding designer.
Section 1.2 - Inspiration
Our first order of business was finding a unique selling point in an oversaturated genre. We looked at many similar games to see what already exists within the market and what we could do to stand out. For example, The Forest is a popular survival island game that most notably has “cannibalistic mutants” as the main enemy. Raft is a similar game that takes place in a completely flooded world instead of an island, and another game in the genre, Rust, has radiation and a heavier focus on PVP (Player vs. Player combat). Other games have unique selling points such as a sanity meter (Don't Starve) or an inherently hostile environment (The Long Dark). However, as we pondered that, we noticed quite a few commonalities between these games. Most included a heath, hunger, and thirst bar, and many include an energy or stamina bar. Additionally, crafting and building mechanics are prevalent in this genre, with players typically gathering resources to create tools, weapons, and shelter. We also noticed that these games often have a day-night cycle, where players must adjust their activities based on the time of day and the dangers that come with it. Another common feature is the inclusion of wildlife, which can serve as a source of food or a threat to the player.
With all of these similarities in mind, we brainstormed ways to differentiate our game. We considered adding a unique twist to the survival mechanics, such as a system where the player's actions affect the ecosystem around them. We also considered implementing a dynamic weather system that would affect the player's abilities and surroundings. Ultimately, we decided to utilise the player's stats against them, emphasising the need to take care of yourself and survive.
Section 1.3 - Design
While taking care of your stats is necessary in these games, letting the bars drop has little to no effect on you, outside of losing health. We found this to be a missed opportunity, especially when it comes to the energy bar. When you go too long without sleep, you can start to experience perception distortion and hallucinations, verging on psychosis. Typically, you need to go upwards of 48 hours without sleep to start experiencing these symptoms but in a live-or-die situation where you don't know who you can trust? It's safe to say you'd devolve into paranoia and psychosis much quicker than that. It is also possible that there is something else affecting the island causing you to get more tired faster but it could also be explained by fading adrenaline; it's up for player interpretation. This gave us a very easy yet unique mechanic to move forward with, and firmly cemented our game within the survival island and horror genres. In addition, this gave players a reason to not only work with others but go out on their own. They don't know who they can trust, if the monsters attacking them are wildlife or their “friends”. However, they do sleep better and therefore regain more energy when watched over by an ally, giving them a reason to work with others.
As for the actual look of the game, we wanted the game to be relatively realistic (without entering the uncanny valley of course) so we opted for 3D graphics. However, we also wanted the player to be more aware of the idea that something is lurking in the corner of their eye or just out of view and found that playing with a close third-person camera better communicated this idea, allowing players to be more aware of their surroundings instead of hyperfocusing into the character's viewpoint. Once the basic mechanics were planned out, the rest of the design became jobs for the rest of my group, allowing me to focus on learning Unreal Engine and creating the game.
Section 2 - Creation
Section 2.1 - Learning Unreal
When it comes to learning Unreal, numerous problems arose. First off, I needed to install the software in the first place, which I thought would be no problem at all considering Unity runs just fine. However, I was wrong, and Unreal didn't properly install the first 3 times. This, of course, lead to me getting a late start on my project. In addition, once Unreal was properly installed, it had (and still has) a very large tendancy to crash my laptop which was less of a problem and more of a time-consuming nusance. After that was solved(ish), I got to work understanding the program which was easier said than done. While we talked about C/C++ in class, I found it to be more complicated than I had anticipated and I struggled to understand it well enough to write my own. Because of this, I attempted to use the blueprint system, after I figured out how to open the blueprints in the first place (which, to be honest, I'm probably still doing in an overly complicated way). However, when I struggle with finding the issues in my code, I often re-write it as a flow diagram as seen in Figure 2.1.1.
Figure 2.1.1 - A flowchart from the development of Interrogate the Truth.
When looking at the blueprint system, you would think that I would prefer it, or at least understand it better. Sadly, this wasn't true at all. Despite its similarities with flowcharts (as it is essentially a modified flowchart), I actually found it more difficult to understand and had to make a flowchart of the flowchart.
Figure 2.1.2 - A flowchart depicting one of my attempts to hold items.
Section 2.2 - Blueprints
Frustratingly, while I often knew how to get the mechanic working in C# and Unity, I found that I didn't know the correct functions or components to make it work in Unreal. Even more frustratingly, I was so preoccupied with figuring out how to work the blueprints in the first place that I completely forgot to document my various iterations and progress on each. While I did utilise online tutorials to figure out the basics, I then modified the blueprints to better fit my needs.
My first step was picking up objects. As many tutorials exist for this mechanic online, I found one that fit my needs and followed it for the most part.
Figure 2.2.1 - The first part of the blueprint which gets the correct item and feeds that information to the blueprint in Figure 2.2.2.
Figure 2.2.2 - The second part which prints a string, runs the function in Figure 2.2.3, and passes on the name of the object for future reference.
Figure 2.2.3 - The last part of the pick up script that waits for 0.1 seconds (so the blueprint in Figure 2.2.2 can get the name in time) and then destroys the object.
After that, I followed the tutorial to create the inventory system that updates dynamically.
Figure 2.2.4 - The blueprint for opening and closing the inventory UI.
Figure 2.2.5 - This takes the name (as gathered in Figure 2.2.2) and adds it to the array that makes up the inventory UI.
Figure 2.2.6 - This takes the array from Figure 2.2.5 and updates the UI widget to accurately display the objects currently in the inventory.
After that, I added some code to ensure that when an object is picked up, the necessary widget exists and linked this into the beginning of the pick up script.
Figure 2.2.7 - This blueprint shows that when the player presses the E key, it will check if they are currently holding something. If they are not, it checks to see if the inventory widget exists; if it does, it moves on to the blueprint in Figure 2.2.1, if it doesn't, it will create it and then move on.
Up until this point, I had followed various tutorials with only slight revisions, but I could not find a tutorial that included placing items back down like I wanted, so I took what I had learned and managed to create a put down blueprint myself.
Figure 2.2.8 - In this blueprint, the game will get the character's location and facing direction to spawn the previously destroyed actor in front of them. It then passes on the name for future reference.
Originally, I wasn't a fan of destroying and respawning the object as I thought it could cause issues down the line, however despite my many attempts to find a work around (like teleporting the object out of the way), I could never figure out how to then target the object to bring it back. In addition, I attempted to simply reverse the code for adding the object's name to the inventory, by simply removing it from the array just like I had added it before, but couldn't for the life of me find a function to remove it like I did for the addition. Ultimately, by the time I had managed to get Unreal up and working, and figure this all out, I had run out of time for the project. While I would've loved to show more progress and development, I had so many issues every step of the way that despite the little I have to show for myself, I am still proud of my work and what I have learned.
