I had just finished my programming education, and was looking for projects, and this was a great opportunity since it was the height of the pandemic. I had joined a small indie team I found on Reddit, and volunteered for a bunch of roles, including all of the programming.
I was used to Unity 3D, I even had a class focusing on it, but I hadn’t used Unreal Engine 4 before so this was a rapid learning experience. It took some iterations, but once I got over the learning curve I got the game working.
The goal was to create a vertical slice of the game. We created one short playable level with cutscenes (AKA Sequences in UE4), choices, and different routes. It’s short, and still rough around the edges, but otherwise it looks really good. And most importantly to me, as the principle gameplay programmer, it’s playable!
First I had to set everything up. Originally I had put everything in the Level Blueprint for the sake of prototyping, but I learned the hard way these changes can’t be implemented in a way that will carry over to future chapters. So I decided to make a class that handled all of that instead.
Set up included added instances of the classes I was using (more on those classes later), and making the UI appear and disappear.
One exception to the overall schema is the title screen sequence. Since our demo was so small I only put it in the Level Blueprint, and never needed to implement a way to go back to the title screen. In retrospect it should be encapsulated into its own class as well so the player can get to the Title Screen whenever they want.
This is the class I spent the most time on. The Sequence Controller class references a data table that tells it where in the story the player is, and what sequence should be played for that position.
Then it saves the game. One thing worth mentioning about saving the game is that the game designer controls whether or not the game should be saved when editing the sequence. This way the player can’t get stuck at a dead end of choices.
The Choices Widget UI holds all of the choices, their visibility, and what controls their visibility. This was the most tedious since it needs to account for a lot of choices. On top of that it definitely needs refactoring. Since choices are different for every chapter we couldn’t just reuse this widget, though it could probably be repurposed. If the team ever gets back together then this is one of the first things that needs improving.
The system is pretty simple. The method references the data table from earlier for the story position, and to see what it should do when the sequence ends. The sequences can automatically play another sequence, lead to a choice, or require a boolean check to decide what comes next. Then it acts like a large switch, falling through each option till it reaches the one that specified. Once it reaches its destination it destroys the level sequence actor and creates a new one for the sequence. Then it plays the sequence, and repeats until a game over is reached.
There are a lot of improvements that can still be made, but I’m proud of what I made. The game only worked in theory before I added all of this, and no one else had an idea how to tackle it. My contribution is largely invisible since the sequences are the focus, but the game would have been unplayable without my help. So that feels pretty good.
Douglas Rysdyk 