8 Lessons from Making my Dissertation Game, To Water
To Water was the first ‘full’ game I’d ever developed, and was my first real project in Unreal engine. It was extremely enjoyable to create, but there were many struggles along the way - some that only cropped up very late in development. These are some of the most important lessons I learnt along the way:
Make a build of the game every time you implement something - don’t wait to find out you have an issue that won’t show up in the editor until the last day. This seems obvious, but there are some issues that can only be seen in an executable file as opposed to the editor, so it’s important to check how the game is running independently.
The cutscenes in the game weren’t meant to directly tell a story, but create an arc through the emotions expressed within. However, creating a narrative that relies on this means that these conversations need to be really interesting. If you can’t hold someone’s attention through what is supposed to seem like a mundane conversation, you’re never going to achieve what you want to do on a higher level. If the message or tone you want to convey is too subtle unless they're totally focused on what seems like an unimportant cutscene, you’ll lose the emotional response you want to create.
When you try something technical and it doesn’t work, make sure to undo that work - it may have unforeseen consequences.
Ideally, don’t change player settings like run speed etc. for cinematic moments - make them want to change them of their own accord. For example, I wanted the player to slow down for a train coming past, otherwise they’d run into it. I could have designed it more effectively so that they wanted to slow down anyway because of some kind of threat etc., and then the moment would be more surprising than them just slowing down automatically, expecting something. Try to remove player autonomy as little as possible.
As this was a dissertation piece, and my deadline was looming, I was terrified of playtesting, preferring to keep working in my bubble and add as much as I could. My time would have been used far more effectively had I tested the game on players and worked on issues brought up. The game ended up being much harder to play than I had intended, purely because I was the only person who’d ever played it. Don’t be afraid to have people play it, because they won’t be able to appreciate all the effort you’ve put in elsewhere if they can’t even get to it.
Address problems with design as soon as you sense them. I realised quite early on that the system I had for puzzles didn’t really work the way I wanted it to, but I got caught up in the fun and excitement of building levels and parts of the world that I pushed this really important element of the game to the back of my mind. I should have dealt with this much earlier to allow for the subsequent design to cater for it, rather than having to shoehorn it in later.
Don’t put off doing all the ‘boring’ but necessary parts of your product. On the day before my hand in I started adding the menu, and this proved to be much trickier than I’d imagined, meaning it didn’t really work. I underestimated the time needed to implement this feature because it wasn’t something I really wanted to do, but it’s important to mix up the most enjoyable parts of development with the more tedious to help progression.
Allow for plenty of time to do voice recording. I booked a studio for a mere three hours and was only able to do a few takes of each scene, which hindered the emotional quality of the acting as the actors weren’t able to really get into it. I was also learning to use the studio equipment on the fly, meaning that a lot of the recordings don’t sound as professional as I would have liked due to audio issues.