Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Student Postmortem: Carnegie Mellon's Beowulf's Barroom Brawl

    [12.19.06]
    - James Portnow
  •  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.

Comments

comments powered by Disqus