In this post, I’d like to thank each of the people who contributed to Buggy AllStars. This project was a massive undertaking, and keeping it all going was no easy task!

Even with 25 students working together, it wouldn’t have worked if we didn’t have all the support we did. So, thank you!

The Client, who brought their project and passion to us

Thank you to our client — the Buggy Alumni Association and everyone within it that we worked with — both for their years of dedication to everything Buggy and for bringing the project to us in the first place! The project has been an incredible experience for all of us involved, and a rare opportunity to really push ourselves to the limit and see what can be done.

We especially have to thank the following people for taking the time out of their busy lives to work with us, check in with us, and see the project through to the finish:

Anne Witchner, Kaycee Palko, Ben Matzke, Laurel Bosshart, and Will Weiner

Their passion for Sweepstakes was infectious and drove us to keep the project going through thick and thin, and their confidence in us was a strong motivating force! So, thank you all!

The Faculty, who built and sustain the program we’re a part of

Keith Webster, Drew Davidson, Steve Audia, and Mary-Catherine Dieterle.

The IDeATe Staff who supported us

Thank you to Kelly Delaney, Gretchen Graff, George Minick, Tim Parenti, and Cody Szoska, the people who make IDeATe work!

The Interviewees and Consultants, who took the time to educate us

Thanks to Jesse Schell and Patrick Jalbert of Schell Games for their expertise in the early phases of the project as we ventured into the realm of designing a VR ride.

Additional thanks go to Michael Christel, who provided us with the video waiver we used before recording playtest sessions; Brad King, who provided us with the decades’ worth of footage and Buggy documentation; and thank you to Kristen Kurland and Emma Slayton for the GIS data we used in generating the terrain around the track.

Thank you to Paul Gerlach and Zachary Kowalewski from the Kiltie Band, who were so kind as to provide us with the score to the CMU Fight Song! Even though we were not able to use it for this iteration of the project, we look forward to integrating it into a future release!

And a big thanks to the buggy drivers and pushers we interviewed (Mary Garrett, Boyao Yu, Tishya Girdhar, and Annie Black) whose input and feedback were crucial in designing the experience from start to finish.!

Additional Assets Created and Contributed by…

The voice you heard in the game was none other than the “Voice of Buggy” himself, Will Weiner! He so generously contributed his time, sending us voiceline after voiceline whenever we needed something new.

The Main Menu music was entitled “Story has Begun (Kielokaz 156)”, by KieLoKaz. It is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information on the license and its use you can follow this link.

An early rendition of the Cathedral of Learning was provided to us by James T. George, which we used to populate our skyline until we had the time to create our own asset.

Many of the campus models were built from existing assets made in a previous semester of Reality Computing (a CMU course also led by Tom Corbett). These models formed the foundation of our 3D modeling work, saving us a substantial amount of time and ensured that the art timeline was realistically achievable. The students in that course were as follows:

Mert Bozfakioglu, Lauren Zhang, Emily Zhou, Matthew Henderson, Skylar McAuliffe, Byungju Lee, and Woody McCoy.

And thank you to Justin C. Macey for letting us use the CMU Mocap Lab, which went a long way towards making the animations in the game look as fluid as they do!

And last, but certainly not least…

Thank you to the entire team, whose dedication even in this time of crisis kept the project moving. In a time when it would have been so easy to just disconnect, their perseverance was something to admire!

And finally, thank you for following along with us in this immense, crazy, risky journey. We hope that you enjoyed this peek into the development of this project, not to mention the game itself!

Stay safe out there, keep in touch, and we hope to see you all again one day!

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!

This past weekend was the Superbowl Global Game Jam, and a part of the Advanced Game Studio team was fortunate enough to take part! In addition to being a valuable team-building exercise, this weekend kicked off a ton of creativity, and was a valuable learning experience for reasons I’ll soon explain.

The Global Game Jam

If you’ve never been to a game jam, it’s best described as a hackathon dedicated to the creation of games. They happen all over the world, at all times of the year, and can range from small, local jams run by enthusiasts to massive events that span the globe.

The Global Game Jam (GGJ) — described as “the world’s largest game jam event” — is one of the latter, with game developers of all experience levels getting together to spend a grueling (but fun!) 48 hours making an entire game. These games can vary in complexity, from the simplest of 2D games to full-blown VR experiences, but all are (or should be) centered around a very specific theme — and that theme is announced the day of the Jam.

After much anticipation, it was announced that the theme for this year’s Jam was “repair.” And so, we were off!

The Process

