RushRushVR
RushRushVR is a VR game, inspired by Nintendo's WarioWare, made on the Meta Quest 2.
​​
Details:
-
My role: Gameplay Programmer and Game Designer
-
Team size: 5
-
Dev time: 7 weeks
-
Contribution:
-
System/Content/Level Design​
-
Game Design
-
Gameplay Programming
-
Documentation
-
Made with:
Premise
This game was inspired by WarioWare. Players will be challenged to complete multiple microgames in a short amount of time with minimal instructions. The final version included 9 microgames. Just like the game it was inspired by, RushRushVR aimed to place players in a high-intensity environment through fast-paced gameplay.
In Action
Game Design
Pre-Production
After completing our three-week prototype, "The Bow Game", we wanted to start with a fresh project without completely scrapping our prototype. Though we were proud of our work, we didn't want to expand anymore on "The Bow Game".
​
We decided that the best way to keep "The Bow Game" and still create a new game was to throw it in as a minigame in a Warioware-inspired game.
Our group set up a Trello board in order to scope the project and discuss our responsibilities.
​
We decided that each member was responsible for creating at least one minigame, with one member being responsible for creating a system to stitch the minigames together.
Minigame 1
After a few seconds of the black screen with instructions, the game will start. Through playtesting, we saw that players did not understand which direction to look when the game started, so the arrows were added to prompt players to look at the right direction.
Just like WarioWare, players are given minimal instruction at the beginning of each minigame. Typically, WarioWare minigames give less instruction than this, but in order to accomadate for the VR learning curve, we opted to give slightly more instruction to players.
​
​
Level Design
Most of the levels for this game are very simple, as players won't spend too much time on each one. The main purpose of each level is to be able to convey to the player what they need to do in a second or less. In the "Eat all the food!" level, players are sat in front of a table with a plate of food and a fork in hand, signaling to them that it's time to eat.
Gameplay and Programming
The main mechanic for this minigame is eating. Players achieve this by using the fork that is placed in their hand at game start to pick up the food. The food items are randomly spawned at game start as well. They then bring the food item to their mouth which will cause them to eat.
​
This was achieved by placing a trigger at the tip of the fork. When a food item enters the trigger, it disables the rigid body on the food item and makes it a child of the fork object. The player spawns with a mouth trigger area. When the food item enters this area, the food's rigid body is turned on and detaches from the fork. A sound and controller vibration feedback is given to indicate that the player has eaten the food. The food item is then destroyed. If the player eats all the food they win, and if they don't finish all the food in time, they lose.
​
The minigame manager keeps track of how much food is left on the plate. The manager inherits from a minigame class, scripted by the group member responsible for stitching the minigames together. Through this parent class, this minigame manager can handle the length of the minigame and take away or keep lives based on the outcome of the game.
Minigame 2
Same as the first minigame, it starts with a short phrase to tell the player what the minigame might be about.
​
In this minigame, the player must be as still as possible, or else the soldier shoots the player.
Level Design
The design of this level quickly sets up the narrative of being caught red-handed. The player was hacking into a system and was caught by a guard. As shown in pop culture, when someone is caught by someone with a gun, they must freeze.
Gameplay and Programming
My initial idea for this minigame was to have it act as a break in rhythm from the rest of the game. The players will spend most of the game frantically moving around, so I felt that throwing them off with this minigame would be a fun way to spice things up.
​
The two sliders on each side correspond with the player's controllers. They act as visual feedback to show how much the player can move. When either of them fills up, the player has moved too much and will lose the minigame.
​
At game start, a game object is instantiated at each controller's position. The sliders are mapped to display the distance between the instantiated object and the controller's current position. The manager from this minigame also inherits from the minigame class.
Postmortem
Over the course of this project, I was familiarized with VR game design, Unity's XR SDK, and VR UX. This was one of my first major XR projects, and I'm satisfied with how it turned out. Because I didn't have much experience working with VR before this, I felt that everything was brand new to me. It almost felt like my prior game design and scripting skills went out the window. Nevertheless, I was able to work well with my teammates to pick up the skills required to make a VR game.
​
​If I had more time, I definitely would have wanted to add more feedback to the game. I felt like the game could have used more visual effects and haptic feedback to notify the player of what exactly was happening. The "You move you die!" minigame could definitely have used some controller vibration to notify the player if they were moving too much. I also would have wanted to use more original assets and music so it could have been easier to release the game on the Oculus store.