Unlike previous spotlights, this post will first provide a run-down of the four aforementioned items and how they work, and then return to our usual Q & A format.

Caffeine Boost

“Use this coffee to get a temporary speed boost!”

Inspired by La Prima and the other iconic coffee spots on campus, this caffeine boost will give our buggies a short burst of speed, perfect for cutting off opponents or taking the lead in the final stretch to the finish line.

Tartan Distract

“Wave your CMU banner to distract your nearby opponents!”

Our heart is in the work, and this item shows our Tartan pride! When a player or CPU uses this item, any enemy buggies caught in its vicinity will slow down and lose their momentum.

Slippy

“Drop this wet water sign behind you and watch your opponents spin out!”

Pittsburgh is well-known for its interesting dialect. Paying tribute to our Pittsburghese, we have the “slippy” — because why use “slippery” when slippy has fewer syllables?

When a player or CPU uses this item, a puddle of water will form behind their buggy. If a buggy drives into this water and tries to turn, it will “spin-out,” losing control temporarily.

Gumband Ball

“Attach a gumband to your oppponents ahead of you and slingshot past them!”

And here’s yet another example of classic Pittsburghese! In Pittsburgh, we don’t have rubberbands: we have gumbands. The player and CPUs can use this item to launch a gumband forward. If the gumband attaches to another buggy, the user will be flung forward to overtake that buggy.

Q & A

For our questions, we will start with Kathryn-Mae and how these items were designed; then, we will go into the programming of these items with Kalpa and Angela.

Kathryn-Mae Eiland – Design

Q: How did you decide on what items would be in-game?

A: “I feel like it was a bit of a leadership roundtable choice. I came up with a pitch/idea for 4 different items – some that seemed good and some that seemed rocky. Then as a group we (the production team and art and code leads) talked through them to help make them more unique. This part took weeks of slow tweaks. In the end, we ended up throwing out one of the items and adding in another so there were 4 in total that feel like a good start.”

Q: What inspired these in-game items?

A: “I would say the games I mentioned before [in a previous spotlight post] were the inspiration, with Crash Bandicoot and Mario Kart being the biggest inspirations.”

Kalpa Anjur and Angela Zhang – Programming

Q: How did you approach implementing these items?

Kalpa: “Since the items were going to be used in a similar way, I started off with an interface and based the item classes off of that. With help from Angela, we also had an interface for using the items and had the players/AI utilize that. Then, we just had the items either instantly work after use (like the caffeine boost) or create a prefab on the track (like the Slippy puddle).”

Angela: “For me, I started off with taking the specifications, and trying to draw parallels to other games – for instance, the caffeine acts as a standard speed boost seen in many other racing games, like Mario Kart. After that, it was a matter of determining what effects needed to be applied directly on the buggies: increasing/decreasing speed, shooting forward, being pulled backwards, etc. Because similar effects needed to be applied on both the player and the CPUs, Kalpa and I worked a lot on generalizing the actions as much as possible, and created interfaces for both the item and the item-using classes to reduce the amount of repeated code.”

Q: Were there any items that were difficult to implement?

Kalpa: “Definitely the Gumband Ball, by far. Iterating over its actual functionality, getting the animation to look decent, and making sure the item felt okay to use were especially difficult for the Gumband.”

Angela: “I think the Gumband Ball might have been the trickiest – we had to determine when a buggy was in front of the user of the item, and shoot that user forward. Our first iteration of the Gumband was also a little trickier: in the beginning, the Gumband item would need to “hone-in” on the opponent buggy it finds and follow it (similar to a red shell in Mario Kart). It took a while to fine-tune this, as we had to make sure it wouldn’t just hone-in on a buggy right next to you and fling your buggy backwards!”

 Q: How did you approach balancing items?

Kalpa: “A lot of trial and error. Testing it out a lot, getting playtester input, and generally making comparisons to similar items in other games was helpful in determining the optimal settings for each item (even now, we’re still making adjustments)!”

Angela: “When writing all the parts for the items, we had a number of parameters that could be easily adjusted: size of the AOE (area of effect) for specific items, how long the effect would last, etc. I think there’s just been a lot of iteration on these values to figure out what feels right!”

Q: Did you have any input in what items are implemented?

