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!

But, even so, Buggy AllStars will go on!

In this post:

• Carnival (and Buggy100) has been postponed
• Buggy AllStars will continue as usual, with some slight modifications
  • Extending deadlines by 1-2 weeks
• Certain features will be impacted
  • Temporarily pivoting away from VR

As of now, I am not sure what we will have to post next week, as CMU works to get everything up and running on Zoom. At worst, there will be a check-in post much like this one. Thank you for your patience, and please stay safe!

Carnival has been postponed

As you might have noticed, the counter on this site has changed: instead of counting down until Carnival, it is now counting down to the week before the end of the semester. This reflects the changes in our development timeline due to Carnival’s postponement.

Although there is no official notice on when Carnival will be moved to, it appears that it will not be during this Spring semester — meaning that the Advanced Game Studio will no longer be developing for the original April 17th deadline.

But, even so, Buggy AllStars will continue development, and the Advanced Game Studio is still hard at work!

Of course, some things will change

In order to ensure that we can release a functioning game, we’ve had to come to terms with a few major pivots. For one, Buggy AllStars will not be a VR game at the end of this semester. Due to the shift to online-only education and nation-wide social distancing efforts, it would be very difficult to sufficiently playtest and develop a satisfying VR experience (not to mention, potentially unsanitary).

Instead, we are looking at creating an “arcade-style” release, which will use or re-purpose all of the art and mechanics created so far. In other words, Buggy AllStars will release for PC and not require a VR headset to play.

Additionally, we are looking into building the game using WebGL, a JavaScript API which would allow it to run in a browser, online and without any applications or downloads. That way, the public will still be able to play our game at the end of the semester — without having to come to CMU or Carnival to do so — and we would still be able to playtest as usual (more or less).

This arcade-style game will differ from the original VR game in the following ways:

• There is potential to have multiple camera views, ranging from first-person, to third-person, to a “cinematic view” (as in Grand Theft Auto or Red Dead Redemption 2)
• Controls will use mouse and keyboard controls, not any special hardware or periphery
• UI will likely be more traditional/non-diegetic, in terms of how it appears on the screen like a HUD
• The player may be given more freedom to drive around the track, making it into less of a ride and more of a racing game
  • To what extent this would be is yet to be determined, but it is possible that we will allow small collisions and the possibility to turn around on a track
• We would like to encourage a social media component, which would have players share their completion times on a platform of their choice to encourage competition
• There will be no physical setup, since there won’t be an event to set up at
• There will be no spectator view, although it might get re-purposed in the “cinematic” camera view

Of course, this list is not all-encompassing, and we will definitely be running into more nuanced differences in time.

With all that said, I think it’s important to restate the following:

Buggy AllStars will continue

Even though things are changing, this shift to an arcade-style game has another benefit: since first-person controls map well to VR systems, we can continue development with a smaller team next year, to create the same, virtual reality experience that we were hoping to accomplish this year.

In any event, we will be working hard to release a product that everyone on the team can be proud of at the end of the semester, and to make that happen:

We have a new work schedule

For now, it is important to focus on the constraints we are given, and complete what we can in the time allotted. Even though a lot of assets and mechanics can be re-purposed, we are working in an unprecedented time, and that requires a bit of foresight and caution going forward.

So, instead of the original deadlines, everything has been shifted 1-2 weeks out, giving the development team more time to work in the above changes, and allowing for the inevitable complications that come with remote work and global events.

Specifically, these are the new deadlines:

Looking ahead

As mentioned earlier, I’m not entirely certain what we’ll have to report next week. CMU is going through a tumultuous time right now, and the Advanced Game Studio is no different. Students across the campus are getting used to attending classes and meetings via Zoom, and some students don’t even have access to their usual computers.

Still, if at all possible, we will have a post up at the usual time explaining the design changes that we will be pursing over the coming semester, how we’re meeting the challenges imposed on us by the new situation we’ve found ourselves in, and any other progress that is made in the interim.

Until next time, stay safe out there and see you soon!

• An inside look at the MoCap sessions,
• New Branding ideas,
• A bird’s-eye view of the Carnival setup,
• And sounds are in the game!

Note: Due to this week being Spring Break, there will not be a dev blog posted next week. We apologize for the inconvenience!

Art

This week marks the start of Beta production for the Art Team — that means a focus on polish, layout, texturing, and animations. As you can see from the Gantt Chart below, that means that a lot of the team will be working in parallel to get everything done on time.

