Posts tagged as “The Centaur’s Guides”

[twenty twenty-four day fifty-eight]: the seven-part story test

Published February 27, 2024 by centaur

So I’ve developed a new tool for story analysis that my co-editor on The Neurodiversiverse, Liza Olmsted, called “your seven-part story test,” and it fits in one long sentence: “Who wants what, why can’t they get it, what do they do about it, how does it turn out, why does that matter to them, and what does that mean for the reader?”

This six-part test is an adaptation of Dwight Swain’s story question “Who wants what and why can’t they get it?” as well as Vorwald and Wolff’s pithier but less useful “What happens?”_, called the Major Dramatic Question (MDQ) in their book “How to Tell a Story.”

Now, V&Q unpack their MDQ into the broader questions “What does my character want? What action do they take to get it? What keeps them from getting it? Who succeeds or fails?”. Like many writing coaches who have their own language for similar ideas, I think both Swain and V&W are tackling the “Major Dramatic Question”, just from different angles - but “how it turns out” is a key question not encapsulated in Swain’s version, and I think it helps us understand what is going on - or should be going on - in a story.

Ultimately, I think a story is an engaging and surprising case, in the case-based reasoning (CBR) sense. For those not familiar with CBR, it’s a reasoning technique back from the days of symbolic artificial intelligence (AI), pioneered by Janet Kolodner, the leader of the AI lab where I was trained (and my original thesis advisor). A case, in the traditional sense, is a labeled experience, which is marked by what problem is being solved, what solution was applied, how it turned out, what lesson it taught, and how we might remember it.

Well, in the age of content-addressable memories and vector databases, we worry less about labeling cases so we can remember them, as the content itself can help us find relevant cases. However, it remains important to analyze our experiences so we can better understand what happened, what we did, how it turned out, and what lessons that taught (or should have taught) us. And the last two are related, but different: what happened are the bare facts, but the same bare facts can have different meanings to different people that experience them - or to different observers, watching from the outside.

Think of a woman in an abusive marriage. What she wants is a peaceful life; why she can’t get it is a husband who’s a Navy SEAL with PTSD. Let’s say what she does about it is try to kill him, and how it turns out is that she gets away with it. But what does that matter to her, and what does that mean for us (the writer, the editor, the publisher, and the author)?

Well, that same outcome could matter in different ways. Perhaps our heroine gets to build a new happy life away from a man who abused her - or perhaps our heroine is now living a life of regret, with a child that resents her and feelings of guilt about killing a man who couldn’t cope with his wartime trauma and needed her help. Because the truth of it is, no-one should have to put up with domestic violence - but a small percentage of people who struggle with PTSD end up acting out, and need help to deal with their trauma.

There’s no right answer here - a skilled author could present a spectrum of situations in which most of us would say either “get them help” or “girl, get out”. But if the author shows our heroine murdering their husband and getting away with it, the story is implicitly endorsing murder as a solution for domestic problems. Conversely, if the author shows the heroine forgiving violence in an attempt to get the husband help, the story is implicitly endorsing women enduring domestic abuse. Not only is there no right answer here, there’s no good answer here - which might lead you as an author to question the whole setup.

That’s why it’s really important to step back and think about what you as an author are endorsing in your story - and whether you’re comfortable with that message. Despite what some writing teachers will tell you, you’re not the god of your story: you’re playing in a playground of your own making, but the materials from which that playground is fashioned - people, places, events, actions, reactions, and emotions - are all drawn from the very real world in which we live, and stories by their nature communicate messages about that real world to those who read them, even if the events in the story are purely fictional.

(This principle of authorial endorsement extends to the editor, publisher, and even the reader as well. There were many good stories submitted to The Neurodiversiverse that we chose to reject because of their implicit message - for example, we wanted our anthology to be empowering, so we didn’t select some powerful stories in which the character’s neurodiversity helped them communicate with aliens, but didn’t help the horrible situation that they were in; these stories might be a great choice for a horror anthology, however).

