Once your project has wrapped up, loose ends have been tied, and the game is out in the world for people to play, it’s standard to look back on how things went in the form of a “post-mortem.”

So, I invite you to join us as we look back at our successes (and failures) to see what was done well, what we’re proud of, and what lessons we learned. It’s been a long journey and there’s a lot to unpack, but the team worked hard and those results deserve to be mentioned! Finally, we’ll end on some thoughts as to the future of Buggy AllStars, and what we can expect in the next year!

I. A Quick (Deep) Dive into Virtual Reality

Taking it in chronological order, it’s important to go back to where we started: in Virtual Reality. Although we never got to see the game fully realized in VR, we made a substantial amount of progress:

• We iterated on controls to find something that was intuitive and contextual.
• We did a quick dive into user and VR accessibility research to understand our domain and posit ourselves in the golden center to reach VR aficionados, Buggy enthusiasts and racing genre fans.
• We had high resolution models of all university buildings, buggies, pushers, and most of campus laid out and ready to go.
• We regularly attended 6 out of 6 of the weekly playtesting sessions leading up to Spring Break, plus a session held during the Global Game Jam. This was crucial in helping us iterate on the design of VR Buggy AllStars.
• We established a working level of communication between Leadership and the triforce of Art, Design and Programming Teams. 
• By Spring Break, we had reached a Beta level of progress for most departments:
  • Art assets were largely complete, only missing texturing.
  • Core controls were functional, although missing AI racing mechanics.
• We planned out what the physical attraction experience would look like at Carnegie Mellon University’s annual Carnival celebration.
• And, perhaps most importantly, we learned a lot! From how to make racing work in VR, to creating a functional pipeline, to adapting a variety of softwares to our needs, the first half of the project was an experiment in education.

As is always the case in such a large project, there were some aspects of the game that were falling behind, and other concerns that we hadn’t quite sorted out:

• How would we disseminate the game to a larger audience? Our initial platform of choice was X, so we intended to optimize the game such that it could run on an Oculus Quest. However, reaching the larger audience outside of Carnival was a stretch goal that required more work. 
• Some assets — like the player buggy and much of sound — were falling behind in the pipeline: since they weren’t finished when they were scheduled to be, they fell to the wayside as more and more piled up. 
• We had a lot of testing we wanted to do before feeling comfortable that the game would be accessible and intuitive to everyone — the UI wasn’t reading perfectly well for everyone, and there was talk that we would need a menu system for teaching controls.

II. Pivoting to Arcade Racing in WebGL

With the developing realities of Covid-19, we realized we needed to radically shift our approach. This is when we made the platform pivot to web-based experience and restructured the class to remote, indie-based game development. Through the continued dedication of our teams, we were able to weather our trials and push Buggy AllStars towards the high quality release we were hoping for:

• First off, we succeeded in completing a game after a major pivot, during a pandemic, and while hitting the bulk of our design goals! That alone is a major success, and something we’re all proud of!
• A lot of the design research we had made into making an Arcade port was used to ease the transition into WebGL, resulting in a very quick turnaround time between design and implementation.
• We had a fully-populated world of textured art assets, effectively hitting every item that was on our list at the start (including Motion Capture animations for all of our models)!
• We collaborated with several others outside of the classroom to make sure the project was a success. In fact, we worked with so many different people that we built a credits page on our website just to thank them all!
• We even reached a number of stretch goals, including “skins” for the Super Buggy, the ability to choose which buggies you race against, a full compliment of voice lines and narration, and so much more!
• Lastly, as a class, this “experiment” was a success. For many students, this was their first time working in an indie studio-like environment, and they performed admirably every step of the way. They learned how to communicate with each other, deliver work that contributed to a greater whole, and even how to work under crisis and mounting pressure without missing a beat. Students learned how to work with software they’d never even heard of before just to make this game what it is — and if that isn’t a learning success, I don’t know what is!