In other words, since a bulk of the modeling is planned to be completed by this time next week (around March 17th), this period marks a transition away from modeling and towards the final stretch.

Characters and Animations

This week, our art team got to set foot inside of CMU’s Motion Capture Lab to get some high-quality animations for the characters in the game. In fact, they received some hands-on experience, with art lead Eric Yu putting on a MoCap suit!

They recorded a variety of animations that would otherwise have been very difficult to create by hand; things like idle animations for drivers and pushers, or even more unique motions like “catching” the buggy at the end of a race!

It’ll be a few weeks before we actually see these animations in the game, as it will take some time for the recordings to get cleaned up to a point that they could be used.

Special thanks to Justin Macey for his help at the MoCap lab!

Buggies – Onto Texturing!

As you might have seen in the headline above, our buggies are almost done! 7 out of 10 have been fully textured, with the rest to come in the following weeks.

Aside from texturing, the next step for our buggies is (of course) to put them in the game! Fortunately, placeholder buggies already exist, so it’ll just be a matter of uploading the correct models. From there, our art team will continue to tweak the buggy models as needed, and the programming team will continue to fine-tune their behavior.

Environment Art – Propwork

Pictured: One of the many signs that dot CMU’s campus, modeled by Sydney Ayers

Design

The design team had two major tasks this week: one, to start building the branding materials that we could distribute to the public. Two, to flesh out what the physical, Disney experience would look like in terms of floor layout and line management.

Branding – Introducing “Buggy AllStars”

Pictured: Logo designs by Adela Kapuscinska

First off, let’s take a look at the efforts of the branding team! After opening a voting poll to the class, the top three choices for a game name were a) Buggy AllStars, b) Buggy100, and c) Buggy VR. Armed with that knowledge, the design team created the title fonts you see above, and the logos you see below!

Of course, these are still just sketches, but after some discussion it was decided that we would go with the name Buggy AllStars for the time being.

So, welcome to Buggy AllStars!

The Physical Experience

From the start of this project, we had been aiming to create a physical display that would help the player immerse themselves into the buggy experience. Originally, we had planned for this to happen following a design for the player buggy.

But now, weeks later, we’ve decided to follow a different approach: instead of drawing a buggy and designing the physical experience to match, it would be better (and easier!) to create a physical layout for the physical build, then draw the buggy around that — sort of an extension of the inside-out cockpit design from the last week.

To that end, one of our UI/UX designers, Jaeyon Huh, took the time to develop a few different layouts for the physical setup. Shown above are a number of his design sketches, ranging from bare-bones (with just a chair), to a chair and fan, to a full seated configuration.

Jaeyon took then took a few of the designs he had sketched out and refined them a bit further, creating two designs that could be used depending on scope and feasibility:

For both of these designs, we’ve toyed with the idea of using a desk fan in combination with an Arduino, which would change speed in tandem with the player buggy — making the player feel the wind on their face!

Next up, we have a few views of potential layouts for the physical exhibit. Pictured below is the layout we decided to run with, featuring physical dividers that partitioned the room into two sections. Players will queue up on the rightmost side of the room, where a TV will be set to display content — either the spectator view of actual gameplay, or a cycling slideshow showcasing the development of the game!

This layout was chosen for a variety of reasons, including the entrance’s proximity to the Buggy Museum (which would be set up next door), its direction facing the entryway of the building, and the ability to curate the queued players experience.

Below are two other layouts, which had interesting features but were set aside in favor of the previous design.

Oh, and speaking of the physical experience, we received something exciting in the mail this week: three USB steering wheels! These wheels are equipped with force-feedback, meaning that (in addition to allowing physical, 1:1 mapping of controls) we can add resistance to the wheel the further the player turns from the center — making the “autocorrect” feature feel even more authentic!

The programming team has been assigned the task of hooking these controllers up to Unity — more on that as it comes along!

Sound

This week was an exciting week for sound, as it marks the first time we got to hear thing in-game! Technical difficulties with FMOD were abundant, but things came together on Friday in the nick of time.

In the video below, you can see (and hear) how the speed of the buggy affects the sound: faster speeds introduce a “whoosh” and the rattling of wind, which gradually falls away as you return to normal speed.

Pretty cool, right?

Gameplay

Gameplay took a few steps forward today, with placeholder UI up and running (which shows both the mini-map and a speedometer), as well as in-world markers that show the player the “ideal path” for their race (the wide blue line on the screen below).