But the point can get lost if you start asking a lot of unconnected questions about your story. That’s why I like the idea of the unified MDQ, and I like the expression of that in Dwight Swain’s three-part question “Who wants what, and why can’t they get it?” But that three-part version is not enough, and expanding that question into a single phrase that incorporates the important elements of action, outcome, impact and meaning turns it into my seven-part test: “Who wants what, why can’t they get it, what do they do about it, how does it turn out, why does that matter to them, and what does that mean for the reader?”

The rewards for thinking through these questions are great. Thinking about how the story turns out matters to the protagonist creates options for tweaking the ending (or the material leading up to it) for greater resonance; and thinking about what meaning the story delivers for the reader creates opportunities to weave that message through the whole story. The seven-part story test can help us create stronger, more impactful, and more meaningful stories that make more sense and feel more satisfying.

So, to unpack the seven-part test further:

Who? Who is the protagonist of your story?
Wants what? What’s their goal, and why are they motivated to seek it?
Why can’t they get it? What’s the conflict in the story? Is it derived from a classical antagonist, or is the conflict based on internal or environmental factors?
What do they do about it? What action does the character take (or fail to take, as Hamlet fails to take action for much of his story)? Ultimately, most good stories are about what people do when facing conflict, so they should not be wholly passive - they should have some agency which affects how the story turns out.
How does it turn out? With the exception of vignettes that are all atmosphere, we want to know the outcome of the protagonists’ action. Did they succeed? Did they fail? Are we left with a situation that’s definitively not resolved (as in the ambiguous endings of Inception, Cast/Away, The Sopranos, or John Carpenter’s The Thing)? Any of these are acceptable endings (though a definitive lack of resolution is the hardest trick to pull off) but you as the author need to pick one.
Why does that matter to them? The ending of Cast/Away is a great example, in that our uncertainty about what the main character does next is actually symbolic of the main character’s situation. It matters to the main character that they are in a state of indecision, because that indecision represents what they lacked when cast away on that island: freedom of choice.
What does that mean for the reader? Regardless of what you choose to the previous questions, you should think through the implications of what that means for the reader, and whether that’s the image you want to present for your story. While you aren’t the god of your story, you are the playwright and stage director, and if the message of your story isn’t what you want, you can just change it.

Overall, I’ve already got a lot of good mileage out of these questions in the new series of stories that I’m writing (which I’m variously calling “The Porsche Xenobiology Stories” or “Tales of Failaka” depending on which planet I’m writing on this week). By asking these questions, I’ve been able to reformulate my endings to focus not just on the outcomes of the character’s actions, but how it matters to them, which makes the endings more satisfying; and also to focus on what it means, which has enabled me to make the stories more cohesive, as well as inspiring ideas for new stories.

“Who wants what, why can’t they get it, what do they do about it, how does it turn out, why does it matter to them, and what does that mean for the reader?” It’s a short, seven-part story test, easily compressible into a sentence that can be used to interrogate your story, and it’s been very useful for me; I hope it is useful for you too.

-the Centaur

Pictured: Loki, and in the background, the reading "pile" for a writing book that I'm working on called "The Rules Disease." Yes, it has filled most of a bookshelf by this point - there's a lot of writing on writing.

Making a Mac Useful, Part 2: Why an New iMac?

Published June 1, 2014 by centaur

Ok, why an iMac? Why Mac OS X at all? “Because they’re easy to use?” After looking at my list of “prep my Mac” todos, I say to that … ha!

However, despite that, I find Macs are just about the easiest to use of the mainstream operating systems (the others being Windows and Linux), but I’ve been computing for a long time and have acquired many quirks - or, more charitably, special needs. Some of those needs are just my druthers on how I want the computer to run, and other needs are vital parts of my workflow for which, if the computer doesn’t do its job, I literally have to go find another machine to get the job done. And I don’t like doing that - so I’ll spend a week or two beating a machine into shape if it means I can flip the thing open for two or three years and just have it do exactly what I want.

