

Words, Art & Science by Anthony Francis
I had planned to post a bit about my work on the editing of LIQUID FIRE, but this image in my Google+ photo stream caught my eye first, so you get a bit of opinionating about work instead.
Previously, I've blogged about working just a little bit harder than you want to (here, and here), the gist being that you don't need to work yourself to death, but success often comes just after the point where you want to give up.
But how do you keep yourself working when you want to quit?
One trick I've used since my days interning with Yamaha at Japan is an afternoon walk. Working on a difficult problem often makes you want to quit, but a short stint out in the fresh air can clear the decks.
Other people use exercise for the same purpose, but that takes such a large chunk out of my day that I can't afford to do it - I work four jobs (at my employer, on writing, at a small press and on comics) and need to be working at work, damnit.
But work sometimes needs to bleed out of its confines. I've found that giving work a little bit extra - checking your calendar before you go to bed, making yourself available for videoconferences at odd hours for those overseas - really helps.
One way that helps is to read about work outside of work. What I do frequently pushes the boundaries of my knowledge, and naturally, you need to read up on things at work in order to make progress.
But you also know the general areas of your work, and can proactively read ahead in areas that you think you'll be working on. So I've been reading on programming languages and source control systems and artificial intelligence outside work.
Now, not everyone reads at lunch, dinner, coffee and just before bedtime - maybe that's just me - but after I committed to starting my lunch reading with a section of a book that helped at work, all of my work started going faster and faster.
Other tricks you can use are playing music, especially with noise canceling headphones so you can concentrate - I find lyric-free music helps, but your mileage may vary. (I often listen to horror movie music at work, so I know mileage varies).
Another thing you can do, schedule permitting, is taking a week out to sharpen the saw and eliminate blockers in your common tools so everything goes faster. I recently started documenting this when I did it and that helped too.
One more thing you can try is inverse procrastination - cheat on one project you really need to do by working on another project you really need to do. You use different resources on different projects, and switching gears can feel like taking a break.
Quitting time is another technique; I often make a reservation at a nice restaurant at the end of my workday, and use the promise of going out to dinner to both motivate me to work efficiently and as a reward for a job well done (I tell myself).
Some people use caffeine to power through this - and sometimes I even describe myself as a caffeine powered developer - but I've seen a developer stop in shock at their trembling hands, so beware stimulants. But at quitting time? That hits the spot.
Oh, and the last thing? Use a different channel. My wife is a painter … and listens to audiobooks ten to twelve hours a day. I'm a writer and programmer … so I doodle. Find a way to keep yourself engaged and going … just a little bit longer.
-the Centaur
I love Microsoft Word, but when I cut and pasted that excerpt from MAROONED into Ecto and published, I noticed a huge blank gap at the beginning of the quoted passage. When I looked in Ecto's raw text editor to see what was the matter, I found 336 lines of gunk injected by Microsoft Word … a massive amount of non printable goop like this:
<!--[if gte mso 9]><xml>
<o:DocumentProperties>
<o:Revision>0</o:Revision>
<o:TotalTime>0</o:TotalTime>
<o:Pages>1</o:Pages>
<o:Words>246</o:Words>
<o:Characters>1183</o:Characters>
<o:Company>Xivagent Scientific Consulting</o:Company>
<o:Lines>18</o:Lines>
<o:Paragraphs>11</o:Paragraphs>
<o:CharactersWithSpaces>1418</o:CharactersWithSpaces>
<o:Version>14.0</o:Version>
</o:DocumentProperties>
</xml><![endif]-->
<!--[if gte mso 9]><xml>
<w:WordDocument>
...
This is apparently XML text which captures the formatting of the Word document that it came from, somehow pasted into the HTML document. As you may or may not be able to see from the screenshot above, but should definitely be able to see in the bolded parts of what I quoted above, for 1183 bytes of text Word injected 17,961 bytes of formatting. 300+ lines for 200+ words. Oy, vey. All I wanted was an excerpt without having to go manually recreate all my line breaks …
I understand this lets you paste complex formatting between programs, I get that, and actually the problem might be Ecto taking too much rather than Word giving too much. Or perhaps it's just a mismatch of specifications. But I know HTML, Word, Ecto, and many other blogging platforms like Ecto. What is someone who doesn't know all that supposed to do? Just suffer when their application programs get all weird on them and they don't know why?
Sigh. I'm not really complaining here, but it's just amusing, after a fashion.
-Anthony
Recently I had a setback. Doesn't matter what on; setbacks happen. Sometimes they're on things outside your control: if a meteor smacks the Earth and the tidal wave is on its way to you, well, you're out of luck buddy.
But sometimes it only seems like a tidal wave about to wipe out all life. Suppose your party has lost the election. Your vote didn't stop it. You feel powerless - but you're not. You can vote. You can argue. You can volunteer. Even run for office yourself.
Even then, it might be a thirty year project to get yourself or people you like elected President - but most problems aren't trying to change the leader of the free world. The reality is, most of the things that do happen to us are things we can partially control.
So the setback happens. I got upset, thinking about this misfortune. I try to look closely at situations and to honestly blame myself for everything that went wrong. By honestly blame, I mean to look for my mistakes, but not exaggerate their impact.
In this case, at first, I thought I saw many things I did wrong, but the more I looked, the more I realized that most of what I did was right, and only a few of them were wrong, and they didn't account for all the bad things that had happened beyond my control.
Then I realized: what if I treated those bad things as actual problems?
A disaster is something bad that happens. A problem is a situation that can be fixed. A situation that has a solution. At work, and in writing, I'm constantly trying to come up with solutions to problems, solutions which sometimes must be very creative.
"Treat setbacks as problems," I thought. "Don't complain about them (ok, maybe do) but think about how you can fix them." Of course, sometimes the specific problems are unfixable: the code failed in production, the story was badly reviewed. Too late.
That's when the second idea comes in: what if you treated problems as opportunities to better your skills?
An opportunity is a situation you can build on. At work, and in writing, I try to develop better and better skills to solve problems, be it in prose, code, organization, or self-management. And once you know a problem can happen, you can build skills to fix it.
So I came up with a few mantras: "Take Problems as Opportunities" and "Accept Setbacks as Problems" were a couple of them that I wrote down (and don't have the others on me). But I was so inspired I put together a little inspirational poster.
I don't yet know how to turn this setback into a triumph. But I do know what kinds of problems caused it, and those are all opportunities for me to learn new skills to try to keep this setback from happening again. Time to get to it.
-Anthony
Pictured: me on a ridge of rock, under my very own motivational poster.
P.S. Now that I've posted this, I see I'm not the first to come up with this phrase. Great minds think alike!
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.
I’ve seen many presentations that work: presentations with a few slides, with many slides, with no slides. Presentations with text-heavy slides, with image-heavy slides, with a few bullet points, even hand scrawled. Presentations done almost entirely by a sequence of demos; presentations given off the cuff sans microphone.
But there are a lot of things that don’t work in presentations, and I think it comes down to one root problem: presenters don’t realize they are not their audience. You should know, as a presenter, that you aren’t your audience: you’re presenting, they’re listening, you know what you’re going to say, they don’t.
But recently, I’ve had evidence otherwise. Presenters that seem to think you know what they’re thinking. Presenters that seem to think you have access to their slides. Presenters that seem that you are in on every private joke that they tell. Presenters that not only seem to think that they are standing on the podium with them, but are like them in every way – and like them as well.
Look, let’s be honest. Everyone is unique, and as a presenter, you’re more unique than everyone else. [u*nique |yo͞oˈnēk| adj, def (2): distinctive, remarkable, special, or unusual: a person unique enough to give him a microphone for forty-five minutes]. So your audience is not like you — or they wouldn’t have given you a podium. The room before that podium is filled with people all different from you.
How are they different?
First off, they don’t have your slides. Fine, you can show them to them. But they haven’t read your slides. They don’t know what’s on your slides. They can’t read them as fast as you can flip through them. Heck, you can’t read them as fast as you can flip through them. You have to give them the audience time to read your slides.
Look, I don’t want to throw a lot of rules at you. I know some people say “no more than 3 bullets per slide, no more than 1 slide per 2 minutes” but I’ve seen Scott McCloud give a talk with maybe triple that density, and his daughter Sky McCloud is even faster and better. There are no rules. Just use common sense.
Ok. That’s off my chest.
Now to dive back into the fray…
-the Centaur
Pictured: A slide from ... axually a pretty good talk at GDC, not one of the ones that prompted the letter above.
As I mentioned in a previous post, Google Reader is going away. If you don't use RSS feeds, this service may be mystifying to you, but think of it this way: imagine, instead of getting a bunch of Facebook, Google+ or Twitter randomized micro-posts, you could get a steady stream of high-quality articles just from the people you like and admire? Yeah. RSS. It's like that.
So anyway, the Reader shutdown. I have a lot of thoughts about that, as do many other people, but the first one is: what the heck do I do? I use Reader on average about seven times a day. I'm certainly not going to hope Google change their minds, and even if they do, my trust is gone. Fortunately, there are a number of alternatives, which people have blogged about here and here.
The one I want to report on today is The Old Reader, the first one I tried. AWESOME. In more detail, this is what I found:
There are drawbacks, most notably: they don't yet have an equivalent for Google Takeout's OPML export. But, they are only three guys. They just started taking money, which is a good sign that they might stay around. Here's hoping they are able to build a business on this, and that they have the same commitment to openness that Google had.
I plan to try other feed readers, as I can't be trapped into one product as I was before, but kudos to The Old Reader team for quickly and painlessly rescuing me from the First Great Internet Apocalypse of 2013. I feel like I'm just using Reader, except now I have a warm fuzzy that my beloved service isn't going to get neglected until it withers away.
-the Centaur
So, after my scare over almost losing 150+ files on Google Drive, I've made some progress on integrating Google Drive and Dropbox using cloudHQ. The reason it wasn't completely seamless is that I use both Google Drive and Dropbox on my primary personal laptop, and cannot afford to have two copies of all files on this one machine. The other half of this problem is that if you only set up partial sync of certain folders, then any new files added to the top folder of Google Drive or Dropbox won't get replicated - and believe it or not, that's already happened to me. So I need a "reliable scheme" I can count on.
The solution? Set up a master folder on Google Drive called "Replicated", in which everything that I want to keep - all my Google Docs, in particular - will get copied to a folder of the same name called "Replicated" in Dropbox. For good measure, set up another replication pair for the Shared folder of Google Drive. The remaining files, all the Pictures I've stored because of Google Drive's great bang for the buck storage deal, don't need to be replicated here.
The reason this works is that if you obey the simple anal-retentive policy of creating all your Google Docs within a named folder, and you put all your named folders under Replicated, then they all automatically get copied to Dropbox as documents. I've even seen it in action, as I edit Google Docs and Dropbox informs me that new copies of documents in Microsoft Word .docx format are appearing in my drive. Success!
At last, I've found a way to reliably use Google Drive cloud. Google doesn't always support the features you want, or the patterns of usage that you want, but they're deeply committed to open APIs, to data liberation, and to the creation of third party applications that enable you to fill the gaps in Google's services so that you aren't locked in to one solution.
Breaking News: Google Reader canceled. G*d dammit, Google…
Next up: after my scare of losing Google Reader, a report on my progress using The Old Reader to rescue my feeds...
-the Centaur
Pictured: A table candle at Cascal's in Mountain View, Ca...