Kartwheel
A team building experience best described as ‘Live Mario Kart’.
OVERVIEW
Kartwheel is an interactive running race experience built to encourage healthy fun team-building. Inspired by Mario Kart, runners sling digital items from their mobile device at opponents while racing around a 1–2mile track. Players hit by items left or thrown by other players must complete challenges such as running backwards, spinning in place, or other games. Winners finish the track in the timeliest manner.
ROLE
I worked in collaboration with the team at Handstand, the makers of SF Hunt and other team-building events, to create Kartwheel. My role as designer was to contribute in research, defining scope, ideation, wire framing, prototyping, iterations, and the final visual deliveries for development. Predominate design tool used was Sketch.
GOALS
- Must have a 1–2 mile course to run, preferably an outdoor track, set up at an event space with geolocation.
- Must be able to facilitate 20+ players.
- Must be able to fire digital items from mobile device to hit opponents.
- Must be easy for players to determine when it is best to fling/drop an item.
- Must have other things to enjoy besides running.
- Must have rest breaks to give players a break.
- Level the playing field for less strong runners with a balanced item algorithm.
- Encourages fun team building.
TARGET USER
20–40yr old adults, who are physically capable to run at any level. The game is not limited to office employees, but office employees are the target market for Handstand’s team building events.
EVENT LOGISTICS
There are some things to keep into consideration when hosting a Kartwheel game. To participate, players must have a fully charged phone, comfortable running shoes, and water. Players will need to be reminded ahead of event day. Team costumes aren’t mandatory, but highly recommended to increase anticipation and even team-bonding prior to race day!
Only courses mapped out within private spaces or public parks are allowed at this point due to city event regulations and safety concerns.
The first Kartwheel game was hosted as a public event at Golden Gate Park, San Francisco. Kartwheel has also been hosted at LinkedIn as a company team-building event.
CHALLENGES
Geolocation technology was our first challenge. Before we could even green-light the project, we had to tap into device geolocation technology to map out course tracks, follow runner progress, and pin-point player locations with close proximity. If Janice was running ahead of all the other players, she should be correctly displayed in the forefront.
Mapping out where all players are located on the track is also needed to determine item pick-up zones and item interactions. Players in the front can get hit by thrown items, where players in the back can get hit by dropped items.
How enjoyable the gameplay is for runners of all levels was another challenge. Playing the game should be fun, no matter if the runner is slow, medium, or fast. With an item algorithm we could balance out the game between the different runners, making sure players didn’t get hit by too many nor too few items.
TESTING A SIMPLE PROTOTYPE
For our initial geolocation test, we ended up sending out an SMS to players when they ran by an item zone or got hit by an item and the run back penalty.
When runners hit an item zone, runners would get a message and have to collect the item before passing too far. If a player isn’t paying attention, they may miss out on receiving an item.
TEST RUN LEARNINGS
During the initial test run we learned several key things;
1) It doesn’t matter what item — 🍌☄⚡👽 — you get hit by, as long as the penalty behavior players must do is crystal clear.
2) The penalties need to vary. Running back or standing in position as a penalty is redundant — aka not fun!
3) Running back is confusing without a map on the player’s side. Run back how far? 100m? How far is 100 meters anyways?
4) Runners without their SMS sound on or haptic feedback on, missed Item Zones and penalties because they were not aware to check their device.
5) All participates enjoyed the game even if they were not trained runners. Many played multiple rounds. Woo-hoo!
NEXT STEPS
The item algorithm is an important part to test. Iterating on how often players get hit dependent on running speed, is just as important as deciding on what actions runners take when hit.
To level the playing field, a strong runner may get hit by items more, so there’s a chance for slow runners to run past. However, a balance in the algorithm is key so players in the lead aren’t constantly getting hit.
The actions runners take is dependent on the item that hits them. We wanted to make sure the actions were a mix of challenges so that runners weren’t bored or dissuaded. To decide on the item and action combinations players would face, we first used different methods to brainstorm, such as tree maps, both individual and group brainstorms.
GAME EVENTS
Keep in mind that on-boarding players prior to event day is just as important as joining a race on game day. We chose to focus on in-game events initially, while simultaneously mapping on-boarding and end of race experiences.
Here are some of the in-game events we came up with:
onRaceGo → Players are reminded via push notification to meet at starting point 🏁 on map prior to race start. Countdown timer in-app displays time left before race begins.
onRaceStart → Countdown timer with haptic feedback (vibration and sound) signals race start. Game map is displayed with all player avatars.
onItemZone → Player receives notification and haptic feedback (vibration and sound) to signal item zone. Geolocation is used to determine when a player is near an item zone.
onGetItem → Player receives an item at random — 🍌☄⚡etc
onUseItem → Player uses item by swiping item up onto map. Items either launch at all players on the map, fire at a targeted player, drop onto a random location on map, or equip to the player holding the item. Players can hold their item for up to a minute from receiving.
onGetHit → Haptic feedback (vibration and sound) to signal stop running and review challenge.
onChallenge → Player receives a challenge to complete. Challenge received is dependent on item which hit player.
onFinishChallenge → Positive haptic feedback (vibration and sound) to signal continue race.
onRaceEnd → Stats, points, medals for both personal and team views.
onRaceList → Shows all races; finished, in progress, and future races.
IN-GAME CHALLENGES
A challenge is a short game, such as a puzzle or video prompt, required by hit runners to complete using their mobile device. Instead of just a time penalty of standing still for x-amount of time, challenges expanded our ability to vary the actions which runners complete. All challenges are time capped and completable via the player’s mobile device.
Challenges are dependent on the items which hit players, and not all challenges are physical. Some challenges create a break for runners to rest, which levels the playing field for non-runners.
Here’s a few challenges we created:
- Earthquake shake up — Video input challenge. Player must complete a prompt by recording a silly video performing an action or answering a prompt question or interacting with fellow runners. Videos are viewable by all players and sharable at the end of each race.
Earthquake shake up prompt examples:
High-five 3 runners who pass you.
Fill in the blank and yell out this phrase: “Start your day with […] and finish it with […]!”
Explain why you chose waffles over pancakes. During on-boarding, players are asked binary questions that may be used in-game. See on-boarding section for details.
- Shout — Audio input. Player must yell into device microphone for x-seconds at a maintained level.
- Spin — Players must spin in place x-times. Players may find running afterwards extremely difficult, dizzying indeed!
- Banana balance — Players must complete a gyroscope game after being tripped by banana. Going from running to zen mode is much harder than you think!
RUNNING BUDDY
Most non-runners don’t know how far 100 meters is, so you can’t expect players to run back the correct distance without getting frustrated. To limit confusion, we came up with a running buddy concept. Players must run with a running buddy, and if an item knocks the buddy off, the player has to run back to pick up their buddy wherever the buddy is shown on the map.
Using the buddy as a visual indicator on the map omits confusion as to how far back players must run. This also gives the game design flexibility to vary the run back distances for each player. Slow runners may not have to run back as far for their buddy as do stronger players.
Players pick out their running buddy during on-boarding. Watch Pick Buddy video for on-boarding run-through.
HAPTIC FEEDBACK
“Will I be staring at my phone the whole time?”
We included haptic feedback, both enabled vibration and sounds, so runners aren’t looking down at their mobile device for prolonged periods of time.
Not only is haptic feedback important in communicating to runners when actions take place, but also for runner safety — to avoid any pot-holes or foot traffic.
RANKING AND EVENTS
Game events are displayed at the end of each race and also accessible by tapping on a race name on the race list. The history of each race is a fun post-game activity where players can review a composed video of player video prompt responses and review who threw items at you. Race history is accessible after each race and is also under race, player, and team profiles.
LEADERBOARDS AND TEAMS
In the spirit of team bonding, we wanted to highlight the competition between teams with course time records, win streaks, and challenge wins.
RACE DASHBOARD
Players can join a race whenever they are feeling up to it, and run at their own pace. Players can use the race dashboard to plan and join future races.
A race page displays the course and where and when to meet. Players can only join one race at a time. To switch race times, players must withdraw from the race they are in.
We found when multiple games were in progress on a single track, runners would be confused and overwhelmed.
Races are capped to 20 runners max and limited to one race per track. For more races to take place at the same time, an event space must be large enough to have multiple non-overlapping tracks.
APP ON-BOARDING
On-boarding is pretty straight forward after players download the Kartwheel app. Players receive a ticket code online or from another player who has multiple ticket codes. Players can share unclaimed ticket codes to their friend so they can join their team.
During on-boarding, players are asked welcome questions which are binary and may be used in-game. See In-Game Challenges section for details.
AR FUTURE
Augmented reality is definitely an option for Kartwheel, but this project goes to show you, it’s not necessary to include AR for players to have a good time. In fact, adding AR may slow down app performance and hinder runner speeds.
EVENT FUTURE
The Handstand team is currently working on providing the app to anyone who wants to start up their own Kartwheel game. Plan includes ability for race creators to map out race course on the app and send out race invites.
TEAM SHOUTOUT
Thank you Team Handstand, I always have a blast working with you all! Special thanks to my good friend and designer, Marie Bautista, who introduced me to the team and worked along side me on this project.
