Personal Reflective Post-mortem

This has been the toughest and most rewarding year for me so far at Champlain. I loved working on Speed Scoop with Rachel, Tim, and Jay, but I just didn’t frontload enough effort over the summer and in the fall to get the game past the end of the semester cut. I’m still immensely proud of our comeback and that we were able to present it to our peers.

I would’ve been thrilled to work on any of the ten projects that moved forward because they’re all fucking incredible games. Pardon my french, it’s true. That being said, I wouldn’t have it any other way if I could go back and pick which team I was assigned to. Sword of the Sorcerer was a perfect fit and I’m thrilled that my name is on it. The art, code, sound, and project management were all top-notch the entire semester, but the people were what really made it all come together.

No one on the team ever showed up with a negative attitude. No one started drama or attacked anyone else, even when stress levels hit a record high. Everyone did good work, listened to my input, and gave me all the help I could ever ask for when it came to diving into a new codebase. At the end of the day, making a great game is important, but being happy and kind are too. I saw some other teams and peers forget this as the senior show creeped closer – which is understandable – but our team stuck together through thick and thin.

I had a rough start in Production this semester. I’d never used Unreal Engine, SteamVR, the HTC Vive, or Unreal’s Blueprint system before January. Completing the smallest task meant reading through dozens of webpages and files for hours. This was frustrating for both the team and I. But practice makes perfect, and after a few work sessions I really started to get the hang of our programming pipeline.

After becoming comfortable with the codebase, Sword really opened up for me. I prototyped a scoring system, created the core wave spawning system which drives gameplay, built an immersive VR environment in the weapon room, learned about menus, motion controllers, navmeshes, and more, fixed endless amounts of bugs, and then finally polished the game into something that the entire team is proud of.

Setting up our booth in the CCM gallery and watching people play the game were extremely rewarding experiences. A little girl sat and watched six people test, mirroring their movements the whole time and jumping up and down with excitement. A grandmother strapped on the headset and shrieked with surprise when she turned around to find an army of skeletons. The entire gallery erupted in applause when Eva beat all nine levels after several hours of no one being able to. This has been a great year, and it’s been about so much more than just the academics.


Polish & Juice

The entire team has been hard at work for the past week and a half or so adding polish to Sword of the Sorcerer. In the game world, polish is an umbrella term that encompasses parts of the development process which are not critical for gameplay or systems to function correctly, but make the game feel more satisfying, immersive, consistent, and fun to play.

BioWare’s Mark Darrah, executive producer of the Dragon Age franchise, says that polish contributes to the “consistency of experience – [it’s] when everything comes together in a cohesive whole.” Epic’s Rod Fergusson, executive producer of Gears of War 2, defines it as “the last 10 to 20 percent of effort where everything in the game is now working. Polish is extremely important, as it has the ability to take a good game and make it great.”

I wholeheartedly agree with both of these professionals’ definitions of polish. The bulk of Nick, Kelly, Stefan, and I’s work was creating back-end systems, writing AI behaviors, making things easy to modify for the design team, fixing bugs, solving VR issues, implementing weapons, and making sure FPS never dropped below the nausea threshold.

But no one playing the game could tell that I spent two dozen hours fine-tuning the system which loads wave data from .CSV files. When the programming team spent an entire Sunday fixing the navmesh, QA testers barely noticed. This is the problem with programming – you can do a ton of work that needs to get done, but it doesn’t improve the player’s experience. That’s where polish comes in.

It’s crazy how much this process is improving our game. Bone-crunching sound effects make testers smile under the headset. Everyone wants to use the flame blade spell to knock armor off the anti-paladin. I know that I restarted the game at least ten times after the art team added in the cupcake models just to keep taking bites out of them. Sword was a well-made game with no critical bugs when we reached feature lock. But now it’s a kick-ass VR experience that makes people jump, scream, smile, shout, and want to keep playing. It’s surreal to see it all come together so well at such a late stage in the semester.


Feature Lock!

As mentioned in my last blog post about fun food interactions, the Sword of the Sorcerer team is now in Feature Lock. Feature lock means that no new systems or gameplay elements can be added to the game – all the features are locked in and won’t be changed at all before the Senior Show in a couple weeks.

This sounds scary at first glance, but it’s actually quite a relief. Before the team got together to down-scope the feature list about a month ago, there’s no possible way that we could’ve added everything our designers had envisioned before the end of the semester. Because we were able to refocus on getting the important parts of the game in on time, everything worked out well with minimal crunch or stress on the programming team.

