Gaffer on Games

GDC 2009 is about one month away, and so far I’ve made pretty good progress on my GDC talks this year

I’m doing two talks at GDC this year. My first talk “Networking for Physics Programmers” was written and practiced in rough draft form for the first time around November last year in front of the Sony Santa Monica programming team. I actually gave the talk at the start of my third week working for them. Ow that was a lot of work while starting a new job!

It took me about a week to plan out the talk, including three or four informal practice sessions in front of co-workers the week before. The key thing I learned from those practice sessions was that improvising a talk against bullet points is not the way to go if you want to really nail a talk. You may do OK, you might not completely fuck it up. But you won’t give a highly rated talk because your thoughts will all be in a jumble.

What I discovered is that you need to distill the information in your talk down. Dump it all out in the speaker notes then talk through it out loud. Actually write out what you want to say. Adjust it so it sounds more natural. Practice each slide over and over, adjusting the speaker notes as you improvise and riff off the contents. Say something you thought was cool? Add it to the speaker notes. Speak it out loud as you add it.

Practice the slides in sequence, do they flow naturally? Practice in front of your girlfriend or your cat (or both) and adjust your slides whenever you feel compelled to explain something in more detail. Maybe you glossed over something critical for people to understand your point? You don’t want to lose people just because they don’t understand a technical term you used.

Then finally practice your talk in front of your team at work. Don’t practice it before you’ve already gotten it to this point. You can’t get a first impression from the team again, and nobody really wants to sit down for an hour to listen to a talk they’ve already heard.

After doing all of this preparation my practice talk at work went really well. Much better than my GDC talk last year where I improvised off the slides and rushed through. I thought reading off speaker notes would be more stilted, but it ended up actually being much more natural because I was relaxed, and I knew the talk well enough to maintain eye contact with my workmates most of the time. Having it all written out also really helped me pace out the talk, so I didn’t rush.

So about a month ago, I started work on my second talk “Drop-In COOP for Open World Games” thinking hey I’ve got this all nailed – no worries! I went through the process described above, worked for several weeks on the talk, wrote drafts, refined, talked through the slides, practiced out loud. I did everything I described above. But I just couldn’t shake the feeling that the talk was mundane, boring.

So I left the talk on the shelf and came back to it a few weeks later. And holy shit, it was boring.

What happened? Well the difference is that my first talk is a tutorial and second talk is a lecture. A tutorial is really just about transferring as much info as I can into the minds of people in the audience. Cram that information in. It’s OK if it’s like a shopping list: this is what you do, then that then this. In the end, you’ll be judged on the cool info you transfer to them. Anything else is bonus points really.

But my second talk is a lecture about a new technique for networking COOP games. It’s controversial. I have to sell it: I have to explain what problem it solves, why it’s a good technique, why it is useful and why it’s better than what people are currently doing. Basically, I have an hour to convince people that I’m not smoking game networking crack.

So the last possible thing you should do in this situation is just jump right in and read out a shopping list of how you implement your technique. First you have to convince people you are right, you have to persuade them.

How did I find this out? I’m not an experienced speaker, so I spent a night researching for tips on how to prepare a talk. It turns out that googling for “how to give a good talk” is a goldmine.

This advice was so useful to me, I kept notes and tidbits I thought were particularly good.

So here is all the good advice I could find in one big list. Hopefully it will help you out with your talk as well

cheers

“You have two minutes to engage your audience before they start to doze. Why should I tune into this talk? What is the problem? Why is it an interesting problem?”

“Use a top down approach. 1) Introduction. Define problem. Put in a carrot. Put in context and give an outline.”

“Motivate the audience. Why is this problem important? How does it fit into the larger picture? What are the applications?”

“Body. Abstract the key results. Focus on a key exciting result. Explain significance of your work. Sketch methodology of key ideas. Keep it high level. Use pictures/diagrams. Provide intuition. Gloss over technical details”

“(1) Communicate your arguments and evidence. (2) Persuade the audience that they are true. (3) Be interesting and entertaining”

“Don’t start with a joke. The audience is not accustomed to you or your speaking style yet. Humor will be difficult at this point.”

“Provide an empowerment promise. Explain why your audience will come away from your talk better than they entered”

“Decide how many concepts or points you can adequately get across in the allotted time (one concept per-5 minutes is a reasonable rule of thumb), and prioritize to the most important ones”

“‘then i did this, then i did that…’, Is your chronology important to them? Start with messages the audience will receive. Plan backwards from them, not forwards from you.”

“You must have messages. Work out what they are.”

“Topic order. State messages early. Not a mystery. Call it out, then explain why it is true. Your talk is not a suspense novel”

“Don’t overwhelm your audience. It is better to clearly explain one or two main ideas than to cursorily cover four or five ideas. In a one hour talk, your audience can only absorb one or two central ideas – if you try to cover several years of work, they are going to be overwhelmed and will stop paying attention”

“The conference talks I remember are the ones where the speaker spoke slowly and confidently and made one point well. Talks that try to make too many points are almost always forgettable (and forgotten.) A rushed talk can be good, but it won’t be great.”

“Talks are different from papers. While you must explain your details in your paper, this is not necessary in a talk. The primary goal of a talk is not to explain every detail of your work. It is more important to explain the general concepts, build intuition, and then allow those who are interested to read your paper to get all of the details.”

“Know your goal. A conference talk’s goal is to make the audience want to read your paper. The talk does not replace the paper.”

“Before you make a point, the audience needs to know the point you are about to make and appreciate why you are making it. After you make a point the audience needs to be reminded of the point you just made and understand why it matters.”

“Most good speakers average two minutes per-slide.”

“When time is short omit the general case, not the example”