Kalpa: “Some of the ideas were a bit vague at first, so we had some leeway in implementing them in a certain way until design solidified the ideas. For example, the Gumband and Tartan Distract used to behave like green shells from Mario Kart and target other players.”

Angela: “There was a lot of discussion-specific implementation details, such as whether items should have a local AOE, if they should shoot off in a direction towards an opponent, or affect everyone on the track. The final results in the game now were the result of a lot of back-and-forth between us and the design team!”

Q: What was the most challenging part of implementing these items?

Kalpa: “In addition to the balancing, as mentioned earlier, it was also just solidifying the functionality of the items. For example, the Tartan Distract was implemented in a variety of different ways before actually settling down on the final version, which is what you see today!”

Angela: “I handled most of the CPU interactions with items, and there were two main challenges. First, from a technical standpoint, the NavMesh “navigation” component of the buggies would need to be carefully enabled/disabled to give me more control over the buggy’s motion when a power-up was in progress. The spinning animation for a slip effect, for instance, wouldn’t work correctly if the NavMesh component still had full control over the buggy!

The other main challenge was ensuring that the power-up effects would be clearly visible to a player. This was accomplished by adding somewhat “cartoon-y” effects to how the AI responds to hitting a Slippy puddle, or a large burst of speed upon using a caffeine power-up. I think exaggerating these effects gives a much better indicator to the player on what the CPUs are doing.”

Closing Remarks…

Thanks to the hard work from Kathryn-Mae, Kalpa, and Angela, we’ve got four items to spice up our gameplay. A pivotal part of our project is the items buggies use — making Bigger, Badder, Buggier the “baddest” buggy game yet!

Q: What software do you use for 3D modeling, and why? What about this software works for you?

Hagan: “For this class, I use Maya for 3D modeling and sometimes Rhino 5 for getting the bigger picture of a space. Maya is good for maintaining a good meshflow, making those who texture’s life easier. Maya is fairly good at taking a base shape and editing it to get the final product. This process is called box modeling.”

Lisa: “I work in Autodesk Maya honestly because it was what I was told to use. I had started with Blender but then switched to Maya. Since it’s industry standard, I decided I may as well switch over and learn it.”

Nick: “Blender 3D, [because it is] open source, free, [with] many high-quality tutorials online.”

Q: What’s your method in creating 3D objects? Freehand/organic, structured and articulate? How would you describe your process?

Hagan: “ For creating props and buildings, box modeling is the style that I’ve been using for this class, it tends to be a bit more structured with the modulation of the object itself to feel more organic.”

Lisa: “Honestly I still don’t know my method. I start from a cube and then extract and use edgecuts to shape it. It’s kind of like a puzzle, trying to see where to cut it to both make it look nice but also have good mesh flow. Mesh flow was why we were taught to use the box method instead of just smooshing 3D objects together.”

Nick: “Pretty freehand, usually starting with a primitive like a cube or a sphere, then extruding / manipulating the shape from there. I mostly do hard-surface modeling, so it’s mainly just manipulating vertices and adding extrusions”

Q: Have you worked in large groups/projects before?

Hagan: “I have worked in a bunch of other team projects before, though nothing quite like AGS where there are multiple teams coming together to make one product. I quite like the process of this class and I wish I had taken it on a semester that I was not overloading so I could devote a bit more time into it.”

Lisa: “I’ve definitely worked in large group projects before! I was actually in this class last year as well. It’s definitely nice to work in this type of environment which has been very supportive and allowed me to learn the 3D Pipeline skills. This year definitely has been a lot more relaxed than last year, although a big part of that probably has to do with me knowing a decent amount more than last year. Plus there is art from last year to go off of.”

Nick: “I’ve taken Reality Computing and Researching Issues In Game Development, so I’ve had experience as a 3D modeler in a group setting for game design. Because we have so many modelers at AGS, I feel like the workload is a lot lighter compared to other classes with smaller groups.”

Q: What is your favorite artistic element of this project?

Hagan: “Of what I’ve done myself, the finish line, but I really love the concept art that Vivi came up with and how it has translated into the game over the course of the semester.”

Lisa: “I really like how we have a distinct style which is really cool. I never really understood how art styles come to be, so it was fascinating to see it come together.”

Nick: “I personally like the low-poly style mixed with the painterly textures. The game has a very unique aesthetic.”

Closing Remarks…