Meanwhile, we got a look at some UI in-game. Seen below, there are two test UI’s in place: one is fixed in the world, while the other is tied to the player’s headset. With the code in place, the design/UI team can work with the programming team to test in-game now, instead of the paper prototypes they had been working with before!

Next on the list will be to anchor the UI to the cockpits you saw last week, grounding them in the game’s world.

Looking Ahead

The coming week will be spring break (starting today, actually) so things are expected to slow while everyone is away. To counteract that, a small subset of the class met one last time before break to get some work done and set expectations.

For the coming weeks, we hope to show the following:

• NavMesh
• Hardware Support
• Buggy Designs
• More art and sound!

Lastly, before I sign off, let’s hear a round of applause for the team and all the work they’ve done in the last few months:

See you in a couple of weeks!

In this post:

• The final buggy model — done!
• Trees and (basic) textures!
• Grayboxed cockpits for the player buggy!

The Alpha

Art

Buggies

This week, we’re proud to show the final buggy in the core lineup: the 1940, Beta Theta Pi’s Beta Baby!

With this model done, we’ve reached 9 out of 9 of the target models we wanted to have ready by Alpha. From here on, the artists will shift focus to texturing and generating additional art assets to populate the world.

Time permitting, we hope to revisit the buggy roster to add a few more to the game later in development.

Characters

This week saw the creation of our final three pusher mascots: James Garrett, Farnam Jahanian, and Anne Witchner!

And up next, we have the models for the AI buggy drivers and the Scotty Mascot:

With the mascot heads and pusher bodies well underway, our character team is gearing up for the beta round of animations and texturing, which will take these characters out of the abstract and into (virtual) reality!

Environment Art – Trees!

Trees modeled by Eric Yu

Grayboxed Cockpits

While the bulk of the design team is working on either the design and layouts for the physical experience or the game’s branding, this week was a good time for the art team to start implementing some of the designs that had been iterated through for playtesting.

Interestingly, the results of playtesting were fairly inconclusive for these two designs — it will likely be necessary to revisit these tests after adding some textures to the cockpits, and a UI element or two.

Still, putting these cockpits into the game was a valuable experience for the artists and playtesters, as it gave the immediate impression that the player was in a buggy, instead of just driving a car.

Gameplay

There isn’t much new to say regarding gameplay this week, as tuning is still a work-in-progress and other features are still in the pipeline.

Spectator view, however, has been implemented — but, since it requires two machines to run it via a network, we unfortunately do not have an image to showcase it at this time. Please check back in the future for an update to this post! Update 3/18/2020: Due to closures surrounding the COVID-19 pandemic, we were not able to meet in person to take said image

Looking Ahead – Leading into Beta

Bugs in Buggy

Although not technically a bug, one issue that we’re currently dealing with is that we do not have a defined end-state to the game… which means that stuff like this can still happen:

So, to get a clearer idea of what that end-state to the game would be, we had one of our artists — Angelina Shi — prepare a view of what the ending scenery should look like:

For Next Week

Next week, we’re aiming to have in everything that was mentioned last week but fell short, as well as the following:

• Art: progress on the textured buggies and MoCap
• Design updates: Branding and Physical Experience
• As a bonus, a snippet of a recording from the class for use as crowd noise!

See you then!

In this post, we have:

• Pushing animations are in the game!
• Several new buggies
• Ideas for the “Disney” side of design
• Goals for the end of Alpha

As a head’s up, next week’s post (Week 07) will go live a couple of days later than usual, on Friday, March 6th.

Art

Character Animation

After getting the running and pushing animation to work together in MotionBuilder — a 3D animation software by Autodesk that excels in combining two separate animations into one — we got our first look at the pusher models and their animations in the game:

With running and pushing now handled, our animation team is looking into creating animations for the more “unique” actions in the game. The swish of a flagbearer’s flag to mark the start of a turn, the stance of a driver as they lean into a tight turn, and driver idle animations are just a handful of examples for what’s next in the pipeline.

Fortunately, we have access to the use of a “motion capture” (or “mocap” for short) lab at CMU, which would give the students a chance to record the animations themselves — much like how a CG movie would use mocap on the big screen!

Buggy Models

We have several new buggy models this last week, putting us well on our way to hitting our target for Alpha! Although we hope to include additional buggies in the final release, the Alpha-stage buggies will need to be refined significantly before that call can be made.

So, let’s kick this off with a fan-favorite: Le Societe Herpolhodique’s Herpole Hode, otherwise known as The Bathtub!

Additionally, we have the oldest-known photographed (winning) buggy, the 1921 Iota Sigma Delta buggy!

