So, wow .. I’m going to be speaking during the iPhone summit at GDC in two weeks. The last few months have been a whirlwind of activity for me as I’ve been churning out Galcon Fusion. So now it’s time to get to business getting my talk ready.
Part of the GDC talk process is sending them a title and a draft version of your talk a month or so in advance. I did this with my talk, which was titled, “Nuts & Bolts of Internet Multiplayer iPhone Game Testing” .. The feedback I got from the iPhone summit advisors was (to summarize): “This talk looks short, and maybe a bit boring.”
After a week of soul searching and considering my options, I had to agree. I wouldn’t want to go to my talk, it didn’t sound that great. Having nowhere else to turn to, I turned to PyCon. I knew that at PyCon people gave talks about how to give talks almost every year. I’ve missed the last two PyCons, so thankfully they’ve been posting them online!
I watched Andrew Kuchling’s How to Give a Python Talk which gave me some insight. The three points he made that really struck me were:
- Think About Your Audience
This means I need to give my audience a reason to be at my talk. What are they interested in? What do they want to accomplish? What can I give them so they are empowered to accomplish this goal?
- Too Short > Too Long
Andrew related that it’s better to cover too much material in too little time, then to cover too little material in too much time. If I can cover a blazing amount of information, but at least hit some key points with a strong note, the audience will come away with something. If I drone away about nothing for 30 minutes, they’ll come away bored.
- Rehearse your talk!
I knew this one. But, it’s good to be reminded. To those who are coming to GDC and plan on seeing my talk, fear not. I’ve got this week and next week with NOTHING planned, so I’ll be rehearsing my talk MANY times. I plan on delivering this one with a bit more style than last time. Last time was at 360iDev, my first “long” talk at a conference. I rehearsed my talk about 1.5 times, and I think it showed.
I think for me the first two points answer my question really quickly. Why does a dev want to hear me talk? They want to learn how to make a multi-player game. As for length, I can cover a bunch of keys to creating a multi-player game and maybe people will latch onto a few key points. If I only cover testing (as was my original plan) the people at my talk would walk away completely unable to use that information if they don’t have any idea where to start. Instead, if I give the whole picture, and include testing as part of it, they’ll have enough to go on to get started creating iPhone multi-player games.
P.S. Yeah, if anyone wants to give me tips on talking, feel free. Oh, and I think my talk is going to be re-titled to: “How GALCON Conquered the Universe of Online Multiplayer Games”