A Nostalgic Design for Fun: Mario Kart 64
As kids who grew up in the 90s, we all have a special place for Nintendo games in our heart, we grew up alongside graphic development, and feel a strong tie to these games. So, when it came time to develop a game for fun, using Leap Motion, Mario Kart 64 was simply a no-brainer. We felt there was no better way to engage our target audience — other students our age — than bring them back to a childhood favorite, and allow them to be one step closer to the game by using real lifelike motions to play the game.
Choosing A Game
We wanted to reimagine the controls for an older game for multiple reasons. We figured it would be easier to control an older game that was on the Nintendo 64 or SNES because of the lack of complex controls. Video games were relatively new and thus the users hadn’t grown up playing video games so the controls had to be easy. By designing for a simpler game, we could spend more time designing the small set of controls instead of spending most of our time getting basic functionality. We saw this as an opportunity to build on the primitive controls and hopefully make it easier and more intuitive to play the game.
“ By designing for a simpler game, we could spend more time designing the small set of controls instead of spending most of our time getting basic functionality.”
We also wanted to pick a game that was action packed. Since we were designing for fun, we wanted a game that that would promote fun through real user-engagement and interest and we could see having controls that were fun. We felt we could design a fun game
- Mario Kart
One of the first ideas out of our brainstorming session was Mario Kart. Mario Kart holds a special place in all of our hearts and this nostalgia gave us a lot of passion to work very hard. We imagined that simulating the driving aspect would be very intuitive and enjoyable. We continued to brainstorm to see what else we could come up with.
2. Tap Tap Revenge
We toyed with the idea of simulating a touchscreen game after seeing a demo for Fruit Ninja. Mapping the 3D space of the Leap Motion to a 2D interface seemed problematic. One idea we had was to do Tap Tap Revenge since we felt nostalgic and it is a very fun and simple game.
3. Flappy Bird
We also thought of doing a very simplistic game like Flappy Bird. We decided against this because of the difficulty from the necessary precision. Flappy Bird is hard to get very far with precise input and we knew that with the Leap Motion, it would be very difficult to even get past that first pipe.
4. LittleFighter
The last game we discussed was different types of fighting games with the Leap Motion. Once again, we saw problems with very precise timing. Another issue that we foresaw is the need for complex combos and numerous inputs to be effective. We were shooting for a simple game and we thought fighting games would be far from simple.
We discussed a wide variety of games, but in the end decided that Mario Kart would be the best option. It not only had the most reasonable range of motions we felt convertible to Leap Motion, but also felt that it would pull on the nostalgic strings of our classmates, and would be overall the most fun for everyone.
Making the Controls Intuitive and Fun
There are three types of control in the game: steering, acceleration and throwing an item. Our main priority in designing controls for the game was to make the gestures as natural as possible; considering we knew natural motions are best and clearest ways to teach users how to proceed and are easily recognizable. That way, the users need less time to learn and adapt, reducing the accumulation of frustration from learning how to play the game.
Our main priority in designing controls for the game was to make the control as natural as possible, considering natural motions are the easiest for the users to learn to play, and are easily recognizable and understandable.
Since we are using Leap Motion, our inputs are limited to hand postures, hand movements and shape-based inputs. One of our first ideas was to make our motions natural by replicating the hand movements of driving a car. The first and more obvious choice for steering was to mimic a steering wheel with both of our hands.
We soon realized this approach required both hands and left no room for other controls, so we decided to mimic steering motion with our left-hand only. For gas, we thought a gas pedal could be mimicked by the flat, non-steering right hand. Throwing items could be represented by the pointing of a finger on the right hand since both hands are already occupied.
However, in our initial stage of pre-development testing we saw some problems with this approach. The right hand was always in acceleration mode, thus it was practically useless for the entire game. The pointing of a finger worked as expected, but the the action was not intuitive, and we were worried whether Leap Motion would recognize it.
Thus, wee decided to change our model of interaction again. We kept the left-hand steering movement since it worked well, and seemed fairly intuitive in our test. We moved the acceleration to our left-hand using fist-closed motion. Fist-closed motion is not intuitive for acceleration, but it is the default action of most drivers while driving — drivers have to hold the driving wheels to drive — which makes it suitable for an action required for the entire game. This now frees up the right-hand, so we were able to map the item-throwing action in the game to an actual throwing motion, as we believed it is natural and fun — it’s always fun to throw something!
Formative Testing
For this project, we went through two different testing stages, one prior to development and one after. The first was through a process otherwise known as “Wizard of Oz Testing” where, one developer plays the game with its regular controls, while watching a user testing the motions we’ve planned as leap motion movements, and performing them. Testing in this format proved to be extremely useful for a series of reasons, but mostly because we were able to determine whether the motions that we planned for development were as transferrable from controller, to human as we expected them to be.
We first tested through a process otherwise known as “Wizard of Oz Testing” where, one developer plays the game with its regular controls, while watching a user testing the motions we’ve planned as leap motion movements, and performing them.
One classmate that helped us test said that he really enjoyed the idea of rotating your wrist for directions because it feels very similar to driving a car, which of course, was our intention, so we were glad to see the motion could convert. They particularly enjoyed being able to actually throw the different objects, and appreciated how realistic the motions from a controller could convert to actual motions, like driving a car and throwing.
Although “Wizard of Oz Testing” was useful in helping us, as developers, transfer motion gestures to reality, one thing we found slightly difficult about this form of testing was the delay-time between seeing the user make some form of gesture, and then converting that to a key being pressed. There was definitely lag in this, which made testing not totally comparable to what really playing the game would actually be like, and we thought could be skewing our results, but in the end decided it was useful enough feedback that we took it into consideration in our actual development stages.
“Wizard of Oz Testing” was particularly useful in helping solidify some of the motions we planned for our users. In our initial development planning stage we were cautious about ensuring that none of the motions were too clunky, or unrealistic for someone to do throughout the duration of a single game in Mario Kart, and testing in this format allowed us to select certain movements or motions over others based on this initial stage of feedback.
Building Mario Kart 64 Controls Mapped to Leap Motion
Once we decided to use the left hand’s rotation for steering, the gas to always be on, and a punching motion with the right hand for throwing items, we got our hands dirty and implemented our first prototype. Doing this with the Leap Motion was very straightforward and easier than we had expected.
Doing this with the Leap Motion was very straightforward and easier than we had expected.
At first, any amount of rotation of the hand from 5 to 180 degrees to the right was treated exactly the same as the left side. The initial 5 degree threshold was to ensure that the player could continue straight if they pleased without having to hold their hand perfectly level. As we continued to test though, we saw that people wanted to turn sharper at certain points so they rotated their hands much more sharply. Eventually, they would fully invert their hand and actually rotate it more than 180 degrees from the level position, thus causing the Leap Motion to think that the hand was rotated from the other direction, causing the Mario Kart emulator to start turning in the other direction that the user meant. To solve this, we created a dead-zone at the bottom from 135 degrees to -135 degrees that doesn’t cause any steering to deter users from turning that much.
Another thing we did to combat this was to output a button press more often if the user was rotating their left hand more. Originally, we had a constant delay of 30ms between button presses, but this meant that any turning left was identical. To allow for sharper turns, we wanted to linearly scale the button presses with the rotation of the hand. As the hand became more rotated, the smaller the delay between button presses and thus sharper turns. We scaled the rotation of the hand between the start rotation and the dead-zone rotation to be between 1 and 0 and then multiplied that by the max wait time which we tuned to be the most effective.
Sleep time = max wait time * (1 — ((rotation — minimum rotation)/(maximum rotation — minimum rotation)))
Design on these Leap Motions is limited by the capabilities of the hand tracking. In a game like Mario Kart, it is devastating to not be able to hit the gas randomly or not steer like you intended to. This is something that we couldn’t control and limited us. Originally, we wanted the user to simulate turning a wheel with their left hand, but because of the movement left and right, some users would go too far left or right without realizing it and go out of the sensors’ scope. We learned that telling the users to just keep their fist in place and just rotating gave the users a lot more success.
Post-Development User Testing & Feedback
Throughout our game development, and testing that naturally goes along the way of any program development, we began to notice one important problem with our intended motions, which is how tiring it can be to hold both arms out hovering over the Leap Motion. We worried this could become a problem in game-play scenarios, especially considering how often a user plays more than just one race.
We decided though, that this was mostly due to the nature of the Leap Motion, and there isn’t any feasible solution that would allow for our game to be as fun and engaging as it is with these motions. Therefore, with the knowledge in mind, we recommended that during gameplay a user could rest their arm on the back of a chair if they felt they were getting tired.
Many classmates mentioned the fond memories of their childhood Mario Kart brought back, which was a huge success for us, considering that was our main goal in designing for fun.
We received a lot of extremely useful user feedback after our in-class hack day. Specifically, our classmates often commented on how fun our final product and even mentioned some of our key goals in their feedback. Specifically, one classmate said “the chosen game is a blast and using the abilities [are] really intuitive.” Many mentioned how many fond memories of their childhood Mario Kart brought back, which was a huge success for us, considering that was our main goal in designing for fun.
Where We Go From Here
As expected, we received a decent amount of feedback about how tiring it can be to hold your arm out for an extended period of time, as well as difficulty with steering due to the occasional lag in motion detection, or it being overly sensitive and a user ending up turning too much. Had we had more time we likely would have found a way to map more clearly how sensitive a user should be to the motion of turning. Since it mainly relies on a key-press, we could have mapped more precisely how far someone has intended to turn by using a counter.
Had we had more time, one of the things we would have liked to explore more was whether someone could use a real steering wheel to play this, or whether the Leap Motion would be capable of detecting this kind of intermediary motion (i.e wheel versus wrist rotation.)
While there are definitely places we think we could improve our design, and explore other options we feel that we overall definitely achieved our goal in designing for fun, through the use of nostalgia and engaging user motions, we’ve built a fun new way to play Mario Kart 64 from your laptop using an emulator and a Leap Motion device.
Click here to find out out how we did it all
Originally published at medium.com on October 29, 2017.