Of course, the pivot had a heavy toll and we felt its impact on various parts of the project, which affected how we approached our process:

• Our timeline was quickly condensed — even though the final deadline had been extended, from April 17th to mid-May, we suddenly had a lot more on our plate! From the port itself (which now mandated optimization) to the design and implementation of a website, we had a lot to do in a short time period if we wanted to get the game out on time.
• Maintaining communication became a major focus: Now that we couldn’t see each other in person day-to-day, a significant portion of the leadership’s time was dedicated to holding meetings and checking in with our people each day. By doing this, we could keep the gears turning and reach deadlines as planned.
• For a while, it was a struggle to playtest the game. Typically, a designer wants to observe the player while they try out your game, so that they can ask questions and pick up on any body language clues about how the player is feeling. With the web format it was now very easy to send the link to someone and have them play it, but written feedback isn’t always as useful as an in-person session!

However, the pivot to WebGL might have just been a blessing in disguise! Suddenly, the questions we had for the VR port went out the window, and some solutions were natural to the new platform. For example:

• By hosting the game on a website, we can easily disseminate the final product to anyone in the world. 
• In order to get the game to work in a browser, optimization took a forefront.
• The shorter, condensed timeline meant that we could quickly and efficiently prioritize the assets that were still stuck in the pipeline, resulting in a quick turnaround between each new development version of the game. 
• Because we were moving to a more traditional control setup — everyone has used a keyboard before, but not many people have ever held a VR controller — we could rely on an established control scheme that would be more intuitive to the average person!
• Even though playtesting was a bit more complicated than before, we were able to reach a greater audience for even more feedback, by having multiple people play on their own machines, on their own time!

III. Lessons Learned

Developing Buggy AllStars was an incredible learning experience for all of us, and it would take pages upon pages more to document every lesson we picked up along the way. 

So, let’s focus on the highlights of what we learned, dividing them into “Universal” — something that is frequently recommended and commonly applies — and “Specific” — something that related specifically to our structure — lessons.

The Universal Lessons

• Frequent and short “stand-up meetings” kept everyone on task by maintaining the communication pipeline, and was especially important after the pivot to WebGL. 
• Quick turnaround times and frequent builds are crucial to getting features implemented, or realizing when features are falling behind early on.
• Having one (or a small set of) standardized software for a task that’s uniform across your time is a valuable boon, especially when it comes to troubleshooting and integration.

The Specific Lessons

• As time went on, we noticed that we didn’t have all of the roles we needed. Specifically, it would have been helpful to have a designated Quality Assurance team at the start — a role which was instead adopted by the leadership crew.
• The flexibility of leadership to get hands-on in the project was a strong motivating force for the team, and also enabled us to get an eye on anything that wasn’t working while it was still in development (instead of it going unnoticed until the build date).
• Dedicated “pairs” of team members devoted to a specific task (Sound, UI, Gameplay) encouraged accountability, as the partners drove each other to work and would check in amongst themselves.
• Perforce was a fantastic addition to the software lineup, as it made additions and documentation a breeze.

IV. The Future of Buggy AllStars

This semester’s AGS class was an experiment in many ways: timing, organization, and communication — even before the impacts of COVID-19. There were over 25 people involved in this project, an interdisciplinary endeavor that brought students, staff, faculty, and alumni together to make it a success.

Even with the pivot and occasional shortcomings, Buggy AllStars was a success. We completed our game, completed all art assets, all core goals (and even some stretch goals) and published a website – all in the span of one semester… even after a major wrench was thrown into the works!

This is still just the foundation for what is to come! Using the lessons we learned from creating this year’s edition of Buggy AllStars, we can move forward to create an even better version next year! One that builds on the art assets created and design explorations made, pulling it all together into one superstar race!

So, the future is bright for Buggy AllStars, and we look forward to seeing exactly what it holds. Until then, thank you for joining us on this little adventure… and see you next year!