Next up, Fringe’s first multi-year buggy, the 1970 Baby Leroy, and CIA’s first buggy with a dropping pushbar, Stealth!

Next in the roster, we have this week’s textured buggy: CIA’s Ascension!

And finally, our Art Team had the special privilege of getting into the workshop for the CMU Robotic’s Club buggy — Robobuggy — to take some photos for reference.

By special request, Robobuggy will be making an appearance in the game.

“Prop” Assets

With buggies and buildings well underway and nearing the first pass’ completion, our artists have started to take on the massive list of “prop” assets that will add some color and character to our world.

Beyond their aesthetic and contextual purposes, props like these help ground the player in space, or add to a sense of speed as these objects fly past their periphery.

Design

With UI almost ready for implementation and Carnival less than two months away, the Design team is changing gears to focus on the “experience” of the whole event, beyond just the game itself. What will the room we set up in look like? How will we get our players into the right headspace for the game? How are we handling the lines, and what if someone gets nauseous while in the game?

Content Design

To answer some of these questions, the Content Design team is looking at Disney rides as a source of inspiration and a master class in how to make something as simple as waiting in line part of the experience.

The spectator view system will be a large part of that experience, giving players something active to look at while they wait. But that’s only one possible component, and our design team wants to consider all of the options.

For example, a new idea that was brought up is the possibility of using additional hardware like a Looking Glass to give players an up-close look at the buggies they’ll race in-game!

The Looking Glass (pictured above) is a piece of hardware that creates holographic, three dimensional models that can be animated and displayed. By setting up one (or two!) of these around the queue of players, we can engage them with more than a simple display.

UI Design

Following up on last week’s playtesting information, the UI team has honed in on one cockpit design that they will continue to develop and implement in game:

This design has the benefit of a thin wireframe that helps the player feel like they’re inside a buggy, without being too claustrophobic for new players. However, testing showed that being closer to the wheel feels better (i.e. faster and more realistic), so the implementation of this design will take that into account: raising the steering wheel to be more consistently in view.

Although this design had a positive response from interview testing, the closed-cockpit still needs to be tested in-game as it might be problematic if and when players decide to move their heads in a way that clips through the model. As a potential solution to that problem, the UI team is also looking at helmet-based UI scheme, with sketches for that coming next week!

Sound

With SFX sampled and on their way into the Unity pipeline (after some hiccups getting FMOD to integrate properly), Sound’s goals for the end of Alpha are to build a sense of auditory immersion. Right now, the game feels empty: the lack of objects and sound gets a little boring, and it doesn’t make the player feel like they’re racing down a hill.

So, in the coming week, we aim to have the following sounds in the game:

• The sound of the buggy rolling on the track (included in last week’s post) augmented by the rush of wind when traveling at high speeds
• A slight “rattle” for when the player hits a pothole
• Another “rattle” for when the player makes sharp turns
• A “boost” or whoosh of when when hitting a boost pad

Additionally, the need for voiceover is becoming increasingly relevant: now that players are starting to get an idea of what the game is and where it takes place, they’re noticing a lack of context for what they’re doing and why. Plus, voiceover can be notoriously difficult to get right: it can be too cheesy, or not cheesy enough; it can be too loud or too soft; or it could just be poorly timed and needs to be tweaked to fit the rhythm of the game.

We aim to have our “scratch” (or test) recordings done in the coming week, using something like the above script as a guideline, and will implement the relevant lines for testing shortly thereafter.

Code

This week, coding effort was focused on tuning the gameplay and mechanics, as well as fixing some bugs that cropped up along the way.

However, progress was made on the visual side of things, as you can see by the image above and the video below!

Bugs in Buggy

As is always the case when introducing new features, we came across a few small bugs that had the potential to cause larger problems down the line.

Fortunately, our programming task force is on the job, and are on their way to settling these issues:

• Visual glitch on the buggy steering wheel, similar to distorted/lagging frame rate — Squashed!
• Player can still “spin out” when bumping into boundaries — A work-in-progress, but this is just a matter of tuning!

Looking Ahead

Next week’s goals

Although this week saw some progress in terms of visuals and design, it was largely setting the groundwork for the week to come. The final collection of preliminary art assets, sound, and design concepts that make up Alpha will largely make their appearance by the end of next week.

For some highlights, we hope to have the following in game next week:

• Spectator view up and running
• Props/Trees to give a sense of space
• Shaders on the terrain and various objects
• A design for the “Disney” side of things
• Sound for various elements in the game