Well, then, why not beat a Windows machine into shape? For the record, I find Windows slightly more usable than Macs - no joke, and I’ve been using both for decades - but Macs are more reliable, more internally consistent, and most importantly, better integrated with UNIX. I’m a web and research software developer, and the standard OS in my part of the world is the UNIX variant called Linux - but Linux isn’t very reliable when running other software I need, like Microsoft Word, Photoshop or Starcraft. Alternatives like Cygwin make Windows more UNIX-friendly, but barely; whereas Mac OS X is built on top of UNIX.

That leads me, inexorably, to the Mac. As I said before, other alternative operating systems, like ChromeOS or Android or iOS, don’t run the software I need for work work, writing work, or pleasure - and cloud alternatives like Google Docs simply don’t count as they lack required features or - wait, why I am I even defending this? Microsoft Word runs on Mac and Windows. Photoshop runs on Mac and Windows. Alternatives to these programs are largely a joke, and that’s coming from someone who uses them - a lot. (I’m using Google Docs to write this note, in fact, and I’m also familiar with and use OpenOffice). If you can’t run Word or Photoshop well, reliably, you can’t play. And that leads me to Mac and Windows. And UNIX, inexorably, pushed me to the Mac.

For my personal use, I need a computer I can easily carry around with me that has at least a half-terabyte hard drive (to hold ALL my relevant files), a good processor, lots of RAM, and a decent-sized keyboard and screen, all in a lightweight package that won’t throw out my back when I put it in a bag. That led me to a maxed-out 13 inch MacBook Air, and it’s served me well.

But for my central home server, the computer to which the primary house printer is attached, I need something more. I need a much larger hard drive - a terabyte or more - so the computer can simultaneously serve as the Dropbox / Google Drive remote backup of my laptop computer, and also have more than enough space left over to hold archives and mirrors of my older computers and copies of my wife’s computer files. Something zippy, good for both game playing and programming and especially Photoshop / Illustrator, so the computer could serve as an editing bay for my comic book art.

I briefly considered the new Mac Pros, which are gorgeous machines. But when I buy a desktop PC, I do my very best to “max it out” so that the machine will last as long as possible. A maxed out Mac Pro with screen came in at something like ten thousand dollars - enough to buy a new maxed out iMac, a new Windows 8 touchscreen PC for my wife, a new backup solution, a storage shed out back, and some very nice dinners at Alexander’s restaurant.

Now, there are drawbacks. iMacs aren’t really expandable. They’re also a bit behind the times, UX-wise: iMacs don't have touchscreens. That’s a shame, but, on the other hand, it isn’t particular to iMacs: Apple overall isn’t really ready to support touch screens yet. There’s a claim that they’re not useful yet, but I have a Windows 8 laptop as well, and I’ve used a Chrome Pixel and an ASUS Transformer Prime, and I can tell you that you get used to the idea that you can manipulate objects on screen really damn fast. However, that means if you want a touchscreen, you’re going to have to get a Windows 8 machine or an Android machine (yes, you can get full-sized - I mean, 19 inch - Android all-in-one PCs [ http://shop.lenovo.com/us/en/desktops/essential/n-series/n308/ ], but I cannot yet find a full-sized Chrome OS touchscreen PC). Honestly, I’d rather have the applications that I want at this point, so Mac OS X is my only choice for now.

So an iMac it is: Microsoft applications, a UNIX base, and a price that fits.

Next up: the physical setup.

-the Centaur

Pictured: an Apple iMac 27 inch, a Microsoft Natural Ergonomic 4000 keyboard, and a towel serving as an ersatz cat bed, sans cat.

Making a Mac Useful, Part 1: Why Are You Hitting Yourself?

Published June 1, 2014 by centaur

OK. This is going to be a deep dive, and it may take some time: I’m going to review the unbelievable list of tasks necessary to make a Mac OS X system usable for my daily work.