Stefan has finished up the tutorial. Kelly did a ton of work on the shield UI, which looks fantastic. Nick is done with the Skullsploder and Antipaladin enemy AI. I’ve finished expanding the wave system to accommodate these new enemies as well as the weapon room with all of its fun interactions. (The boring cubes from the last blog post are now cupcakes! It feels super satisfying to eat them.) With all core features of the game complete, we are now a week into the polish phase of development. Next week’s blog post will go over what we are adding to make the game really pop – particles, more sound effects, dynamic armor collision, emissives, art passes, and more!

The Weapon Room: Fun Interactions


This week is feature lock for Sword of the Sorcerer and the other nine senior games scheduled to be presented at Champlain’s Senior Game Showcase on April 28th. The team will be working hard and polishing for another two weeks, but as of this past Wednesday no more new features will be added to the game. Stefan, Kelly, Nick and I managed to squeeze in nearly everything on our designers’ feature list! Now that gameplay is all done and locked down, the programming team has been fixing bugs and creating fun toy interactions. Below is an example that Stefan and I created last week – consumables!


The red and blue blocks are placeholders which will be replaced with tasty beverages / food items after the art team makes another pass over the weapon room. Cupcakes and rock candy are popular ideas at the moment. Stefan and I created the core interaction this past week – the consumables only spawn once every three or four waves. The player can eat the red box to restore all of their health or the blue box to repair any damaged crystals.

Our Senior Production professor Ben Throop (who created Headmaster, a flagship game for Sony’s PlayStation VR) told us early on in the semester that some of the most satisfying and immersive virtual reality interactions revolve around eating and drinking. We were brainstorming trying to think of polish ideas and how to fill out the weapon room. The first idea we wanted to implement plays off Ben’s great tip and is much more enjoyable than we thought it would be!

I’m looking forward to adding more toy interactions (especially in the weapon room) in the next two weeks. We also want to pay careful attention to player feedback and particle effects, which is what I’ll be tackling next.

The Weapon Room

This week, I did a ton of work on the weapon room for Sword of the Sorcerer. The weapon room is a cool little environment that the player can return to in between waves to swap weapons, beat up on training dummies, or drink potions. It acts as a physical menu screen, breaking up the monotony of playing the entire game in the same area.


I really liked working on the weapon room because it adds a layer of depth to the game. It’s tons of fun to beat up on skeletons in the abyss, but virtual reality games should feel like adventures to different worlds. When the weapon room is fully textured and outfitted with toy interactions (drinkable health potions, books with flippable pages, ragdoll skeletons hanging from the ceiling, etc) it will really bring an element of intrigue to the game and help players feel like they’re really inside a wizard’s tower, not just playing a game.

The weapon room has been fully tested and integrated with the old menu system. After the programming team merges it, we’ll be working on other critical parts of the game that need to be done before feature lock. High on the list are a 3D sound engine, a tutorial level, and player feedback for important game events, which is what I’ll personally be tackling.


After Stefan and I painstakingly merged the wave system, Ben and I started investigating Steam. We really want to get our game on Steam to share with friends and facilitate a smooth VR experience. The Steam Partner program utilizes SteamPipe, a complex pipelining tool for packaging games into Steam-compliant “apps”. I spent a couple hours looking through the SteamPipe documentation at Ben’s request last week.

Because steam has become so popular in the last five years, there are quite a few hurdles we have to overcome in order to publish on the platform. The most notable hurdles are a $200 deposit and a slew of legal paperwork. After exploring the process a bit more, it’s obvious that we need to do some more formal planning and structuring before we can approach the Steam Partnership program, let alone look into building through SteamPipe.

With Steam on the back burner, I’m free to tackle another large project. Stefan has tasked me with creating the Weapon Room, a cool little transitional stage between waves where the player can switch weapons, adjust options, and drink potions. It may seem small, but I think if we do this right having another detailed VR environment for the player to explore will add depth and intrigue to the game.

Core mechanics, waves, & blueprint limitations

This week, I’ve been working hard on the wave system for Sword of the Sorceror. The entire game is waves of skeletons coming at you, so this is an important system. I ran into several roadblocks along the way, but the team was able to work around all of them and I’m very happy with the final product.