In some ways, creating a game at a game jam is very similar to creating a game under other circumstances — the timeline is just more condensed. In our case, we more-or-less followed the above timeline, starting with an intense bout of pre-production and brainstorming.

Although the pre-production stage is normally meant to take most of the first night, we quickly settled on a genre, setting, and mechanic that we wanted to run with. So, I introduce to you Iron Rations!

The Game

The so-called ‘Iron Ration‘ comprised an emergency ration of preserved meat, cheese, biscuit, tea, sugar and salt carried by all British soldiers in the field for use in the event of their being cut off from regular food supplies.

– https://www.firstworldwar.com/atoz/ironration.htm

Set in a retro-futuristic world, the game Iron Rations has you play as a scavenger robot caught in the middle of a savage war. In other words, you are a non-combatant, and your job is to survive for as long as possible in order to escape.

But, the only way you’ll survive is by dodging bullets, and the only way to escape is to get the bits of scrap and machinery scattered around the battlefield, repairing them as you go!

Iron Rations was meant to be a bullet-hell game with mini-game crafting mechanics that challenged the player with completing said mini-games while actively trying to survive on the battlefield.

Pre-Production and Prototype

Friday night into Saturday afternoon marks the transition between pre-production and prototype, meaning that all jammers should be working on getting their game’s core mechanics in and have an idea of what the final product will look like.

For us, that meant that we had to pick the aesthetic direction; code in movement, mini-games, and bullet patterns; and start thinking about what our level design will be.

Art

Design

Programming

“Alpha” and “Beta”

From Saturday afternoon to Sunday morning, teams are focused on getting into the alpha and beta stages — meaning, art and sound assets start to take the place of programmer art, mechanics start getting more complex, and the game starts to “feel” more like the end-product.

The Mini-games

Iron Rations featured two components to its gameplay: the bullet-hell, and the crafting mini-games. We were aiming to have three total mini-games, one for each repairable item in the game.

Wiring

Welding

In the welding mini-game, the player has to maneuver through a randomly-generated maze, from start to finish.

Lining-up Sights

Art

Untextured assets for various in-world obstacles, to help populate the environment and give the world its character

Saturday Playtesting – Buggy100

Of course, the Global Game Jam wasn’t all fun and games. Whenever the team wasn’t working on coding or asset creation, they were hard at work with the Buggy game — playtesting, designing, or even researching how the GGJ experience would translate to Buggy100.

More info on the results of this weekend’s playtesting will be in the regular dev blog.

Final and Showcase

For many, Sunday morning is when the “crunch” (the frantic last push to finish your game) really kicks in. It’s the last opportunity to get any and all assets in, finish the core features you’d been aiming for, and iron out any game-breaking bugs that might exist.

Our game, of course, was no different: things were broken, art was missing, and most of the sound effects hadn’t been made yet. But, thanks to the hard-working effort of everyone involved, by the time the 1PM submission deadline rolled around, the entire game was complete! A full level of bullet hell, with three mini-games, a win/loss state, and all art/sound were submitted just in time…

And not a moment too soon, because at the end of every game jam, the participants are expected to set their games up on tables for everyone else to play. This is the time for everyone to go around and see what the others were working on… and have their own games seen by the site’s judges!

For many teams, it’s also the first time that they’ll get to sit down and actually play the game for themselves. It can be a cathartic moment all around, sometimes, as the adrenaline rush finally subsides and you get to see the results of all your hard work.

The Award Ceremony

At the end of the game jam, after judges had the chance to play each of the 40 or so games at the showcase, they present awards to each of the teams they felt particularly succeeded in specific categories:

• Technical Excellence
• Artistic Excellence
• Diversity Award
• Non-Traditional
• Best Theming
• First Penguin
• Jammer’s Choice
• Judges’ Choice

And, as you might be able to guess from the above images, Iron Rations was selected as the recipient for the “Artistic Excellence” award!

Takeaways

Everyone worked incredibly hard to make this weekend a success, and it showed! Not only that, but each of them learned a lot that can be applied to future work on Buggy100.

Without a doubt, the game was hard and was missing a lot of tuning. Some sections of the level were too difficult, others too easy, and that meant that a lot of players were left feeling frustrated and unable to complete the game. In other words, we would have benefited from taking more time to playtest Iron Rations during its development, so that we could tune the difficult a bit more.

Fortunately, one thing that we did catch early on in the playtests that we were able to do was that many players had difficulty understanding what they needed to do, or how to do it. The game was missing feedback and instruction. To solve the issue, we added an overlay that showed the actions available to the player at any given time, and which button mapped to a specific action. In short, playtesting gives valuable data and insights into our development!