Thanks to the hard work of Hagan, Lisa, and Nick, our cartoony, low-poly style has come to fruition. In the upcoming weeks, we will continue fine-tuning our art assets, excited to soon release our game to public!

This blog post will be a bit longer than our previous entries. We will continue with our Q & A format, first interviewing each student individually, and then coming together at the end to discuss their shared work.

Emil Balian

Q: How did you approach creating our buggy driving mechanic?

A: “The main approach to the buggy driving mechanics was to maintain relatively simple arcade vehicle physics (i.e. not get bogged down in complex traction and/or real car simulation), and to design a driving system with parameters that can be extended and tweaked easily, vehicle by vehicle. Our system was built from scratch with no pre-made scripts or aids, just using Unity’s physics engine, which allows us to have close control of all physics of the buggy. “

Q: What different elements must you consider when creating the driving mechanic?

A: “Creating physics-based systems can often get complex just by virtue of the number of parameters one has at their disposal to tweak and change. Because of this, you have to consider which elements are most fundamental for the game at hand. Given the huge buggy roaster, driving mechanics and visuals may need to be adjusted buggy by buggy due to the variations in size and shape over the years, but the basic underlying system is the same for each.

Our buggy has two core independent components: a physics proxy to determine the driving and physics, and a visual component. Under the hood, each buggy is some variation of a basic rectangle shaped vehicle with differing size, speed, acceleration, traction, etc, which can be tweaked from a prefab. For the visuals of the buggy, a model is added over which scales appropriately with the size of the physics proxy and does things like placing the wheels in the appropriate position and orientation with information from the physics proxy.”

Angela Zhang

Q: How did you approach making CPU opponent buggies?

A: “There were a few guidelines in the original design of the CPU components that I used to shape how the current code was. From the very beginning the different requirements included:

• CPUs must be able to navigate a track
• CPUs must be able to use and be affected by items
• The CPU system should be easily adaptable for other tracks

The initial week of designing the CPUs were a lot of trial and testing of different AI systems in Unity. I spent some time working on both MLAgents, NavMesh Agents, and coding an AI system from scratch. After some feedback from the other programmers, we decided the NavMesh Agent was the best way to go – it was easily adaptable to newer tracks without requiring too much setup.”

Q: How do you train your CPUs, both to move and to use items?

A: “The moving portion of the AI is mostly handled by the NavMesh portion of each of the CPU buggies. The base library handles setting a destination and basic movement of an agent to that destination.

In the first iteration of the CPUs, we found that the movement needed to be tweaked to prevent the CPU buggies from just hugging the edge in an attempt to get to the final destination. We solved this by setting incrementation checkpoint destinations along the track to make driving look smoother.

Another aspect that needed to be adjusted was collisions with the CPU buggies; at the beginning, running into a buggy would be similar to running into a wall. There needed to be additional controls to ensure a sort of “bounce-off” effect would happen and make the collision seem more realistic.

For items, the current CPU code doesn’t do anything special; if an item is picked up, the CPU uses it instantly. I’ve been working on making the CPUs more intentional and having them use the items in a more competitive manner – coming soon!”

Emil and Angela

Q: What’s it like trying to find balance between too fast and too slow when adjusting speeds? How do you test difficulty as a player versus the AI?

Emil: “Mostly trial and error, changing specific parameters and running the game again in editor is pretty much the only way I have done it. Since the AI and driving system evolve week by week, my focus while doing the driving mechanics (during development) is to make sure that it is a speed similar to that of the AI buggies, but beyond that my focus was mostly on making the driving feel good itself. Given the system we have put in place, it will be very easy to tweak these values for difficulty later on in development (like around now-ish time wise) which was the plan, but earlier in development that was not necessarily the main focus since things change quite easily.”

Angela: “This has been tricky so far – the player code (and therefore the player buggy speeds) have been adjusted numerous times throughout the development of this game. For the most part, speeds for the CPUs have been set at random within a given range that would hopefully make them feel competitive, but not unfair. 

There is also a rubber-banding system with the CPU buggies; depending on their relative positions with respect to the player, they will incrementally adjust their speed to either catch up to the player, or give the player a chance to take the lead.”

Q: How does your code rely on your teammate’s? What’s it like working with this codependency?

