-
Notifications
You must be signed in to change notification settings - Fork 3
Development History
Cheese Quest started development in 2016 while I was in my 3rd year majoring Geophysics at the University of Calgary. I had no prior programming knowledge or experience, and was taking an introduction to computer science course for non-computer science majors (CPSC 217) as required for my degree.
As soon as I learned that I could receive input from the keyboard and output text to the screen, I knew I wanted to create a simple IF game. Infocom's Hitchhiker's Guide to the Galaxy IF was a big part of my childhood and a game I really came to appreciate because the whole concept of a game based on a typing in commands seemed so cool and different from any other games I've played.
At first, Cheese Quest was just going to be a couple of rooms with some puzzles. The implementation wasn't particularly well thought-out since (A) I only intended it to be something small and (B) I was completely new to programming as a whole. As a result, the code was essentially a giant series of if/elif/else statements encased in a single multi-thousand line while-loop, where problems were repeatedly solved with ad hoc band-aid fixes with little code reusability. Sticking with this approach would ultimately lead to the downfall and eventual abandonment of the project.
While I knew what functions were at the inception of Cheese Quest's development, I don't believe the concept of using functions to reuse code entirely sunk in until quite some time. I did make a couple utility functions (just to reverse a string which I only use once), and some functions that were just to print text. Despite that, I essentially used functions to represent the game's current menu state: in the main menu, in a game over prompt, or in the game itself. Looking back at it now as I write this, this might have caused some stack overflow issues if the player goes back and forth between menus enough times, but that was a concept entirely foreign to me at the time.
Later on in development when I decided I was going to increase the scope of the game, I wasn't entirely sure how I was going to store the data of all the rooms and items.
I was already doing some of it through global variables, and some through local variables within the main() function.
I did some research and learned about classes and objects, although I didn't figure out about the whole paradigm of object-oriented programming until my 2nd Computer Science course (which I didn't take until later on when most of the game was already complete).
As a result, only a few components of the game were converted to classes, being Inventory, Room, and Stat (player statistics). Part of me wanted to convert everything into classes, almost discovering object-oriented programming on my own while being blissfully unaware of it already being a thing, but I figured I might as well spend that time adding more content instead.
Yeah... I never figured this out during the game's development, which is why the game does not have a formal save/load game system but instead uses spells (more details on that here).
This problem is one of the central motivators that prompted me to start development on Cheese Quest 2.
Shortly after starting my second Computer Science course (CPSC 219) and learning about object-oriented programming, it quickly dawned on me just how terribly designed my initial approach to the game was. I kind of already knew that the code was terrible early on since I had to move around the file through 4 or 5 different locations if I wanted to add a new item or room, but it never really bothered me since the game was of an intially small scope. I completed the game to the point that it was actually winnable, and continued changing and adding content afterwards due to feedback. This was all the while the idea of creating a new version of the game from scratch lurked in the back of my mind. Eventually, I began to understand that if I were to increase the game's scope further that I would have to make some drastic changes to the code if I were to continue working on it.
After learning about creating GUIs through Java's javax.swing and java.awt packages, I finally decided I would remake Cheese Quest in Java. I liked Java's approach to object-oriented programming better than Python's, and while I'm probably in the minority here, I also liked its overly verbose syntax as well. While I understood that it would take some time to build the game's foundation from the the ground up before I could actually start adding any real content, it didn't really bother me. After all, I never intended to share this game to anyone beyond maybe 2 or 3 other people, and I took this more as a learning experience rather than anything else. I abandoned any serious development of the Python version although I occationally made small patches afterwards.
Moral of the story: Creating a game with a foundation designed with little to no Computer Science knowledge and building upon it until it grows into an unmaintainable monstrosity is probably not a good idea. Who would have guessed?