Warehouse Wreckage is the first game students build in GameDev.tv's UE5 C++ Developer course. Building the game introduced me to some core features of Unreal Engine 5, such as Blueprint programming and a number of the built-in object and functions used to make games in UE5.
The course content was pretty basic, with the final product being a building resembling a warehouse of sorts with some objects you could knock down. I decided to spice it up a little for my own take.
One thing we were introduced to is the Print String Blueprint node. The course instructor used it to print some simple welcome messages, but I got a little more creative. While games do not necessarily have to justify themselves, I love when a game sets the scene and really gives the player a reason for the situation they find themselves in. So I did!
You wake up in a warehouse surrounded by crates after being abducted by strangers.
And true to the message, I did in fact start the player in the middle of a warehouse, surrounded by crates.
The second message continues to set the scene and let's the player know there is maybe something they can do about the situation.
You can safely assume this is their warehouse. And you can safely assume they did not know about your special power.
Iiiinteresting. So, the player is in their abductor's warehouse, and they have a special power that will presumably help. If only there were a third message to tell them more!
Press space to use it, escape your makeshift cage, and take revenge by destroying their warehouse!
This message serves the purpose of telling the player the primary control that they need (aside from movement which most players tend to assume is WASD anyway). It also gives the player all the motivation they need to actually play the game: revenge on their abductors. Again, games do not necessarily need to justify gameplay elements, but to me it is always a little more fun when they do.
The original teaching material had the player with 20 shots - which it would count down with blue messages - after which it would tell the player they were out of ammo and that the level would restart. After a few seconds, the player would find themselves back at the start of the whole cycle. This is fun, but how do I sell it?
First, given the player had to use some shots to get out and that I filled the warehouse end-to-end, I decided to give the player 30 shots. I also decided not to tell them how many were left, instead prompting them with this message when they ran out:
You run out of energy. Exhausted, you realize this is starting to feel familiar. Have you done this before?
With this final bit of story, the final gameplay portion of a round looked like this:
And with that, the game sets up some kind of time loop logic for why the game just restarts. Perhaps a bit cliche, but for me a cliche reason for the restart is better than no reason at all.
Overall, the meat of the game is no different than the project as defined by the course. But I think the addition of my little story - as simple as it was - transformed the game from a simple physics playground to something more personal. I really like it, and at the end of the day the important piece is that I am happy with the result.
If you are a GameDev.tv student, I challenge you to make these projects your own even in some little way. For me, it was adding a silly little story. For you, maybe it is a reoccuring theme or easter egg in each project. Or it could be something else entirely. Add something to each project that makes you smile when you run through it. It will do wonders to keep you motivated and eager to complete each section.
And with that, this showcase comes to a close. I will be putting up similar showcases for the other GameDev.tv projects, as well as whatever comes next when I am done with the course work. If you found this inspiring in any way, be sure to keep an eye out for those!