January: "Hey, Can We Talk?" (Game a Month)

Last year had me feeling physically and mentally unproductive. Starting college is extremely time consuming, but I’ve decided that it’s time to return to game development to see if I can balance the two. I miss the game jam experience, and believe that returning can make me feel productive once again and keep me sane through my monotonous schoolwork. So, my New Year’s resolution: create one game a month, and document the process. Hey, Can We Talk? is the game I made for January.

This postmortem does not contain spoilers, but it may make sense to check out the game first.

Idea

Admittedly, I had a late start, since I had not fully conceptualized this jam idea until late in the month. The project officially began on the 21st, but this game was not started until the 24th. Prior to this, I had the idea to create a tower defense game. The quick synapsis: combine top-down tower defense with the looter-shooter genre (I recently picked up the Borderlands franchise and was heavily inspired), in which zombies dropped procedurally-generated guns that could be equipped by survivors. This idea had several gameplay problems, mainly the lack of gameplay overall. I had unknowingly stripped every element of skill from the typical shooter game, essentially creating a casino wherein the enemies were slots and success depended on whether or not it would spin a legendary gun. I was having several non-gameplay related problems, too. For instance, I was struggling with the Pico-8 color palette; since most of the palette colors are bright, I felt limited and ineffective in establishing the right apocalyptic tone for my game. The color limitation left my game feeling very monotone (see level image below), which is not what I wanted. After much thought, I dropped the project.

Philosophy

I knew that I wanted the game to take place outside, as 8-bit nature assets are relatively easy to create and can be flipped or rotated for variation. As this theme emerged from my project, I decided to create a “puzzle philosophy” to go along with it. Simply put, I wanted to create puzzles that had a constant forward direction; no action could be undone (an idea I thought related to nature). Something you do now could prevent you from collecting a gold signal in the future, which in turn would require you to replay the entire loop. This was not intentional from the start. Instead, I thought that the gold signals would simply provide bonus content - they were not even on every level. However, seeing that I could add more substance to the game, I added them and gave the player a reason to replay levels. I felt that this also justified not having many levels in the game. Furthermore, these golden signals break the rule of the normal checkpoints in the sense that the path towards them can be broken at any point. In other words, while no move can prevent a normal signal from being accessed (I needed to prevent soft-locks since there is no undo button), a wrong move can easily prevent the player from reaching a gold signal. As such, the player is encouraged to figure out the route before attempting the puzzle, rather than brute forcing. With this in mind, how do the puzzle elements support this idea?

Pieces

Water was the first puzzle piece to be implemented. I wanted to introduce the looping mechanic by dividing the level into two parts and forcing the player to discover that they could loop to the other side. A river running through a level was the first idea that came to mind. Rocks came next, as they could interact with the water and give it a changeable state (traversable and non-traversable). The difficulty with rocks is that if placed incorrectly, inherently go against the puzzle philosophy. For example, if there is only one desirable spot for the rock but the player chooses to put it elsewhere, they would need to restart. As such, a lot of thought had to go into their placement. I added fences, which only had a non-traversable state, to help me with this. Fences always stop rocks from being moved into locations that would soft-lock the level. The final piece to the puzzle was lily pads. Lily pads accomplish two things: preventing rock movement into water, and making water temporarily traversable. These were tricky to use in puzzles, since they had the same problem rocks did. Through puzzle design, I had to ensure that a lily pad could never get locked in an undesirable/unreachable spot. Most time dedicated to this project was spent on designing, but even a few alternate solutions or soft-locks may have snuck through.

Thoughts

Speaking of time, I missed my January 31st deadline by a week. At the end of the month, the game still needed a lot of polish and packaging. In fact, the gold signals, story, ending, and even the bees were all made in February. I technically failed at what I set out to do. Still, I am content with the outcome and ideas I was able to incorporate into the published game. Of course, I would have liked to do more, but with the time I had and the direction the project went, I do see it as a full, completed game - albeit short. The ending may feel lackluster, but I’m not sure yet. When reflecting on this challenge, I can say that it was nice to be mostly free from scope creep. This was also my first time creating a game with multiple screens, so I definitely learned a lot about Godot and the general process. I hope to use what I’ve learned about game-dev (and myself) going into February. If you're interested, feel free to follow or subscribe to my YouTube channel [opens in a new tab]. Thank you for reading, and I hope to hear your thoughts on this project!