Overcoming Graphics and Design Challenges in Across the Valley

We are FusionPlay, a small Indie studio, based in Germany, that has been developing VR games since 2016. We released our first title, “Konrad the Kitten”, for Oculus Rift in 2018, followed closely by the “Konrad’s Kittens” update in 2019. Lately, we’ve been working on our newest title for Meta Quest, “Across the Valley.” Let’s talk about some of the graphics and design challenges and techniques that we used in “Across the Valley.”

For “Across the Valley,” we began with an intensive experimental phase to determine the game’s look and feel. We explored various technologies and their effects on the player in VR, including digital watercolors and virtual crayons.

It’s not uncommon for 2D games to be entirely hand-drawn and for some 3D games to mimic a hand-drawn style. However, this technique is not common for VR games. Many design methods established for non-VR games do not translate well to the virtual world, because the gameplay environment is immersive and not simply a 2D projection.

We collaborated closely with Michael Kremmel, a shader programmer who built a customized version of his toon shader for our game. This tool fits our special requirements and integrates into our own technology stack. The result is a blend of flat cel-shading with automatically generated edge lines, which is key to our signature look.

The key aspects for this look are clearly visible in the image above. All elements are shaded flat and all the textures are hand-painted. This makes them look more “painted,” and less realistic or generated. Additionally, the shadows have a scribbled look, as if somebody sketched them with charcoal or a pencil. This "sketching" is animated in real-time, with shadows that are constantly redrawn.

As for the above-mentioned computed edge lines, they are an option on PC-based VR hardware but they are not recommended for Meta Quest apps. As the outline shader ultimately renders every object twice, we could double the performance by deactivating the outline. Although this removed some of the identity of the artistic style of the game, we knew we needed to do this. The alternative would have been to save polygons somewhere else and drastically reduce the visual fidelity. We surely didn't want to save polygons on the cute animals! Our solution was to partially paint the outlines on the textures themselves. This solution, in tandem with the flat shading and lighting, complements our visual style and justifies the performance savings. The combination of all these methods allows for a look similar to non-VR games without generating distracting visual artifacts in the virtual world.

Rendering two images - one for the left eye and one for the right - at 90 frames per second for VR was the project's greatest challenge. Traditional games only render a single image at 30 or 60 frames per second. To achieve this, we implemented a custom Level of Detail (LOD) technique. Usually, LODs are used in Open World games to automatically render objects further away with fewer details. In "Across the Valley,” the player doesn't move freely but is always at one of the fixed action points. Because players can still move manually in VR, a traditional LOD system would have to constantly monitor the LODs and swap out meshes at specific distances. For players, this would look like objects popping up or abruptly changing shape.

Our system determines the LODs for all objects at the moment the player changes the location. It then freezes the LOD management, as long as the player does not jump to the next action point. This unique locomotion approach allows us to avoid pop-ups and save 30% performance by ensuring new meshes and textures are not constantly pushed to the graphics card.

When porting the game from PC to Quest, our LOD management helped us to reduce the amount of polygons used. As nearly all of our objects have 3 different meshes to support 3 LODs, we blocked our most detailed LOD0, set the LOD1 meshes as defaults, and altered the threshold for when we show LOD2 meshes. This system saved a huge amount of triangles and vertices without sacrificing the overall look and feel.

The most intensive visual in “Across the Valley” is the outdoor scene. The grass that grows around the farm therefore had a big impact on performance. In the PC version, you can see grass as far as you can look. For VR, this would cost a lot of performance. For Quest, we lowered the visibility range and the density of grass. To increase performance, we reduced the grass by 95%, but placed each tuft of grass by hand to ensure maximum coverage and an authentic, non-generated appearance.

Motion sickness is a common challenger for VR developers. If players feel sick while playing your game, they likely won’t play again. To prevent motion sickness, we decided to implement an action point system as opposed to the default free locomotion system.

Various "action points" are scattered throughout the game where the player performs specific actions. At every action point, everything required to perform the task is within reach of the player's hand. The player therefore does not need to move their position in the real or the virtual worlds. Each action point automatically aligns the player in the correct direction, eliminating the need for artificial rotation. With this system, players never need to move between points or rotate themselves artificially.

Designing a game around such an action point system is not a trivial task.

