Introduction:
Bit-Bots: Asteroid Defense is a virtual reality asteroid shooter game for the HTC Vive and Oculus Rift. A simplified version of the game will also be playable on Google Cardboard.
Bit-Bots: Asteroid Defense is a virtual reality asteroid shooter game for the HTC Vive and Oculus Rift. A simplified version of the game will also be playable on Google Cardboard.
Above: a demo video of the game being played on the Oculus Rift, including walkabout and asteroid shooting.
Gameplay Description:
The player starts the game inside of a biome in a science colony on Pluto. Soon after the game starts, they hear an alarm signaling that the colony is under threat from waves of asteroids. The player can defend the base by getting into a spaceship that will transition them to the main game, or they can go to a design area to modify their weapon abilities first.
In the main game, the player is standing on a platform in space with a gun attached to their right hand. The planet that the player is protecting is behind and waves of asteroids spawn in front, moving towards the planet. The rate at which asteroids spawn increases over time, which increases the difficulty of the game (we will eventually replace this mechanic with a level system). By shooting asteroids with the gun, the player can knock the asteroids off course or, after shooting them enough times, can break the asteroids apart. The gun has a maximum firing speed and must build up charge in order to fire. The player scores points whenever they break asteroids apart. The planet loses health whenever asteroids get past the player without being broken up or knocked off course. Digital readouts on the platform facing the player display the player’s score and planet health. When the planet health falls to zero, the game is over, the player is returned to the starting scene, and game updates the player’s high score.
The player starts the game inside of a biome in a science colony on Pluto. Soon after the game starts, they hear an alarm signaling that the colony is under threat from waves of asteroids. The player can defend the base by getting into a spaceship that will transition them to the main game, or they can go to a design area to modify their weapon abilities first.
In the main game, the player is standing on a platform in space with a gun attached to their right hand. The planet that the player is protecting is behind and waves of asteroids spawn in front, moving towards the planet. The rate at which asteroids spawn increases over time, which increases the difficulty of the game (we will eventually replace this mechanic with a level system). By shooting asteroids with the gun, the player can knock the asteroids off course or, after shooting them enough times, can break the asteroids apart. The gun has a maximum firing speed and must build up charge in order to fire. The player scores points whenever they break asteroids apart. The planet loses health whenever asteroids get past the player without being broken up or knocked off course. Digital readouts on the platform facing the player display the player’s score and planet health. When the planet health falls to zero, the game is over, the player is returned to the starting scene, and game updates the player’s high score.
In the design area, the player can modify their in-game attributes by adding or removing energy cores from their gun. There is a maximum total number of energy cores the player can have in their gun, but they can choose how many of each type to include. There are three types of energy cores, distinguishable by color. Red cores increase the gun’s firepower, which improves the player’s ability to break apart asteroids. Blue cores increase the gun’s maximum firing speed. Yellow cores increase the planet’s health, allowing more asteroids to get past the player before the game ends. Functionality for green cores will be added to the game at a later date. The maximum total number of cores may be increased by accumulating points from shooting asteroids.
The player can also swap guns in the design area. Swapping guns serves as a method of saving attribute configurations. So if the player finds a set of attributes they like but wants to try something different, they can swap to a different gun and experiment with their attributes and then swap back to their first gun when they want to return to their original setup.
Story of the Process:
The original idea for this game was an adaptation of a board game designed by one of the team members to a VR RTS (real time strategy game in virtual reality). This idea, however, was too ambitious to be feasible for the short timeframe of the project, so it was scaled back into a PvP arena-style shooter, and then scaled back again into an asteroid shooter. The core concept of using colored blocks to maximize the player’s freedom in customizing their abilities, however, carried through from the original idea to the present version.
The original idea for this game was an adaptation of a board game designed by one of the team members to a VR RTS (real time strategy game in virtual reality). This idea, however, was too ambitious to be feasible for the short timeframe of the project, so it was scaled back into a PvP arena-style shooter, and then scaled back again into an asteroid shooter. The core concept of using colored blocks to maximize the player’s freedom in customizing their abilities, however, carried through from the original idea to the present version.
We met regularly to make key design choices, ask questions, and divide the workload. A summary of the breakdown is as follows:
Will Petillo: User Interfaces, Design Scene functionality, Vive implementation, and asteroid behaviors.
Alberto Garcia: Artwork for planet base, sound, and asteroid behaviors.
Ricardo Funk: GitHub repository management, implementing key external assets, Oculus implementation, leaderboards, gun behaviors.
Devin Moya: Google cardboard implementation.
During our first team meeting after deciding on a project proposal, we kept our scope as minimal as possible so that we could be sure to meet the Udacity project deadline with a functioning prototype. This limited scope did not include a design scene or leaderboards, among other features in the current version. In less than a week of development, however, we hit nearly all of our objectives and chose to re-expand our scope to the above bullet-point list.
Will Petillo: User Interfaces, Design Scene functionality, Vive implementation, and asteroid behaviors.
Alberto Garcia: Artwork for planet base, sound, and asteroid behaviors.
Ricardo Funk: GitHub repository management, implementing key external assets, Oculus implementation, leaderboards, gun behaviors.
Devin Moya: Google cardboard implementation.
During our first team meeting after deciding on a project proposal, we kept our scope as minimal as possible so that we could be sure to meet the Udacity project deadline with a functioning prototype. This limited scope did not include a design scene or leaderboards, among other features in the current version. In less than a week of development, however, we hit nearly all of our objectives and chose to re-expand our scope to the above bullet-point list.
Above: video of the game being played on the Vive, including teleportation around the home scene and using the block design system.
Learning Objectives:
Besides creating a great VR experience, one of our core objectives in this project was to improve our skills as developers. This motivation did not change the overall design of the project, but influenced our priorities in terms of what to include in the initial prototype and how to focus our time. Some of our educational objectives were as follows:
Cross-platform development and working with an online repository proved to be especially challenging, forcing us to look for ways to standardize our usage of GitHub and minimize platform-dependent elements in our game.
Besides creating a great VR experience, one of our core objectives in this project was to improve our skills as developers. This motivation did not change the overall design of the project, but influenced our priorities in terms of what to include in the initial prototype and how to focus our time. Some of our educational objectives were as follows:
- Practice working together with other developers remotely with widely varying backgrounds and skillsets and develop an efficient workflow.
- Get familiar with using GitHub repositories and avoiding merge conflicts.
- Designing for cross-platform development. Specifically, creating the project from the beginning in a way that makes porting functionality to new platforms as simple as possible—as opposed to porting as an afterthought.
- Creating novel yet intuitive user interfaces that explore the unique capabilities of VR.
- Performance optimization.
- Developing a platform-neutral online leaderboard system.
Cross-platform development and working with an online repository proved to be especially challenging, forcing us to look for ways to standardize our usage of GitHub and minimize platform-dependent elements in our game.
Results from User Testing:
We tested the game with someone not involved in the development process and with limited experience in VR. The tester enjoyed the game, including exploring the main scene, moving blocks around in the design area, and shooting at asteroids. The tester was only given instruction on elements that would be included in a to-be-created tutorial system, where there were bugs or incomplete features, and when she got stuck. There were, however, still some minor areas of confusion we will need to address as we continue to improve the game:
We tested the game with someone not involved in the development process and with limited experience in VR. The tester enjoyed the game, including exploring the main scene, moving blocks around in the design area, and shooting at asteroids. The tester was only given instruction on elements that would be included in a to-be-created tutorial system, where there were bugs or incomplete features, and when she got stuck. There were, however, still some minor areas of confusion we will need to address as we continue to improve the game:
- Tester was able to walk inside large objects that should have blocker her bath, leading to her getting disoriented and lost. Potential solution: block user from moving into areas they shouldn’t be able to go.
- Tester did not know how to get to the asteroid-shooting area from the home base. Potential solution: include a starting tutorial guiding the player (e.g. with signs) from the starting area to the teleporter.
- Hand placement to successfully add/remove blocks was finicky. Potential solution: adjust trigger collider sizes and locations.
- Tester figured out how to remove blocks after a while, but did not realize how to add blocks back. Potential solution: add an in-game tutorial explanation.
- Effect of adding/removing blocks on gameplay not guessed without explanation. Potential solution: show attributes instead of (or in addition to) block counts on the design stats panel.
- The reloading user interface was mostly self-explanatory, but the tester erroneously thought that it also indicated firing power and that the gun could still fire when at zero (it cannot, but the reload rate is fast). Potential solution: add sounds for when the player fires a bullet and a different sound for when they try to fire but are out of ammo.
Above: the game on the Oculus, including the latest visuals of the home environment and gunshot audio
Plans for Future Development:
The primary area of expansion will be in the level system. In the prototype, the player simply shoots a continuous stream of asteroids that are fairly similar to each other. A full version will involve more variety in types of asteroids (or other threats) that in turn require the player to use a wider variety of tactics. A level system will allow us to introduce this added complexity one element at a time so that the player is continually challenged without being overwhelmed. New game-play mechanics to include in future levels are yet to be determined.
The primary area of expansion will be in the level system. In the prototype, the player simply shoots a continuous stream of asteroids that are fairly similar to each other. A full version will involve more variety in types of asteroids (or other threats) that in turn require the player to use a wider variety of tactics. A level system will allow us to introduce this added complexity one element at a time so that the player is continually challenged without being overwhelmed. New game-play mechanics to include in future levels are yet to be determined.
Conclusions:
Our goal for the Udacity project deadline was to create a fully-functioning prototype that gives a basic sense of the gameplay. Since we enjoyed and learned a lot from the process—and found the core game to be surprisingly fun—we are strongly considering continuing to build out this project into something worth publishing for a larger VR audience.
Pivoting from an educational exercise to developing for publication will bring with it many new challenges. Business and legal considerations, for example, will be important to figure out early on. It will also be important for us to work from a central design document that we all contribute to, understand, and agree with—with roles clearly defined—for the purposes of allocating ownership, minimizing merge conflicts in our repository, and generally staying on the same page. Finally, we will need to transition our driving design questions from “what is the simplest implementation we can test right away?” to “what is the best user experience we can provide within the spirit of this game?”
Given the success of our prototyping process, we are confident about our prospects moving forward and excited to see what happens next.
Our goal for the Udacity project deadline was to create a fully-functioning prototype that gives a basic sense of the gameplay. Since we enjoyed and learned a lot from the process—and found the core game to be surprisingly fun—we are strongly considering continuing to build out this project into something worth publishing for a larger VR audience.
Pivoting from an educational exercise to developing for publication will bring with it many new challenges. Business and legal considerations, for example, will be important to figure out early on. It will also be important for us to work from a central design document that we all contribute to, understand, and agree with—with roles clearly defined—for the purposes of allocating ownership, minimizing merge conflicts in our repository, and generally staying on the same page. Finally, we will need to transition our driving design questions from “what is the simplest implementation we can test right away?” to “what is the best user experience we can provide within the spirit of this game?”
Given the success of our prototyping process, we are confident about our prospects moving forward and excited to see what happens next.