Unicycle Samurai

Preproduction Phase 1

MSU's MI 455 Game Design & Development II has three projects in which teams of 3-4 spend approximately four weeks ideating and prototyping a game concept, resulting in a "vertical sliver" of the game and a pitch presentation. Unicycle Samurai was developed in the second of these projects; for this project at the kickoff the instructor gave each team five randomly-generated three-word game titles, and the team had to come up with a game idea based on whatever combination of them we wanted. We scrambled the words variety of ways and suggested different games to each other; Enraged Unicycle Samurai was the clear winner although we dropped the first word as the project got underway.

The team collaborated on the game design as we didn't have one focused designer. We considered a number of possibilities including driving around breaking things, driving around landing tricks, and a local coop game where the unicyclists would fight zombies or other monsters, but quickly coalesced around a local two-player arena battle. We talked about rock-paper-scissors kind of resolution with attacks and blocks, but in the end the driving won out and we left the swords fixed like a joust.

As the programmer on the team, I developed a series of quick prototypes to prove out the idea; two are shown on the right. Because we were using unicycles, we really wanted a balance mechanic and the top picture on the right shows an early prototype focused on driving with one stick and balancing with the other. After testing several variations of this, we didn't find one that was satisfying and decided that the unicycle feel would simply come from how it drove with broad, sweeping turns. In the end, at the professor's suggestion I interpolated between the player's current direction and desired direction from the stick to give that sweeping turn; the lower prototype on the right was where I refined the turning and began to experiment with sword collusions.

At the end of the four-week project, we had a playable two-player demo in a Japanese garden and a single hit decided each round.

Preproduction Phase 2

For the third project in MI 455, if teams felt they had a strong concept from Project 2 or an earlier project they could continue to develop it, so our four-person team opted to continue Unicycle Samurai. After briefly experimenting with a split-screen, over-the-shoulder variation on the game we stuck with the top-down arena battler idea and developed a second arena, the graveyard shown on the right.

As programmer, in this phase I focused a lot on smoothing out the driving and getting a good overall feel. Because of how we did movement, we needed to fake gravity rather than relying on Unity's physics engine and I tuned this quite a bit on ramps and hills. I also built our power-up system in this sprint, including both the pickups and a pickup generator.

At this point in the game's development, powerups were entirely focused on movement — improving the speed and turning of the unicycle. Our character artist Al created a (horseless) Headless Horseman character in this sprint with our initial idea being that there'd be a different playable character matching each arena in the game. Because of concerns with scope and game balance, we decided not to include chooseable characters, but here we decided that if you collected enough power-ups you could become the Champion of the Arena and transform into that character with additional power and tha ability to take an extra hit.

This is the version of the game we brought into the final pitch process at the end of the semester. As the final project for the semester, we refined our pitch and then gave it competitively with nine other teams to get the green light to develop the game with a larger team the following semester.

Production

Over the summer, Unicycle Samurai got approval to continue into MI 497: Game Design Studio and our team swelled to eight members. In the course of the semester we were joined by a composer from the School of Music who did three tracks for each arena, and a member of another team from the class provided a bit of UI work to increase our bandwidth.

With the addition of two more programmers on the team, I stepped back almost entirely from programming the game to focus on my other role of Producer and to continue working on the Alt Controls. As Producer, I conducted weekly one-on-ones with each team member as well as discipline meetings with the art and programming teams and general team meetings; I also managed the burndown chart for each sprint and kept the team focused, communicating, and moving forward.

In our first sprint of the semester, a four-week sprint dedicated to creating a final vertical sliver and confirming the game's scope, I developed a comprehensive list of tasks and metrics to show that the scope was reasonable and achievable. We then had a four-week sprint to Alpha, a three-week sprint to Beta, and then a final polish and cleanup sprint. The team made it to release without any need to crunch, accomplishing everything we had layed out in our final Macro Document at the end of Sprint 1.

The final game is a local two-player arena battler with four levels (Japanese Garden, Spooky Graveyard, Cat Cafe, and Pirate Ship). For players who want to play solo, we also have a challenging AI opponent, and the game includes an effective tutorial for player onboarding.

Analytics

One area where I continued to program during the production phase was analytics; I began implementing Unity Analytics but found the current version cumbersome and limiting, as did the other teams in the class. Since I work in Learning Analytics, after discussion with the rest of the team we agreed I should implement our analytics through xAPI, a learning analytics standard. The Learning Analytics Platform where I work, Watershed LRS, allowed me to use a sandbox environment for Unicycle Samurai.

I used the GBLxAPI Unity package as a quick way to get the Rustici TinCan.NET library and its dependencies into the project, then sent customized xAPI statements to Watershed directly using the Rustici TinCan library. This allowed us to capture a greater number of data points at different events than Unity Analytics would have (see planning document), along with customized reporting shown on the right.