Date: September 2016 – May 2017
Engine + Platform: Unreal Engine 4, HTC VIVE
Description and Details
Sword of the Sorcerer is a VR hack-and-slash game that pits the player as a knight against a horde of undead skeletons. As the knight, the player must defend the wizard’s tower by any means necessary using a variety of weapons and spells at their disposal to do so.
For this project, I filled several roles. During the first semester of senior year, I acted as both the Lead Designer and the Producer for the game, while during the second semester I solely tackled the Lead Design role and also assisted with Gameplay Design.
While this game did act as my senior project, our intent for the game was simply to create an amazing, immersive and engaging VR experience. It should be noted that before the development of this game, none of the members (originally) had any experience developing a game in a VR platform for any engine available.
In September of last year, our team came up with an idea for a VR game. It started as a sword and spellfighter VR game but then changed to a “Knight on a Bridge” VR game that focused on comedy and combat a la Monty Python. It was only after a great degree of delegation and discussion that the original “Knight on a Bridge” prototype became Sword of the Sorcerer with the gameplay that it has today.
A big role that I’ve played throughout the project is that of a Gameplay Designer. Most of my work involved designing how the player’s interacted with the skeletal enemies during gameplay. While I am not directly responsible for programming any of the interactions between player and enemy, I am largely responsible for much of the interaction concepts. There were a few major components of the gameplay design that I was present and responsible for that I’d like to discuss here: the three-lane system and the crystal system.
The Three-Lane System
I’d like to stress right off the bat, I’m not responsible for this idea. No, in fact, one awesome professor by the name of Nate Walpole is actually the one who came up with the idea for the three-lane system. Originally, our game was intended to be about a literal representation of the Monty Python Black Knight harassing travelers of all kinds on a single bridge. While our original idea would have been fun, we were trying to go for an arcade kind of feel and it just wouldn’t have worked for that kind of gameplay. So, Nate devised that we move from our original single-bridge idea to something like this:
After its initial conceptualization, this three-lane framework became the basic foundation on which our game stood. Now, you may have noticed 6 floating white crystals above each of the platforms in the above picture and that’s where the aforementioned crystal system comes into play. However, before I get into that, I’d like to introduce it with a concept that is incredibly important to how our game functions.
A big part of getting across the arcade-style gameplay that we want for our game is pushing a sense of urgency on the player. Nate’s original idea certainly helped to provide a much greater sense of urgency than we had with a single-lane system, that’s for sure, but it still wasn’t quite there. In fact, simply giving the player three lanes full of enemies to defend actually made the game too hard. We needed to give both the player and the enemy a second objective in order to both balance out the difficulty and the sense of urgency that we wanted the player to feel. Enter:
The Crystal System
The crystal system was something that I came up with as an answer to our balance problem with the game. Basically, we placed a crystal above each of the six platforms that the player can teleport to. Now instead of making a beeline straight for the tower core crystal, the enemies are required to destroy the platform crystals first. This not only gave the player something else to do other than just stand there and wait for the enemies. They now had a reason to move from platform to platform and the crystals themselves also provided a buffer for the enemies to slow them down a bit on the way to the tower’s main core crystal.
It’s quite easy to say that this was a fantastic learning experience both for me and all of the other members of my development team. During the first semester, none of us (the original team of 4) had ever worked on a VR game before. It was a challenging experience, despite using an engine we all knew (Unreal Engine 4), learning an entirely new technology/platform. Not only that, I’d certainly say that it was a risky move as well but one that has certainly seemed to pay off. In light of this challenge, though, I’ve definitely learned several things that go along with developing a game for a VR platform.
Polish First, Add Later
In the early stages of the first semester and even the second semester, we as a team kept saying things like “this would be cool” and “wouldn’t this be awesome to get in the game?” Unfortunately, as we learned the hard way, adding things in one after another because they seem cool doesn’t work well in VR. In games that aren’t being made for a VR platform, it’s at least easier to get away with that. However, in order for a VR game to be immersive and play well, it needs to have an incredibly high degree of polish. That means that we could really only afford to add one thing at a time and then polish the hell out of that one thing as soon as we get it working. Unfortunately, this also meant that we were able to make progress seemingly slower than other teams that were not making VR games, which at times could seem a little disheartening.
The Bugs are Bigger ‘Round These Parts
Sure, bugs are going to happen in any game during the development cycle but from my experience so far of working on several games outside of the VR space, I can say that it has been far easier to break VR games than normal PC or console games.
The Phrase “Just Make it Work” Rings Much Truer in VR
Once again, in regular games, it’s a bit easier to get something in after making sure it’s already polished up. On the other hand, it’s really impossible to do so in VR. If we wanted to add something new to the game, we first had to make sure what we wanted could be done at all. Following that, we’d need to get a prototype of this new element to a testable state within the game before we can afford to do any polishing at all.
Despite all the ups and downs that we’ve had throughout this game’s development, I can absolutely say that I’m happy we went forward with this idea. I feel as though I’ve learned more than I could about my craft through the development of a regular game (as a senior project) and I also feel that I’ve come out as a better designer because of it.