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:

• 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!

• The Prototype
  • Early Art Models
  • Design Research
  • Coding Progress
• A New Design for the Racetrack
• The Buggy Roster

The (Early) Prototype

At this stage, the prototype is expected to consist largely of programmer art and have a fair share of bugs — that’s fine! Instead of actual polish, the intent behind the prototype is to give us a solid grasp of the mechanics to help answer our original design questions.

In other words, the prototype gives us the opportunity to test our hypotheses!

Art, Animations, and Modeling

This week, we saw a lot of the theory and research from the prior weeks put into practice. Although a lot of this isn’t set-in-stone yet — animations will be tweaked to match the feel/speed of the game, textures are incomplete without shaders, and building models will get altered to fit the course — the current artwork is a strong jumping-off point for the future.

Character Animations

Environment

Buggies

This week, we got to see our first rough model of a buggy — it’s missing wheels and textures, but even a basic model lends a lot to the feel of a prototype. It’s the difference between playing a Buggy game and just racing cubes!

Design

Accessibility

The accessibility team spent their time this week researching existing controller types in different VR racing games. Interestingly, they found that a number of games elected not to use in-game, diegetic controls (like digital steering wheels that you interact with in-game, using the VR controllers as hands).

Instead, a number of games (like Assetto Corsa above) used gamepad controllers to control the vehicle. The benefit to this is that the designers can rely on existing control standards — joysticks can be used for turning, buttons for acceleration/deceleration, and so on — instead of having to “teach” a new control scheme.

Since Buggy100 is meant to be a bit more authentic of an experience, replicating the controller design of the above steering wheel might be a bit of a stretch. Instead, the takeaway here is that we should consider having the physical controls match the in-game controls as closely as possible.

Content

The content subteam spent the last week gathering research on what needs to be shown on the spectator view — the secondary screen that will be constantly displaying information on the game, in real time, to spectators as they wait in line.

UI/UX

The UI/UX subteam sketched out two possible layouts for a User Interface (below). They focused on capturing the essential information for the player: Speed (shown by the small running figure), time elapsed, and progress through the course.

These designs, of course, are still early ideas, and are only indicative of one possible control scheme. Additionally, they don’t account for any additional HUD-type display, which may end up being used in the game.

Code

Controls

The following control schemes have been coded into the game, based on proposals from the design team:

• Bike Handlebars – Used just like you would on a bike, with the ability to use the handle-brakes to brake
• Levers – Pull back on the left lever to turn left, the right lever to turn right, and both to brake
• Steering Wheel – Maneuvers just like a car steering wheel

Of course, we won’t be using all of these control schemes in the final game. In fact, most of these will get cut before Alpha! But it’s important to have each of these implemented at the prototype stage for testing purposes; in order to make an informed decision regarding what is best for the player, we need actual playtesting data. And you can’t playtest without implementing the designs in question!

Rival Buggies

Although it’s difficult to see in the above GIF, the Rival Buggies have been programmed to follow any track they are given. They can be assigned “lanes,” putting them in different starting positions from the player, and gives the appearance of them racing around the track.

Over time, this will be tuned to create different speeds for each buggy that reflect their real-life counterparts. Additionally, they may be given more complicated behavior to make the race feel more life-like (the extent to which this will be done is a question for playtesting).

The Course

Using satellite image data, we were able to generate an accurate, 1:1 scale terrain (or “mesh”) of the course and the surrounding environment. Unfortunately, the data is not perfect, and captures a lot of extraneous information: cars, treetops, and other objects appear in the data as floating blobs around the track.

Subsequent iterations will have this terrain cleaned up, and real models put in place of the amorphous blobs that currently exist. For now, though, this mesh will be used to help place the track for the AI buggies to run on and get a rough sense of what it feels like to race around the course.

Other Notes

The Historical Archives

In addition to everything else above, we took a deep dive into a terabyte-sized amount of historical data (ranging from the photos you’ve already seen to newspaper clippings and more).