Emil: “This might be a question that Angela can answer better, since the player and AI systems have been not-so interdependent until recently.”

Angela: “There’s a lot of dependence between our two portions of code! Along with having to balance AI vs player speed, the general relationship between the player’s actions and those of the CPUs means there’s a lot of back-and-forth tweaking that needs to happen. 

For instance, something that was an issue in a previous week was needing to balance how a speed boost and/or caffeine power-up affect the player versus a CPU. A CPU buggy was able to immediately change its speed, making it appear to be much more affected by the speed boosts than the player’s buggy, which would instead gradually accelerate. We ended up changing up how a player reacts to the boosts to be more similar to the CPU system.

It is a little tedious to perform all of these adjustments, but I think there’s also a large benefit in seeing how someone else approaches coding the same features for a different purpose, then figuring out how to make them work together.”

Q: What has it been like working in a team of fellow coders?

Emil: “Everybody working on the code team has been great and working on games with other people is loads of fun. We naturally have taken up our own areas to become the go-to person for so everybody knows their stuff and there is a lot to learn from one another.”

Angela: “It’s been a really fun experience! I’ve enjoyed seeing everything come together and the progress we make with each new week. This was my first time working on a driving game, and I’ve learned so much from working with others on this team. Through both seeing my teammates’ code in various components and discussing approaches to different problems, I think I’ve definitely grown as a programmer, and I’m super excited to see how our game turns out!”

Closing Remarks…

Teamwork is essential to our project’s development, and thanks to the hard work Emil and Angela put in, our game’s code is progressing nicely. In the upcoming weeks, we look forward to seeing how our driving and CPUs will evolve!

Using our Q & A format, we will see how Jonathan manages the Code team and keeps our project running smoothly. 

Q: Have you led previous code-based projects?

A: “Nope. I’ve been on a number of coding projects, both games and software, but this is the first time I’ve led a coding team.”

Q: How do you approach assigning tasks to your team members?

A: “At the beginning of the project, I was familiar with a few of my team member’s past work so I had some idea which areas they would be able to tackle. I also tried to take into account anyone’s desire to work on a feature, because it can really suck being assigned something you have no drive to work on, and different areas of implementation can offer different challenges to tackle. At the current phase of our project, a lot of assigned work comes down to two questions: “Who is free to have more work assigned?” and “Who was the last person to work near that feature?” With so much of the core game built out, most of the things that code is working on now builds off of what is already there, so I try to make sure that tasks around the same topic are generally handled by the same people. This is apt to change if those same people are already super packed with work, in which case it falls back on the next most applicable person.”

Q: Do you ever have to take on code tasks yourself? If so, can you give an example where you stepped in?

A: “I’m often the person who puts together the builds, so I usually go through a lot of clean up. Many of the quick little fixes (re-applied colliders, adjusted speeds, general code clean up) are done by me when I’m preparing to build. I try not to take on any major coding tasks because management often takes up a lot of my time so trying to split myself between team managing and actual coding usually means one or the other ends up dipping in quality.”


Q: What are your thoughts on Code’s progress so far?

A: “I’m really proud of how fast the code team was able to pick the project up and how they’ve been able to adapt to the changes and tasks that get thrown at them. Whole systems have been reworked in a single week and that is a really impressive task to do once in a project life cycle, but to do it three or four times over has been absolutely incredible. As for how the project as a whole is progressing, I’d say that we are in a good spot. Knowing that we just barely missed our carnival deliverable goal was a little disappointing, but when taking into account just how ambitious that goal was, id say its still very impressive that we got to where we are now.”

Q: What features are you most proud of?

A: “While all the features play a critical role in the success and feel of the game, and they have been so complexly interwoven with one another, if I had to pick just one to single out, I’d say the buggy driving is the most impressive. I’ve become so used to default unity movement that I can sometimes forget just how good you can make the act of driving around a track feel. Emil put a ton of work into designing and redesigning the driving so seeing the state it’s in now is really incredible.”

Q: Any final thoughts?

A: “It’s been interesting not having a client this semester. In all the previous big software or game classes I’ve been in, we’ve always been developing to meet the expectations of an outside client or professor. Being able to essentially set our own goals and deadlines has been very freeing but also somewhat challenging at times. Overall, it’s been a really interesting experience and I’m looking forward to our push to the final product.”


Closing Remarks…

