Hello and welcome to another installment of the Blightmare development blog! Today’s post is going to take a look at a recent iteration cycle that one of our mechanics went through to show how incremental improvements can be a useful tool for a small team.
Before we dive in, I want to make it clear that all the “art” you will see here today is placeholder. It is what many people call “programmer art” and does not represent what the final visuals will be. In addition, the names that I will use to refer to a mechanic are also not finalized in any way and often represent the first thing that came to mind by someone on the team.
One of the creatures that Blissa encounters on her journey is the PokePine. This little guy is one of the most powerful mechanics in the game because when you have one in your net, you can use it to hang from any wall that your net hits. Capturing a PokePine in the first place can be a bit risky, but the reward is well worth it. Here’s a short video of the first implementation of the PokePine in game:
There’s a short windup phase before the PokePine starts rolling at you with spikes out, but once you capture it, the spikes can be put to good use. The horizontal lines here are raycasts that look to see if there is something to attach to. When there’s a hit, the PokePine is moved to the hit point, and Blissa hangs there. This reused a lot of code that we already had, so the whole thing only took a couple of hours to put together.
This implementation made it into the game around October 2019, and it was like this until just a couple of weeks ago. In that time, the levels that use the PokePine were built and partially tested. In the video you can pretty easily see some of the rough edges in the implementation as a result of just bundling together what we had instead of making something specific to solve the problem. In particular: Blissa teleports to her hang point which is rather jarring; Blissa can’t hang on a surface that is horizontal, even if it looks like she should; and the attach detection is pretty far removed from where the PokePine in the net is visually. However, despite all these issues, the mechanic works well enough to get a level roughed in. This is important because it means that the designers aren’t blocked by programming. An absolutely critical part of working in a small team is allowing parallel work. This means that we have to keep a sharp eye out for dependencies between people and make sure we prioritize tasks in a way that prevents blockage.
Fast forward to a few weeks ago. In one of our weekly meetings, there was some discussion about how the PokePine didn’t feel as good to play as it should, and that prompted me to revisit it. This time around, I had some examples of how the mechanic was intended to be used to work with. In particular, climbing up a wall to a ledge was a pretty common thing to do, and that meant that attaching to a horizontal surface (the ledge) would be a big improvement to how things worked. I also wasn’t very happy with how static and woody Blissa felt while grabbing onto various pieces of terrain, she should be swinging around a bit after latching onto something. In addition to not feeling or looking great, it was possible to attach to the inside of the terrain which results in all manner of bad things – typically just falling infinitely or if you’re lucky, dying.
In order to get a natural attach behavior, I needed to use a systemic approach that would just settle based on gravity. Once that was in-place, the logic that decided if we should be attached to the wall or not would need to get a lot tighter, and with a little luck, things would be good. With that plan, I got to work.
I added simplistic angular velocity support into our physics object to provide the systemic support for falling while attached to a point. This integrated pretty nicely into the rest of the movement system and after adding some features for damping and breaking an attachment, this feature may be able to replace the more controlled swing arc in the dragonfly. There are reasons why we don’t want to do that as well, but I will save that for a later discussion.
The next thing on the list is making the attach point detection a lot better. The idea that I had is just to treat the caught PokePine as if it were a “live” physics object while it tracked the net and then if it ever had a collision that prevented the full movement request, we just use the normal collision resolution code to ensure that the attach point is valid. This worked for the most part, except when the net actually started entirely inside terrain. In this case, the PokePine would collide with the edge of the terrain as it leaves, resulting in an attachment inside the terrain. To address this, I make sure that the starting point of our movement test is not overlapping a collider that we are trying to avoid. In my tests, this solution performs well, but these literal edge cases are always difficult to track down completely. Here’s a video of what things look like now:
If you enjoyed this post or just want to support the game, please head over to Steam and add Blightmare to your wishlist and head over to Twitter to follow all the latest developments. Thanks for reading!