Now, this isn’t particular to Macs, nor even particular to desktop systems. Usually, when I get a new desktop or laptop or tablet or phone, I’m up and running in a few hours - sometimes, a few minutes - but for the next several weeks, I find myself cursing as I realize yet another program or setting hasn’t propagated over to the new machine.

That wouldn’t be much of a problem … except I do most of these tasks when I first get a machine, and I don’t update my machines often. I update phones roughly once a year, and laptops twice every few years - twice, since my work MacBook Pro and my home MacBook Air get refreshed on around the same schedule. While it’s easy to remember to toss a half dozen apps onto a phone and tweak a few settings when you get it, the more complex configuration tasks for a desktop operating system, sometimes involving multiple steps and research, are something that slowly evaporate from my memory over two or three years.

This is the kind of problem that the Chrome OS by Google is designed to solve: a system which ties all your configurations to your account, so if you toss your laptop into a wood chipper, you can get a new one and pick up literally where you left off. Unfortunately, a browser only operating system really doesn’t work for me. I am primarily a producer, not a consumer, and my daily work environment is filled with programs like Word and Excel and Photoshop and Illustrator and Acrobat and Ecto and Python and Bash and J and Aquamacs and Vi and Eclipse and MAMP and Gimp and so on and so forth.

So I’m more than willing to put up with this once or twice every two or three years. Hopefully, by blogging about it, I’ll get a better grip on the process, and so next time, it will be easier.

SO I got me a new Macbook Air with a half-terabyte hard drive, and planned to make this tiny aluminum wedge into my primary computer, replacing both my old MacBook Pro “server” and my MacBook Air mobile writing computer. I began configuring it, writing the list of tasks down, expecting it to take a page or so.

Ha!

That list rapidly spiraled out of control, so I never started that blogpost, even though I got the new MacBook Air configured so well it did indeed become my primary machine. I carry it everywhere, use it for everything - well, almost everything. It was missing only one critical feature: a connected printer - natch, it is a lightweight laptop.

I do have a Canon MX870 multifunction printer-scanner-copier hooked up to my old MacBook Pro, but that MacBook Pro was getting so long in the tooth that I was afraid to turn it on, and when I did so Chrome complained that it couldn’t update because my OS was unsupported and Apple complained that the OS was out of date and my neighbors complained because every time I moved the mouse their TV flickered. So, I decided to bite the bullet and replace it, ultimately with a shiny new iMac.

Which brought me back to this list.

Now that I’m doing this process twice, in close succession, I have the opportunity to find out what’s really necessary, and can see where I’ve missed steps. I’ve broken this list into two parts - one very, very long document in which I am documenting, for my own wordy gratification, ALL the tasks that I have to do to make this new Mac useful to me, and then this series of bite-sized articles, which breaks that apart into small logical chunks. By the time I’m done, I’m guessing there will probably be a dozen articles in this series on Macs alone - not counting setting up Windows boxes, or phones, or the work I’ve had to do on my development environments.

To some, this might seem not just a deep dive, but off the deep end. But there’s a dual method to this madness.

First, having this information on the Internet makes it searchable. Many a time I’ve followed a set of directions related to some computing task and found them nearly useless, and only by piecing together clues from half a dozen different pages online have I been able to, somehow, adapt a solution to the problem. (I have no idea where I might have picked up that problem-solving strategy).

But often the information is not available at all. Even doing this blogpost on the new computer required doing several tasks which were simply not documented anywhere. That’s a blogpost for another time, but hopefully, putting this information up there will help change that.