See you next week!

• Art progress
• Design Ideas for the Player Buggy’s Cockpit
• A sneak peek at Sound
• Free Drive has been implemented!

Progress

Art

Buggy Art

This week, the in-game buggies improved by leaps and bounds: in addition to a slew of new models, we also saw old models improved with the addition of textures and shading!

For example, here we have the Keg; seen just last week as an untextured, grey model, it is now completely textured, shaded, and ready to be put in the game!

Meanwhile, this week’s new buggy was the Pi Kappa Alpha buggy from 1946, which is reportedly the first “torpedo-shaped” buggy! For that reason, we selected it as one of the representative buggies for Buggy100.

Although the model is still a work-in-progress (it still needs the paint job and textures of the original, for example), you can see how closely it resembles the original in the pictures above!

But, that’s not all… as an unexpected bonus, our artists got started on another popular contender for the Buggy100 all-star race: The Fish!

Character Art

Environment Art

With the results of last week’s shader testing underway, we’re now getting an idea of what the final game might end up looking like. Although a lot may still be changed between now and Beta, it’s giving us a much clearer picture than what we had with just grey boxes!

For now, we have the campus laid out with models on their way, and so the shaders and textures from the previous image haven’t been applied just yet. That will be coming soon, likely in the Beta builds!

Interestingly, although the Hunt Library building already had a model in-game (thanks to resources provided to us from another class), it was not rendering properly in the VR view. A few theories were thrown around (including the possibility that our laptops’ graphic cards were failing), but the likely conclusion was that the model was simply too high-poly.

So, the above model was re-designed with fewer polys, in the hopes that it will be more VR-friendly.

Design

Last week, we saw the results of the UI subteam’s research into possible control schemes, but with mechanics and controls now decided the Design Team has fully turned towards implementing the User Interface.

Designing UI is no simple task, and it will take a number of passes through each of the teams before the final product is made:

One question that came up during last week’s rounds of UI design was “how will it integrate with the buggy’s cockpit?”

To answer that question, the Design Team drafted a series of potential cockpit designs, with large frames, small frames, and everything in between. There’s also a healthy mix of diegetic (in-world) and non-diegetic UI to be seen.

Another benefit to designing the cockpit and UI design now is that it can encourage an “inside-out” design for the player buggy.

Instead of drawing and detailing a buggy design first — then shoehorning controls and UI to match it — we can create an optimal UI design now, then build an aesthetically pleasing “shell” around it. This ensures that the mechanics look and feel good, without sacrificing any visual qualities.

In the coming weeks, the Art Team will be working on creating 3D models to represent some of these cockpit designs and collaborate with the programming team to generate a UI overlay for testing.

Sound

Over the last several weeks, our sound designer has been hard at work researching Sweepstakes videos (and even attended some of the weekend rolls) to build a library of sounds to use in the game.

Although said sound library is still a work-in-progress and won’t be in the game for a few weeks yet, here’s a small sample of what the buggy’s ambient “rolling” sound will be!

Code

Last, but certainly not least, the programming team has been hard at work this week trying to make up for lost time after the pivot to free-drive.

After the leadership team made the decision to focus on the steering wheel as our primary control scheme, the major bugs with it were ironed out and the on-the-rails system for the player was disabled. However, the work was not lost, as the AI racers that drive the other buggy will still be following the old track!

Free Drive

Course-Correction

A major concern with giving the player full freedom to turn and drive around the course was that it would be almost impossible to control the player’s actions — what if they turned around, or crashed into a wall? With the pivot to free drive, we had to create a way to keep the player on-course and solve those issues, while still giving them enough leeway to feel in-control.

Fortunately, our programmers discovered a solution! By using a modification of the original rail the player was using, they could have the player’s buggy “course-correct” back to the center of the track whenever they strayed too far.

Although this early implementation is still rough and a bit slow, future iterations are expected to react proportionally to the player’s distance from center and even provide haptic feedback to the player’s controller.

Looking Ahead

With two weeks to go until Alpha, things are really heating up! Our goal for Alpha is to have as many environment assets in as possible — including buildings and things like trees, hay bales, and other objects — get controls to feel smooth, plus have SFX and Voiceover making appearances.

For the coming week,

• We hope to put our game in front of a buggy driver, to see how they feel about the direction of the game
• The Design team will have layouts for the UI that can be tested and iterated upon
• Concept sketches for the player buggy

See you next week!

In this post:

• The Importance of Playtesting
  • What is Playtesting?
  • Goals for Buggy100
