[Originally posted at http://gambit.mit.edu ]
Moki and Rooki are back! Moki Combat 2.0 features a brand new design built around a unique physics engine. It’s been a fascinating experience to take the original demo and gradually transform it to the current state. Moki Combat 1.0 was based around arena combat, but as we implemented the new physics we transitioned towards slower almost puzzle-like jousting, switched from arenas to linear levels, and eventually de-emphasized the combat itself. Hopefully I can shed some light on our process and the challenges we encountered along the way.
Crashing through blocks
More Than Just Ragdoll
The core feature of Moki Combat 2.0 is the physics engine developed by Computer Science graduate student Yeuhi Abe. You may be familiar with “Ragdoll Physics” which is frequently used to simulate falling or unconscious bodies. Instead of being stiffly posed, the limbs of the body move freely. Yeuhi’s engine experiments with active control of the character through physical means. This allows a body to support itself and move naturally when force is applied. In other words, rather than having an animation ready for when Moki gets hit by a spear, Moki will procedurally bend and try to right himself in the saddle.
Though it often results in impressively lifelike motions, this model is challenging for several reasons. First, control over the character has to be seriously rethought. Physically simulated characters are restricted to physically plausible motion. As a result, the character will not always respond immediately to user inputs. It’s not just a matter of triggering the “Swing Spear Animation.” You might notice some of the actions in the game feel a bit sluggish as result. We saw this physical lag as part of the challenge for the player, but some players will likely find it to be frustrating that the character doesn’t respond as they might expect.
In order to implement the new physics engine, the physics from the summer had to be pulled completely. Despite parts of the framework remaining, the programmers chose to scrap everything related to physics and basically start from the ground up. For the first few weeks of work on Moki Combat 2.0, there was little more than boxes and balls bouncing around. Yet the framework that resulted was much better than the original. Not being afraid to start over and develop a stronger foundation brought our more complex goals within reach.
The Design Evolution
It was around this time that I joined the team as a designer to better incorporate the new physics into the gameplay. The early prototypes combined the arena combat of Moki 1.0 with object manipulation puzzles. While play-testers enjoyed the look of the game, the actions were too imprecise for most of the object manipulation puzzles. The most consistently praised element was running through a block wall and watching the cubes fall down on top of Moki, pushing him around. I proposed a new jousting mechanic that would show off the natural movement of characters in the engine while adding more precise interactions.
Jousting an opponent
The zooming, slow-motion joust took many iterations to get right and persisted through all the designs that followed. Yet the challenges surrounding the joust changed a great deal. Given our lack of satisfaction with how the arena combat meshed with the physics, the next idea was to make the game a series of one on one jousting matches. The player would maneuver Moki into position and charge at the enemy. My original designs for the jousting developed into an almost puzzle-like challenge with the player having to observe how the enemy reacted to each blow in order to determine their weak spots. But as we began trying to implement this mechanic, certain challenges arose.
Size Matters Not. Usually.
During the Fall semester, our development team consisted of two programmers (Mark Sullivan III and Igor Kopylov), myself on design, Yeuhi as the product owner, and of course QA testers Jose Soto and Ruben Perez. When implementing new features, we quickly ran into the limitations of having such a small team. In particular, not having an artist meant that we had to make do with existing assets, only tweaking the models’ poses slightly. The puzzle-like jousting idea became an impossibility just given the shape and size of Moki and Chawi (the NPC enemy). As we came up with new ideas, we had to find ways to reuse assets in new ways. To create a circular track, a single hut was placed in the center of the arena level and enlarged to fill most of the space.
We lost a coder after Winter Break, but picked up a level designer and 3D artist in Randy O’Connor. Finally we could add new models and levels! His addition to the team came just in time for another major design overhaul. To better emphasize the excitement of jousting and to keep the player always moving, we decided to trade arena combat for gauntlet runs. Dashing through a narrow mountain pass, trying to hit as many targets as possible was an instantly exciting new mode. As soon as we had a minimal demo of this idea, we had our own tournament to see who could score the most points in 2 minutes. We knew we were on to something.
No time to stop and admire the scenery
Yet the limitations of our team size still created a hurdle. Not having the resources to develop our own level editor, Randy and Igor hijacked Maya. Rather than hardcoding all the collision geometry and objects, they created some tools to utilize specially named 3D objects in Maya that would export into the relevant information. A smooth pipeline was created for level design allowing complex levels to become feasible. A difficulty that arose was having to use primitive objects such as cubes, cylinders, and spheres to create free form terrain. Panda3D has limits on stacking material effects so we had to make certain decisions about having shadows, normal maps, or other effects. Despite the limitations, Randy made some great looking levels. A general theme of the development process was finding ways to overcome (or at least work around) our limitations.
As a demonstration of Yeuhi’s physics engine, and as a quick, fun, lighthearted experience, we feel that Moki Combat 2.0 certainly succeeded. Throughout the last semester we tossed around various ideas for further small games utilizing these physics controls. Some early prototypes are already underway. Don’t expect Moki Combat 2.0 to be the last you’ve seen of this engine.