When I joined the team, there was not a wave system. There was a data structure manually assigned to each spawner actor in the Unreal editor. The data structure allowed designers to specify the number of armor pieces that the skeleton should spawn with and how long to wait until the next spawn. This implementation could only spawn one skeleton per spawner at a time, had to be tweaked in the editor by the design team, didn’t incorporate waves, and left a lot of features to be desired.One of my first big programming responsibilities was redesigning this system from the ground up. The pillars of this redesign were as follows:

  • The design team shouldn’t have to delve into an obscure widget in the editor to adjust spawn behavior.
  • Enemy spawns should be grouped into waves.
  • There should be support for spawning multiple skeletons at a time.
  • Each spawner should be able to read in data from its own file, making for more dynamic gameplay.
  • The player should have a break and be able to switch weapons between waves.
  • The design team should be able to extend, create, or manipulate spawn logic very easily.

With the above set of requirements, I set about creating a robust wave system for Sword of the Sorceror. Each spawner loads in data from its own unique .csv (comma separated value) file. The files contain five columns – Wave, InitialDelay, NumArmorPieces, NumSkeletons, and TimeUntilNextSpawn. These fields are fairly self-explanatory. I had to restructure the SpawnDetails data structure in Unreal to accommodate these fields, which was straightforward enough. But then I had to delve into the spawner blueprint and completely rewrite it, which was…. less straightforward. But after a week and a half of trial and error, I’m proud to say that they wave system has been merged into the build and is working very well!


This week, we’ve made some important decisions about the development of Sword of the Sorceror. The team was getting carried away with ideas of new enemies, weapons, shifting environments, spells, and gameplay modes. But when it comes down to it, our game is built around a single core mechanic: wailing on skeletons with weapons in virtual reality. We’ve agreed as a team to refocus our efforts towards making this vital interaction feel as satisfying as possible – the game just isn’t compelling without it.

So we still have a ton of great ideas as far as new mechanics that would work well with the game, but we’ve officially moved them to the “stetch-goals” category and assigned each discipline specific tasks that contribute to our new goal of polishing the combat mechanics. Artists are polishing skeleton textures and animations instead of making new environment assets. The design team is working on the hammer, our second weapon which smashes instead of slashes. Programmers are focused entirely on sword mechanics, enemy navigation, and making playing the game feel good.

Of course we won’t really know if the game feels good until we get it to QA, which is hopefully happening this week. But I have high hopes – ever since our formal refocusing effort has begun, we’ve been picking up steam. By devoting all of our energy and talent to one very specific goal, we have the potential to make some huge strides in the upcoming weeks.

Nose to the Grindstone

Now that we’ve all gotten used to eachother and the game, work has really gotten underway. Kelly, Nick, Stefan and I work straight through every team meeting implementing features and fixing bugs. This week, we made progress on the tutorial, enemy AI, navigation, UI, spell mechanics, and the backend of the game. I’ve been working on a scoring system. It’s not too difficult to implement, but it’s definitely a core component of any feel-good arcade game.

I think it would be super satisfying to have combos and streaks. Like hitting four skeletons in one fell swoop would give you a huge bonus, and hopping between platforms without missing a beat would build a combo multiplier over time. George and Chris are open to the idea, so I’ll probably be working to extend the scoring system into something much juicier when I finish it. Gotta get back to work!

Easing Into Virtual Reality

Today is our team’s third work meeting this semester. We’re starting to pick up steam, getting used to each other and the development process. Developing a VR game presents a unqiue set of problems that require unique solutions. For starters, we can’t write any C++ code for the game. Unreal’s VR system is 100% blueprint based.

Blueprints are Unreal’s visual programming system. Like Scratch, users drag blocks onto the screen and link them together in sequence. Execution then steps through each block. Blueprints are powerful and flexible, but they’re no substitute for real code. Especially when it comes to writing a full-fledged 3D game. For example, this is a single function that spawns enemies:


That’s one function of one class. Like most games this size, our code base consists of dozens of classes. The biggest struggle for me so far has been trying to step through game execution in the blueprint editor – there’s just so much code that it’s hard to understand everything.

There are also many other interesting issues to solve when working in VR, such as how to move around the level without walking, how to direct the player’s attention without breaking immersion, and keeping FPS above 60 to combat nausea. Thankfully, the team has been doing a great job helping me get up to speed. Today I implemented a data-driven spawning system that pulls spawn data from a CSV (Comma Separated Value) file. This will help our designers quickly test changes without having to muck around deep inside the editor.

Stefan and I implemented ragdoll physics last week, which is just plain awesome. Instead of collapsing to the floor when struck, enemies now fly in the direction they were hit! It’s super super satisfying to fling a skeleton in a 50 foot arc into the abyss. The game feels and looks better after every iteration – I can’t wait to see what we can accomplish in the next few months!