Student Postmortem: Carnegie Mellon's Beowulf's Barroom Brawl

By James Portnow [12.19.06]  Introduction

With the release of the Wii and the growing interest in unusual input devices I thought it might be an appropriate time to write about Beowulf's Barroom Brawl. Beowulf's Barroom Brawl is a first person fighting game based on the idea of kinetic freedom. Think Punchout with motion trackers. It was designed and developed by a team of four over two weeks (yes, two weeks). The game was built in Panda3d with the models being made in Maya, the textures being done in Photoshop and the sound being crafted in Audition and Fruity Loops.

Before we begin in earnest, I should explain a little about what we do in the Building Virtual Worlds class at the Entertainment Technology Center of Carnegie Mellon. Every two weeks we are assigned to make a new game on a new platform with a new team. The teams are chosen randomly from a pool of modelers, texture artists, sound people and programmers. Once we have a team we are given a series of constraints which can be as vague as "tell a story" or as specific as "the game must include one character which is afraid of another."

This week's constraints were "build a game for a naïve user... give them the illusion of freedom." Clearly this was an assignment about indirect control. "No problem," we thought, then we were handed four motion trackers and a projection screen.

 

This Postmortem will attempt to describe the trials and tribulations of working on an unusual platform as well as the wonders of being freed from standard controls. We'll also touch on some of the risks and difficulties associated with rapid prototyping and short cycle game construction over the course of this article.

 What Went Right

Quick Decisions: Throughout the development of Beowulf's Barroom Brawl we were constantly aware of our schedule. Having two weeks to complete the entire project meant we couldn't be ambivalent about anything. It forced us to realize that anything we were having a hard time deciding about was either: A. Unimportant or B. Fundamentally flawed and not worth the time investment to fix.

Oddly enough we realized this when we were trying to get dinner one night. We couldn't decide on a place to eat, after a half an hour of indecision, someone asked "why is this so hard?" Almost immediately we all responded "because it's not important." We ended up skipping dinner that night and tearing through all of questions we had left undecided.

The Team: I have to give a nod to my teammates here: Giray Ozil (programmer), Jack Bader (modeler), and Nick Lee (textures). They were not only great to work with but also very forthright about what they could and couldn't do from the beginning, which allowed us to play to the strengths of the team while avoiding losing time trying to implement things we weren't capable of.

Jack, our modeler, is an architecture student, which meant that we knew he could deliver us a fantastic mead hall for the brawl to be set in. Unfortunately he was less confidant about his ability to model people. Luckily for us, Nick, our texture artist, favors a dark-comic style, which meant that the human models could be a little more brutish and still look fantastic. This also made organizing the pipeline easy, as Jack delivered the mead hall first, giving Nick plenty of time to texture it (as it needed to be in a slightly more realistic style than Nick was used to), and then move on to the human models.

 

Early Testing: Here's where I have to compliment Giray Ozil. By the third day he had a prototype up and ready for testing. This allowed us to tweak continuously, which was key given that we were going to have a naïve user play our game. If we hadn't had a week and a half to make minor adjustments to the player's life and the enemy's speed, the game would have lost a lot of the frenetic activity that made the game so enjoyable. Early testing was also crucial in discovering things about the technology we were dealing with. Initially we had a duck mechanism in the game that worked intermittently. This stumped us for some time until we realized that taller players were consistently able to duck, whereas shorter players only sporadically triggered the duck mechanism when they, in real life, ducked. We discovered that the trackers we were using started to lose signal once they were more than four feet from the tracker base (a device which was suspended about 8 feet in the air in the middle of the room). Thanks to early testing, we were able to move the Z-axis tracker from the player's chest to a helmet on their head and have it work for all but the shortest players.