The gameworld layout must consider all the action points. Each action point needs to help the player navigate quickly through the work, have a clear sightline to the next action point, and have all the required items for each task in one location.

For navigation, we ensured players would not have to jump more than two times within one area to reach the destination. With a smaller number of jumps, players won’t have to blink repeatedly.

For visibility and sightlines, each action point and associated world elements were oriented in a pragmatic manner. For example, when working on the fields, we rotate the player 180°, ensuring they are looking towards the farm and not away from it. In some instances, we integrated signposts as shortcuts to get back to areas that are behind the player as a backup measure for action points that don’t fit all the criteria.

For each action point, we needed to consider the task(s) a player would be doing and the tools/devices/props (we call these interactables) a player would need to perform that action. We tried to place all the important items in a 120° arc in front of the player. This ensures that when a player looks straight forward, nothing is beyond 60° to the left or 60° to the right.

To define how far an item should be from the players, we created two dummy players, each with two spheres at shoulder height. The radius of the spheres resembles the length of the arms. We create one dummy based on our smallest employee and one based on our tallest employee, both with some buffer to reflect very short and very tall players. As long as all interactables are inside the spheres of both dummy players, real players can reach them too.

Ultimately, knowing your target audience will help you determine if it’s worth designing such a system. If your audience is primarily made up of hardcore VR fans, they probably won’t have any issues using smooth locomotion or free teleportation. Setting up default locomotion systems is much faster and easier, giving you more time to focus on other features of the game. However, if your audience is casual gamers, it could be worth taking the time to design an action point system.

Every action on the farm is an activity that the player performs with their own hands. All actions are incorporated into automatic microgames. Every time the player performs such an activity, a microgame automatically starts. This approach allows score hunting and a skill-based result without interruptions to the gameflow that minigames often bring.

Instead of a "Press Start” or a countdown, the microgames run automatically while the player is completing the activity. For example, as soon as the first seed hits the soil, the microgame begins, the music changes, and the wooden sign next to the field shows the microgame status. Once all the seeds are scattered and the seed bowl is empty, the microgame automatically ends. With an automatic start and stop, we avoid any friction that an artificially embedded minigame would create.

During a microgame, the score and progress appear on a wooden sign next to the field. The results of the microgame are purely based on the player's skill. At the end of a microgame, players can discern their success directly by the score on the wooden sign and indirectly by the reaction of the plants.

This concept can easily be used in other games as well. Instead of having an explicit minigame that is started manually by the player, developers can track player activity and start and end the minigame automatically. As a general tip, developers should ensure a player’s success or failure is immediately discernible. We achieved this by having plants either grow or die, helping players realize “because I did good/bad at this, that amount of plants spawned/died.”

The audio design of “Across the Valley” supports the relaxing atmosphere that permeates the entire game. The music was exclusively composed by the state-of-the-art audio service provider Dynamedion, who has contributed to many AAA titles, like Mortal Kombat 11, Company of Heroes 3, Age of Empires 4 and Total War: Warhammer.

An important element of the audio design is a custom sound manager capable of dynamically blending different versions of a music piece. This system accomplishes two things simultaneously: real-time adaptation of music to the situation and dynamic transitions between music pieces.

The sound manager is used in the fields to adjust the music to the current pace of the game. When the player is active in one of the fields, the music becomes more intense. Once the player finishes a task, like watering plants, the music assumes a calmer tempo. The system doesn't always transition uniformly but insteads dynamically selects an ideal transition between the two music variations. If there's a tension point (e.g., a drum roll) in the current piece, we’ll insert a sharp transition. If there's no tension point nearby, the music pieces will blend more smoothly.

When listening carefully to the example video, you’ll notice that the first transition (from A to B) is shorter than the second one (from B back to A). This length is determined by the proximity of the next tension point. In this example, the player has just finished the game a few milliseconds after a tension point in the music. As it just missed a tension point, the engine took the full maximum of 3.5 seconds to face back to the calm (A) version of the music.

As a VR dev, you will very likely face problems that normal game developers don’t have and may not even know about. “Across the Valley” was in development for more than three years. We wanted to build a unique experience exclusively for VR and this required us to get creative with the issues we encountered.

We hope you enjoy playing “Across the Valley” as much as we enjoyed solving the challenges we encountered during development. The game is available for half the price during an initial launch period, via Meta Quest App Lab!