"Memory Leak" Dev Log #3 - (Re)-learning Python & MEMENTO constraints
Last I left off, MEMENTO was looking kind of ugly. But now...MEMENTO is still kind of ugly but with more functionality I’ll be needing for the actual game.
The next test cases I wanted to tackle were
When adding a memory from Gestalt to a brain region, check if that memory belongs to that region
Else, do NOT add memory to brain region.
When adding a memory to Gestalt, check if Gestalt is full.
Else, do NOT add memory to gestalt.
Seemed simple enough. The reason I didn’t tackle them earlier was because I was manipulating the Inventory class directly in small ways to get it to look how it looked in the last log.
After looking more at the Inventory class, I figured it would be best if I just made my own class for MEMENTO that extended from Inventory. Then I would just override and add my own methods to do what I needed it to do. There were no checks for “brain regions” or “gestalt space” in Inventory, so it made sense that I just make my own class. The MEMENTO class looked like:
Gestalt extends Inventory
New features: Check for max size and current size
Brain_Region extends Inventory
New features: Region name
Memory extends Item
New features: Region name
Extending from the Inventory and Item classes wasn’t hard - it was implementing “trading” between regions and gestalt that was way more difficult than I expected. This was due to:
Inventory having several modes - banking, trading, selling
Not really knowing which words were python keywords and which were Ren’py keywords
Basically, not really knowing how Ren’py worked in general
I was also super overthinking how I needed to implement trading between regions - I did that newbie game dev thing where I thought I had to make it all by myself. When really, all I had to do was override the given “take” and “drop” methods that Inventory already had. After that, it was really just a matter of re-learning python and reading Ren’py documentation. Actually, most of my time was spent reading Ren’py and python documentation.
But I ran into a new issue: When trying to move a memory from Gestalt to the incorrect brain region, the brain region won’t take the memory but Gestalt will drop the memory as if it had been traded and said memory is lost forever (to the player, at least). The same would happen vice versa (brain region to Gestalt if Gestalt is full).
So that meant, I needed to add to my previous test cases:
...Else DO NOT add memory to Gestalt and DO NOT drop from brain region
...Else DO NOT add memory to brain region and DO NOT drop from Gestalt.
Both were easy fixes but it goes to show how important it is to start with small test cases and build from there in case of unaccounted for cases.
The next test case I wanted to work on was triggering dialogue options based on memories stored in Gestalt.
For Memory Leak, I wanted the gameplay to be similar to the Ace Attorney series which has a combination of point and click gameplay and visual novel mechanics for narrative. And this is when I learned that the Ren’py engine is more suited for linear visual novels.
BUT I did come across SusanTheCat’s point and click sample project and looked over the provided sample's source code to get an idea of how to implement point and click game mechanics in Ren’py.
Though, Memory Leak wouldn’t just be point in click but would also involve character interaction. One major issue with using Ren'py screens and labels to implement a point and click was how menus in Ren’py worked - they’re meant to transition to other scenes (or “labels” in Ren’py) in a linear fashion. While in Memory Leak, the player would be able to return to certain locations (“labels”) multiple times and have different interactions with characters based on what the player has learned.
My work around was similar to how SusanTheCat implemented her point and click example by using booleans to mark whether a room’s been visited already, or in my case to mark if it’s the player’s first time meeting a character. That way locations can be visited multiple times and the characters will behave differently based on a bunch of booleans.
With that said, here’s some potential problems:
Lots and lots of variables to keep track of
Labels getting messy with said multiple variables
It seems like an awfully inefficient workaround but if I want to stick with the Ren’py engine I guess it’ll have to do for now. We’ll see!