Context

This game was created in a team as part of the Godot Fire Jam 1. However, I (SelinaDev) have participated in this year's Devtober Challenge alongside it, and this here is my personal Post Mortem for both. However you got here, I hope you enjoy this devlog.

Gotm.io Jam #9

So, unless you follow my work closely you might be confused how yet a third thing fits in here, but at the end of September I joined the 9th GOTM.io Jam. That jam ran into the first week of October, while my team and I were just in the idea phase for what later would become Heart of Bark I continued work on my project for the GOTM.io Jam with the topic "Haunted". I had an idea for a little narrative game, and I misjudged the scope of my project big time. And that twice. First iteration was based on the GOAT (Godot Open Adventure Template) by Miscatonic Studio. That was coming along really nicely, until I realized how much I would have to create in terms of assets, just to make a small 3D apartment feel cluttered. So then I switched to hand drawn environments, which was then relatively feature complete. However, being inexperienced with writing a story for a game, and Ink, the language I used for that, I was quickly running out of time. I finished a little mockup, showing how the game would have played out, but nothing more than that, and I submitted not game yet again.

Here are two of my tweets showcasing these stages of the project.

https://twitter.com/SelinaDev/status/1442086064575877121

https://twitter.com/SelinaDev/status/1445099386535661572

Especially with GOTM Jams I feel like I often enter, rarely finish, but learn every time. This time was no exception, as including a narrative system into that project was great practice for my main project, where I want to do just such a thing.

Waybuilder

Which leads me to the second project I worked on this Devtober (which is still not the game this devlog is attached to). My main project, WayBuilder, is a card game I am developing since I did neither finish nor submit it as part of GOTM.io Jam #3 (you probably see the pattern here). I'm making good progress with it overall, but I slowed down development on it a bit during October. Getting a bit of distance to it was good for me. I did think a lot about it and what I want it to be, and I got a bit better overview of where I'm at with the game right now. I managed to get some coding in on it at the start of the month after I was done with the GOTM.io Jam, but when the Godot Fire Jam development hadn't picked up steam yet. But mostly I used the time to refine a bit what I want in the first prototype I'm going to give to playtesters. I created some lists and spreadsheeds, and implemented a few cards.

What I'm most proud of though is that I feel like I finally took the time to articulate what the game is and what it (hopefully) will be. And beyond that, that I also did that in video form, which I wanted to do for a long time, but was very anxious about.

If you're interested in what I came up with for that, or want to know more about WayBuilder, you can find my first devlog here:

Heart of Bark

Now we can finally move on to my main focus for this month: Heart of Bark. Initially I wasn't sure how much I wanted to actually participate in the Godot Fire Jam, so I offered to basically co-pilot for a less experienced programmer in their team search channel. I quickly got invited into a team.

For the idea finding we threw some ideas around. There were some ideas and interpretations of the theme that I have now seen in other games, which is always a fun experience. We then settled on a dungeon crawler where maybe the rooms would change, as to incorporate the theme "Everything Changes". While we all agreed on this in the beginning, I think how the idea evolved over time and how the implementation of things worked in engine made the final result be in a slightly different direction than we (or at least I) originally envisioned, but I am content with the result anyway.

While I first thought I might just provide support to another programmer, I quickly felt like I wanted to be useful to the team, so I started putting some time into the game soon. I started on the system for having rooms and switching between them, then how to integrate puzzles in to that. I contributed two of seven puzzles, which also delights me because it means I did not have to feel like I would completely overshadow my developer colleague. Beyond that tired to put a bit of framework around the game by providing the menus, scripted scenes, story triggers, and stuff like that, as well as some dialogue.

Wile I like our product and I think most of the collaboration went well overall, there were of course the things that didn't went well. These came down to the end of the Jam, at the very last day. Due to technical difficulties we only got all the sound files after I went to sleep on the last day (knowing that wen I would get up the jam would be over). My other teammates had already informed me that they didn't know how to get the audio into the game. I couldn't sleep, and at the same time my partner was getting sick and couldn't sleep either, so I got up at 2 am to integrate the audio files. This feeling of working so close to a deadline, especially while others depend on me, is really unpleasant for me, but I managed to get everything in and go to sleep again, feeling much more relaxed.

However, I did not have the time or energy to test the game, and was just hoping it worked, which of course meant I did not catch a few mistakes. No one really has seemed to notice so far, that when you start the game no music plays in the main menu, but the credits music will continue in the main menu when you complete the game. However, people did notice other audio bugs, which were down to another collaboration problem. Of course I also had to include audio triggers in my colleague's puzzles. I did that working off of assumptions of how I would solve a problem. You can notice it very clearly when picking up an item and carrying it. I would pick it up when the button is pressed down and toggle a state, toggling this state back when the button is released. However the pickup was implemented in a continuous way, meaning items basically get picked up again every single frame, which leads to my audio trigger starting the corresponding sound effect every single frame. My lesson from this is to read other people's code more carefully, not simply assuming that I know the one way everyone would use.

Other than these issues however I really liked working with my team. Everyone did their part and I am proud of our product. I enjoyed making it, and I hope you enjoyed playing it (if you haven't yet, just go to this game's main page).

Thank you for reading.