The second reason for documenting this so thoroughly is to put, on record, how difficult it is to use even the easiest of the modern desktop computer operating systems (again, excluding Chrome OS, which does not (yet) compete in feature parity with standard desktop operating systems). I’m a computer scientist with a PhD in Artificial Intelligence who currently works with four different operating systems, and I’ve got thirty-five years experience working with dozens of different kinds of computers - and if I have trouble with some of these tasks, what hope does a non-specialist have of fixing their brand new shiny money-burner when it decides to become non-functioning, or, more insidiously, simply fails to work as expected, in some subtle and hard to debug way? As my wife says, there’s no hope: she claims the typical user needs to hire someone to help them out, and that’s why the Geek Squad does so well.

Maybe she’s right. But, I hope by putting some of this information out there, I either help some poor shmoe just like me solve their problem … or convince an operating system designer to start thinking energetically about how to make the problem just go away.

-the Centaur

Next up: why pick a (new) iMac?

Write Your Own Damn Sentences

Published June 10, 2013 by centaur

Recently I've been reading a lot on sentence construction - in particular the "little books" Mark Doty's The Art of Description: Word into World, Stanley Fish's How to Write a Sentence (and How to Read One), and Bruce Ross-Larson's Stunning Sentences, not to mention essays scattered across half a dozen books. I've enjoyed all this writing on writing, and I think all of it has been useful to me, but, as usual, there's one bit of advice I find myself encountering, find myself willing to take, yet find myself reacting against:

Find examples of great sentences to emulate.

On the one hand, I agree with this: finding great examples of sentences, then deconstructing them, imitating them and attempting to progress past them is a great exercise for writers, one I intend to follow up on (in my copious free time). On the other, focusing on exemplars of great sentences in the past, like it or not, encourages a mindset of focusing on the greatness of writers of the past, idolizing them, and then following in their footsteps.

I'm extremely allergic to the "idolizing the greats" syndrome. There have been greats in history, no doubt: great writers and thinkers, leaders and followers, heroes and villains. And there are people you will encounter that will impact you like no other: prophets whose principles will change your life, philosophers whose thought will change your mind, and authors whose writing will strike you like a physical blow. But they won't affect everyone the same way, and they won't solve your problems for you.

There are no secrets. It's all up to you.

Having said that, let me undermine it by recommending the following book of secrets: First Thought, Best Thought by Alan Ginsberg, Anne Waldman, William S. Burroughs and Diane Di Prima - an audiobook by four authors of the Beat Generation, talking about their experimental methods of poetry. I recommend the Beats because, like the Beats, I feel the need to counteract "conservative, formalistic literary ideals," but unlike the Beats, I don't reject those ideals: I just want more tools in my toolbox.

The Beats don't recommend emulating the past; they recommend finding ways of producing text that violate the norms. Ginsberg used breaths and rhythms. Burroughs cut words and sentences up and pasted them together until he had a whole page of, potentially, gibberish, which he then would mine for gems - perhaps finding a paragraph or even just a sentence out of an entire page of cut-up. Each author had their own method of breaking out of the mold. And a mold breaker … is a tool you can use.

So don't just find sentences to emulate. Write your own damn sentences. Cut up words on a page until they're confetti and rearrange them until they make sense. Build a program that writes random sentences. Throw down Rory's Story Cubes. Try magnetic poetry. Learn rap. Take improv. Stay up all night until you're loopy with sleep deprivation. No matter what crazy ideas you have, write them all down, then winnow through them all and pick the best ones - the ones that hit you like a physical blow.

THEN go back to the tools for sentence analysis from all those little books, and use them to make more of your own.

Seriously, what do you have to lose? Try the exercise. If you don't like what you produce, you may learn that your inspiration lies in understanding the past and building on it to create something new. If you do like it … you may add something to the world which, while its parts may come from the past, is in its whole ... wholly new.

-the Centaur

Pictured: a truly bizarre photographic composition that occurred by chance, and which I could not have planned if I tried.

The Science of Airships, Redux

Published May 24, 2013 by centaur

Once again, I will be giving a talk on The Science of Airships at Clockwork Alchemy this year, this time at 11AM on Monday. I had to suffer doing all the airship research for THE CLOCKWORK TIME MACHINE, so you should too! Seriously, I hope the panel is fun and informative and it was received well at previous presentations. From the online description:

Steampunk isn't just brown, boots and buttons: our adventurers need glorious flying machines! This panel will unpack the science of lift, the innovations of Count Zeppelin, how airships went down in flames, and how we might still have cruise liners of the air if things had gone a bit differently. Anthony Francis is a science fiction author best known for his Dakota Frost urban fantasy series, beginning with the award winning FROST MOON. His forays into Steampunk include two stories and the forthcoming novel THE CLOCKWORK TIME MACHINE.

Yes, yes, I know THE CLOCKWORK TIME MACHINE is long in forthcoming, but at least it's closer now. I'll also be appearing on two panels, "Facts with Your Fiction" moderated by Sharon Cathcartat 5pm on Saturday and "Multi-cultural Influences in Steampunk" moderated by Madeline Holly at 5pm on Sunday. With that, BayCon and Fanime, looks to be a busy weekend.

-the Centaur

The Centaur’s Guide to the Game Developers Conference

Published March 27, 2013 by centaur

Once again it’s time for GDC, the Game Developers Conference. This annual kickstart to my computational creativity is held in the Moscone Center in San Francisco, CA and attracts roughly twenty thousand developers from all over the world.

I’m interested primarily in artificial intelligence for computer games– “Game AI” – and in the past few years they’ve had an AI Summit where game AI programmers can get together to hear neat talks about progress in the field.

Coming from an Academic AI background, what I like about Game AI is that it can’t not work. The AI for a game must work, come hell or high water. It doesn’t need to be principled. It doesn’t need to be real. It can be a random number generator. But it needs to appear to work—it has to affect gameplay, and users have to notice it.

That having been said, there are an enormous number of things getting standard in game artificial intelligence – agents and their properties, actions and decision algorithms, pathfinding and visibility, multiple agent interactions, animation and intent communication, and so forth – and they’re getting better all the time.

I know this is what I’m interested in, so I go to the AI Summit on Monday and Tuesday, some subset of the AI Roundtables, other programming, animation, and tooling talks, and if I can make it, the AI Programmer’s Dinner on Friday night. But if game AI isn’t your bag, what should you do? What should you see?

If you haven’t been before, GDC can be overwhelming. Obviously, try to go to talks that you like, but how do you navigate this enormous complex in downtown San Francisco? I’ve blogged about this before, but it’s worth a refresher. Here are a few tips that I’ve found improve my experience.

Get your stuff done before you arrive. There is a LOT to see at GDC, and every year it seems that a last minute videoconference bleeds over into some talk that I want to see, or some programming task bumps the timeslot I set aside for a blogpost, or a writing task that does the same. Try to get this stuff done before you arrive.

Build a schedule before the conference. You’ll change your mind the day of, but GDC has a great schedule builder that lets you quickly and easily find candidate talks. Use it, email yourself a copy, print one out, save a PDF, whatever. It will help you know where you need to go.

Get a nearby hotel. The 5th and Minna Garage near GDC is very convenient, but driving there, even just in the City, is a pain. GDC hotels are done several months in advance, but if you hunt on Expedia or your favorite aggregator you might find something. Read the reviews carefully and doublecheck with Yelp so you don’t get bedbugs or mugged.

Check in the day before. Stuff starts really early, so if you want to get to early talks, don’t even bother to fly in the same day. I know this seems obvious, but this isn’t a conference that starts at 5pm on the first day with a reception. The first content-filled talks start at 10am on Monday. Challenge mode: you can check in Sunday if you arrive early enough.

Leave early, find breakfast. Some people don’t care about food, and there’s snacks onsite. Grab a crossaint and cola, or banana and coffee, or whatever. But if you power-up via a good hot breakfast, there are a number of great places to eat nearby – the splendiferous Mo’z Café and the greasy spoon Mel’s leap to mind, but hey, Yelp. A sea of GDC people will be there, and you’ll have the opportunity to network, peoplewatch, and go through your schedule again, even if you don’t find someone to strike up a conversation with.

