Monster King! Development History

  • Role: Product Manger (credited), Game Designer (in practice).  Worked on concept, high-level mechanics, level design, monster design / stats, attack design / stats, writing, sound, balance.
  • 4-month development
  • Completed April 2010

Monster King! was pitched as a concept reversal of the typical RPG role – you play as the boss monster in a dungeon, only killing what you must to survive, contrasted with the typical RPG hero, who comes in and kills everything for no apparent reason. It was intended as a sly critique of the lack of context or sense in most action scenes in games.

We quickly sketched out other concepts to support this idea. Taking a page from EVO, an SNES-era RPG about evolving an animal by eating other monsters, we decided Monster King! would have multiple powers that you would gain through eating other monsters. We wanted to cast the player monster as a predator, killing out of necessity and in a natural way, not ruthlessly and wastefully. To put pressure on the player and emphasize the player’s role as a predator, we decided there would be a hunger meter that drained steadily; it would allow us to create scenes of desperation and block off areas by leaving them empty of food sources. In order to mechanically express the idea that the players were not senseless killing machines but instead rational predators, we imagined a ‘morality’ system, Aggresion. Every time a player killed a monster they would be assumed to eat it. If the player was already full, and they killed a monster, they would instead let the meat rot. This would raise their aggressiveness. We planned on combining this with AI behaviors that would allow for similar monsters to ‘pack up’ with the player and follow them, if the player wasn’t aggressive, or fear that would cause monsters to flee from an aggressive player. The player would have only a few evolutions, determined by the overall diet the player had eaten over a level. Two branching points would lead the player into one of 9 final forms. This would have necessitated 7 seperate levels to support abilities such as swimming, climbing, and flying.

We still felt that the design was not necessarily compelling. Our concepts were interesting but they were lacking a fundamental hook; the battle system was always left in the dark as “similar to a rogue-like”. In addition, it was far beyond the scope of what we would be able to accomplish in the few short months we had available.

So we presented our concept at a Game Design Club meeting, and with the help of students and a motivated teacher, honed our concept into a tight, focused idea: round based gameplay, with a Hero appearing every round to serve as a ‘boss’ fight. Powers would be gained from every enemy, and the hunger would serve as a time limit of sorts – the player would only be able to eat X monsters, so they would have to strategize a path through the neutral monsters to be as effective as possible. This was a much simpler development path, and mechanically quite interesting. We began work in earnest.

When development came to actually building levels, we realized that having a single large level would be better than the multiple levels we had planned. Because all of our pieces would move in fixed ways on the board, we wanted our levels to be challenging and repeatable, with players able to try different strategies on a similar map. At this point we planned for the Hero to move through the level exterminating all remaining neutral monsters – this would also provide a strategy for the player to leave behind certain monsters to fight the Hero. But we anticipated having to reduce the complexity of the Hero’s AI pathfinding, and needed a system that would work even if the Hero couldn’t seek out neutral monsters. And implementing all the levels together, in one large level, would allow a crafty player to retreat and cover old ground if they chose.

Monster King!, in its new form, would have a multitude of player abilities. We wanted to give the player the feeling that they had a keyboard full of cool things, and wanted to capture one of the best traits of rogue-likes, the multitude of attack effects. But in order to limit our coding requirements, we at first implemented 16 attacks, 4 each being of the elements Normal, Water, Fire, or Plant. The elements had a rock-paper-scissors mechanic tying them together. This proved very boring in practice; without other mechanics to interface with, selecting the proper element to get extra damage is such a trivial mechanic it might as well not matter.

So we added properties to the attacks. Fire attacks would do area-of-effect damage, water attacks would push enemies back so they would lose turns returning to attack range, and plant attacks would stun enemies for a number of turns. Implementing this immediately gave a player a reason to use attacks of different elements even when they were not optimal and combat was suddenly more strategic and fun. But we still found that the higher-level powers were rendering the low-level powers obsolete. In such a situation we might as well have replaced the earlier powers. But we added cooldown on attacks, and balanced it so that the more powerful abilities had longer cooldowns. This made all powers useful in combat, exactly what we were hoping for. A player would now tend to open a fight with a powerful attack and then switch to less-optimal crowd-control abilities while waiting for their higher power to recharge. It is similar in some respects to a game like World of Warcraft, but with the tighter math of a turn-based game.

As development wrapped up (or rather, screamed toward the rapidly-approaching due date), we wrestled with whether to cut or keep level 4. It was designed to be more open to support experimentation with the area-of-effect and crowd-control abilities the player would by that point have. Level 5 was to be a series of small rooms connected by teleporters. The game’s artificial intelligence, however, starts to break down in larger areas like level 4. We were set to cut it because the enemies were not behaving as expected. However, players seemed to enjoy it, even though the monsters did not attack together as played. It was an object lesson in listening to player feedback above design concerns: players enjoyed the feeling of power they got from a break in the difficulty.

Learning this, we ended up keeping level 4 and in fact cutting level 5. Instead, level 5 is an arena combat that builds off of level 4 to provide the ultimate test of all the abilities the player has up to that point. In fact, there are so many enemies that movement becomes almost impossible, and the player’s only action is managing their attack powers and cooldowns. I’m happy that the game seems to hold up even in these circumstances.

