"Memory Leak" Dev Log #2 - Implementing MEMENTO
NOTE: This was meant to be part of the first dev log (hence why I'm posting immediately after it!) but it started to get too long so I separated implementing MEMENTO into its own log!
After I thought of what I wanted Memory Leak’s main mechanics to be, I spent a long time ruminating on how to implement it. A common mistake a lot of newbie game devs make (such as myself) is trying to reinvent the wheel. I thought of this cool game mechanic and I’m going to code it from scratch to show my Programmer Skills.
I use to think this a lot and it’s why a lot of my projects and ideas just kind of sat there in my Google drive, untouched and forgotten.
I’ve since convinced myself it’s okay to use something that already exists and build on top of it, which is basically what most professional software developers do anyway. Again, there’s no need to re-invent the wheel here.
Except, I still kind of fell into this pitfall when trying to create MEMENTO. I was so convinced that my super cool game mechanic hasn’t been done before therefore I had to code it from scratch on top of learning the Ren’py engine. I’ve programmed in python before, so no big deal, right?
I found myself getting frustrated trying to figure out Ren’py and thinking of unnecessarily complex ways to implement MEMENTO. I initially wanted players to be able to drag and drop memories and I spent a ridiculous amount of time trying to configure Ren’py’s Cardgame framework to do exactly what I wanted it to.
I more or less gave up for some time and decided to approach it more abstractly (which by the way is how you should approach most software development - don’t think in code first!). This way I realized, MEMENTO was nothing more than an inventory with a crafting system and cool doodads that I would implement later. Instead of starting from nothing, I came across sagurao’s inventory system implemented in Ren’py, which already had the crafting system I needed.
First, I familiarized myself with sagurao’s code and made notes of which functionality I could use to implement MEMENTO.
Though, I unfortunately got ahead of myself and thought too much in little details like how would drag and drop work? How do I make the encryption mini-game fit in here? I understood the code, but now what? Where do I start?
I started to get frustrated again and every time I opened the inventory code would get discouraged and close it after 10 minutes or so.
Lately I’ve been working as a counselor at Girls Make Games and found myself too busy to spend lots of time on Memory Leak. It started to look like another one for the Google doc graveyard.
That was until I gave presentation on Game Design and used my notes making Memory Leak as an example of game design documents. I felt kind of hypocritical showing my own notes on a game I haven’t really thought of for a while. It was this and helping the girls figure out their own game mechanics more abstractly when I realized hey maybe I should take my own advice.
A method I used when helping the girls figure out their game mechanics was thinking of small simple tasks and testing them then incrementally implementing other requirements. This way of development is similar to Test Driven Development where test cases are made for a specific requirement, implemented, tested, then done again for more features. I have had some experience doing this myself at work and it’s infinitely less frustrating than trying to create one big picture all at once.
I came up with small seemingly trivial test cases for MEMENTO and started working up from there.
Samples of test cases I used:
- Create MEMENTO (instance of Inventory) and Gestalt (inventory instance)
- Add memory (instance of item) to Gestalt
- Add sections to MEMENTO to present regions of the brain (each region is an instance of an inventory)
They seem simple but they add over time and soon I should have a very rough prototype of MEMENTO working!