“inVert - evade and destroy” is a high score based, VR Segway-like action racing game, in which the player is moving along the inner surface of a sphere and tries to reach certain checkpoints while avoiding any contact with enemies.

PROJECT INFORMATION

Date: 4th semester (2015)
Duration: 3 weeks
Team Size: 4 people
Technology: Unity5, C#, Oculus Rift DK2, Wii Balance Board, Photoshop, Ableton Live 9
Constraints: Develop a fully playable prototype with the focus on alternative interface devices as a proof of concept.

Gameplay Video

Introduction

This project was part of our 4th-semester experimental game jam. Our task was to design a game within a three week period. Having this in mind; our schedule was very tight and the scope of this project strongly limited.

The topic for this group project was: “Interface Device”.

Concept

The focus of this project was to design a game specifically addressed towards a chosen interface device and not vice versa. The interface device we chose is the Oculus Rift. But having the head tracker of the Oculus Rift as the only input device felt somehow limited to us, for which reason, we decided to include another input device. We then chose Nintendo’s Wii Balance Board, because it is making use of the most natural human body movements while remaining very simple to handle. It was important to us, to forgo the typical, but mostly unintuitive, on hands controller input, which could destroy immersion.

Thinking about the Oculus Rift; one of its main advantages is the player’s ability to look into any direction and to have a 360° view. To fully utilize this feature, we decided, that the player should be surrounded by the playing field, in which the point of interest could be in any direction. By that, we do not mean only all around the player, but also above and underneath. This thought led us to the conclusion that the playing field should be a sphere, on which the player is moving along its inner surface. The player would, for example, see the other side of the sphere by looking upwards.

Game Mechanics

Our game, “inVert - evade and destroy”, is a high score based, single player, Segway racing, action game, in which the player is moving along the inner surface of a sphere, trying to reach certain checkpoints while avoiding any contact with enemies. Enemies are moving straight along their lanes, and the amount of appearing enemies is increased by time. At specific intervals, the enemies are starting to chase the player, forming a big mob. While the player is moving and continuously trying to avoid the enemies, there are also gates appearing on the surface. The player can drive through those gates to destroy them. When being destroyed, the gate will burst into pieces and destroy all nearby enemies as well.

The player can use this as an advantage to destroy as many enemies as possible. The score is raised with every destroyed enemy, and the multiplicator is increased with every reached gate. If the player gets in contact with an enemy, the game is over. To orientate in space, the player can use the Oculus Rift to look around. Also, the player can move along the surface by leaning forward, backward, left or right on the Wii Balance Board.

Art Style

Having the low resolution of the Oculus Rift’s development kit and general motion sickness in mind; we were aiming for a rather simple and clean look. We wanted the least distraction from gameplay relevant elements as possible and had chosen to use very simple geometries with easily distinguishable silhouettes.

My Task Area

Before anything else, we needed a concept for the gameplay and a working scoring system. In addition to that, I was given the task to design and implement the acoustic feedback. It was essential to coordinate and share our responsibilities carefully as we had three programmers on our team. One of my other tasks was to create all necessary game objects, like gates and enemies, as prefabs for prototyping purposes. I was also in charge of the spawning system of those. Other minor tasks I had to tackle over the course of the project involved the creation of a pole-less sphere, visual feedback by changing the color scheme as well as arranging the title and high score menus.

Developing Gameplay Concepts

Our mission for this project was not only to work out a game concept, which would support the Oculus Rift and the Wii Balance Board but furthermore, is noticeably designed around those devices. We wanted to make them an honest part of the experience. To be able to start prototyping as soon as possible it was necessary to develop several gameplay concepts. We agreed on the sphere as the playing field and continued to develop the gameplay concept with having the Oculus Rift and the Wii Balance Board in mind. All the little details, like for example the scoring system and the movement system had to be taken into account.

I have learned, that it can be constructive, to take non-digital prototyping material and go through the rule set of the game to identify potential problems early.

Creating Prefabs

My task was to create a stack of scripts and game objects, which we could use for prototyping. It was important that everything was designed with modularity in mind. Being able to reuse and combine modules was supposed to lead to more efficient prototyping.

The enemies are sphere meshes attached with a script giving them a constant force in the direction of their local forward vector to make them moving forward. They also carry a script which makes the up vector to look at the center of the sphere and a force which is pushing them away from the center and onto the surface of the sphere resulting in somewhat like “reversed gravity”. If they collide with a game object, which is tagged as “player”, the game ends.

The gates are two poles with a collider in between. They will be destroyed on overlap with the player. When being destroyed the tag of all game objects within a specific radius are being checked. If the game object is tagged as an “enemy”, they will be destroyed.