Jonathan has been a diligent Code lead, making sure his team and our project stay on track, and picking up the pieces when necessary. Thanks to his hard work and management skills, this year’s game will be the biggest, baddest, and buggiest one yet!

We approach our playtests with a general set of questions. For instance, every playtest we ask our volunteers if they are familiar with CMU buggy, and how comfortable they are with video games. If people are unfamiliar with the tradition of buggy, then we have the challenge of quickly familiarizing them with it in-game; if people aren’t avid gamers, then we need to make sure our controls (like WASD for movement) are clear. 

We also ask questions tailored towards our main focus at the time. Over these next few weeks, our specific questions will focus on:

• Art: Shadows and lighting
• Design: The tutorial screen, and button layout
• Code: How driving feels, player and opponent speeds, and notable differences in speed and acceleration among our buggy variations
  
  

We ask our questions in three parts: a pre-survey before playtesting, during the actual playtest, and in a post-survey. Typically, the pre-survey covers our more general questions, while the more specific questions are asked during or after the playtest. And sometimes, we don’t even have to ask a question: we can observe the player and see for ourselves if the AI opponents are too fast, or if textures are glitching, or whatever else comes up during the playtest.  

After playtests are all said and done, the next thing to do is translate that feedback into action items and implement them into the game. While that usually means fine-tuning what we’ve already got, sometimes we end up implementing new features altogether. For example, players can now steer with arrows keys, instead of being restricting to just WASD. We reskinned our Distraction flag powerup, and made it Area-of-Effect (AOE)-activated.

As the semester goes on, we aim to do a lot more playtesting. With just a few weeks left until our final build, we look forward to sharing our game with the public.

Art

In previous weeks, we have showcased our concept art — a low poly, geometric design and more cartoony artstyle. For our alpha build, our Art team translated this 2D concept art into 3D models. Players are now able to choose from eleven unique buggies inspired by real buggies throughout CMU history.

Our art team has also implemented 3D builds throughout Track 1, including barriers, the Phipps Conservatory, and the Pothole Bus, and our finish line on the Schenley Bridge. 

Lastly, Art has created UI icons for each powerup item. These will appear on the player’s screen when they pick up an item. 

Design

Our Design team has been focused on UI design, weekly external playtesting, and level design.   

For our alpha build, we have implemented the beginnings of UI framework. Our improved buggy selection screen allows players to scroll through each of our eleven buggy models. Players can also see their buggy opponents.

Sound

Our Sound team has included SFX for rolling wheels, when an item is picked up, and when a player goes through a speed boost.

Code

Our Code team has been hard at work finalizing our buggy driving system, and driving has been fine-tuned for a smoother, easier-to-handle player experience.

Code has also included opponent buggy AI. Now players will race against three opponent buggies.

In addition, Code has implemented the powerup item framework. Players can now pick up and use items along the track — but so can opponent buggies.

Looking Ahead

In the coming weeks…

• Art will be creating more 3D models for Track 1 buildings and powerup items.
• UI designs will be further developed
• Code will be fine-tuning opponent AI and powerup item usage

See you next week!

We will continue using the Q & A format so we can dive in Kathryn’s design process and see how she thinks through important game decisions. 

Q: What is your philosophy when you design?  

A: “When I design, I try to start off by understanding the subject-matter as best I can. This allows me to get the details more spot on. This means immersing myself in the real-world content as much as possible. I pull just about everything I know from past experiences in work and school. Lessons from Game Design with Jesse Schell and working in Barbara Chamberlain’s Games Lab Studio have kept me immersed in the space of game design to the benefit of all the design work I tackle.”

Q: What inspired your design choices?

A: “For this year’s buggy game, I looked first and foremost at what was made last year. It provided a great starting point, especially since so much of last year’s team was returning. Then I looked at all the other popular racing games I could get my hands on. Forza, Crash Team Racing, Mario Kart, and even Steep (a snowboarding game) were the most useful contributors, but there were many others I played through as well.”

Q: How did you start planning?

A: “I first met with last year’s designer for a great handoff, then with Tom and Trento to better understand the goals for this year’s buggy, then with all the team leads. I started planning by making a list of what I felt was working in last year’s buggy game and what we should iterate on, then I got a feel for the entire racing game scene —  learning more about CMU buggy racing in the process. I also had friends test out last year’s game as well and share feedback.”