• How do we Playtest?
  • Our Protocol
  • Equipment
• Results so Far

The Importance of Playtesting

You are cordially invited
To tell me why I suck
Bring a friend — Refreshments served

– Jesse Schell on Playtesting, from The Art of Game Design

In many cases, playtesting is a vulnerable experience for game designers. You’re taking something you’ve worked hard on and love, and asking people to tell you why it isn’t fun. But hard as it may be, playtesting is part of the design loop and the more you do it, the better your game will be!

But what exactly is “playtesting,” and what does it do for us?

What is “Playtesting?”

Playtesting, as defined by Jesse Schell, is the act of “getting people to come play your game to see if it engenders the experience for which it was designed.” In other words, it is how we test our game to see if expectations and assumptions hold.

In its simplest form, Playtesting just involves putting a player down in front of your game, and asking them to play it for you. They tell you what they think, maybe reveal a bug or two, and you walk away knowing a little bit more about how your intended audience feels about your work.

But playtests take a variety of shapes over the course of a development cycle (according to this talk from the ETC):

In the beginning, playtests are a form of exploration — you don’t know what questions you need to ask yet, so you playtest your own game to find out what you’re missing. It’s the process of building expectations.

Once you have a prototype, you start to refine your game — you can “tune” mechanics to make the game feel better, or smoother, and start to see if your expectations from before hold up. This is also when you can start asking more pointed feedback from your players.

Finally, when you’re out of prototyping and continue to test your game in its Alpha, Beta, or even Final stages, you start to “prove” your work to others — the playtests become an affirmation that what you’ve worked and iterated on reaches your goals in the intended way.

Benefits of Playtesting

We’ve said a lot about how playtesting is a valuable part of the game design experience, but we haven’t covered why that is yet. Here are just a few benefits that come with playtesting (again, from this talk at the ETC):

Playtesting helps you…

• Make a better game by identifying flaws and problems you didn’t know you had. This can include bugs, accessibility issues, or design problems.
• Test your assumptions about aesthetics, mechanics, and your audience.
• Make decisions — sometimes, you’ll hit a wall in designing some theoretical feature. In those cases, it’s often faster to just slap together a quick prototype and actually test it with your users.
• Save time by identifying features that players aren’t interested in. One of the worst things you can do to your pipeline is spend months developing a feature, just to find out that players dislike it on release.
• Build an audience of people who are interested in seeing your game at completion.
• Build a valuable skill set that is used across this industry (and many others)!

How do we Playtest?

At all playtests, we require there to be at least three people from the class attending — this is considered the minimum ideal staffing.

Why three, you ask? Well, each person is given a defined role that helps the session go smoothly, which are as follows:

The Technician

The Technician is responsible for running the computer at each playtesting session — sometimes, that might just mean hitting “Play”, or changing a value for The Designer. Other times, though, that means fixing any game-breaking bugs that are revealed during playtesting.

The Wrangler

All manner of players can show up at a playtesting session: from VR experts to “naive guests” that have never touched a game console before. In either case, a person in VR is very vulnerable to what is happening in the real world: they could trip on the cable connecting them to the computer, or run straight into a wall. The Wrangler’s job is to keep the player safe, and monitor their surroundings at all times

The Designer

Sometimes, playtesting sessions have to run a little bit like a game of Dungeons and Dragons, where one person has to guide the player through the game with their words. The Designer is responsible for giving the player context that might not yet exist in-game, and interview the player as the session progresses.

As you can tell, each of these roles is incredibly important, and while it is possible for one person to do each thing, it is much better to have one person handling each task (for the sake of the player and the quality of the feedback).

Playtesting in Practice

When we hold our playtests, we’re looking to answer a variety of questions centered around our design decisions: How does the game feel? How does it look? Do things do what the player expects them to do?

Of course, we can get these answers by asking the player questions directly (and that questionnaire is covered in the next section below), but sometimes the best thing a playtester can do is just be quiet and observe.

For example, sometimes a player won’t know exactly how to answer certain questions, especially regarding how things feel. In those cases, body language is your best sign. If the player is engaged and actively interacting with the world (like in the above image), then that’s a good sign!

In other cases, you’ll often find that playtesters ask a lot of questions when they’re playing, especially in early stages. A good Designer/Playtester knows when to answer these questions, and when to stay silent and observe; if you answer too many of their questions, after all, you won’t get to see how they figure out the problem!

Goals and Big Questions for Buggy100