Kinetic Freedom: To this day I am totally convinced that giving the player the illusion of kinetic freedom was the best design decision we made. Unfortunately the hardware limited the amount of actual kinetic freedom given to the player. The player could not walk around the bar; in fact they couldn't even turn around. If they dodged more than a few feet to the left or the right we'd lose them, so we needed them to stay stationary and face the screen, only punching or moving their torso to dodge. In order to do this we made the opponent much larger than life, filling 80% of the projection screen (which is already about fifteen feet tall and looming over the player). We gave the player a first person view, allowing them only to see their arms and fists (which did a lot to explain the principle interaction of the game without us having to give a single instruction). We also placed overturned chairs and tables to the players left and right but these turned out to be almost irrelevant as no one ever tried to move that far. To this day we have never had a player ask us why they can't turn around (or even try to turn around) as they are so focused on the large menacing man in front of them.

The music also played a large part in establishing the illusion of kinetic freedom. Originally I had written what I thought was a beautiful, somber, epic symphony piece for our world. I played the game once and spent the rest of the night writing some pounding techno instead.

Clearly techno does not fit in a barbarian world, but it did get every player who played to do the Street Fighter bounce, which in turn got them ducking and dodging, which made them feel like they could do anything. It was amazing watching a player whom you've given no instructions discover that they could dodge and duck. Because these were things which they wanted to do but didn't expect to be able to do, when they found out they could duck and dodge, they forgot about all the things they actually couldn't do.

 

The Costume: Yes... we built a costume for the player to wear. It was intended to hide the trackers so the player would be less aware of non-diegetic elements of our world. To our surprise it totally sucked the player into the world. For our naïve guest we got a fifteen year old, female, art school student. At first she was a little unsure about the whole thing. She didn't want to look stupid in front of her classmates (several of whom were at the showing of Barroom Brawl as guests to test for other worlds being shown that day). Once we put some leather gloves with chains around them and a big barbarian fur on her she really got into it. It was interesting because we had unintentionally left her with nothing to feel shy about. After a fashion change, we had already made her look silly so there was no reason for her not just to let go and have fun.

 What Went Wrong

Over-scoping: Despite everything we did to economize on time we still over-scoped. In the initial design scheme we had planned to include objects which you could grab and smash as you fought. This was simply not realistic. What's worse, our attempt to implement this feature cost us time that could have been used to better implement other parts of the game.

In Beowulf's Barroom Brawl we had initially planned to have 2 human-model opponents whom you boxed before "the big surprise." In the middle of the second fight, Grendel was going to come crashing through the roof of the mead hall, eat your opponent, then you would have to box him to win the game. Unfortunately the day we spent working on the smash and grab mechanic took time away from working on the surprise and we ended up with one boxer and a Grendel entrance largely masked by camera shake and smoke.

While the surprise still worked it wasn't the jaw dropping spectacle we could have made it if we had simply focused on it. The problem with the "grab and smash" mechanic was that it added very little to the game for a great cost in man hours. Unfortunately we failed to see this during the design phase and caught it only during test when we had already spent a full day trying to implement it. This really taught me that when the crunch comes you've absolutely got to have your priorities locked in and that there's no real room to be wrong on them.

Exhaustion: Each team member worked 60-70 hours a week to get this project done. There was always more that we could do. We didn't have an established cut off. We didn't have a point where we were going to say "we're done." The modus operandi from the beginning was "let's just keep making it cooler until the moment we have to turn it in." This was beneficial in a many ways but it also cost us greatly by the end of the second week. If we had cut everyone's work week down by seven hours we probably still would have gotten as much done.

I can only speak from experience but exhausted work is not efficient work. As producer for the team I was trying to be there whenever my team members were working but they weren't always on the same schedule so some days I'd be there from 9am until 3am. On the day before the project was due and we were running tests, another group was building a rafting world and had left their rubber raft in the testing room. I actually ended up falling asleep in their raft mid-testing. Yes, it's the last day before ship, we're doing the final test and the producer is passed out in a raft... My critique of that test was probably not as through as it could be.

 