Q: Were there any specific ideas you knew you wanted to incorporate? Maybe things you added on a whim?

A: “Everything feels pretty planned out to me. Nothing I can think of that was on a whim. One aspect I knew I wanted to incorporate was the steep nature of some of Pittsburgh’s streets. I wasn’t sure how, but I just knew I wanted to. Where I am in New Mexico, there aren’t really steep roads like that, aside from in the mountains, so that aspect really stood out to me.”

Q: How do you decide what goes into a game and what ideas are shelved?

A: “I proposed quite a few ideas early on to get the wheels rolling, so to speak. But after that, most changes are primarily based on playtesting feedback. We started with internal playtesting, but now have moved out to friends and family, and soon we’ll be testing with the general public. We tend to make most of these decisions in our Friday class with all teammates there to voice their opinions and suggestions. And sometimes, I, along with other team leads, make final decisions just between us instead of the whole class.”

Q: What’s your favorite design piece of this project?

A: “My favorite thing designed for this project, so far, is the explanation doc for our second track’s aesthetic. It was created at the request of our Art Lead, Eric Yu, when he needed more information about the style direction. I think it has been one of the more useful pieces of documentation I’ve created. It utilizes three of the concept pieces Vivi made for this track, but I think a lot of the design “juice” comes in with the details and a readable layout. It is surprisingly difficult to remember to include some details (such as the fact that Gates should be exaggeratedly tall) when you know and feel the track in your head, but haven’t actually articulated it yet to another person.”

Q: Any final thoughts on our project?

A: “My final thoughts are really corny, but I am loving being a part of this team. I feel a lot of pride from the excellent quality of work our team delivers each and every Friday. Our share-outs inspire me to “up my game.” It’s that awesome feeling you get in a race when you think you’ve hit your limit, but then you end up right next to another runner and you feed off each other’s energy to propel you both forward. There is a comradery there that can’t be beat.”

Closing Remarks…

Kathryn has been an incredibly hard-working design lead, helping make sure we all stay on track. Thanks to Kathryn’s guidance, dedication, and tough decision-making, we are confident that this year’s buggy game will be the best one yet!

For this post, we will have a Q & A-styled format, diving into Vivi’s artist process and her thoughts on our games development!

Q: What was your intent with this year’s concept art? 

A: “We wanted the art direction to be different from the Buggy Allstars last year. So I went with a brighter distinct color palette and bolder shapes. Since the game this year is more surreal and imaginative, I explored how to exaggerate the buildings and environments. I drew environments with simple shapes and some textures so that it would be easy to transfer the concept art to the low poly models.”

Q: What references helped inspire your artwork?

A: “I looked at low-poly games to see how they utilized colors and shapes to create distinct environments. Games such as ART SQOOL, Good Job, Going Under, Sayonara Wild Hearts, and Monument Valley used surreal color palettes and bold shapes.”

Q: What was your process in developing this concept art?

A: “I start drawing very rough sketches, with an emphasis to exaggerate certain parts of the environment: twist the road, stretch buildings, etc. Then I reference my earlier colored drafts to match the color palette; I want to make sure that concept art from the same track design matches each other. I block out big sections to see how the colors work together, then I block out the lights and shadows. Each track takes place in different locations and has unique design elements, so I planned out each track to have a distinct color palette. For instance, the first track takes place outside, so the colors are bright and help reflect the warm sunlight. The second track takes place in a nighttime environment, so the colors are more cool-toned, and the objects themselves radiate bright light. The colors, textures, and shapes, of the concept art, convert pretty seamlessly onto the low-poly models. Hence, a lot of the style in the concept art is retained so far.”

Q: Are there any specific pieces of concept art that you especially like?

A: “I enjoyed drawing the rainbow bridge and helix gates spiral since I could exaggerate the shapes as much as I wanted. I also liked drawing the scenes with the bus ramp and the driver, since it helps me understand how players interact with the environment.”

Q: Any final thoughts?

A: “I enjoyed working on these concepts and seeing them be translated into a 3D environment! I think the development of the project is going well so far. Seeing the other team’s progress and work is really exciting. The track designs are interesting and the soundtrack brings a lot of life into the game. We have a prototype build of the game, and I had fun playing and navigating the buggy around the track.”