You can read the detailed questionnaire that the Playtesting Team drafted here (Updated 2/7/2020)

Now that we’ve covered everything to do with how playtesting works, let’s talk a bit about what we’ve been asking our players these last few weeks. Since the prototype is all about testing your core mechanics, we focused on the following topics:

• Of the three available control schemes, which controls feel the best? Which are most intuitive?
• Of the two existing map types, which feels the most fluid? Does either one take too long or get boring?

The specifics of each feature have been covered in previous posts — See Weeks 03 and 04 — but here’s a short recap:

Control Schemes

• Handlebars: Player grabs both handles with the controllers, and turns it like a bike to control the buggy.
• Levers: Each lever functions as a “brake” for that side, so pulling back on the left causes the buggy to drift left, and pulling on the right causes the buggy to drift right. Pulling both causes it to brake.
• Steering Wheel: Functions like a normal car steering wheel — rotating counter-clockwise turns left, clockwise turns right.

Map Types

A major question for the design and art team has to do with the relative size of the map: do we keep everything at a 1:1 scale, or is does that make the uphill too long? If we stretch out the freeroll portion of the track to smooth out the curves, how does that affect the shape of the buildings? Do players feel like the race is too long, or is it not long enough?

To answer those questions, we generated the two map types above. On the left is the 1:1 scale map, and on the right is a “U-Shaped” map. We ran each player through each of these, and their responses gave us the information we needed to know.

Results so Far

• On-the-rails motion does not feel good — Players expected to have freedom and control when they drive, and the realization that they didn’t have that control quickly broke their immersion.
• Different players had different control preferences, but the steering wheel was the most intuitive from the start.
• There was no preference between either the U-Shaped or “Regular” 1:1 Scale Map — In fact, most players didn’t notice the difference.
• No one reported feeling any nausea during normal gameplay — “Normal,” in this case, referring to a bug-free playthrough.

Although playtesting sessions will often answer the questions you had originally set out to solve, they also have a funny way of bringing out unexpected feedback that make you rethink your original assumptions.

Take the first bullet above, for example. From the start of the development, we had been planning on implementing a form of “on-the-rails” driving system. Turning the handlebars, levers, or steering wheels wouldn’t actually turn the buggy — it would just make the player “strafe” from side to side on a track.

We designed the prototype that way believing that staying “on-rails” would reduce the chance for nausea and discomfort, with an added bonus: if the player doesn’t have complete control, we wouldn’t have to worry about what would happen if they turn around and drive backwards!

But across the board, our players kept saying that the strafing motion just “didn’t feel right.” In fact, one player effectively stopped playing once he realized he was on-rails — that realization took the fun out of the game for him!

When your players have such a strong reaction to a feature in your game, that’s a good sign that it’s time to pivot. Which brings us to the last stage of any playtesting session:

Responding to Feedback

After collecting the data and responses from your players, it’s important to really dissect what their answers mean, and think about how you’ll integrate their feedback into your design.

Since players had such a strong response to being on-rails, the Leadership Team had to revisit the decision to limit the player’s freedom-of-movement. At the moment, Buggy100 is much more of an “experience with game elements” rather than a full on game, a distinction that was causing frustrations.

So, we decided to pivot and implement a new driving system: “Free Drive”. In this system, the rails for the player are (almost completely) removed, and now serve more as a guidance system rather than a rule. The player can now turn as they wish on the track, and the rail system only kicks in when they approach the boundary of the track — gently guiding them back towards the center to prevent a crash.

Future Testing

Although we still don’t want to give the player full control, or else we’d have to figure out what to do if the player went backwards on the track, so far this new system felt much better to our players and will be a subject of much future testing

And sometimes, there’s more to playtesting than testing the gameplay itself. Playtests are a great time to get feedback on stuff like branding, aesthetic style, and even slogans. So, the Playtesting Team will be polling players for their thoughts on those aspects, as well as testing the new mechanics.

In this post:

• Art Progress
• Design Updates
• Looking Forward to Alpha

This Week’s Progress

Art

Game Elements

Although not what will be used in the final product, we have placeholder sprites for the boost pads and potholes that make up part of our gamification. These sprites are a part of the rapid prototyping process, allowing us to test these features before fully committing to their development.

Character Art and Animations

This week, our character modelers made progress on getting the pusher mascots ready for the game. Seen below, we already have 2/5ths of the pushers we hope to have by Alpha, leaving plenty of time for tuning and polish by the Beta and Final releases.