Although the initial intent was to gather additional images from the archives to use as reference images, we came across a surprising bit of new (old) information. Namely… the original Sweepstakes course from 1923!

As you can tell from the images above, the original track took a very different path — at least at the start and end. Instead of beginning at the bottom of the Tech Street hill, in front of Margaret Morrison, the buggies began and ended in the middle of CMU’s campus!

This realization inspired a redesign for Buggy100’s track: instead of directly recreating the modern track, we can bring back a piece of the original track — paying homage to the origins of Sweepstakes, shortening the backhill section (which feels very slow in VR), and has the player finish the race in the middle of carnival, right where the Alumni Tent will be!

Although this new track design introduces a bit of a scope problem in regards to art assets, we believe that this can be mediated with careful planning and that the design benefits outweigh the risks.

The Buggy Roster

Of course, we can’t have a Buggy game without actual buggies! This week, our Art and Leadership teams finalized the roster of buggies that will be making an appearance in the game.

This roster was curated from a list of historical buggies — provided to us by the Buggy Alumni Association as a result of their surveying the various organizations involved — and the selections had to be made using a variety of qualifications:

• Is the buggy in question unique in some way?
  • This primarily refers to being visually unique, to ensure a wide variety of buggies in the game
• Do we have the visual references we need to create an accurate model?
  • This is especially important for older buggies
• Does the buggy in question have historical significance?
  • Especially for our spectator view

Click here for a sneak peek at the list we put together.

Looking Ahead

Bugs in Buggy

Now that we’re firmly in the implementation stage of the development process, with our early prototype “out in the world,” this is when bugs start to show up. Bugs — mistakes in code that cause unintended and often undesirable effects — are common to all games, especially at early stages in development.

Of course, Buggy100 is no different, and our programming team is hard at work squashing those bugs. This past week, we encountered the following bugs:

• Testers can’t swap between control schemes — Squashed!
• Player can drive off of the map — Cause identified, solution underway
• VR Headset not being picked-up in-game — Squashed! Hardware error

Goals for Next Week

• A completely greyboxed environment
• Textured buggy models
• Resolving this week’s bugs to create a stable build

And since we ran out of time to cover playtesting in this article, expect a separate post on that soon.

See you next week!

• Team Progress
• Production Tracking
• Behind-the-Scenes
• Looking Ahead

Team Progress

Art

This week, the art team divided into pairs of people who were responsible for researching and creating different assets:

• Character Modeling and Rigging – These people will be handling the creation of the drivers, pushers, and crowds that populate our game.
  • This also includes any necessary animations, such as cheering, pushing, and running.
• Buggy Modeling and Rigging – You can’t have a Buggy game without buggies! The goal for the prototype is to have two buggies at least partially modeled — enough to get a sense of what’s running around the track, but not any final designs.
• Shader Testing – To get the art style we set out for — that sort of cartoon-y, semi-realistic look — a subset of the art team will be testing and researching shaders to put a bit of polish on the game world.
• Environment – These people will be creating the buildings, trees, and landscape that make up the racetrack. For the prototype, everything will be grayboxed — meaning that we will have placeholder buildings that fit the proper dimensions to give a sense of space, but no real “detail” just yet.
  • UI – Pending the conclusions from the Design Team, the UI artist will be working to turn concepts into a reality.

Design

The design team was hard at work this week, with each member assigned a specific racing game (VR or not) to research even further. Although this had been done over winter break as well, our new design goals gave us new lenses through which to interpret things.

This research brought up a few new and interesting ideas:

• Many racing games utilize in-game, or diegetic UI — this seems to help the level of player immersion, while still conveying valuable information.
• Some games, like Mario Kart Arcade and DiRT Rally VR treat the vehicles motion separately from the player’s view — if the car starts to tip over or spin out, for example, the player’s view remains stable.
  • Turning, however, seems to be a mostly 1:1 action.