Hardware: Working on an untried platform was a great experience, but trying in many ways. Not only did our coder have to learn to code for the device, but we as a team had to learn its limitations after, not before, designing. Much of the time we lost was directly related to not understanding the nature of the hardware. While we got many of the key points right (not having the player be able to move their feet or turn around), we missed minor details in several important places (such as the duck mechanic mentioned earlier). Moreover we did not understand what I call the ‘intent' of the hardware and what sort of sensations it could deliver. Punching things, especially with four pounds of chain around your wrist was very satisfying, even though you were swinging at air. On the other hand, the smash mechanic felt totally flat without haptic feedback and actually brought the player out of the game. As games move away from a traditional mouse/keyboard or joystick input it will be interesting to see how these problems are overcome.

Testing on different hardware: Another minor point... Choose the hardware you test on well! Due to the non-standard nature of the product, we found it very hard to test on hardware that was similar to the hardware we'd run the game on when we had our naïve guest play. You might be thinking that the computer we tested on was different than the computer we ended up running the world on, but in our case, the computer was the one thing we were able to emulate. The two major stumbling blocks for us were the screen and the speakers. Yes, things as minor as that can change your whole world. When we tested we tested on a pair of tiny computer speakers with no sub-woofer and a screen that was slightly bigger than a large TV, as a result both the audio and the visuals performed unexpectedly.

The Audio: During the guest test we were using a large PA with a lot of bass rather than tiny desktop speakers. This was great for the "pounding techno beat" and the visceral hit noises; unfortunately it entirely swallowed the voice acting for the intro. We used a slideshow with voiceovers to briefly lay out the story of our game before the brawl began; tragically the guest only saw a bunch of stills backed by unintelligible rumbling. After the game ended, we asked our guest, "Who were you?" She was totally unaware that she was Beowulf. She had forgotten the splash screen in the excitement of the experience, which was fantastic, but there was nothing else to ground her in the world with the intro missing (this also left the appearance of Grendel as um... quite surprising).

The Visuals: As with the audio, the visuals turned out somewhat differently than we had expected. For the guest test we projected the game onto a screen comparable to one found in a small movie theater. While this greatly enhanced the effect of some brute or monster looming over you (the player), it made the graphics appear less crisp and well defined. Many of the artifacts of having only two weeks to spend on graphics became apparent on the larger screen.

One man too few: Perhaps it's just a personal complaint, but being producer/sound guy/costume designer stretched me to the limit. If we had another team member to fill one of these rolls it would have made production of Beowulf's Barroom Brawl much easier. I like to say that the product didn't suffer for this, only I did, though realistically I know this is probably not true.

This was a good lesson about resource management though. I honestly believe that we made a product of 90-95% the quality that we could have with another team member. All the cost was personal rather than fiscal or temporal. It showed us just what you could do with a dedicated team that really wanted to put out the product they were making. Moreover it showed everyone on the team just what they could do when called on to do it.

 Conclusion

While Beowulf's Barroom Brawl will probably not be hitting home consoles anytime soon, it taught us a great deal about working with unusual technology as well as working with each other. We were lucky enough to have Barroom Brawl make it into the BVW Show (a Carnegie Mellon sponsored demonstration of cutting edge entertainment technology) and there be seen by members of the industry working on projects of a similar nature.

This was a great experience, and really, what more can you ask for than swapping stories with pros about all the things people do that you can't possibly anticipate? (We had a player who got it into their head that Dokar, the first opponent, was much taller than them and ended up hitting the tracker box suspended seven feet in the air.)

Having worked on Barroom Brawl leaves us all excited to see how many of the challenges we faced are overcome by the industry at large as games move towards more natural input devices. We wait with eager anticipation for the first game that really gives us a sense that we are not only moving within a world but interacting with it as well.

 

Website and Trailer:
Developer: Round Table Games (an ETC group)
Publisher: The Entertainment Technology Center at CMU
Number of Designers: 4
Length of Preproduction: 2 weeks... 8 days a week
Length of Production:
Approximately 130 hours per person
Release Date:
October 17th, 2006
Platform: Projector and Motion Trackers
Development software used: Panda3d, Maya, Photoshop, Adobe Audition, Fruity Loops
Development hardware used: 4 Dell Precision 380 Workstations
Project Size: 70MB

James Portnow is a Master's student in the Entertainment Technology department of Carnegie Mellon.

Return to the web version of this article
Copyright © UBM TechWeb