Creating a variety of prefabs helped me to get back into text-based scripting. Each of the different game objects came with a unique programming problem. Because each game object by itself was representing a rather simple problem, I was able to solve them all one by one. Also, it was helpful to put extra attention on the modularity and consistency of the objects. There have been several other game objects like collectibles or projectiles shooting turrets, which didn’t make it into the final game. I am satisfied with the result, and I am proud to see, that I felt comfortable and was immediately able to access and transfer all the knowledge from visual scripting to text-based scripting.

Sound Design

While movies do not give any control away to the consumer, games do. This makes music in games sometimes tricky to handle. The tension in games is often situational, which makes prearranged composition less efficient and less powerful if they do not adapt to the game state. Therefore, I wanted the soundtrack to be reacting highly dynamically to the state of the game, to enhance the gaming experience. I had to find a way to let it react to the current game state through other variables. Because the pacing of our game is continuously raising and falling, I wanted the music to be bound to the pacing and the tension of the current game state. Another goal was to modulate all sounds from scratch, without using any sound libraries. The idea was to learn how to pinpoint a specific sound while having total control over the creation of itself and without being influenced by any external factors.

The longer it takes the player to destroy an enemy, the more elements are being cut out, which continually raises the tension and increases the effectiveness of the incoming drop in. The longer none of the enemies are destroyed, the more enemies are gathering in the arena. In the same principle, as a DJ is raising the tension on the crowd by cutting out elements and fading out the lower pitch sounds, my script for the soundtrack is also cutting out elements to build the tension and prepare for the drop in. Furthermore, the soundtrack is also changing accordingly to the state of the enemies. If the enemies are switching to the mode in which they chase the player, the hi-hat, bass, and lead is replaced by a faster-paced arrangement.

I am delighted with my results in designing sounds and I think, that I have made an enormous leap forward. The soundtrack has a very progressive character, which is precisely what I was aiming for. The highlight for me is, the dynamic aspect of the music and how well it adapts to the tension of the game. I carefully crafted the sounds so that each sound would have its own frequencies within the sensible acoustic spectrum. This helps the sounds to stick out and remain distinguishable even when several sounds are overlapping.

Visual Feedback

After having implemented the acoustic feedback successfully, I still saw opportunities to enhance the experience by adding more visual feedback.

In some cases, the player would hear the shift in the soundtrack, but would not notice the change in the enemies behavior. This situation could provoke confusion, because the sound changes remarkably, but nothing seems to happen. That is why I have been implementing a script, which changes the color pattern of the game, whenever the music changes drastically. Furthermore, it gives the player important feedback about the progression of the game.

To achieve this, I wrote a script, which accesses all used materials directly. By changing the attributes of a material, which is in use, all game objects that are linked to it, can be altered in their appearance at runtime. This way, for example, the script can change the appearance of all enemies at the same time, by just changing the referred material of the enemies. I added several color patterns so that the script can blend between them.

This visual feedback was implemented last minute and can still be further optimized in many ways. I am not entirely satisfied with the color patterns, which I have been adding and I think the color fading system could be much better. Right now the colors are only changing when the enemy’s behavior is changing. I think a constant slow color fade would have fit perfectly into the mix. Nonetheless, I think it is an important feature, and for the time I had, well enough implemented.

Spawn Point Manager

Having the stack of prefabs done, it was essential to find a way how to utilize the prepared items comfortably for prototyping purpose without having them to be dragged into and out of the scene every time. For that matter, I have written a script, which spawns the desired game objects in the desired pattern under desired restrictions.

The spawn point manager has a public variable for game objects, in which the user can define the prefab to be spawned. In addition to that, the script knows the length of a beat in seconds and can generate the objects in definable intervals accordingly to the music. The user can also define whether the game object should spawn on a random location within the sphere or a random location on the surface of the sphere. This is accomplished by a random normalized vector, going from the center of the sphere. To spawn within the whole volume of the sphere, the vector has to be multiplied by a random float between 0 and the radius of the sphere. To spawn on the surface of the sphere, the vector has to be multiplied by the radius of the sphere.

There can be multiple Spawn Point Managers in the scene, each handling their own prefab, spawn amount, starting time, interval length and end time.

Although it was an easy task to accomplish, it was still confronting me with some new problems. I am glad for every work, in which I have done something new. It expands my knowledge and can help me to solve other problems faster in the future.

Recap

I am delighted with the outcome of this project and would mark it as a great success. I have thoroughly fulfilled the goal to transfer my knowledge from the visual scripting language to apply it to the text-based scripting language. Working as a team of three highly skilled programmers was an exciting experience. Because each one of us had a different skill set and approach, it was always exciting to exchange ideas and opinions. Also, working together forced us to work tidy and structured.

Being in the position of having full freedom in designing the sounds was great, and I am particularly proud of this the results of the sound design. I am still very interested in the programming of AI and would love to improve in this area at next possible chance. This time there was no complex AI needed. In overall, I am delighted with the result of this project, and I am pleased with my performance.

>>For my full documentation: Click HERE!<<