Let’s Talk About Machinery

The project that I’m working on is the text-based adventure game. I think it helps to understand this because what I’m about to say was sort of an epiphany for me. I wracked my brain for days trying to figure out how to organize the code, what kind of abstractions to use, and so many other thought experiments. But, like all coding miracles, I woke up one morning with a crazy idea. (It’s really not that crazy). See, a text-based adventure game is one where the user inputs some commands, they’re interpreted, and then something cool should happen. The more I began to think about this, the more I realized that the request/response model in this game is almost identical to a typical HTTP request/response model. This notion really brought some abstractions to life for me and helped me draft up a design document which laid out all of the abstractions we would need to model our game after this similar style. In my mind I had somehow thought that it was going to be really difficult to work out a design and it turns out, like most things, I was simply overthinking it.

One of the biggest benefits to the design architecture that we’ve chosen for our project is the fact that there are many separate layers that have their own independent job. For example, we have an AdventureGame class that handles the main game loop and knows how to host services, much like a web server. Then, we have a TextParser class which interprets the intent of the request (much like an HTTP request is interpreted). The TextParser then passes the request off to a Router, which in turn passes it off to various GameControllers whose primary function is to interpret the types of requests, and then delegate the requests to various functions in a service layer. Each service layer has access to the GameRepository which is a persistence abstraction to maintain controlled access to the game state. What makes this design great is that there are a ton of internet resources about it because it’s such a popular design for web applications. Another benefit is that it becomes very simple to write some new logic in one of the layers, and then mock any layers around it for unit testing. This means that my teammates and I can be working on separate sections of the code at the same time, but know exactly where the boundaries are between layers.

Once the design was squared away, it was time to start thinking about what to build, and how to build it. For our primary technology, we chose Python as the programming language. This is simply because it’s easy to use, easy to test, and part of the learning track for this program which meant familiarity for the team. I also chose to set this project up using Poetry, which is a package management tool for Python that helps to create virtual environments and manage dependencies. It also happens to work very well with Pytest, which is my favorite testing framework. We also chose to use an online application to help us with our map design called Dungeon Scrawl. It’s a fantastic, free map making tool designed to help game players everywhere create interesting maps for their adventures. One library that we added to our project so far is called BlingFire. Despite the cool sounding name, it’s primary job is to help with splitting paragraphs into sentences. So far it has done amazingly at that and I have no complaints.

Although all of these technologies were perfect for this project, they aren’t without their limitations. For instance, I primarily use C# and the .NET infrastructure at work. I’ve become very used to the dependency injection container handling a lot of, well, dependency injection for me. This meant that in Python, I had to think a little bit more about how I would pass things around from the AdventureGame class. Another con to using Python is that even though it’s easy to use, it requires that Python be installed where the program is run rather than creating a binary output which can be run anywhere.

One think that I think would be really interesting, would be to do a language comparison using this game as a test platform. I’ve always been interested in learning different programming languages, and it would be really interesting to recreate this game using C#, Go, Rust (a language I’m really interested in learning), and many others in order to learn, add more examples to my portfolio, and explore languages using a familiar project to discover more about them.