• A number of games utilize “cockpits,” as seen above — this might help players feel more grounded (thereby reducing nausea), while still maximizing visibility.

Beyond that, we also heard the results of new interviews with Sweepstakes pushers and drivers. A link to the questions asked can be found here, and here are some of the takeaways:

• The countdown is exciting – People start to cheer as you get close to starting.
• The chute, top of hill 2, and the finish line are the most exciting moments.
  • This confirms what we had heard earlier.
  • Interestingly, we were also told that you hear and feel the finish line more than you can see it.
• The road is very loud, so it’s hard to hear people talking to you.
  • But you can hear vague mumbling, “which is important.”
• The track is very bumpy.
• Leaves on the course would be cool to see.
  • This could be an additional mechanic, similar to the potholes: driving into a pile of leaves could slow you down slightly, introducing a new obstacle

While not all of these responses will be applicable to our game (for example, the player buggy will have an upright/seated design, so the player won’t be too close to the ground), they still offer a significant amount of insight into what makes the race fun.

Lastly, since the design team had nearly doubled since the first class session (due to several new additions to the class), they were divided up into several different sub-groups, each assigned to handle a different aspect of design.

• Sound Design – Handles the music and SFX to convey subtle emotional cues and information.
• UI/UX Design – Collaborates with content design to create the spectator view setup, but focuses on creating intuitive in-game UI.
• Content Design – Ensures that the game contains the lore, history, and authenticity of the buggy experience. Also tasked with defining a narrative (including voice-over scripts) and designing the physical experience at Carnival.
  • In keeping with Design Goals #3 and #4, Contextual and Authentic
• Accessibility – Tasked with creating intuitive controls that can be used by anyone, are easily explained, and are not restrictive.
  • In keeping with Design Goal #1, Intuitive Controls

Programming

The Programming Team is well underway, with each of its members handling their tasks independently. While most were working on back-end frameworks, they have now shifted into handling tasks like Control Schemes, Gameplay, and AI Motion.

Come next week, they will begin to integrate everything together into a functional prototype.

Production Tracking

You might recall theis milestone chart from our first dev post:

And while such a chart is an important early step, it isn’t quite enough for a truly robust production tracker. It’s a framework, used to get team leads started with task breakdowns and expectations, but it can’t be used to gauge our progress. For that, we need a different tool known as a “burndown chart.”

Burndown charts are a valuable production tool that provide a producers and managers with a big picture view of a project, while allowing (in fact, requiring) individual task tracking. In the above image, the red line shows the idealized projection of remaining work hours; the blue line is a linear projection of the actual work you have remaining; and the fine orange peaks on the bottom show the amount of work done on any particular day.

• If the blue line meets the x-axis to the left of the red line, your project is either underscoped or you are under-estimating the number of tasks you have on hand (the latter is true in this case: the model is still a work-in-progress and is not comprehensive)
• If the blue meets the x-axis to the right of the red line, your project is out-of-scope. In other words, your project has too many components and some features might need to be cut.
• Lastly, if the blue and orange lines meet the x-axis at similar points, then your project is on track. This is the ideal situation, and a burndown chart should be constantly updated and your project re-evaluated at regular intervals to ensure this is the case.

Additionally, it will be necessary for team leads to communicate with the producer, executive producer, and their team members about the tasks that need to be done, are in progress, or have been completed. To do so, each Team Lead will be using Trello, a free service that functions as an online “scrum board,” to track individual tasks before they can be transferred to the burndown chart.

Behind-the-Scenes

Looking Ahead

In the coming week…

• a subset of the class will be participating in the Global Game Jam, as a bonding experience and to kickstart both creativity and technical practice.
• we will see the first iteration of our project come to fruition in the Early Prototype, and have our first playtesters try out the game!
  • Playtesting will provide us with valuable design information that will guide future development — more on that next week!
