Balam Postmortem

Balam has unfortunately been canceled, and with its (and my) termination, I am unable to place pictures or videos to describe what I'm about to get into, as I no longer have access to the source. This text exists to explain my process to the project, and how I approached it. Consider this a postmortem of sorts, and a broader explanation of my design work inside the game and my approach to the problems I encountered in it.

Balam was, at its core, designed to be in the same vein as Hollow Knight, with a primary pivot towards the exploration of Mayan mythology. I was specifically tasked to design the AI, and my first course of order was to look at the budget we had to work under, and then the code base to see what we could make in a reasonable amount of time, and those were the two primary conditions I worked under: what I could do with what we had, and what we could do under a quick turnaround.

So I looked at Mega Man.

In my experience, there is a sliding scale of AI design for 2D platformers. They don’t exist exclusively in isolation, and sliding around between the two points can create some variety, but they’re an easy way to describe my thoughts. On one end, you have Castlevania: Symphony of the Night, where the level geometry was almost completely flat and wide open, so that the enemies themselves were exclusively the challenge involved, and complex behaviors were needed to make that meaningful. On the other end, you have Mega Man, where the AI is designed to have explicitly simple behaviors, and they function as an extension of the level design - the physical geometry of the level would determine exactly the challenge they would present to the player, and changing that geometry meant variable challenge potential with minimal new code. Their simplicity also leant towards quick traversal, as they could be understood and read at a glance, and in a game where backtracking was prevalent, this enabled quick transit. Between the two styles of AI, especially with the budget constraints, I found the Mega man approach to be the right direction for the job. We would later start edging further into more complex behaviors, but this was otherwise my approach.

Next up was the AI behaviors themselves. In 2D design, the most important consideration in my experience is how they interact and exist in the space around them. How far they move, how fast they move, how physically big their colliders are, whether or not they’re static parts of the geometry, whether or not they have a projectile, whether or not their actions are meant to read well or surprise the player, and so on. All the AI I developed was built by playing around with these collection of parts, so each enemy could be functionally unique and utilized by the level design in multiple ways.

The demo was made to be played at a convention, which was also a factor. I intentionally made the AI a bit easy so that a general passerby could quickly play through the game in one sitting, in around seven to ten minutes, so that they could complete it and get a good feel for what the experience was intended to be.

My work on the character controller was more straightforward. Through constant playtesting and refining, I took the existing character controller, made it more responsive, adjusted the attack speeds, trajectory, attack colliders, and so on to feel better to control. After that was established, I began designing AI behaviors around the player controller and its constraints.

The Grind

The Grind was, at its core, as cooperative as it was competitive, and everything had to be designed to fit that theme. Items could just as easily be used to help the player and his friends as they could be to inhibit or disrupt them. Since time was an issue, everything I designed for the Grind was done with the mindset of trying to get the least amount of overlapping function possible, to maximize the usefulness of each asset we had to create.

Enemies

All enemies were designed knowing that we would only be able to get so many models and animations done by the deadline. As such, each enemy was developed at extremes, so that each one had a specific role that could be utilized by the level designers to vary the gameplay.

Some of the enemies are fairly straightforward - the imps simply run at players and attack them. The Juggernaut is similar, but his attack hurts players in a radius and knocks them backwards.

Other enemies, such as the Wisps and the Hoppers, are more complex.

The Hopper enemy was designed to give a bit more of a challenge to the player by only letting the player attack them during specific windows - if the player got too close, the enemy would hop off screen. The player had to wait until the Hopper moved to attack the player on their own before the player could retaliate.

(Unfortunately, due to time constraints, the animations are somewhat glitchy, which can make the enemy read off. The animations for the game were not my department, and were done under a serious time crunch of about a month or two.)

The Wisps were the other outlier. They were simple balls of energy that moved towards players in range and were detonated in powerful explosions when they touch a player or are attacked. Players would often kite them into groups of other enemies - or each other - and detonate them from a safe distance using the bow.

Weapons

Each of the four initial weapons were designed to fit specific roles, and allow differing styles of play. The hammer, for example, was intended to be a brutal close-quarters weapon that would knock enemies away from the player, and in the case of lighter enemies such as the Imp, potentially off of the platforms entirely. The bow was the standard go-to weapon for attacking from a distance, keeping the player out of harm's reach. The sword was for straight-up damaging your enemies, and had the potential to deal ludicrous amounts of damage, at the risk of putting the player in harm's way from the shorter reach. The shield went through numerous revisions, and ultimately settled into a mid-ranged weapon with a boomerang effect with a dashing move to bash enemies into the air should they get too close.

Items

Every item I developed was done so with one thing in mind: everything must be as useful to use against other players as it was against enemies. The Portal item, for example, was useful for swapping positions with a remote enemy for getting a player out of the way of danger, but saw a lot of emergent gameplay where one player would jump off a ledge and would swap places with another player who would immediately fall to their doom. The Mind Control item had similar dual use - it was just as easy to take over an enemy and have them attack other players as it was to control those players directly and walk them off ledges. Bombs were just as lethal to players as they were monsters, and created situations where players were frantically kicking them between each other trying to blow up the other first. Even the healing item's aura would heal monsters in addition to other players.