Blog - When Presentations Go Bad
Wednesday, August 6, 2008Another lesson from EGD I thought might be nice to post about is on presenting your game.
Instead of saying how this related to any moment at EGD, let me first tell you a story about the first video game I worked on with a student development team.
It was a pretty basic SHMUP called Core, built in a simple 2D game development tool.
We only had two weeks to develop it. Unfortunately, it was also one of the first (if not THE first) video game done by anyone on the team, so I don't think any of us knew how to budget our time properly for the project.
We fell quite behind. Near the end we realized how screwed we were and were trying to cut and cut just to get the thing into a presentable level by the deadline. Lots of good work got cut, but it still wasn't enough.
A few of us were still crunching to get the game done on a series of laptops during the bus ride to class on the last day.
Needless to say, the game was not finished in time for our presentation.
What followed was an awful, awful presentation where everything that could have gone wrong decided to do just that. Even glitches we weren't aware of popped up unexpectedly by the dozens, on top of the hundreds we knew of. We couldn't help but express our horror at each one that came up. My personal favorite line was "And all the music was composed by Brian here.... although this isn't the right song for this level is it?"
It was after that tragic presentation that I was taught that glitches were likely to come up when presenting any game, and what exactly one should do when bugs rear their heads at such a time. I was told not to point out the things that are wrong and instead gloss over all mistakes, glitches, etc. Since then I've learned another tactic, of talking only about problem areas when you can talk about what you did (or at least tried) to do to overcome such obstacles.
Now, back to EGD, there was one group of students that, due to fighting within their development team, had fallen quite behind. They had to scramble to get their game done, but it was already too late.
Their game was falling apart during their practice presentations.
I told them the above story, and gave them all the advice I had been given on what to do when things go wrong during a presentation.
Sadly, they didn't follow it at all, and new horrifying bugs showed up during their final presentation to the judges. The best of which was at one point they opened a door and inside the door frame was a brick wall that wasn't supposed to be there, rendering that level unbeatable.
Since they didn't take my advice at all, the judges had to console them to help derail the train-wreck that resulted. Let's hope that when they gave out the exact same advice I had given earlier, the students finally listened.
Labels: EGD, presenting
posted by Brian Shurtleff @ 7:00 PM
1 Comments:
dsilvers said...
This post reminds me a lot of Level Design, where the presenter for one group loaded a very early version of the level and thought everything had been lost. His group, too tired to stop him (we had been at Monty for 3 days straight, no food, no sleep), let him rant on and on about how much it sucked. He pointed out all the problem areas and basically kept punching himself in the gut for being a failure, until finally somebody shouted, "Could you at least TRY to sell it to us?!" That's really what you need to do. Interrupt the presentation to let them know they are losing street cred. Sometimes, you even gotta get them to lie. Like the brick.
"We put this brick here because there's a glitch in that room that makes the game crash. That'll be fixed soon, we just ran outta time. But trust us: that room is awesome."