• Lastly, we’ll also see the results of the research from the design subteams.

See you next week!

Although this site will be used by other members of the team (including Thomas Corbett, our professor and Executive Producer) for various posts, most of the development blogs you see here will be written by me. Although this post (and the next, for Week 02) are written out-of-sequence, there will be regular posts going live every Monday evening starting next week (on February 3rd) unless stated otherwise.

For now, please pardon the delay as we get settled in to the semester, and I hope you enjoy this peek behind the curtains to see what’s going into this massive undertaking!

The Project

This semester, the Advanced Game Studio is banding together to create a Virtual Reality game entirely unique to the Carnegie Mellon experience, in celebration of the centennial anniversary of the Spring Carnival and the phenomena known as Sweepstakes.

Sweepstakes or, as it is more commonly known, Buggy, is a “student-led relay race” held once a year at CMU’s Spring Carnival.

But it’s so, so much more than that — it is no exaggeration to say that Sweepstakes is the culmination of design, engineering, and athletic effort as students team up to build “an aerodynamic vehicle with no engine… Powered by brains and brawn alone.” ( https://www.cmu.edu/buggy/ )

In other words, CMU students get together and build this buggy over the course of the year, engineering it to be as fast as possible, and train almost every week at the crack of dawn to be prepared for race day. It’s a commitment for sure!

The race itself takes place on the above course, with a mixture of uphill and downhill sections. The organization with fastest buggy to reach the finish line wins!

But Buggy is easier understood with visuals than words:

While Buggy is something that everyone at CMU has heard of, if not seen, few have actually participated in it; the hours are rough on a student’s schedule, and the size requirements to be a driver (you must be smaller than 5’3″) mean a lot of people can’t take part.

What that also means, though, is that we have less than 95 days, from the start of the project, to create a full, standalone experience that can be showcased to the general public: a public that would include buggy veterans and novices alike. The project must bridge old and new, celebrating the history while giving newcomers a taste of the excitement around buggy — even if they’ve never taken part.

Which brings us to…

The Game – Buggy100 (Working Title)

To celebrate the Buggy Centennial, we were asked to create a game that takes the player “through time.” Now, while a time-traveling buggy sounds amazing, we decided that it would be more in the spirit of Buggy if the player actually raced — and what would be better than getting to race against the buggies of history? Competing to see who, over all 100 years, really had the best buggy?

After all, the Buggy Centennial is likely to be the biggest celebration in Buggy history!

So, with that in mind, we developed the following story setting:

The year is 2020.  For the 100th anniversary of Buggy, the President of CMU has invited everyone, across Buggy history, to compete, to see who had the best buggy of all time.  Various buggy organizations have entered, hoping to take that coveted title and the Buggy Cup, using their famous buggy designs.  This is… the Buggy All-Stars race!

The player has been appointed as the pilot of the Alumni Association’s buggy, a high tech buggy  whose design is inspired by old and modern buggies.  Can you take first place in the ultimate buggy race?

– story blurb by Eric Yu, Art Lead

Of course, there’s a lot that is going to have to go into the development of this game to make it feel like you’re going through history, and that’s something that we’re still figuring out. But the gist is this:

• The player will race against historical buggies
• There will be some sort of announcer/spectator setup that showcases the other buggies in the race
• The game is set in the present-day, on the day of the Centennial celebration
• The buggies will be split into “eras” — at the start of the race, the player will see more of the early, 1920s buggies. But, as they progress through the race, they’ll start to encounter more modern buggies; in essence, they will be “passing through time.”

The Team

From the start, we knew that this class would not follow the usual group-project structure — or number. While a typical game design class has students divide into groups of around six people, this class has a total of 18 to 20 students, all working on the same project. Even a group of eight can become unmanageable — at 20, it’s almost impossible to communicate and assign tasks effectively!

For that reason, it was decided to break the class down into distinct “teams”, which (for all intents and purposes) mimic the departments you would find in a small video game studio. Art, design, programming, sound, and so on.

Each team consists of roughly 4 to 8 people, with each student sorted into their teams depending on their particular skill sets and interests. Of course, there is some occasional overlap and redundancy — some members of the art/programming team also have a role in the design team, and vice versa. As a result, teams are inherently built to be cross-disciplinary and reinforce communication.

Each team also has a designated “Team Lead,” who is responsible for assigning tasks to those in their team, managing expectations, and communicating with the other leads.

The team leads are as follows:

• Executive Producer: Thomas Corbett
• Producer: Trento von Lindenberg
• Art Lead: Eric Yu
• Design Lead: Adela Kapuscinska
• Programming Lead: Angelo Pagliuca
• Playtesting Lead: Nicole Chu

Technical Details

To create Buggy100, we will make use of the following software (at least, additional software will be added on an as-needed basis):

• Game Engine: Unity
• Modeling Software: Blender, Maya, Substance Painter, Mixamo
• Audio Software: FMOD, Pro Tools
• Version Control: Perforce
• Other: Discord (for communication), Trello (task management), Google Drive (file management and documentation)

And now that we’ve gone over what the project is, who is involved, and what we’ll be using for it, it’s time to get into the actual development side of things. Starting with…

Pre-Production

“Before anything else, preparation is the key to success.”

– Alexander Graham Bell

To capitalize on the free time available to us over winter break, the leadership team held regular meetings to establish the basics of our design, production schedule, and an early timeline. By using this time to get everyone on the same page and hammer out some basic design concepts, we hoped to hit the ground running at the start of the new semester.

Additionally, the time spent discussing the specifics of how the game might work brought up a number of valuable clarifying questions. For example:

• How will turning/other mechanics work?
  • Or, more specifically, “How do we keep people from getting sick?”
• What features do we need in the game?
• How will we keep track of and document our progress?
• What definitively makes this Buggy?

Although we were able to reach satisfying conclusions for some of those questions (after all, you’re reading a piece of documentation right now!), others are still a work in progress — and will continue to be for many, many weeks.

So, the pre-production period was valuable to us as it gave us time to think over those questions and others. But it also gave us time to familiarize ourselves with the ins and outs of Sweepstakes: some of us took to reading the official rulebook, while others scoured the CMUBuggy website for photos and videos of races to add to our historical references. For many of us, this was the first time we had ever heard of the terms listed at the beginning of this post.

We also looked to existing games (seen below) for inspiration, selecting a few based on their art style, mechanics, and genres, and collected those to form the early beginnings of our design documentation.

Using these references, each member of the art team was assigned a part of the game that needed concept art. Some were assigned character work, others environment design, and others drew the buggies themselves.

And so, pre-production carried on, with everyone working on some aspect of the early design. Weeks passed, and that brings us to…

The Post-Break Check-in

At the end of break, the students got together to touch base and show off their work. Here is just a small (but impressive!) selection of what was presented.

Art

Taking inspiration from the reference images, our artists put together the above pieces of concept art. Although they might seem simple at first glance, these will go a long way to guide us in the coming weeks!

Design

Goals

The design team was tasked with researching existing racing games (both VR and traditional) in order to determine any standards or conventions that exist. Additionally, they were asked to prepare a set of “design goals” which would become a part of a living “design document.” The goals are as follows:

1. Intuitive Controls – Bridges Buggy enthusiasts, VR aficionados, and new users
2. VR Fun Ride – Well-executed, replayable, and appealing to many audiences
3. Contextual – Incorporates Buggy 100 content & lore
4. Authentic to the Buggy experience

You can think of the “design goals” as a framework: they’re meant to guide our choices, and help determine what features should be prioritized, emphasized, or pushed aside. By adhering to them, we can keep the final product in-line with the spirit we set out to create — even if it might look drastically different from what we first expected.

Mechanical “Rules”

However, there also exists a list of stricter rules, drawn from research and requests from the client:

1. Buggy is in constant motion
2. The Player will be seated upright, or leaning slightly forward
   • This is due to accessibility considerations — not all of our players will be able to get into the modern-day buggy position
3. Player steers via controllers
   • But steering is more like strafing than turning
4. Drifting is only a visual effect
5. Brake is present but not significant
6. Player cannot crash or collide with other buggies
7. Player is trying to stack up speed
   1. Dash Panels
   2. Special Panels (Crest, Top Flag, Chute Flag, Pusher Handoffs)
   3. Draft/Slipstream (by following a different buggy)
8. Player may run into potholes (which takes away their speed stack).
9. The Player (almost) always places

Much like how the design goals guide our features, these mechanical rules influence the next item on the design agenda: Game Elements.

Game Elements

• Boost Pads – Inspired by Mario Kart-style games, some form of boost pad might be ideal to give the player a sense of agency and control.
• Potholes – Creates a mechanical obstacle that players will have to navigate around, inspired by real-life.
• Drafting – Inspired by other racing games, players can “draft” behind other buggies to get extra speed.
• Passing – The more buggies the player passes, the more they’ll see.
• Unique Events
  • Timing – What’s a race without the need for speed, and Buggy wouldn’t be Buggy if you weren’t up against the clock! Players will need to race to be the fastest if they want to get the top time against history’s buggies!
  • Flagbearers – Timing your turns to enter a passageway at just the right time might give the player a boost.
  • Pusher Handoffs – Similarly, navigating to your pusher could help players shave those precious seconds off their time.

Although these elements are still in the early concepting stages, they all have one specific purpose: to turn the Buggy100 VR experience from a strict simulation into a true VR game.

The Interest Curve

All of these elements (design goals, mechanics, and game elements) are brought together to form what will become the user experience in our game. To decide how they come together, though, designers use something called an interest curve.

An interest curve, as you might suspect, is a simple chart showing how interested someone is in something, plotted over time. Your typical interest curve for a game, movie, or any other piece of media will typically fluctuate: peaks of excitement are contrasted with relaxing lulls. And that’s a good thing! Too much excitement can lead to a forgettable experience that tires out the mind; just try to remember the plot of the last action movie you saw! Conversely, too many lulls can lead to a… boring and monotonous experience.

So, what matters is not how many peaks or lulls you have, but that the interest curve a) trends upwards and b) ends on a climax! In other words, to have a truly memorable experience, you want your player to walk out of your game with the most exciting moment most fresh in their mind.

