Nearing the End

As we’re nearing the end of the term and finalizing much of the work on our adventure game, I’ve had a lot of opportunities to solve problems and I would like to share some of the techniques that I’ve learned in this blog post.

Throughout the process of building a text-based adventure game, I’ve been faced with challenges that go outside of what I normally experience. Some creativity related, some engineering/best practice related, and some to do with new technology. All of these have their own techniques and I approach them differently.

Recently, I experienced a creativity problem with the storyline of our murder mystery game. Most of the storyline flowed really well, but there was one part of the “how did they do it” that wasn’t tying together with the rest of the storyline so well. At first I felt stuck because I had an idea of how I thought it would go. After tinkering with some different story ideas, I realized that the benefit of a text-based game is that it’s very easy to change the story with little impact on the gameplay. One of the strategies I took was to ask someone in my family about how they would solve the problem. They started asking me a lot of questions and through this back-and-forth dialogue I was able to see a clear path to how I could solve it. In the end, I was able to tie the story together in a nice neat way.

Often though, in software engineering the problems are largely technical. I was recently facing a strange unit testing issue on one class in my codebase that deals with loading and saving JSON files. All of my unit tests were passing locally, but when I pushed my code to GitHub it was failing the GitHub Actions. I was able to go and review the logs to see what happened, but it wasn’t very obvious. After some time studying the cryptic looking output, I discovered that my file operations weren’t all being mocked. I had recently added a new load operation in that class, but didn’t go back and mock it in the previously written unit tests. It was working locally because it was able to actually open and close files, but in the CI pipeline, that wasn’t allowed and so it failed. I was able to solve this problem by thinking critically about the changes that I had recently made to the program that could be causing the strange behavior and it led me to the file manager class.

During the course of this project I have been really interested in learning about some new technologies. As I mentioned in my last post, I think it would be a great opportunity to take the storyline that we’ve created and use the existing configuration to recreate a new text-based adventure game engine using another programming language. I’ve been really excited about functional programming lately and being familiar with the .NET ecosystem, I naturally found F# and am excited to see what I can do with it after graduation. One of the interesting things about game programming is that it involves a lot of mutable state. One of the principal tenets of functional programming is to reduce and minimize the amount of mutable state to keep things purely functional where possible. I think it would be an exciting challenge to try to recreate the game engine using a functional language since the approaches to problem solving are vastly different.

Though we’re nearing the end of the project, I know my journey with software engineering is really just beginning. Every new technology I find and use keeps me excited to learn and grow. This project definitely pushed me beyond my comfort zone and that’s exactly what I needed. As they say, there’s no growth in the comfort zone and no comfort in the growth zone.

Print Friendly, PDF & Email

Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *