End of the Line is a game about a man stuck in a time loop on a train, trying to escape the loop and stop it from exploding. It was my Final Year Project, and I worked on it alongside 8 other team members, comprised of 2 artists, 4 programmers and 2 other designers. It was a game that took approximately 8 months to complete, from conceptualisation all the way until the final build. I was in charge of several aspects of design, most notably writing dialogue, designing some of the levels and creating the game’s puzzles.
In this post, I will cover the various elements in the game that I designed, and I'll go over my thoughts on them. I'll also go over what went well throughout development, and what I would have done differently with the power of hindsight. Last but not least, I will also look at some of the things I wish I could have added to the game with more development time.
First, I’ll go over the aspects I designed in more depth, starting with the level design.
In particular, I designed the layout for the seating area and engine room/driver’s cabin. I also worked on the preliminary layout for the garbage room, working with the other designers to refine and improve it, as well as the 3D layout for the bar. Each level started out with a 2D side-view layout created in Photoshop, with each prop labelled. It was then brought to the team to be reviewed for any potential changes.
Once those changes (if any) were made it was on to blocking out the level in 3D. For the garbage room and bar, I used Minecraft to make the layouts, as it was something I was familiar with and made it easy to iterate quickly. After I had created those, I learned how to use Unity’s Probuilder, and used it to make the 3D blockouts for the seating area and engine room. In hindsight it would have been better if I had learned Probuilder earlier, as it would have streamlined the process further. The Probuilder assets worked as placeholder for the actual 3D assets, and they still had to be created even with the 3D layout in Minecraft, and so going from 2D layout to 3D Probuilder blockout would have been the ideal pipeline throughout.
The next aspect I’ll go over is the dialogue. The majority of the dialogue still left in the game was written by myself, with the exception of the interactions with Rocco as well as some of the item interaction monologues, which written by the other designers and some of the programmers.
The dialogue system of the game was handled via a modified version of Yarnspinner, a Unity add-on that allowed myself and the actual designers to write dialogue that could be inputted into the game directly. This made it so that changes and additions could be made quickly and easily, streamlining the whole process and reducing the workload of the programmers significantly.
As the dialogue was in the form of speech bubbles above the characters’ head, every line had to be as short as possible, as to not clutter up the UI and overwhelm the player with too much information. Therefore lots of edits had to be made to the dialogue over time to ensure that the correct information and message could be given to the player in the least amount of words possible. Quite a bit of dialogue ended up being cut out or simplified, in favour of keeping it brief. Multiple testing iterations assisted in culling the dialogue even further, and helped ensure that the core point of the dialogue was still retained.
For the final aspect, the puzzles, I made two of them: The bionic eye quest and the engine room quest, and worked alongside the other designers to make the garbage room quest. I also gave feedback on, and assisted with the wine, bartender and coinflip quests. Every puzzle in the game was first shown to the team as a diagram, with an annotated series of numbers on the 2D layouts of the levels, with the annotations describing the player's actions at each of the numbered points. One of these preliminary diagrams is shown below:
All of the puzzles in the game went through numerous iterations; the bartender and wine quests in particular went through the most, as they had the most sequence breaks out of all of the puzzles, and were constantly intertwined, making adjustments slightly more difficult in comparison to the others. The primary difficulty with designing the puzzles was to make sure the players could understand and thus complete them. It was quite the challenge ensuring that the puzzles were sufficiently difficult, yet also making sure players weren’t completely lost. The journal system was introduced to help players retain key information, and guide them towards completion.
While for the most part gameplay went smoothly for players, there were a few instances where testers got completely stuck and either stopped playing completely, or had to ask what to do. This would happen most notably in the garbage room. There were several cases in earlier iterations of the game where we (the team) believed a quest would hold the player’s hand too much, but in testing the player themselves found the quest to be either slightly too difficult, or just the right difficulty. It was an interesting observation, and something to be wary of when creating puzzles in the future. All in all the puzzles ended up being just the right difficulty for the most part, with the majority of players enjoying them and finding them sufficiently challenging.
In this next section I’ll go over what I think went well throughout the whole development process, and will also give my thoughts on what could have gone better, as well as what I would have done differently with the power of hindsight. I’ll also cover what else could have been added if we had more time.
First off: What went well. All of the puzzles flowed relatively well together, leaving very few moments where the player had no actions they couldn’t perform, the size of the train and the proximity of all the puzzles allowed for almost completely continuous gameplay, keeping players engaged throughout. The time loop was also roughly the perfect length, aiding the flow of the puzzles, keeping players on their toes while still giving them ample time to perform the necessary tasks each loop. The time loop itself is 2 minutes and 30 seconds long, which was decided on after numerous playtests with different loop timers, and we eventually narrowed it down to its current length.
For the most part, all of the dialogue and interactions in the game were not too long-winded, getting sufficient information across to the players without making them lose their focus. This was quite the concern with some of the bartender’s dialogue, and after multiple iterations we managed to get it down to a concise length. The dialogue and interactions managed to balance narrative and instructions relatively well, in a manner that didn’t seem too out of place. Finally, we were happy that the majority of players could complete the game with little to no outside guidance, as that was a major worry of the team throughout the earlier testing iterations.
Next: What I would have done differently during development. As there’s quite a few relatively minor things, I thought it would be best to put them in a list, shown below:
- Change the garbage room to be more consistent with other quests, and more intuitive
- Change the wording for the coolant box and keypad codes in order to be less confusing
- Change how the coolant box works so players don’t get confused by it and assume one of the answers is correct
- Add more story elements, to provide the players with a greater sense of the narrative
One additional thing I felt I should have done differently is my approach in designing the puzzles/quests; I brainstormed numerous ideas and cut/polished them based on my perception of how much my team was able to handle given their current workload before bringing them to them, where instead I should have presented the initial ideas regardless and decided on them together with everyone else. Culling the ideas myself led to a smaller pool of ideas and longer time spent developing ideas without presenting them. I was initially worried about puzzles taking a large amount of assets, given that my team only had 2 artists who already had quite a large workload, and decided to take matters into my own hands at first, which in hindsight was a bad way to do things, as potentially more unique and interesting puzzles could have been made if I had brainstormed everything with the team first.
And finally, a list of some of the potential features that I think could have been added if we had more development time.
- More interdependent quests, similar to the Eye quest
- More dialogue to flesh out the background story
- More narrative elements throughout the game to actually push a story
- Add the second floor, with fancier and richer props and environment to further the narrative
- Add the previously cut eavesdropping mechanic, which would add more gameplay variety
- Improve the existing UI, as it was an element that was left till late, so much could be changed
And there we go, all of my post-mortem thoughts on End of the Line!
All in all End of the Line has been an amazing project to work on, and I’ve learned so much over the course of development. It’s definitely been a journey of personal and professional growth, and I’d like to think I’ve come out of it a far better designer than I was those many months ago. I’m also proud of what Semicolon Studios; (that’s our team name!) has accomplished with End of the Line; winning the Best Student Game award at the SEA Game Awards 2022 is something I never would have dreamed was possible early on in my university days, and we managed to do it together. I want to thank all of my team, for being simply amazing to work with, and for pushing me to improve myself constantly. I’d also like to thank all of the lecturers for their incredible advice and support; this game wouldn’t be possible without them.
Till next time!
Bình luận