Building VR Games Like MageWorks: Part 2
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…
Pre-Launching A VR Game
Minimum Viable Product (MVP)
The first playable version of MageWorks focused on the combat system. We built mechanics that allowed the player to flip through their spellbook in one hand, and based on whatever spell was open in the book, the player could use their staff to cast their spell. The spells were divided into several classifications: long-range, short-range, area of effect, pet-based, and defensive.
This corresponded with the typical language of spells offered in most popular fantasy-based games. A player could then use their staff to cast their chosen spell. The short-range spell also required the player to include some additional motion to their cast either by raising their staff up in the air,or lowering it to the ground. All shields walls (the defensive spells) were also cast by players touching the ground with their staves and using the action button to raise the shield wall out of the ground.
A “home level” (Mage’s Quarters), as well as five additional levels, were planned, each reflecting the schools of magic players could unlock. However, only three of these were available at launch to test how intuitive map travel was. At the time, map travel was based on selecting a 3D icon located on a map board in the game. This method would quickly change soon after release based on development plans to create an observatory system allowing players to stargaze and look for constellations. The constellations would then be used to travel to a desired level. Constellation shapes reflected the type of magic used in the level they could travel to.
With only a handful of spells available on first release (each representing a type of mechanic that would be built out during development) and a couple levels to test, players could get a general feel for how the game worked and what it could offer in the long term (minus the crafting element, which was included in an update a few versions later). A rudimentary AI system had also been built, which included a basic “skeleton” enemy type with melee combat and ranged combat.
The story behind the game was a parody. The player was in the role of a wizard who just graduated wizard school and would need to fight enemies to collect gold and pay off their wizard school loans (learning a trade skill in the process through staff-crafting tutorials). Quite topical given the news at the time regarding students finishing college with massive debt, yet having a tough time landing a job in their educational focus.
Feeling pretty good about the prototype we had put together, and having been “greenlit” on Steam (Steam Greenlight still existed at the time of development), we released into early access to start building our community.
At first I was kind of surprised this didn’t receive more positive feedback because, when testing with folks locally, people were pretty excited about it. As I read and responded to various comments, I began to see why the reviews were what they were. First, we released into a market where consumers were getting frustrated with VR concepts and wanted to see more finished products. Second, the prototype systems we developed thus far worked well when testing because we were talking directly to our testers (which were composed of family, friends, and locals) but ultimately were difficult to understand by new users without any guide or tutorial to help them.
Prior to release, the VR consumer community was beginning to express their concerns about VR having a lack of finished content. The cause of this from a developer or business standpoint made sense. Some of the bigger names in game dev were hesitant to invest a lot of time and money into VR because the market size didn’t justify that kind of commitment. This meant that the first round of high-end products was really an investment designed to drive market adoption of VR. A lot of people at the time were asking “Is VR here to stay?” In short, the answer would be a definitive yes, but market segmentation made it difficult to determine how it would be adopted, especially beyond gaming. MageWorks was a self-funded side project at its inception, so development was expected to be slow on my end of things.
Based on community reaction, and the quickly evolving VR tech, several of the prototype systems we developed ended up being scrapped. By the time we had finished a few of our systems for integration into the game, the VR tech scene had already advanced. New and better hardware was on the horizon, VR templates were now integrated into middleware, and we started to see somewhat of a standard interface and interaction system across multiple genres of VR games and applications.
The VR templates tackled player movement in VR in a different way, which we found to be much more effective (and cross platform compatible). While the player would still be teleporting from point to point, under the hood, the system that controlled this was overhauled on our end. We also saw menu systems were more prevalent in VR products now. We had initially tried to integrate the menu into the environment but found that there was too much discontinuity in the environment to make this an effective solution. So we began to migrate our menu system into a stand-alone traditional menu.
For combat in MageWorks, we saw that players loved spell casting but didn’t really enjoy flipping through a book when under pressure to cast a spell, so we knew that we needed to change the system to be more accessible. With a crafting system on the horizon for the game, we also needed to scrap the current staff/stave feature in preparation for the crafting element that would be introduced. Instead of a single stave, players would have a staff with interchangeable parts.