When I started this dev blog thing I intended to keep it regularly scheduled. But I have to balance my energy to make the actual game, and doing that has captured my interest more than writing about doing it. I’m not sure at this point anyone is actually interested in these, but here are some random thoughts and updates.
1. This is my first game that’s bigger than a few screens. I am learning so much as I go, and I keep wanting to re-do things as I learn better techniques. I’m trying to find the right balance of letting something go if it works, and doing better next time, while also identifying what changes really need to be made in the moment. How do other devs stop themselves from getting into an endless cycle of iterating?
2. Because of that behavior, the project got so cluttered with my failed attempts. I created an entirely new project where final and close to final code goes, and the original project file is now basically a wacky debug land.
3. I have settled on a movement system. I mentioned in my last post that I started the game with smooth movement, but had issues rounding corners and getting trapped on the collision. I eventually chose to have the game run on a grid based system. This makes several of the systems easier to manage across the entire game. My dream was to have smooth movement, while always ending with the player on the grid. I tried several versions but just don’t have the skill yet. But if I spent too much time I would never finish the actual game. I originally didn’t like the way the grid movement looked, but that was because of how I had the animation setup, and some recent improvements have made the animations much better.
4. I learned a few techniques I’m especially happy with.
In the original prototype I was instancing each explosive potion in real time, causing a huge amount of slow-down. I learned about object pooling, and now have a dictionary of bomb nodes pre-loaded into a pool node, which is part of every level. Since each room in game is a set size, all bombs are secretly just hanging out right outside the level, and then get positioned, run, then reset when used.
I needed to solve a problem with moving from room to room in game. Some rooms have multiple doors that lead to other rooms. Each door has an entrance and exit variable, an integer. When a door is touched it sends it exit variable to a global scope scene manager, as well as the room name and number. The scene manager loads the next scene, and the level scene matches the exit door variable to an entrance door.
I’ve also further explored the power of export variables and have built some enums right into some nodes that change aspects of the node upon initialization. Some examples are changing the type of breakable wall sprite to match a level, setting a doors entrance, exit, and behavior type, and deciding if the door animation should play when a level is loaded.
5. I have started to explore add-ons for Godot Engine. I only have one so far. TODO manager, which let’s you add comments that show up in a color coded to do list. It’s really convenient to keep track of things, and I’ve added several custom comment types to keep track of ideas, important warnings, and general problems I need to solve. I am going to avoid add-ons for actual game logic, which I think would get in the way of learning those skills.
6. Designing around a ZX Spectrum aesthetic has been very challenging. It has grown my design skills, because you have to figure out how to represent something with just two colors. With certain sprites though, I just desperately wish I could have one more color. Like the NES had 3 color sprites and it makes a huge difference in readability. It’s so frustrating but also feels great when I finally have something that works.
One example that got me recently was realizing that the potion sprite I had made would not actually work in the game unless I changed a whole section of the screen to match the potion color, as it was a two color sprite on a black background. Now I have a single color sprite, which doesn’t look as dynamic, but this is the reality of the aesthetic.
That said, I have many problems to solve once more objects are interacting on screen. I want to faithfully recreate the attribute clash (here’s a great article about that), and have a few theories on how I can to that. That will come later though, when the actual game logic is working completely.
7. Game logic can be very weird sometimes. Because of the way I’ve learned to use signals, I have a bomb that tells a wall when to explode, and a door that tells the player where to position itself. Perhaps someone more experienced knows if this is normal or if I’m doing things in a bad way.
So those are some things. I have some more challenging coding tasks coming up, that I’m sure I’ll be able to figure out eventually. At this rate I have a feeling my hope of having a demo out by the end of January is unlikely. I can be bad at estimating how long something takes, and I think at this point it’s realistic to say January isn’t happening. But maybe I’ll surprise me.
Anyway, thank you for reading and have a nice day
- Mia Malaise