Scoot City

Game Designer

Overview

Scoot City is a multiplayer scooter-racing game built for Virtual Reality. I created it while at NYU studying Virtual and Augmented Reality UX.   The above video was the initial game conceptualization spec. 

My goal for the project was to build VR locomotion and interaction scripts for the scooter.  The early mockups were meant to define the primary gameplay loop and functionality: picking up a scooter and scooting. 

The Spec

  1. Scoot-city is a multiplayer scooter-racing game
  2. Target Users: Gamers with virtual reality headsets
  3. The game will be played on Oculus Quest 2 headsets
  4. Currently, no way to scoot with your friends in VR
  5. Scoot-city solves this by providing a scoot-based multiplayer game
  6. SCOOT and ScooterFlow are trying to solve this
  7. SCOOT and ScooterFlow are not VR based or multiplayer.

Loot.  Scoot.  Reboot.

I love riding electric scooters with my friends. The problem is we all live in different cities, some of those cities banning electric scooters. So instead of waiting for the next bachelor party, I built Scoot City. Now anyone with a VR Headset can scoot around town with the homies.

Iterations & Testing

Implementation Round 1:

To maximize time creating and testing this I created a visually simple game world and implemented a quick game loop. An example of this can be found in the below images of a cube. These were the initial iterations of the grab and socket VR interactors. I ran an initial round of testing with this environment.

Testing Round 1:

Two out of the three users that tested were able to complete all three tasks with zero assistance.  The tasks were focused on grabbing the cube, dropping the cube, and then placing the cube back into the socket. The feedback ranged from logistical things I hadn’t built in order to focus the tests (“why can’t I move?”) to more practical things like “why can’t I grab this with my right hand”  which I actually thought was pretty fair and implemented in future versions.

Implementation Round 2:

Next up, I applied the cube interactor methods to the scooter. This was a little trickier as it was an imported asset. But after some tinkering, I was able to replicate a fairly similar experience (see images below) and then run the second round of testing…

Testing Round 2:

Once again, two out of the three users that tested completed the 3 tasks. All three were able to go through the test at a much quicker pace as well. With the more customized scooter asset came additional problems. 2 users ran into a collision between the scooter and the table. My plan to fix this was to test the ‘grab point’ being at the handle-bars instead of the base of the scooter. – This ended up causing more collision issues, so I resorted to the initial base grab point.