As an experienced video game artist and car repair hobbyist, Alec Moody used his unique skills and experience to create Wrench , a VR game that teaches players how to repair cars. Starting out as a solo developer who lacked extensive programming experience, Moody relied on Unreal Engine’s visual scripting system Blueprints to create the programming backbone for the game. With this early foundation, Wrench garnered a lot of attention and even became an NVIDIA Edge Program winner Now in Early Access , the indie game has garnered rave reviews, netting a “Very Positive” rating on Steam. Wrench has evolved to become a two-man operation with the founding of studio Missing Digit. The developer recently announced that the game would be coming to the Oculus Store on March 13. We recently had the chance to interview Wrench creator Alec Moody along with programmer Jim Ashcraft. In the following Q&A, the two discuss how realistic and educational Wrench can be, describe how they got the models and graphics looking fantastic while keeping VR performance in check, and more.

In its current state, Wrench is pretty thorough at the nut-bolt level of car assembly. Right now we have the engine, suspension, and brakes for player service. And more systems are coming. Players that have no experience servicing cars are going to want to stick to smaller tasks (fluid changes, tires, etc.) and slowly work their way deeper into the car. The gameplay mode we designed operates with that in mind--if someone plays long enough to be comfortable replacing the engine internals in the game, they should be totally capable of reading a repair manual and doing basic service on their real-life vehicle.I’m interested in right-to-repair and encouraging people to repair instead of replace their possessions. One of my hopes for Wrench is that it helps demystify cars and teaches some applicable skills so that people can tackle their own maintenance. I imagine our customers are often people with an interest in working on cars, but who may have found the idea intimidating, or maybe they live in an apartment and don’t have a workspace or tools. Wrench provides a low-risk way to start learning. Wanting people to actually learn from the game has guided a lot of the design decisions.I want the game to be approachable for a wide audience, offer complexity and realism to satisfy car enthusiasts, deliver game content at a pace to maintain interest, and have interesting game progression reward the player for time spent playing the game. Balancing all of these is a challenge, and we have to be careful not to broaden our goals to the point of diluting some of the experiences. We feel like we are on a good path to achieving these goals, although some of the goals will not be met until we approach full release.We also acknowledge that Wrench is a game, and not a purely educational experience. Knowing this, we want to offer some ways for the player to "just have fun" that would likely be omitted from a purely educational product. Examples of this would be easter eggs, mini games, and toy-like experiences that may be present in the game.I was really enjoying VR and I have also wanted to build my own game for years. I scanned a few car parts for fabrication projects and thought it would be interesting to have a whole car to interact with in VR. A repair simulator seemed like a good fit for VR since spatial relationships and how things fit together is at the core of what VR is. I also wanted to build a project that pulled together my work and hobbies. I have done hard surface game art for a long time, have plenty of mechanical experience, a photography background, which was helpful for scanning [in components], and I can do basic metal fabrication, which was needed to build fixtures for scanning some of the more complicated parts. It occured to me that there can’t be that many other video game artists with that specific combination of seemingly unrelated skills. I took that as a sign to move forward.Yes, definitely. I want people to actually learn something from the game. We try really hard not to simplify the car. When I talk to car people about Wrench, I often describe it as a non-linear shop manual that lets [you] dry run all of the assembly. Rather than reading an index, finding the chapter, then locating the relevant paragraph, players just scan the part they want to know about, and they can see relevant diagrams and written install instructions. The assembly process is already detailed enough to be applicable. Fasteners all have torque specs, etc. As the game grows, we will be able to dive further into the specifics for maintaining each sub system of the car and implement unique part behaviors.Building the art was a challenge and the first thing I had to nail down before jumping into working on Wrench full-time. Dimensional accuracy is hugely important for a game like this. Typically, when cars are modeled for games or film, the mechanical components only look correct from an external view--they don’t actually fit together and proportions can be off without major consequences. For a game like Wrench, everything needs to actually fit together. To solve this, about half of the high-res geometry in Wrench is from scan data. The other half is clean models and sculpting done in Zbrush. For the stuff I model from scratch, I either measure out with calipers or I do a scan just to pull dimensions off of. Being confident that all the parts are dimensionally accurate lets me skip the block-out phase and focus complete attention on each part as a singular prop. I try to treat everything in the game as a hero prop, even seemingly mundane things like fasteners. Most of the effort is front loaded into the high-res art. The low-res models are usually from scratch remodeling, and the materials are built in Substance Painter.Our content is really atypical, so we are not following any of the recommended VR practices. Most VR games are static worlds with few dynamic actors. Wrench is a small static room and nearly 1,000 movable actors. Because of the nature of the content, dynamic shadows, and some way to dynamically occlude reflections plus ambient light is really important. The assembled car is basically a bunch of dark, shiny moveable actors crammed into a small shadowed space. It’s really easy for content like that to look like it is glowing. We are running the deferred rendering pipeline, primarily to sidestep early Z pass. This cuts our drawcalls and triangles in half. Temporal AA lets us run SSAO on the highest graphics preset without seeing a bunch of screen space noise in VR. For dynamic shadows, we are using a single super high resolution cascade. We also use screen space reflections to provide some dynamic reflection occlusion. Lower-spec VR players will tend to be drawcall and triangle-bound. Flipping off dynamic shadows for those players makes a big difference.Performance in VR can quickly become a problem due to the high-resolution and framerate requirements combined with rendering the scene twice; once for each eye. With a good amount of game dev experience between us, we have been aware of this from the beginning of the project, so it has always been on our minds. However, with only two of us on the project, we have had to choose optimization targets wisely as well as make a few compromises in areas that didn't have a large impact on visual quality.A couple notable optimization targets were dynamic shadows and mesh instancing, to help reduce draw call counts and improve the render thread performance. For example, we have a system to disable shadows on small parts [that] are installed. For small nuts, bolts, and washers, the visual fidelity gain from having these parts render shadows is almost negligible. Turning shadows off for these parts relieved a lot of draw calls, and we saw a noticeable gain in performance. Also to help relieve draw call count, we allow instance rendering of parts under certain conditions. This can be a challenge to manage, however, since we occasionally need parts to render using a unique material, or change the state of the part based on wear.We also provide basic video settings to allow people with a more powerful rig to take advantage of extra features and fidelity. In the future we plan on improving the video settings to allow users to really fine-tune their performance and visual quality to their liking.Yes. This has been one of the most challenging obstacles we have faced in creating the game, right up there with the high-level game design and some difficult technical requirements relating to the assemblies. The difference in input between VR and desktop is astounding. VR provides unmatched spatial awareness and the ability to precisely control position and orientation of the camera and motion controllers, but has only a few controller inputs. Desktop mode, on the other hand, provides a vast array of inputs from the keyboard and mouse, yet offers no immediate way to effectively manipulate the position and orientation of objects in the world.The reality of this is that almost any interaction in the game has multiple code paths: one for interaction using the VR pawn, and one for interaction with the desktop pawn. Every tool in the game is aware of this, as is every object in the world that can be interacted with. Maintaining this can be a challenge, particularly when functionality changes in a major way. We just have to be smart about where we spend time, making sure not to spend time polishing an interaction that may need to change significantly later.And it's a challenge that never goes away. Any new tool or interaction that is to be added to the game has to function in both VR and desktop modes. We try to share functionality where it makes sense, although this usually involves a compromise. In some cases we have lived with the compromise, in others, we develop more custom interactions.UE4 has provided a solid base for developing a VR game. The available template projects offer a good starting point for someone new to VR development. With time, I found the basic interface between game code and VR "input" to be very intuitive…Also notable is the physically based rendering capabilities of UE4. Combined with the exceptionally detailed parts that Alec produces, the rendering quality has allowed our game to look great in VR. Due to performance reasons, we can't take advantage of every feature available in the renderer, but we have still been pleased with what we have been able to achieve visually.For me, that would have to be Blueprints. I was able to get a prototype running, use that to get exposure, and then translate that into fundraising. Being able to do that as a non-programmer is fantastic. Aside from Blueprints, the fact that Epic actually uses Unreal Engine to makes games shows through. The feature sets fit together without any major gaps and you can tell that someone has actually thought through potential problems or encountered and fixed them before you. We also don’t have to use any third-party functionality, and aside from one small engine source tweak, we have been on a vanilla Unreal build.We have a lot planned. From a high level, there are three main development pushes in progress. First, we want to make the game more approachable. We want to make a casual play mode for people who want a simpler way to interact with the game without losing the visual complexity. After the casual mode is functioning well, we can start making the regular play mode more intricate. We’ll do more part specific interaction polish, add things like a silicone gasket maker, measuring engine tolerances, and generally give the player more things to do like simulated EFI tuning, and car alignments/setup. The last prong of development is really expanding the content library. More parts, more drivetrains, and a huge library of aftermarket components so players build cars to their own specification.We are on Steam at http://wrenchgame.com/steam . We also have a development blog at http://www.wrenchgame.com/ and on the Oculus Store at https://www.oculus.com/experiences/rift/1415202825245458/ . We also have a development blog at http://www.wrenchgame.com/