Building VR Games Like MageWorks: Part 1
Ever wondered what goes through a VR Game developers head? How they conquer technical obstacles never before encountered in entertainment? Ladies and gentlemen—we got the full scoop from Hadar Silverman. One of the VR creators from Earthborn Interactive, the company who developed MageWorks…
The Inspiration for Mageworks
The “MageWorks” project is an ongoing study in VR derived from several years of experimentation with the DK1 and DK2 from Oculus. After building a few prototypes with the DK1 (Stereoscopic + Rotational Tracking), and testing out possible ports to VR on the DK2 (VR + Rotation + Positional Tracking) with some of our existing IP, we were excited to grab an HTC Vive in June of 2016 to start studying room scale VR with positional tracking for both the headset and hand movement.
Upon reviewing the library of games on Vive’s initial release, we got our virtual hands wet with with a couple products, but mostly spent time in “The Lab” from Valve. It was a great way to study how different concepts were tackled in VR with regard to player perspective, player translocation, and the choice-making process in a VR environment when objects could now be directly interacted with using one’s real hands represented in virtual reality.
One thing I noticed in the library of games that were released on the market with the Vive was that there weren’t too many fantasy games with a “mage” theme at the time. I was (and still am when I have a rare moment to play) a fan of the Blizzard’s Diablo and Warcraft series, and was hoping to hop into a similar type of environment to see how they tackled various challenges of developing in VR. When attempting to port several types of features/mechanics on some of our existing IP into VR using the DK2, we realized that porting in general was problematic because of our natural limitations/constraints associated with operating software in a virtual environment. This process led me into the development of MageWorks.
When starting to build MageWorks, the concept was derived from the questions “How can you play the role of a wizard in VR? And how does the inclusion of motion control (referring to positional tracking of hands in VR) impact the way we game in VR in the context of wizardry?” Looking back at the various studies in Valve’s “The Lab,” among other products, I studied the physical movements a player was required to make when interacting with environments in VR. Unsurprisingly, simpler movements tended to be more effective with environment interaction. While more complex patterns coupled with gesture recognition created some exciting and innovative content, it was still a bit complex for such a new medium of interactive expression (at the time). The motion control we studied looked at various combinations of:
Motion Control + Crafting (Tilt Brush, Quill, Medium, SculptVR)
Motion Control + Roller Coasters (Roller Coaster VR)
Motion Control + Reading (Nothing really existed yet that we could find)
Concluding the study of existing content, I decided to move forward with the concept of putting the player into the role of a wizard wielding a staff in one hand and a book in the other. At the time of inception, menu systems in VR games were still very much in experimentation mode. The idea of creating a spellbook was intended to propose a way for a player to choose various spells. This would become the fundamental way the player could unlock pages or gain access to more powerful spells when they progress through the game.
The staff – on the other hand (pun sort of intended in retrospect) – would be a way for the player to cast their chosen spell. And ,of course, if a wizard game has a staff, then true to the nature of it’s genre, there should probably be a way to craft that staff.
Crafting quickly became an important part of the study. Finding a balance between virtual crafting with real-world physical movement – yet avoiding “watching glue dry” mechanics – was part of the focus during development.
Early Development Challenges
Given our past in developing content with UDK, we moved forward in creating the MageWorks prototype with Unreal Engine 4. The built in API would expedite the prototype creation process, however, their VR template had not yet been implemented into their binary release. This meant we needed to build a system to handle locomotion/player translation in VR, as well as an interaction system in some rudimentary way.
When considering locomotion in VR, it is also important to consider the scale of the environment. Scale directly impacts navigation in VR, the perception of the fantasy world, and the amount of detail that goes into the environment. With small scales, more of the environment is accessible, but the player could feel constrained. With large scales, the player could feel like they are in a free and open world, but detailing this environment could be time consuming. Plus, navigation could be challenging with teleporting being too frequent or analogue movement being too uncomfortable.
This leads us to probably one of the most important parts of VR development: market segmentation. We wanted to develop the game catered to the market that appreciates this genre. The problem we ran into was that during our several years of experimentation in early VR development, we found there was a pretty large divide between first-time VR users and more experienced users.
First-time users were still getting acquainted with what VR had to offer, while veteran VR users were ready for more advanced controls. Finding a medium here could be problematic because the medium could be too difficult for beginners, yet too easy for veterans. Additionally, the fantasy/wizard genre market population in VR gaming was somewhat low compared to that of other genres, like first-person shooters.
That’s all we have for you today, but we will be releasing Part 2 of this series next Friday! Leave your comments below and remember to sign up to our newsletter so you don’t miss potentially profitable VR trends.