Path of the Rainbringer


Release Journal

This was a lot of fun!

For starters, I have watched dozens of Godot Wild Jams go by and I have always liked the structure and timing. This has been on my to-do list for a while. Life is busy these days and I am usually unable to meaningfully dedicate much time to jams, especially not the big 48-hour engagements like Ludum Dare or GMTK. But this time around, the stars aligned and my personal schedule was wide open. I am very grateful for how it all worked out.

I decided early on that I wanted to make a platformer based on Jump King with a few key differences, but primarily concerning the world design. Rather than the play space being an entirely vertical shaft where the player can lose minutes or even hours of progress with a few poor decisions, I wanted my game world to be fundamentally horizontal with distinct vertical sections. This way, I can capture some of that feeling of challenge and risk that Jump King has but without really punishing the player all that hard.

The reason for this is because, based on my experience and the experiences of others, it can be difficult to get players to actually finish playing jam games. Little difficulty spikes paired with the rough around the edges vibe of a game pulled together in a week will lose them nearly every time. My response is an attempt to amend an engaging but minimalist gameplay loop by mitigating the threat of massive progress losses for the player while preserving some fundamental challenge of the experience. My hope is that it can hold the attention of someone with no financial or personal stake in it while still being a rewarding experience.

I chose the "textless" wildcard for this project. In some ways, this limitation was actually just a massive time save. I extrapolated a lack of text out to mean an entire lack of UI elements as well, which is always a pain point for me. Godot is great for UI, but I am not. However, I think the final project is sort of under-served by a lack of text. I am not a good enough artist to express a post-apocalyptic old world setting beset by heavy rainfall in purely visual terms and I am sure the majority of my vision for the game's setting is just not coming through. I also had lots of ideas for silly little NPC guys that would have been fairly pointless without dialogue. All the same, I am glad I decided to tackle it this way.

I came up with the title a few hours before releasing the game. Usually I have this figured out way sooner, but I think the whole textless thing put this out of my mind. It's a little generic, but not as bad as "Shrine of the Rainbringer" would have ended up being in relation to what I am sure many of the other submitted projects are going to be called.

Favorite Development Point

My favorite part of making this game came in day 6. I noticed a consistent but unexplainable stutter in the world camera when the Player would move between specific rooms. With how smooth it normally is, this stuck out very badly. I spent hours timing functions, monitoring scene count and memory usage, and commenting out huge chunks of code to isolate this thing. I am not a software engineer by training, so this is not my strongest point. However, I did eventually notice the stutter going away in one specific instance after I had commented out a single line of code, and even then it only went away after the first room transition. This was an excellent clue, though. 

Eventually, I figured out that the stutter happened sometimes when the Player entered a room adjacent to a different room that had trees in it. That was the first piece of the solution.

Some background: my games usually implement a module I have been working on for a while that allows me to create the game world in one large scene but load in the fewest number of individual rooms possible at runtime based on the player's location to improve performance specifically in web exports. I use coroutines to (hypothetically) mitigate visual performance impacts of loading in rooms with many or expensive objects in them (the camera will not scroll until the new rooms are ready), so I was sure this issue couldn't be a CPU/Node-based problem.

So what's the deal with the trees? Well they use a shader material to give them a little wind sway effect that is based on some generated noise. It's not an expensive process on its own, but basically I had configured this material to be unique per-tree and to also generate its own unique noise texture (it made the trees not look like they were all synced up with one another, more visually interesting). I guess a Node's ready signal is agnostic to properties of any materials applied to the node or its children (makes sense in hindsight), so my camera scroll would stutter when these trees were added to the SceneTree because the GPU compiles the shaders out of sync with anything coroutines can look for. So what do I do?

I remembered a story I saw an industry dev sharing on Twitter a while back when their team encountered shader-related performance problems. Basically, they forced their engine to cache every shader in the game by instancing an individual object for every shader material the game used behind a black screen that showed for a split second when the game started up. It looked just like part of the loading process to the players, but was actually a very hacky and silly fix from the dev's perspective. I wish I could credit the person here, but I cannot remember who they are. Shout out to them. 

So I based my solution on that story. I started by removing all the per-scene unique stuff in the tree wind shaders, which got rid of the diverse, unique movements that I thought looked very cool but would make storing those materials in memory very difficult. Once I had every tree using the same shader material, I added a CanvasLayer as a child of my root Game scene. To this CanvasLayer, I added a little white square in the bottom corner of the screen. To this little white square, I added the same shader material that the trees used. Then, I made the CanvasLayer invisible.

... and that fixed it. The shader is now always in memory, the stutter is gone, and all it cost me was like 3 hours and a little invisible wiggly square.

Moving Forward

I will do more jams. If all goes well, I will start another one in a couple of weeks. Hopefully I can finish it, but that may not happen due to some life events. We will see though. What I can say for sure is that I won't be making another platformer any time soon.

Leave a comment

Log in with itch.io to leave a comment.