Ask people who’ve been before what they recommend. This post got started when I left early, got breakfast at Mo’z, and then let some random dude sit down on the table opposite me because the place was too crowded. He didn’t want to disturb my reading, but we talked anyway, and he admitted: “I’ve never been before? What do I do?” Well, I gave him some advice … and then packaged it up into this blogpost. (And this one.)

Network, network, network. Bring business cards. (I am so bad at this!) Take business cards. Introduce yourself to people (but don’t be pushy). Ask what they’re up to. Even if you are looking for a job, you’re not looking for a job: you want people to get to know you first before you stick your hand out. Even if you’re not really looking for a job, you are really looking for a job, three, five or ten years later. I got hired into the Search Engine that Starts with a G from GDC … and I wasn’t even looking.

Learn, learn, learn. Find talks that look like they may answer questions related to problems that you have in your job. Find talks that look directly related to your job. Find talks that look vaguely related to your job. Comb the Expo floor looking for booths that have information even remotely related to your job. Scour the GDC Bookstore for books on anything interesting – but while you’re here: learn, learn, learn.

Leave early if you want lunch or dinner. If you don’t care about a quiet lunch, or you’ve got a group of friends you want to hang with, or colleagues you need to meet with, or have found some people you want to talk to, go with the flow, and feel comfortable using your 30 minute wait to network. But if you’re a harried, slightly antisocial writer with not enough hours in the day needing to work on his or her writing projects aaa aaa they’re chasing me, then leave about 10 minutes before the lunch or dinner rush to find dinner. Nearby places just off the beaten path like the enormous Chevy’s or the slightly farther ’wichcraft are your friends.

Find groups or parties or events to go to. I usually have an already booked schedule, but there are many evening parties. Roundtables break up with people heading to lunch or dinner. There may be guilds or groups or clubs or societies relating to your particular area; find them, and find out where they meet or dine or party or booze. And then network.

Hit Roundtables in person; hit the GDC Vault for conflicts. There are too many talks to go. Really. You’ll have to make sacrifices. Postmortems on classic games are great talks to go to, but pro tip: the GDC Roundtables, where seasoned pros jam with novices trying to answer their questions, are not generally recorded. All other talks usually end up on the GDC Vault, a collection of online recordings of all past sessions, which is expensive unless you…

Get an All Access Pass. Yes, it is expensive. Maybe your company will pay for it; maybe it won’t. But if you really are interested in game development, it’s totally worth it. Bonus: if you come back from year to year, you can get an Alumni discount if you order early. Double bonus: it comes with a GDC Vault subscription.

Don’t Commit to Every Talk. There are too many talks to go to. Really. You’ll have to make sacrifices. Make sure you hit the Expo floor. Make sure you meet with friends. Make sure you make an effort to find some friends. Make time to see some of San Francisco. Don’t wear yourself out: go to as much as you can, then soak the rest of it in. Give yourself a breather. Give yourself an extra ten minutes between talks. Heck, leave a talk if you have to if it isn’t panning out, and find a more interesting one.

Get out of your comfort zone. If you’re a programmer, go to a design talk. If you’re a designer, go to a programming talk. Both of you could probably benefit from sitting in on an audio or animation talk, or to get more details about production. What did I say about learn, learn, learn?

Most importantly, have fun. Games are about fun. Producing them can be hard work, but GDC should not feel like work. It should feel like a grand adventure, where you explore parts of the game development experience you haven’t before, an experience of discovery where you recharge your batteries, reconnect with your field, and return home eager to start coding games once again.

-the Centaur

Pictured: The GDC North Hall staircase, with the mammoth holographic projected GDC logo hovering over it. Note: there is no mammoth holographic projected logo. After that, breakfast at Mo'z, the Expo floor, the Roundtables, and lunch at Chevy's.