Summary
The goal of Sorcerer School was to create a puzzle game based on interaction between player created spells and environmental set pieces.
Overview
Platform: HTC Vive
Project Duration: September 2017 - December 2017
Project Role: Project Lead and Systems Designer
Sorcerer School was planned to be a vertical slice of a puzzle game allowing the player to utilize custom spells to navigate a level. It ended up being the first time a project I worked on did not go according to plan.
Spell Crafting Design - Making the Player Feel Smart
From a design standpoint, the concept of working in VR was pretty much entirely foreign to me when I started working on Sorcerer School. I wanted to have an element of physicality in the casting and use of spells, since that was something that I really enjoyed as a new Vive owner. The original plan called for the use of image recognition to identify different player drawn icons, each of which would apply different effects and modifiers. With these, players could be able to create spells tailored to their own way of solving a puzzle. When a rope bridge needed to be lowered, the player would be able to conjure a sword to cut the ropes, or burn them away with a fireball. I wanted to the player to feel smart after having completed the puzzle, regardless of the way they chose to do so.
After QA testing our prototype, we found that players loved the idea of the custom spells and drawing with the controllers. Our fireball was a favorite, as it made a large explosion that sent our demo cubes flying. To improve it further, I changed the ball from a point and shoot projectile to a thrown object to take advantage of the physicality of VR. After that change, the fireball was the crowd favorite until the end of development.
The fireball spell definitely could knock over the wall!
Adapting to the Unexpected
The other thing that we found in QA was that our implementation of image recognition didn’t work reliably. In fact, it hardly worked at all. As a backup, I prepared a version of the spell crafting in Unity utilizing grid points rather than image recognition. Fortunately, it came in handy. Within a few weeks of starting, our programmer left the project for medical reasons, leaving just myself, another designer, and an artist. As the one with the most programming experience, I found myself at this point the de facto programmer for the project.
Having never worked in Unreal Engine before, it took me a bit to get into the swing of things. Eventually, I was able to recreate my efforts in Unity within Unreal. Unfortunately, in order to hit our assigned milestones, I had to cut the advanced “sentence” structure of the original spells, instead going with simple predefined icons which translated to specific spells. As a designer, I wasn’t particularly happy with it, but as a programmer I was very pleased that I managed to get something functioning before the deadline.
Lessons Learned
Throughout working on Sorcerer School, I learned a lot about managing a team working on a struggling project - I did my best to delegate a lot of the level design, documentation, and coordination with the art team to the rest of the design team, in order for me to remain focused on the systems design and implementing the game after the loss of our dedicated programmer.
One of the best things I learned was that maintaining a positive attitude in the team and in myself was probably the most effective thing that I was able to do as the project flopped - after spending time in team meetings keeping everyone motivated, I noticed a big difference in the amount of work produced.
On the whole, I’m happy to have learned some of these lessons earlier rather than later. I loved the idea behind this project both then and now, and it’s one that I’d like to come back to and try again in the future.
Developers
Jacob Foster
Designer
Michael Walker
Project Lead, Systems Designer
George Foss
Artist