Closing Remarks…

Thanks to all this great concept art, we have been able to translate it into stunning 3D models. Vivi’s talent and dedication is vital to our team, helping us make this year’s biggest, baddest, and buggiest game yet!

Gallery

To make this all happen, our indie studio has separated into several teams, each focused on different disciplines: Art, Design, Sound, and Code. Each team has specific functions and goals that are essential in producing this project.

Here is what our teams have been up to since the start of the semester:

Design

Our Design Team has been focusing on what locations to feature in our tracks, potential obstacles for these tracks, and types of powerups that players can use throughout the game.

We’ve decided on the following so far:

• Our first level will be the same traditional buggy path that we used in last year’s project, but “remixed” with more twists and new features!
• We will be including some notable CMU/Pittsburgh landmarks, using last year’s work as a foundation to build upon.
• Time permitting, our goal is to expand the game with a second level based on other CMU campus locations.
• By using powerup items, the player and the AI can either help themselves and or hinder others. Early concepts included speed boosts, distractions, and throwable obstacles.

We will discuss the design process and how we came to these decisions in a future spotlight blog post. But in the meantime, here’s an example of an early track design drafted by our designer Kathryn-Mae Eiland!

Art

Our Art Team creates the stunning visuals that will give our game its cartoony design. Part of our Art Team has been working on concept art, while the rest are in the middle of transferring these 2D designs into 3D models.

The art style this year will embrace a low-poly look. Instead of being smooth and heavily detailed, like in many newer video games, our 3D models will look angular and more geometric. This style will allow for easier rendering and allow for more people to play our project, regardless of their computer’s specs.

Here’s a sneak peek of some concept art by Vivi Nguyen!

Sound

Our Sound Team has been focusing on music and sound effects to accompany gameplay. Here’s what we’ve got so far:

• We want a more upbeat, almost rave-like sound to complement our game’s cartoony style. Here is a demo track composed by Jonathan Fischer, based on CMU’s Fight Song!

• We are in the middle of drafting sound effects that will bring the buggies and the environments to life.

Code

Our Code Team has been working on the mechanics that allow our game to function. They’ve gotten a lot done in the last several weeks, including:

• Reworking how the buggies drive, using wheel-based physics to make them behave like a real-life vehicle.
• Implementing other racers to compete against, this time with more variation in their movements.
• Creating a framework for the game from start to finish: a start screen that will eventually host new features currently in development, the “rules of the race”, and more.

With the final prototype still in development, here’s an early preview of the driving mechanic, and going off a “ramp”!

Looking Ahead

In the coming weeks…

• We will be able to race on an early version of track 1.
  • In-house playtesting will begin at this stage of development, with external playtests to follow.
• Art is generating more low-poly 3D models and working on applying textures to the old models, in order to recreate the aesthetic from our concept art.
• Sound is polishing the first round of sound effects and music.

See you next week!

This course was first launched in the spring of 2018 to give students the opportunity to work on developing a video game over a longer design cycle than what most courses typically offer. It is unique within the offerings available to students through IDeATe’s game design curriculum in that here students will focus on developing just one product across the entire semester.

Also unique to this class – the students work collectively to create a single project, with each student responsible for their own portion of development. In this way, we are directly replicating the processes of the industry by standing up our own indie game studio. We have teams set up for art, engineering, design, and production, and plenty of opportunities for cross-collaboration.

This “all-in” approach was implemented last year when the class was invited to create a virtual reality experience to celebrate the 100th anniversary of the Buggy Races that are part of Carnegie Mellon’s annual Spring Carnival event. Sadly the pandemic altered these plans, but we were able to resume our class and our game online, releasing Buggy All-Stars at the end of the semester. Despite the disruption, their heart always remained in the work.

This semester, I am excited to announce that our project will be the sequel – Buggy All-Stars 2! (Bigger! Badder! Buggier!).

We are taking the buggies beyond the traditional track and exploring campus in a wild, family friendly racing game. New buggies, new locations, and a stunning new art style. We are once again targeting a browser-based game using WebGL, so that everyone and anyone can join in the fun. And we are targeting this year’s Spring Carnival (online) to showcase our first tracks.

Check back often as the team releases weekly progress updates, feature overviews, interviews, and as we post opportunities to participate in our playtesting.