Blog

Omni Arena: Iterative improvements for VR development.

For context: Omni Arena (OA) is a protect-the-objective, FPS game being developed by and for Virtuix; a company that creates an omni-directional treadmill for VR. I was the Lead Artist on this title during it’s development from 2015 to 2018.

I’ll be showcasing some iterative work for various parts of the art pipeline; along with giving some insight into what prompted each iteration. As I’m the only artist on the dev team, I’m responsible for the majority of the artwork shown (along with it’s implementation), unless otherwise specified.

Additionally, I’ll be talking about areas of VR development that were especially troublesome with this project, along with how solutions were discovered.

Gameplay footage of Omni Arena.

 

 

Environments

Initially, OA was developed as a tech demo for the Omni treadmill. The intent was to create a short experience that was intense enough to appease gamers, but also straight-forward to make it accessible for a wide audience. Creating all the necessary artwork for that experience within a 2-month deadline made taking a minimalist approach to environment art a very savory option.

The visual style generated from these requirements is shown below. I opted to use a neutral palette that relied on varied geometric patterns, emissive lighting and large, imposing architecture for visual interest. This simple aesthetic allowed for quick iteration on both art and level design.

First iteration of the Thunderdome level.

An elevated perspective of the arena. The powercore (shown here in the upper left) was the player’s defensible objective. Floating, red markers were used to guide the player towards the powercore. Nobody paid attention to them, unfortunately.

The player entrance (shown in the upper-right) also served as a container for us to spawn the enemies in.

This is the view the player had moving through the entrance tunnel towards the arena.

While this approach got the job done in time, there were some glaring gameplay issues that stemmed from this iteration of artwork.

The lack of secondary details on the floor and walls made judging distance difficult, especially in VR. This led to FPS gameplay that felt sloppy and unpolished from a player perspective. The powercore (opposite the tunnel entrance) was visually unimportant amongst an equally greyscale environment. This played a large part in allowing the player to forget about the powercore, which needs to be monitored throughout the game. Another negative aspect of this iteration lied in the composition of the informational assets (player score, powercore health). Similar to the powercore, these UI assets lacked the proper design qualities that made them feel important and necessary to look at during gameplay. Most of our players left the demo not ever knowing what their score was or how low the powercore’s health became.

These issues, along with other thematic and compositional shortcomings, helped inform what needed to be changed in the next iteration of the level.

 

 

Second iteration of Thunderdome.

Concept by Manuel Gomez

Now we’re getting somewhere. With the help of the wonderfully talented concept artist, Manuel Gomez, the second iteration of Thunderdome started to address many of the concerns listed above.

Color variation and secondary details on the floors/walls improved spatial awareness and the ability to judge distances more accurately. Improved lighting and varied, shadow-casting objects provided a better sense of depth in the environment. Contrasting backgrounds, along with improved framing helped informational assets stick out more. The powercore was now prominent against the surrounding environment with an expanded color palette. The addition of a proper stadium, crowd and cityscape brought in some much-needed immersion and helped the level feel like a fully-realized space. Overall the level looked better, felt better and player’s experiences were improving.

These changes resulted in a good second step overall, but readability was now becoming more of an issue. High amounts of contrast due to vibrant lighting, emissive materials and color choice was making the overall composition feel very chaotic. It became difficult for players to focus on enemies and other information was still getting lost in the environment.

 

 

Final iteration of Thunderdome.

And here is the answer to our readability issues: Thunderdome as it stands currently. A lot of time was spent tweaking the color palette and changing the lighting to help increase readability and provide much needed contrast between the exterior environment and the playable arena. Many thanks to the multi-talented Pramod Ramesh for his insight and help with fleshing out this iteration.

While testing different lighting setups on another map, I realized that night time lighting worked incredibly well for our game. That, along with strict color usage helped me compose a play-space that was easier to read but still visually interesting.

I was also more subtle when adding secondary details and props throughout the map. Most non-uniform, impractical or chaotic details were discarded and replaced with props or materials that were more uniform, symmetric and functional. The hedges and scoreboards, for instance, are both functional with providing depth and information, and are composed in a way that allows the player to focus on them when need-be. Panning materials and persistent VFX were either removed or pushed into the background to keep players from getting distracted.

 

 

Environments (continued).