Since our game shouldn’t be much longer than three or four minutes, a much simpler curve (seen to the left) is good enough. The main takeaway here is that, like above, our ideal interest curve (in red) needs to have the climax the game be at the end of the game — as the player crosses the finish line.

But this introduces a design challenge: from the interviews we’d gathered, the exciting moments of a Buggy race are when the driver first crests the top of Hill 2 and when they go into the “chute” turn at the bottom of the freeroll. In other words… that leaves a whole third of the race left after the climax!

To solve this issue, the design team must bring together all the elements they’ve collected to turn the current interest curve (in black) to the ideal interest curve (in red). But how exactly that will be done is a topic for playtesting… and future development!

Looking Ahead

With such a large project, it’s crucial to have an early idea of your deliverables, deadlines, and milestones. Additionally, we had to consider major university holidays (e.g. Spring Break) and events (e.g. Game Developer’s Conference, Global Game Jam) which will interfere with the usual work schedule.

With those constraints in mind, we created the following table of major milestones, dates, and expectations:

With only two weeks to the first milestone (our prototype), there isn’t much time to lose! Everyone will be hard at work in the coming weeks: The design team will be researching additional game elements and control schemes to hand off to the others for implementation, while the others will be modeling “grayboxed” art and coding together a functioning game!

See you in the next update!