A part of the reason the team elected to move forward with a 3D-style game was to practice working in that space — after all, all of Buggy100 is going to be 3D! So, by taking these past 48 hours to do nothing else, the artists were able to practice their character rigging, texturing, and architectural modeling to the fullest. Some time was even spent researching shaders, to get a good feel for what they were capable of.

Speaking of shaders, the programmers took this opportunity to expand on the “Toon Shader” created by our very own Adrian Biagioli, configuring it to work with “deferred lighting.”

A more detailed breakdown on what shaders are and what they can do will be the topic for a future post, but it is what allowed us to make each bullet in the above GIF its own lighting source — instead of being limited to only four.

The Team

Pictured above, six students from AGS took place in the Jam as their own team. Forming a full compliment of three artists, two programmers, and a producer/sound designer, the team was ready to take the weekend on at full force!

Special Thanks

Although not officially on the team for this jam, the music for Iron Rations was composed by Michael Bridges. A special thanks to him for his contributions on this project!

Gallery

Pictures say a thousand words, so here are some additional photos of what the final product ended up looking like!

Mini-game screenshots and full gameplay video coming soon!!

Download Links

If you’d like to download a copy of Iron Rations to play for yourself, you can click here to download. Note: An Xbox gamepad is required to play.

Alternatively, if you’d like to download the Unity project for Iron Rations, you can download that here. The Unity version used was 2019.2.18f1.

Finally, the link to Iron Rations‘ GGJ page is here.

As always, thank you for reading, and see you next time!

• The Buggy Alumni Association – An organization within Carnegie Mellon University, and the “client” for this project.
  • Founded in 2008 as an organization centered around buggy for all members of the buggy world, past and present.
  • Read more here

• Spring Carnival – A yearly, three day university holiday filled with “amusement park rides, adventures in booths, unhealthy snacks, and buggy races”. (https://www.springcarnival.org/ )
  • This year, Carnival (and Sweepstakes) will be celebrating its 100th year anniversary.

• Sweepstakes – A competition where Greek and independent organizations race with their buggies: small, low, aerodynamic vehicles, powered only by gravity and human pushers. (from the CMU Carnival page)
• Buggy – A more commonly known, alternative name for Sweepstakes, but also the name of the vehicles pictured and mentioned above (and the main focus of our game).
• Driver – The person inside the buggy, who maneuvers the vehicle during the race.
• Pusher – In Sweepstakes, a pusher is someone who runs up and physically shoves the buggy to accelerate it forward (since buggies have no internal engine). There are five total pushers, one for each “hill.”

• Hills – There are five hills, which mark the pass-off sections of the uphill portions of the race. The first two are at the start of the race (in orange), and the last three make up the tail end of the race (in red).
• Top of Hill 2 – Referred to as the “crest” in our internal documentation, the Top of Hill 2 marks the start of the downhill portion of the race. The fastest buggy to reach this point is dubbed “King/Queen of the Hill.”
• Flagbearer – People who wave flags in front of the buggies to mark the start of a turn.
• Top Flag – The flagbearer that marks the half-way point of the Free Roll segment.
• Free Roll – The downhill portion of the race, and the primary focus of our game. This is the most “race-like” section of Sweepstakes, as it is when the drivers exert full control over their vehicle.
• Chute – The sharpest turn in Sweepstakes, located at the bottom of the Free Roll.
• Chute Flag – The flagbearer that marks the turn into the Chute.
• The Backhills – The final pushing segment of the race, consisting of an uphill straightaway to the finish line.

Production Terms

• Prototype – The prototype is meant to answer early questions regarding the game’s design: What controls feel natural? How fast/slow can you go? Is the environment disorienting? What should the UI look like?
• Alpha – At this stage, we begin to see more of the game’s character taking place. Art assets start to replace programmer art, and we begin to iterate on feedback collected from playtesting the prototype. Definite game elements and sounds make their appearance.
• Beta – In beta, we continue to refine the game elements from alpha, while adding in any remaining core features so they can be tested for the final version. If a feature doesn’t make it into the game at this stage, it runs the risk of getting cut/pushed to “Polish.”
• Final – For the final deliverable, we used the term Feature Complete to describe its key features. In essence, this means that the product at that stage should contain all (or most) of the elements needed for a stable release. Art assets, game elements, and other essentials are present. Since a member of the class will be onboarding guests into the game at Carnival, the tutorial has been pushed into the “Polish” stage.
• Polish – At the polish stage, we can finish adding in the “non-essential” features. For a game like this, that includes features which would make it a standalone game: tutorials, additional voiceover, and additional visual effects.