Listed below are some images showing the progression of artwork in a couple other maps I worked on. Higher-resolution stills can be found on my Studio Work page.

Overview of the “Gaeana” level. This served as an expanded version of the Thunderdome map for players that wanted a more challenging experience. In this level there are 3 powercores to be defended, each at different areas of the map. Blue and Orange hues were used heavily to differentiate either side of the environment. It’s effectiveness scaled along with the increased usage of color on larger assets.

These images showcase the first powercore area. Since the map was so much larger than the first, a lot of time went into designing each powercore area in a way that kept the player from wandering away from the action before it started. One big help in solving this problem was limiting the view distance of the player in each powercore area. By the end, the map had become much more compartmentalized and players were more keen to hold their ground, rather than wander about, looking for enemies.

By the second iteration of the map, the aesthetic was becoming very chaotic. Similar to my approach with the Thunderdome map, I spent time organizing large and small details throughout the space to help distract the player less with large sections of unbroken patterns, detail and color.

 

The original, PVP Hardpoint map. The most challenging aspect of this map was coming up with enough landmarks to orient the player while keeping the number of unique assets down.

The central area of the map was a key location for player orientation.

Even on the lower level, the center room maintained a unique appearance.

Similar to Thunderdome and Gaeana, the color palette went through constant refinement to improve visual interest and player direction/focus.

 

 

Tutorials:

Tutorials: the bane of our team’s collective existence. Nothing is quite as depressing as watching tester after tester lose a game because they didn’t understand what they needed to do. VR makes this issue even worse, especially with people that are new to it. The level of immersion is so high, you quickly become unshakably laser-focused on what’s happening in-front of you, consistently. Any detraction from that is minimal, at best.

Getting players to focus on everything you need them to is very difficult and it becomes increasingly so as you add more attention-seeking bits of information. It took the team about 6 months before we realized we needed a stand-alone tutorial to go along with the main experience. Before that, this is what we started with:

 

First iteration of Omni Arena’s tutorial.

Splash screens and a shooting gallery! It was a start, but ultimately wasn’t enough. For the few players that paid attention at the start of the game and were already experienced with VR shooters, it did do a small bit of good. However, for the majority of our players this content was largely useless.

There were three big issues with this approach. The first issue was time. In total, our players were spending roughly one minute looking at or interacting with this content. With that short of an experience, most our testers didn’t remember the shooting gallery. Even more didn’t remember seeing the splash screens.

The second issue (by far the largest) was the lack of in-game audio and supplementary text. Without this additional feedback, we would often resort to removing the player’s headphones to instruct them manually.

The third issue was with the lack of continued gated progression and repeated instruction. I’ll explain this more in the next section.

All of these issues greatly contributed to what was, overall a very passive tutorial that provided more frustration than explanation. Because of this, we decided to take a completely different approach for the next iteration.

 

Second iteration of OA tutorials.

Emissive materials, VFX and bounding props help direct the player.

Overview of the equipment node.

Weapon interaction / Enemy overview in equipment node.

One thing we did do well was gathering feedback. We had plenty of great information to go off of which made the choice to switch to a gated, standalone tutorial experience a confident one.

The first thing we did was split our tutorial into separate “nodes”. Each node was a short experience that focused on one key element of gameplay. Health, weapons and game objectives would each be explained to the player individually through text AND narrative audio in these nodes. Each node was then broken up into “gates” that could only be passed by player action. This ensured we stood a better chance of our players focusing on specific bits of information exactly when we needed them to. We also made sure to put each bit of audio or text information on a loop. This allowed our players to take their time in each node, without the risk of missing important information.

Visually-speaking, I kept the exterior structures drab and put all of the visual interest in the player’s path. Emissive materials, particle effects, and framing pieces of architecture were all used in a way that would focus the player on a specific area immediately in-front of them and keep the player moving forward. Players were now able to easily identify their path and navigate through the tutorial without any hand-holding.

At the end of the day, tutorials aren’t something we want to spend a lot of time on, both as a developer and as a player that just wants to get into the game. Hopefully, as people become more accustomed to VR and, as we figure out a better pipeline for adding information into OA, we can revert to a less-obtrusive tutorial. But, as for now, it continues to be a necessary, yet effective evil. :]

Advertisement