Pictured above, we also have our first pass at pusher animations (courtesy of Mixamo), with a distinct “pushing” and “running” state. Although future iterations will need to blend these two together — so that the character pushes and runs at the same time, like they would in a Sweepstakes race — this early animation will be used to help our animators get an idea of how running looks in the game.

Environment Art

Buggy Art

This week, we get our first look at one of the older-era buggies: The Keg!

Possibly one of the most unique buggy designs out there, The Keg will make its appearance at the start of our All-Star race.

To make the texturing and design job easier, one of our artists — Daniela Moll — has been drawing side-views of the various buggies. These side-views help fill in the blanks for our 3D modelers, especially when working with old buggies that don’t have many reference photos.

Lastly, we finally get to see what a fully-textured buggy looks like! As you can tell, just adding a texture makes the object really “come alive,” and feel like something taken from the real world.

Of course, it’s too early to call this buggy “done” — we have to see what it looks like with the rest of the in-game world first. But those final tweaks are yet to come, and will happen in the Alpha/Beta stage.

Design

The goals for design this week were to take the data received from the last week’s worth of playtesting and turn that feedback into the next round of designs. Additionally, we have new designs from the UI team and two “mesh types” that we had been testing!

“Free Drive”

After this week’s playtesting, it became clear that players aren’t enjoying the “on-the-rails” system that we were prototyping. It felt too limiting, almost restrictively so, and the impression of the average user was that they had hoped to have more control in a racing game.

Fortunately, that kind of discovery is exactly what playtesting is for! After some time going back to the drawing board, our programmers came up with a potential solution in “Free Driving,” which serves as a blend between total user control and the on-the-rails system.

This free-drive system gives the player variable control of their buggy:

• At the center of the road, the player has total control to move left or right, but has a limited range through which they can turn their wheels. This keeps the player from being able to turn around and go backwards on the track.
• Away from the center of the road, the player still has control, but their wheel will begin to “drift” towards center, subtly guiding them back to place.
• At the far edges of the road, this guidance ramps up, and keeps the player from turning too far towards the edge they’re at — keeping them from crashing into the wall or driving off-road.

This “guidance” system works much like Mario Kart’s lane assist feature, and (in theory) will keep the game feeling fluid without introducing design complications.

User Interface

The UI/UX team drafted a number of instructional User Interface layouts for each of the potential control schemes. Each of these layouts took into account the following:

1. The Time that the player has elapsed on the course
2. A Mini-Map to show the player’s location
3. A red brake indicator
4. Directional indicators to guide the player on the track (“Turn Left”)

This fourth type, the flight-stick, was introduced as a potential solution to players’ aversion to the on-the-rails system. However, since we pivoted into “free drive,” this control scheme likely won’t make it into the game.

Mesh Types

After the terrain was generated, an early concern was that the 1:1 scale map would feel too slow in the uphill portions (see the Week 01 discussion on “flow”). So an alternative map design was proposed, which would turn the track into more of a “U-Shape” — shortening the uphill sections, with the added benefit of smoothing out the sharp, potentially nauseating turns.

However, this alternate shape introduces a new problem: to make the U-Shape map work, several of the existing building models have to be edited or they will appear “distorted.”

Since playtests have been inconclusive regarding a preferred map type, with most players not even noticing a difference, we will likely continue with the 1:1 scale.

Sound

A goal for this month is to have voiceover present in the game, using placeholder voices for the time being. To accomplish this, the Sound team has begun building a script, complete with when the line would be played:

The reason for having voiceover in by the end of Alpha is to have it available for testing: we need to know if players benefit from having voiceover in the game, if it adds or detracts from the experience, and how well it plays with the other sounds in the game.

For now, the voicelines are largely one-offs, and don’t significantly contribute to a linear narrative or tutorial scheme. Instead, they give a sense of context to the game — which, if you’ll remember, was one of the core design goals in creating this experience!

Looking Ahead

As we transition out of the prototype’s development and into the Alpha stage, we’re looking to make progress towards creating what is known as a Minimum Viable Product. In other words, our game, at Alpha, should encapsulate our core features and what we expect the final game to look and feel like.

Art and animations should be present, even if they’re still rough and lacking polish. Game elements (like boosting and obstacles) should be present and functional, even if they need tuning. The mechanics from the prototype should feel smooth, and most large design decisions (like track type and control scheme) should be settled.

So, the goals for the future are as follows:

• Continue to produce buggies at a rate of 2 models per week
• Finish all (low-poly) building models by the end of Alpha
• Implement free-drive for testing

See you next week!

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!