Mario vs. Donkey Kong
- Mario vs. Donkey Kong is a 2d action/puzzle platformer for Game Boy Advance.
- This million seller was the first entry in a new Nintendo franchise, which has gone on to sell several million units.
- Developed and tuned player control, player state management, world objects, enemy AI, and world building tools.
Player controls and state machine
I programmed and tuned Mario’s controls , behaviors, world interactions, and state machine flow. Much of this work was done in a combination of C code and a proprietary state machine editing tool that allowed me to specify collision boxes, input frames, flags, and conditions for transitions to new states.
- Much of the state machine editing tool was developed by the lead engineer, but when I needed new states or conditions to improve controls, I would often add those states and conditions myself via code.
- Mario’s move set was specified by the game director and franchise expectations and my role was tightening the response of movement, chaining player actions, connecting animations together smoothly, and tuning jump curves and movement graphs for Mario.
- In order to define each of Mario’s 300 states, I set input windows, tuned velocity per frame, set several state flags, and defined the conditions that caused state transitions.
- I worked very closely with the game director and animators to determine optimal solutions for delivering a high quality player experience.
Designing Mario's Moves and Controls
From left to right: A basic run, a basic jump, landing, a mid-run skid, turning around, a backflip that transitions into a run, a ducking crouch, and a handstand.
- For each of these states, and many times for each individual frame, I specified how the state would change based on different input combinations, how long buttons needed to be held, collision parameters, state flags, condition transitions and their priorities, velocity, and a movement vector.
- The input needed to be highly responsive and flexible at the same time.
- For example, from a standing position, the player could potentially press A to jump in place, down to duck, left to walk, right to turn around, or up to look above.
- From a standing jump, the player could press left or right to move in that direction, then immediately press the opposite direction to cancel the jump and enter into a different state.
- While in the process of ducking, the player could quickly press A to enter into a handstand jump, during which the player could also press left or right to specify a movement direction.
- In addition, because the character had discrete animation frames in a 2d world, it was critical to make sure that the animations transitioned smoothly between the various states because there was no way to blend animations. This was an area where I worked closely with each animator to iterate on different animation sets and input combinations that produced the most responsive and aesthetically pleasing movement.
- Coded and maintained state machines for over 20 different enemies.
- These enemies included a combination of original designs and traditional Mario franchise characters.
- Enemy AI was created via a combination of code and a proprietary state machine tool.
- I set movement patterns, movement speed, collision boxes, behaviors, and properties such as which sides the enemy was dangerous from, whether it could be picked up, etc.
Examples of several enemies from Mario vs. Donkey Kong. From left to right:
- Sleeping Shyguys: sleep when idle, then wake up and charge when you land on platforms they sleep on.
- Monkiki: This enemy walks back and forth on platforms and its tail can be used like a rope. When combined with colored switches that activate/deactivate parts of geometry, this enemy can be directed to different sections of the level so Mario can cross pits or reach places that are normally inaccessible. This enemy sparked the idea for the level I created (detailed under the level design section).
- Pirahna plants: These plants regularly spit seeds that can be ducked or jump over by Mario. They are primarily used in jungle levels where Mario has to navigate ropes while Pirahna plants on both sides take aim at him.
- Thwomp: Thwomp is dangerous on all sides and cycles between idle, warn/angry, and stomping up and down. Depending on how close Mario gets to this enemy, it adjusts its behavior accordingly. These enemies became an interesting puzzle element when combined with the colored switches which allowed the player to trap them underneath platforms or keep them from being able to stomp directly on the player.
- Fireballs: Some walk around platforms and ladders while others act as moving barriers that Mario must run underneath or jump over. They are lethal and light Mario on fire when touched.
- Shyguy: One of the most basic and versatile enemies, Shyguys are safe to stand on but dangerous if Mario runs into one. They walk back and forth along platforms and can also be picked up by Mario. Once picked up, they can be used to cross pits of spikes or to thrown at other enemies to eliminate them.
- Boo: Dangerous on all sides. Boo is a coward who only chases Mario when he is looking away. He can pass through geometry and speeds up depending on how long Mario has been looking away.
- Charging Knight: When the knight sees Mario, it will dash in his direction. If Mario is pressed up against a wall, he will be squished and killed. This enemy is useful for getting pushed under long narrow sections where no conveyer belt is present, or to reach heights that are above what Mario could normally jump to.
I developed and tuned game objects such as ladders, ropes and springs.
- I made sure that these objects were fun to use and that Mario could transition between them in a smooth way.
- I defined the collision parameters, the input mechanics that allowed Mario to interact with them, and the associated states that they caused Mario to go into.
- Once the player grabs the wire they can shimmy left and right, cancel their grab, or begin spinning.
- There are 9 levels of spin and a different jump for each of those 9 levels.
- If the player holds down the up button on the DPad, they will increase speed and move through each level of spin in order.
- If the player holds down the up button and suddenly stops, they progressively revert to slower spins in the cycle.
- The player can bounce low or launch themselves high in the air on this object.
- This particular sequence of moves went through a lot of tuning.
- The difficulty in tuning it was getting the initial impulse to feel solid and balancing the proper input window that matched with the bounce trajectory and animation.
One and Two-Handed Ropes
- This world object is meant to evoke the spirit of the original Donkey Kong games, with a more modern and fluid input scheme.
- Players can climb up, slide down, drop off, grab left, grab right, jump, grab two ropes at the same time, and climb and descend on two ropes.
- A lot of my work on these objects involved tuning the collision boxes for when different grabs began as well as getting the transitions to feel fluid.
- For example, if you hold left or right across a string of ropes, Mario quickly lets go of one rope and moves into position on the next one.
- For this object, tuning was focused on defining solid collision boxes for enter and exit states that allowed the player to jump or cancel at appropriate times without penalizing them for waiting as enemies above them pass by.
During development of the game, it was necessary to test Mario’s move set constantly in different environments. Mario had over 300 states and setting jump parameters incorrectly could easily break many puzzles. I created test maps throughout the development process to verify that the move set behaved in a consistent way across different puzzle configurations. In addition, the company had an open call for level submissions and I created several levels for consideration in the shipping game. One of the levels I created was used and modified slightly for final release.
Double Monkiki Puzzle Drop Level
- The premise behind this level is to use the Monkikis as a portable rope to cross a long pit of spikes in the lower right quadrant of the map.
- In order to do this, the player must make use of several color switches which turn world geometry on and off, and allow the Monkikis to walk across the map and fall down.
- My initial concept featured a single Monkiki that you had to lead via the switches to the position you needed him.
- The colored blocks in the picture represent pieces of geometry that can be turned on and off depending on which switch you have active in the level.
- In this picture, the yellow switch is currently active. If the player hit the red switch, then the Monkiki Mario is hanging onto in the picture would drop, allowing the player to have a portable rope in a different part of the level.
- A second Monkiki was added for pacing reasons since they walk relatively slow (which was necessary to allow players to easily grab their tail).
Tile editor and state machine tools
In order to improve level layout and player control, I contributed to the design and development of 2 of our game creation tools.
- The first tool I worked on was the tile editor, which allowed artists to create multi-layered animating 2d environments.
- I added a number of features to improve their work flow including numerous ways to sort and organize tile groups, as well as undo, redo, copy, paste, block copy, stamp, and template creation features.
- The other tool that I contributed to was our state machine editing tool.
- This tool was my primary connection to Mario’s behavior and the lead engineer created the bulk of functionality for it.
- I often found that I needed a way to add new states, conditions, or shortcuts and when those issues came up, I would add code on both the engine and tool side to enhance the functionality of this tool.
All images (c)Nintendo