Monster King! ended up almost exactly where we planned after the first major revision. Being open to changing things up gave us a strong plan. Development after that point involved following our roadmap and filling in gaps when they appeared. It was an iterative process that naturally built into the product we had planned.

ter King! was pitched as a concept reversal of the typical RPG role – you play as the boss monster in a dungeon, only killing what you must to survive, contrasted with the typical RPG hero, who comes in and kills everything for no apparent reason. It was intended as a sly critique of the lack of context or sense in most action scenes in games.

We quickly sketched out other concepts to support this idea. Taking a page from EVO, an SNES-era RPG about evolving an animal by eating other monsters, we decided Monster King! would have multiple powers that you would gain through eating other monsters. We wanted to cast the player monster as a predator, killing out of necessity and in a natural way, not ruthlessly and wastefully. To put pressure on the player and emphasize the player’s role as a predator, we decided there would be a hunger meter that drained steadily; it would allow us to create scenes of desperation and block off areas by leaving them empty of food sources. In order to mechanically express the idea that the players were not senseless killing machines but instead rational predators, we imagined a ‘morality’ system, Aggresion. Every time a player killed a monster they would be assumed to eat it. If the player was already full, and they killed a monster, they would instead let the meat rot. This would raise their aggressiveness. We planned on combining this with AI behaviors that would allow for similar monsters to ‘pack up’ with the player and follow them, if the player wasn’t aggressive, or fear that would cause monsters to flee from an aggressive player. The player would have only a few evolutions, determined by the overall diet the player had eaten over a level. Two branching points would lead the player into one of 9 final forms. This would have necessitated 7 seperate levels to support abilities such as swimming, climbing, and flying.

We still felt that the design was not necessarily compelling. Our concepts were interesting but they were lacking a fundamental hook; the battle system was always left in the dark as “similar to a rogue-like”. In addition, it was far beyond the scope of what we would be able to accomplish in the few short months we had available.

So we presented our concept at a Game Design Club meeting, and with the help of students and a motivated teacher, honed our concept into a tight, focused idea: round based gameplay, with a Hero appearing every round to serve as a ‘boss’ fight. Powers would be gained from every enemy, and the hunger would serve as a time limit of sorts – the player would only be able to eat X monsters, so they would have to strategize a path through the neutral monsters to be as effective as possible. This was a much simpler development path, and mechanically quite interesting. We began work in earnest.

When development came to actually building levels, we realized that having a single large level would be better than the multiple levels we had planned. Because all of our pieces would move in fixed ways on the board, we wanted our levels to be challenging and repeatable, with players able to try different strategies on a similar map. At this point we planned for the Hero to move through the level exterminating all remaining neutral monsters – this would also provide a strategy for the player to leave behind certain monsters to fight the Hero. But we anticipated having to reduce the complexity of the Hero’s AI pathfinding, and needed a system that would work even if the Hero couldn’t seek out neutral monsters. And implementing all the levels together, in one large level, would allow a crafty player to retreat and cover old ground if they chose.

Monster King!, in its new form, would have a multitude of player abilities. We wanted to give the player the feeling that they had a keyboard full of cool things, and wanted to capture one of the best traits of rogue-likes, the multitude of attack effects. But in order to limit our coding requirements, we at first implemented 16 attacks, 4 each being of the elements Normal, Water, Fire, or Plant. The elements had a rock-paper-scissors mechanic tying them together. This proved very boring in practice; without other mechanics to interface with, selecting the proper element to get extra damage is such a trivial mechanic it might as well not matter.

So we added properties to the attacks. Fire attacks would do area-of-effect damage, water attacks would push enemies back so they would lose turns returning to attack range, and plant attacks would stun enemies for a number of turns. Implementing this immediately gave a player a reason to use attacks of different elements even when they were not optimal and combat was suddenly more strategic and fun. But we still found that the higher-level powers were rendering the low-level powers obsolete. In such a situation we might as well have replaced the earlier powers. But we added cooldown on attacks, and balanced it so that the more powerful abilities had longer cooldowns. This made all powers useful in combat, exactly what we were hoping for. A player would now tend to open a fight with a powerful attack and then switch to less-optimal crowd-control abilities while waiting for their higher power to recharge. It is similar in some respects to a game like World of Warcraft, but with the tighter math of a turn-based game.

As development wrapped up (or rather, screamed toward the rapidly-approaching due date), we wrestled with whether to cut or keep level 4. It was designed to be more open to support experimentation with the area-of-effect and crowd-control abilities the player would by that point have. Level 5 was to be a series of small rooms connected by teleporters. The game’s artificial intelligence, however, starts to break down in larger areas like level 4. We were set to cut it because the enemies were not behaving as expected. However, players seemed to enjoy it, even though the monsters did not attack together as played. It was an object lesson in listening to player feedback above design concerns: players enjoyed the feeling of power they got from a break in the difficulty.

Learning this, we ended up keeping level 4 and in fact cutting level 5. Instead, level 5 is an arena combat that builds off of level 4 to provide the ultimate test of all the abilities the player has up to that point. In fact, there are so many enemies that movement becomes almost impossible, and the player’s only action is managing their attack powers and cooldowns. I’m happy that the game seems to hold up even in these circumstances.

Monster King! ended up almost exactly where we planned after the first major revision. Being open to changing things up gave us a strong plan. Development after that point involved following our roadmap and filling in gaps when they appeared. It was an iterative process that naturally built into the product we had planned.