May 14, 2015

What I mean by "be kind"

My "crunch crash" article went on Kotaku, republished in full (and I also put it up on GamaSutra, because maybe the audiences are a little distinct). I read the comments¹, or at least a few of them. And I realize maybe I should clarify what I meant about "being kind."

As I mention in the article, I'm most definitely not saying, "Don't serve your audience." If you're a reviewer, your responsibility is to do that. But John Updike gave some great rules of thumb for criticism that could easily be adapted for games, especially in today's primarily web-based critical environment².

Beyond that, I also meant the sort of online environment we find amongst our fans. One of the first comments on that Kotaku article was about, "What, are we supposed to ignore bugs and stuff just because the developers crunched?"

Of course not. Because although there are places where crunch is mandated and terrible, in some cases it's employee-driven³: we do it because we love what we're making and we're just plain driven to do as much as we can to make that thing the best it can be before it goes out the door. It's part of our gift to the people who will be playing it -- games are the product of our creativity, and therefore our art4. What I mean is, we sometimes put in a lot of extra time just because we're really trying to make that game the best we can under the constraints we have.

What I'm looking for is just a bit of kindness, and I'll give you an analogy in a moment. Because we're there at the end of the project, we're exhausted and raw and we've thrown everything we had into it. One can be both honest and kind.

I happened to speak to a developer friend about this, and he pointed out how important it is to us actually to get the feedback. We want to know if there are obscure crashes, or weird issues, especially showstoppers. We live in an era where games are significantly more complicated, technically, and fewer and fewer studios have an in-house QA department that they can count on5. This developer friend pointed out that the tone of the reports is what really wears you down. You're trying to help; you're trying to find out what the issues are, and meanwhile someone is shouting angrily at you.

I get that it's frustrating to encounter an issue with a game you've been wanting to play; totally get it. I also play games, and I have had those experiences. But Hulking out at the developer in some Internet forum somewhere isn't going to help you or them! You will forget it five minutes after you write that angry comment, and somewhere else in the world, someone will be totally bummed out for the rest of the day.

Here's that analogy: I'd like for us to imagine, if one would, being in a restaurant. One orders the soup of the day, and when the waiter or waitress brings it out, one discovers its cold. At this point, does one:

a) Irately debase this person, using as inventive names and cursing as you can muster, calling into question his or her abilities and parentage, and demanding a refund immediately while at the same time shrilly announcing to all and sundry that you'll never eat here again, OR

b) Politely explain the problem you're having with the meal and work together to understand and resolve it.

I humbly suggest that (b) is a better option, because I've seen (a) and it's never pretty. With (b), you'll almost certainly get an apology and if it's possible, an earnest effort to solve your problem, whether it's soup or an issue with your game. After a team pouring all this effort into your experience, we really do want it to be the best experience it can be for you.

Besides, wouldn't it be embarrassing after all that to learn that the soup of the day was gazpacho?



¹I know, I know. Actually Kotaku seems to police theirs, which is great, and as a result they were fine.

²This was pointed out to me by a friend; thanks, friend!

³Not in all cases. But in some. I don't want to diminish those that aren't. But I will say that if you're part of a team that crunches because you work well together and you just want the best thing you can get out there, that's an intrinisic motivator, and anecdotally speaking, that has different effects on your productivity than the extrinsically motivated forced crunch modes. It's possible to be productive in crunch; not after months of it, but sure, for brief bursts. Anyway.

4This is shorthand from Lewis Hyde's The Gift, totally worthwhile reading if you can find a copy.

5I've always been lucky enough to have really good QA departments working in the same building with me, but this isn't the case for a lot of studios. Often you have a publisher's QA department looking it over, nowhere near where you're located, and therefore you don't develop the personal relationship with them that helps ensure that you're really working towards the same goals. You may literally not have seen some of the bugs that your community finds, sadly. And yes, again, that needs to be brought up in reviews, etc. But everything is patchable these days, so hopefully we can fix it!

Posted by Brett Douville at 05:09 PM

May 02, 2015

Crunch Crash

This week I watched the 19th episode of the Double Fine documentary, "Last Call", and I had a real moment of recognition (and concern) when I saw Senior Gameplay Programmer and friend Anna Kipnis miss two weeks of work.

It brought to mind my own scariest contact with crunch. It was on Jedi Starfighter, my second game at LucasArts, the first where I was a lead programmer. We had been told by the company that the game had to come out in the fiscal year, which ended March 31st of 2002; the company had nothing definitive on the slate for the year, and having just finished Starfighter, they wanted to take that investment and put out another game using the engine. I led a team of programmers mostly new to the project, since the other two senior programmers were investigating some new tech and we had had a lot of turnover due to the dotcom boom. I had one more junior programmer who stayed on from Starfighter, one new hire for graphics and collision stuff, one for gameplay from our tools department, and a shared resource who maintained and improved the low-level graphics library we had in-house for the PS2.

Due to business reasons, this meant Jedi Starfighter had to be done in about eleven months. We had a story which involved a bad guy who tactically deployed remote probes to destroy infrastructure. I don't really remember too much about the details, but it was an uncomfortable mode of destruction once 9/11 happened. And so we did what we could to change the story without impacting the mission structure too much -- helpfully, half of the game revolved around Nym getting his base back after he fled it in the original game.

What also happened as a result of 9/11 was the departure of that one programmer who had stayed on from Starfighter. He had known people who worked in those towers, and just needed a break from making video games for a while. I didn't blame him in the least; he gave us the standard notice, we tried to tie off any obvious loose ends, and he moved on.

I did what seemed reasonable to me at the time -- I absorbed that programmer's work into my own schedule. It had taken me a long time to fill the other roles on the team, and I didn't think I could find someone to do what this programmer did in that time.

I took a 40 hour a week job and turned it into an 80 hour a week job, about five months from sending it off to manufacturing. Not really thinking about how a month or two from then, my 40 hour a week job would have turned into an 80 hour a week job all on its own.

All of this led to the specific moment I wanted to talk about. In February, as we were preparing for our first submission to Sony, I wasn't feeling so hot. It was the middle of the afternoon, and my stomach was all queasy, and I needed a little air. Intending to get some saltine crackers, I drove to the Safeway a couple of miles away, parked, opened the door... and couldn't stand up.

I had no strength in my body.

I sat in that car for nearly an hour, not really knowing what to do, and knowing that every minute was precious as we tried to get that game out the door. That's right, the first thing I thought of in my predicament was that I was hurting the game -- not, "oh shit, am I having a heart attack," which would have been a rational thing to consider, but "oh, I hope this doesn't hurt cert." I didn't have a phone; I was late on the cellphone train, didn't get one until 2005. I just sat there with the window open.

Eventually my strength returned. I got my saltines and some ginger ale and got back in the car and went back to work. I never did go in for a checkup. I still don't actually know what happened to me that day.

I thought of this when I watched the latest episode of the Double Fine Adventure series; I hadn't thought of that day in the Safeway parking lot for years. We push ourselves so hard some times, because we feel the responsibility to support our team, or because we feel that not doing so will impact the company, or because we love what we're doing enough to make sacrifices for it, or because management dangles a carrot of a higher bonus, or because we feel trapped. There are a million reasons, none of them better or worse than any other. It's hard to make games, and some of its costs never show up on a balance sheet. My story is far from unique; I shared this one because it was my own.

Why mention any of this? Well, I don't know, I guess I just want people to be kind. It's easy to put on an angry face and say a thing sucks and let me tell you why it sucks and throw a pile of snark at the wall to see what sticks. It's hard to remember that these "products" are complicated endeavors requiring myriad talents, and that those talents come from people who tried to pour a little bit of themselves into it at sometimes significant cost. I'm not saying, "Don't serve your audience" -- if you're a reviewer, you should do, and you should explore your reactions, and if those reactions are negative, it's your responsibility to be honest about them. But maybe just go that extra bit to be kind, if you can, to start from a position of kindness. To save all that bile for things that are truly deserving of your rancor, and make that bile stand for something because it isn't the default. To be as generous as you can be especially to those things which try to push the medium in new directions, where the cost is maybe even higher to individuals because the returns are likely to be lower, and thus capital isn't interested. To remember that that thing you want to savage was made by people.

*EDIT*: Now that I've had my coffee, I might also point out another reason for a bit more kindness -- typically these reviews are coming *ta-da* right after creative folks have been through the absolute worst. They've poured in all their energy, and their reserves are low, their defenses are down, and *that's* exactly when they get hit with the snark. It can be dispiriting -- I mostly avoid reading stuff about games I've worked on, but I didn't used to. Right after JSF shipped there was a review in a big magazine that was particularly unkind to something that I had worked on, and that has stuck with me way more than the memory of nearly collapsing from exhaustion ever has. It doesn't sting any more or anything, but I can't think of the game without thinking of that comment; and that's likely because of how worn out and raw I was when I read it.

Posted by Brett Douville at 09:45 AM | Comments (0)

October 01, 2014

An open letter to Intel

I posted this letter through Intel's corporate responsibility page just now in support of GamaSutra and its editorial stance.

Hi Intel,

I've been a game developer for coming on 17 years, and spent all of that time developing both on and for Intel architectures. I was at LucasArts in the late 90s and early 00s, and we were often lucky to receive Intel development hardware directly from you. I've used your tools for years, including your optimizing compiler, which led the competition in terms of performance almost from its birth.

So it's with no small amount of sadness that I see you pulling your ad support for GamaSutra today. I imagine there's been some incoming email about recent editorial choices at the site.

GamaSutra, and it's long-associated print publication Game Developer (RIP), were the developer-focused materials that I could also rely on over much of my career. I've seen your sponsored articles there frequently over the years; often it would be the first or even only place where I'd see your products, since so few advertiser-supported sites focus exclusively on game development.

I believe that pulling your support over recent editorial choices is a mistake; I believe that you've largely been contacted by a group who are not made up of the site's audience. It's a shame to see you pull your advertising dollars in hostage to a virulent hate campaign orchestrated by a small number of people who use the Internet's anonymity as a shield.

I hope you'll reconsider. I visit GamaSutra frequently, and I think the editorial choices have always pursued inclusivity in game development. Indeed, I think that's why it has lasted as long as it has.

Sincerely,

Brett Douville

Posted by Brett Douville at 07:46 PM | Comments (0)

July 22, 2014

How I deal with data, part one

A Maze of Stupid Little Languages, All Alike

Advance notice: Nothing here is terribly new or revolutionary. Someone out there may find it useful. This is the sort of stuff that often comes up in game development but that people rarely write about, at least, in my experience.

I'm in the process of designing and building a game with attention-management, simulation, and Sim elements. In it, the player will directly and indirectly affect the happiness of Little Computer People through decisions made in the attention management part of the game, backed by a richer simulation of an audience for that performance. That's all kind of hopelessly abstract, I realize, but it's kind of the level at which I'm comfortable discussing it in a public Internet forum at the moment. (I do discuss more specifics in person with people. So ask me when you see me.)

Lately¹ I've been taking my ugly, rough, hard-coded test data prototype to a series of data files that can help me more fully flesh out the game play and create content that is more reflective of how I expect the final game to actually work and feel, both in terms of quantity and quality. My intent is to have a "campaign" of fully authored data with a procedural approach for people who want to continue playing beyond that, and these articles address the hand-authored content specifically, though I expect the description of procedural stuff to follow along similar lines. After I feel like I have the data thing nailed down enough to build, balance, and play a few (again, super-ugly) levels that have the right feedback loops to the player, I'll be looking into the actual visuals that will support the final product (characters, environment, etc).

Anyway, because I'm a programmer, I tend to go straight to text for data. It's easy to manipulate (by hand if need be, which is where I'm starting from right now) and easy to read. In so doing, I tend to come up with very simple little context-specific languages to deal with my data. But for performance and sanity reasons, I work with binary when I'm actually loading this stuff into my game², mostly because I hate parsing stuff in C++. Granted, I could use a well-known format like JSON or what-have-you, but I haven't at that point really solved anything, I've just offloaded parsing the text into a library (with its own run-time performance concerns, usually having to do with memory allocation), and then I need to walk the built-up data structure to look for stuff, and handle failure conditions. Bleh. Instead, I prefer to build a custom format that can be directly mapped simply to data structures in memory, allowing for a single allocation to read in the file once, a little walking over that data to map structure pointers (typically by converting offsets to pointers). The data can be then deleted in a single deallocation later and the structure cleared out.

It's also worth noting that I could, at a later date, write tools that sit on top of that simple format, and I may well do so to support post-ship modding of the game or the Steam workshop (should I be on Steam), or whatever. For some of the data I expect to author, it'll be useful to be able to visualize the data in terms of frequency of certain occurrences, but I could certainly do that by writing additional simple tools that spit out different data (images, comma-delimited text files, whatever) from

I would almost certainly choose differently if I were working on data that I expected many people to have their hands in at any given time. At that point, I'd probably want a database of some kind and things like that. Solo development makes this sort of thing much easier. In this case, I'm designing development tools for myself -- a person who is super-comfortable with text files and actually can visualize stuff from text files pretty well in his head. Whenever you're developing, you should think first of the client for your tools. Also: if I worked against a database, later steps of this process would be largely the same, I just wouldn't be parsing the data in the same way.

Here's what my languages tend to look like, with some real text that I've moderately fudged to obscure actual subject matter (in other words, not a game about outlaws). Just to give the flavor. There are no lawyers, guns, or butter in my game. I may add butter. ;)

## Josie Wails
:littlecomputerperson JWails "Josie Wails"
:lcpshort JWails "Former outlaw, now reformed"
:lcplong JWails "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et"
:lcplong JWails " dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."
:lcparrives JWails 3.3
:lcpskill JWails lawyers 16
:lcpskill JWails guns 32
:lcpskill JWails money 16
:lcpskill JWails butter -8
:lcpappears JWails initial
:lcpinitialHappy JWails 32
:lcpHappy JWails and gte ammunition .3 lte butter 0 3
:lcpHappy JWails gte ammunition .6 3
:lcparrives default 0.0

Stuff to note:


  • Simple command structure. Basically, every line is a command, and they all follow a pretty simple structure that adds a specific bit of data to a particular main container item. I declare the LCPs with friendly names (which will be displayed in-game) but then use identifiers from that point on to prevent the need for global search and replace later.

    This has some great benefits, in particular that I can separate out data however I like -- I might want to keep all the skills descriptions in one place so that I can see at a glance that I don't have anyone who has a positive "butter" skill or I might put all the descriptions in one place at the bottom since I tend to write them once and then not think about them again. If I were working with a format like JSON, my natural inclination would be to keep all the data for a particular LCP together in one place. (It would probably also be significantly more verbose.)

  • Minimal data per line. As I'm not going to ever ship this stuff, I just go ahead and put only one bit of data per line. It's all "this command tells you this about this data object".
  • No multi-line stuff. As you can see in the :lcplong command, it would sometimes be easier to deal with this stuff on multiple lines, but that just makes parsing complicated. Instead, whenever I see a long description, I look for the LCP id in the appropriate Python dictionary, and if it's there, I append.
  • Prepended : for commands. On occasion I have need to rename a command because I've changed what it means and already have data. It's helpful for find-and-replace to have the : there and it doesn't add appreciably to typing. Originally I had named the command "lcplong" as "long" but ended up using the same command in multiple data files. In case I want to merge them all together later, it's helpful to have distinct commands and searching and replacing ":long" with ":lcplong" meant I didn't have to worry about stepping on the word "long" in descriptive text.
  • Not shown: documentation in the file. At the top of each file I explain the syntax to myself for each command, because I expect I'll forget things. Often, it's enough to see the commands already in use, but it's helpful to have something to refer back to in case it's not clear. In a pinch, I can always examine the Python parser, but I'd prefer not to have to.
  • Also not shown: extensibility. Adding an "include" directive is super easy and doesn't complicate the resulting Python all that much, it just means encapsulating the parser loop in a function that can be called in a re-entrant fashion. Because commands are all basically additive, the "state" will be just held in Python data structures and anything that needs to be shared and included in multiple files can be easily handled.
  • Handling default behavior. Ultimately, I'm going to want to have reasonable defaults for things to fall back on, so there's a dedicated keyword that can't be used as the id of any specific LCP, which is "default". All of my parsing commands will notice this, as you'll see tomorrow.
  • Comments. Comments are, like Python, begun with the octothorpe³ and are single-line only.

Tomorrow I'll come back to this and show how simple languages like these are easily handled in Python and output to a binary.




¹Since shipping Sixty Second Shooter about a month ago, which had occasioned a six month break from my game or so.

²Note that I say game and not game engine. My game is currently hand-coded C++ on top of some cross-platform libraries.

³How great is that word.

Posted by Brett Douville at 02:30 PM | Comments (0)

November 28, 2013

Thankful for the work

About a month ago, a friend of mine sent me email asking me to answer a few questions about programming so that he could put together some advice for a niece of his who was struggling with computer science in her high school classes. I wrote him a reply and pretty much promptly forgot about it.

I came across it again this morning and what struck me re-reading it is how thankful I am that I get to do this work as my profession. So, while I'm thankful for a lot of things that I won't go into here, I'm immensely grateful that I draw so much intellectual reward from the work I do. Not everyone is so lucky.

Happy Thanksgiving everyone.

What do you love about programming?

What I really love about programming is that more often than not, I am trying to take a mental model of some thing -- some problem I'm trying to solve, perhaps, or maybe just some process -- and comprehend it enough to break it down into parts that will interact and become a computational model of that same thing.
Another thing that I love is how much programming has been changing ever since it began. Programmers and researchers create whole new languages constantly to try and meet new challenges, to find new ways of modeling the world and solving problems. There's a huge body of work that's already been done, but I feel like we've discovered a whole new continent to explore and we've barely left the beach where we landed. Whether you're one person working alone or as part of a team, you can be constantly growing as a programmer. There is no end, only constant, wondrous change.

What’s something about programming you wish someone had told you when you were starting out?

Honestly, there are probably several things.

The first would be to have a healthy skepticism of whatever new flavor-of-the-month technique or method comes along. By "healthy", I mean that you should be open-minded about new methodologies, but temper that with seeking evidence for the claims the methodology makes. Often, the proponent of a new way of working in programming is simply trying to rationalize what has worked well for him or her -- that may not work well for everyone, and it may just be that the person is him- or herself really productive, and that any approach may have worked. Programming is difficult, and we are often easily lured to new ideas which may make it easier -- these aren't always better, merely newer, and so we have to evaluate them as rationally as we can.

Another thing I wish someone had told me was what a rich early history computer programming has; there was so much wonderful theoretical and actual work done in the early age of computer science that I now feel we truly do stand on the shoulders of giants. These were people solving really hard, fundamental problems in algorithms, in language design, in thinking about how problems break down, in efficient uses of resources, in the representation of time and interdependency, in human-computer interfaces, in all sorts of things, in every branch of computer science you can think of. The fact of the matter is that a lot of these papers are very hard to read; they often rely heavily on mathematics and on language that has very specific meanings, and so you might have to read and think about a paper for a long time before you fully understand it. But it's marvelous.

I also don't think I understood coming into it just how much a programmer's job involves communication. Unless you are completely working in a vacuum, which is extremely rare (how do you breathe in there?), you'll have to communicate with other people. About six months ago I was asked on a panel what the most important language was for programmers to learn, and I said completely honestly: "English" (or whatever language it is your co-workers use). Even if you're working on your own, you'll be solving problems that are described in natural language, not in computer terms, and being able to understand both the stated requirements of a system and those ephemeral issues surrounding a problem will be valuable. I've learned easily a dozen computer languages in my fifteen years as a professional programmer, and even created a couple, and none of that matters compared to being able to read, write, listen, and speak fluently. Be prepared to ask questions, probably lots of them, as simply as you can.

What about programming is fun for you?

Breaking down a problem into sensible parts is probably the most fun thing, but maybe it's just because that's what I've been up to lately. Taking something large and maybe not even entirely defined and putting it in smaller chunks that you can grasp and start to fit together is really wonderful. I've heard this process described as firing "tracer bullets" through the code -- you solve a problem end to end as narrowly as you can, and then once you understand the whole way it will work together, you broaden it out to cover more of what it needs to do. It's terrific.

It's also always fun to see the results. There are occasionally moments when a system you've built will surprise and delight you, when something you didn't explicitly code in a mathematical sense will nonetheless come out of the program you've written. These are sparkling wonders. I can recall maybe midway through Star Wars: Starfighter's development when I challenged my project leader's assumptions about how AI should be structured for flight games and went a different way. The resulting prototype ended up being reasonably difficult to fly against, but it also exhibited what fighter pilots call a "scissoring" pattern -- not something I had coded deliberately, but which had simply emerged from how the AI "thought" about what it was going to do next. That was a moment of magic I'll never forget.

I also really enjoy learning new programming languages. It's like a whole new way of seeing the world. I don't paint or sculpt or create visual arts like those, but I imagine it's a little bit like discovering pastels or oil paints, or getting a new lens for a camera, or working with clay for the first time or in a different way. New tools provide new ways of looking at the world in the same way, I think.

I really enjoy working with people who have very different skills than I do -- I've worked with a lot of great designers, artists, animators, creative people of every stripe, and I almost always come away from it energized to do my best work. When you're working with good people, you push yourself to excel to meet their own best work, and the results can be much, much greater than what any one of you could have done on your own.

What about programming is funny?

I don't know that I find a lot of humor in programming per se. But that said, I've found that I've always been around a lot of smart, creative people, and those people tend to be funny. I don't think this is unique to programming, however; whenever you dive deep in a particular subject, you end up with new building blocks for humor, whether it's terminology that means something different normally and can be played off of or punned with, or just the deep nerdy stuff that comes from shared experiences in programming. Many of the little jokes or funny observations that you'll hear in conference talks or in general conversation with other people who do what you do are only funny because you've experienced something like it yourself. It's a laugh of recognition.

What made you want to be a programmer?

I was really lucky to come along at a time when computers were still young. My father worked as a computer programmer professionally all his life, and he would bring home a terminal some weekends to play games on. It would spool out page after page of teletype on green and white paper, and we'd explore the crystal caverns for hours through a 200baud modem connected to his work. That gave me a fascination for how those things were put together, and when I got an Apple ][+ a few years later after showing an affinity for it in my school, I was hooked for life. That machine came with two manuals: a hardware reference, and a reference manual for programming in Basic. I've basically been programming ever since, but I started by writing text adventures and simple arcade games.
I think the hook was set by being able to imagine things and then see them on my screen, taking some weird esoteric instructions in a file and translating that into a robot moving around in RobotWar, for example, or even just having a prompt on the screen that was there because I made it be there. It was to me, and remains, absolute magic.

What’s your favourite teenage programming memory?

I wrote a 3D wireframe renderer on that very Apple ][+ when I was in my early teens, and I also used it to code up some visualizations of how aerodynamics and the Bernoulli effect worked for a science fair around that time. That was all pretty cool. But that's a long time ago and it's kind of hard to remember :)

What about programming is annoying?

It can be really frustrating to work with a system that is implemented differently from how you would have done it or that was made to solve a different sort of problem than it's being used to solve now. Sometimes you're even the person who wrote it, and you want to go back and tell your past self to make just a couple of changes so that the system is easier to maintain and extend in the future. But these things just happen, often, as a result of code that has to be written to meet a deadline or which outlives its usefulness or which multiple people have supported over its lifetime, none of whom have really thought through the way the system was meant to be maintained or extended, just bolting on the functionality they thought needed to be there. It happens.

The other is when your iteration time slows down. Working on small programs is wonderful because you can keep everything in your head all at once and nothing takes long to do or evaluate. When you work on large code bases with many contributors, this isn't true any more -- you can't understand all of it, no one person understands all of it, and making changes can become a long and protracted process. Iterations themselves can be very slow just because changes cause chain reactions of things that need to be recompiled and relinked, which can become time-consuming. Nothing promotes creativity better than iterations taking no more than a few seconds to test.

Posted by Brett Douville at 09:02 AM | Comments (0)

August 08, 2013

So, I'm Moving On

This week I gave my notice at Bethesda Game Studios. I've been a lead programmer there for five years. In my time at BGS I helped ship Fallout 3 and led the systems programmers for Skyrim. I'd be enormously pleased to have either of those on my résumé; having both is humbling, and I'm very grateful to fans and friends for their support. I will continue to play the games Bethesda carefully crafts, and I kind of look forward to being able to spend hundreds of hours in those worlds when the products are finished instead of when they're still being built. It is certainly bittersweet to leave. It's a great team. I've made many friends there. My last day will be on August 30, which will leave me unemployed just in time for Labor Day.

My departure isn't about them; it's about me. I've largely been doing the same job for most of the last dozen years or so of my life, and so I think when I saw this SMBC comic the kernel of the idea of doing something at least a bit different was lodged. I didn't think about it too hard at the time. There is a bit of truth in that series of panels. It nagged at me.

There have been other signs. I was asked on a podcast whether I'd ever considered going indie and I had to take a long pause before giving an answer that was kind of rote. I went to GDC this year and didn't return as recharged and energized as I always have in the past. I kept at the job, giving it my best, being a professional. I was content. All my basic needs were well accounted for. But I've had an itch.

As I've told a few people this week, I'm young enough that I'm not done with seeking new challenges. I'm also old enough that I know my ability to meet those challenges won't be there forever. Huge thanks go out to friends with whom I've discussed this change; lending me your ears and listening to me cavil and kvetch has been enormously productive for me in my thinking. Your support has been hugely beneficial to me.

Some of the challenges I'm really curious about are in videogames¹. I've been really impressed with the work in the indie space in the last year and some of my favorites come from small groups or solo creators. Some have shipped, and some have yet to ship. When I started programming games as a kid, I did it all myself and that holds some appeal to try now with years of experience. There's still that little kid in me. Having been an IGF judge and jury member for a couple of years has exposed me to so many more possibilities. It's a heady time for videogames. Explosive growth. Explosions of meaning and markets and membership in the creative club. Terrific stuff.

In the short term a certain amount of idleness and reflection is called for, just to catch up on some chores that need doing, finish up some games that need playing, and enjoy some extra time with my sons. One of the challenges I have in mind will call to me.

In the meantime, if there are any indie friends out there who need a little technical advice or feedback on your upcoming games, I'd love to help out. Hit me up on Twitter and we'll figure it out.






PS. If you are a colleague at BGS and learning about this here, I'm very sorry. I figured the news would have gotten around via sneaker-net by now, and time was somewhat short before I got out of town for a few days.


¹I also may like to write. I've had some novels and stories in mind for a while, jot down notes from time to time. So that's something I may need to do for myself at some point, too.


Posted by Brett Douville at 11:38 AM | Comments (8)

January 03, 2013

Fifteen

Today marks the fifteenth anniversary of the day I first joined the games industry and made the programming of video games my profession.

It's difficult really to remember what life was like before that, because so much of what is part of my life started around then. I've been a parent in the industry nearly the whole time -- my first son was born about eight months from my start date at LucasArts, and my second son two years later. Most of my close friends are friends I gained through my work, though of course not all. I've grown significantly over that time, in my professional habits and my personal hobbies, and it's really hard to cast my mind back.

The one constant through it all has been change and challenge. When I started, significant changes were the explosion of 3D¹ and the threat of the dot-com boom; LucasArts hemorrhaged employees while the economy enjoyed what turned out to be an immense bubble, but at the time the United States was enjoying what appeared to be limitless prosperity. Some artists had trouble making the transition to 3D and quietly drifted away to other things. When the bubble burst, some of those we had lost returned to games, some didn't. The industry grew and grew.

The next significant change and challenge, at least where I worked, was the switch to focusing on console games, another milestone. In the time before I arrived, LucasArts had enjoyed a diverse portfolio that included Nintendo 64 titles with fairly great success and PlayStation titles with perhaps more modest success, but its real bread and butter was the PC. The company started to put an even greater emphasis in the next generation of consoles with titles like Rogue Squadron on the GameCube and my own first game, Star Wars: Starfighter, on the PlayStation 2. These machines sparked another technical trend that has now come to dominate the industry, the ubiquity of parallel processing; for a long time, PCs would remain a bastion of a simpler programming model, but no more. As with 3D before it, some programmers had trouble adapting to the model and moved on. But still the industry grew and grew.

The industry grew and so did its audience. Now that truly beautiful experiences were possible on your TV, without all the finicky driver madness of the PC, consoles came to dominate more and more each year; I seem to remember that around this time Electronic Arts was the first third-person publisher to crack the $1B milestone for revenue on a model dominated by movie licenses. Games became more complex and while there were bright spots of personal expression from design auteurs, they certainly seemed less frequent than they had a decade before. Game teams of course also grew in size; the first team I worked on was around thirty or forty people, with a peak programming team size of perhaps seven, and it has never been smaller than that; now I work with a team of thirty programmers as part of a larger team, and there are development houses who throw truly staggering numbers of people at projects.

As audiences grew, budgets grew and games became more and more a hit-driven business. A high degree of polish became really important² and this was increasingly a demand on the technical team. As a result, crunch times became a truly staggering problem in the industry that drove people away, perhaps really reaching its limits when the "EA spouse" story broke, but still the industry grew and grew.

We started to fracture only recently, perhaps in the last seven years or so, in the latter half of my career thus far. I've read constantly about how one or another segment of gaming has died or is going to die, dire predictions that we're not reaching our full potential and therefore we'll be pigeonholed like comic books were, how this issue or that issue is going to kill off our industry. Adventure games were dead, until they weren't -- I can't tell you how many GOTYs The Walking Dead got, but it wasn't a small number. AAA games are apparently dying -- except I'll tell you right now, they aren't. Budgets will continue to increase, but the market will correct for that; games that don't meet the bar won't sell, and there may be fewer teams that can meet the bar, but there will be a market for AAA games for the foreseeable future. And still the industry will grow.

What I see, again and again, is growth and maturation. I'm glad to hear voices calling for more diversity in both our games and our creators, but then I look down at the iPad I'm typing this up on and about a hundred games of all different kinds, many of them not violent at all, and coming from all sorts of team sizes and make-ups. There are so many roads into game development now -- indeed, you can sit down and program games that are hundreds of times as complex as my very first games³ in your browser or on your phone for a relatively minimal investment. I feel in many ways like we've come full circle from where I began, as a player, but with the cultural heft of products which sell millions of copies behind them.

I understand when people complain that we aren't diverse enough -- we aren't, though I think as a whole the industry is getting better. I understand when people say that AAA is dying -- even though I know it's here to stay4 and that we're simply going to be a smaller percentage of a substantially bigger pie. We do need to explore areas other than violence -- but we're doing so. We do need greater variety -- but I look down at the various devices I carry around with me day to day and I know we're attacking that problem too. I'm glad that people are concerned about these things and demanding that we not rest on what we've done. We shouldn't. And I know we won't.

In an interview a few years before his death, Sir Edmund Hillary was asked whether there were any peaks left conquering in the world, and he remarked that there were a few climbs of interest left... but that he wasn't going to tell, since he might still like to be the one to be first. I feel much the same way about game technology: lots of challenges remain in this field that I love, some that have been identified and some that haven't. I hope I'll scale them along with the rest of you some day, because there are an awful lot of truly great big and interesting mountains out there left to conquer. Here's to the fifteen years just past, in an eye blink, and to whatever comes next.

¹In fact, as I recall LucasArts shipped what it claimed would be its last 2D title ever in the year I started, or perhaps shortly before, with Curse of Monkey Island. It claimed around that time that forever more it would be developing and publishing only 3D-accelerated games. It was sort of like Dylan going electric, an immense surprise to those who loved the 2D adventure games we were really known for. I don't think it was premature, but I bet you could still find a few people on the internet today who are angry about it.
²Recently I've played PS2 games that lacked the polish we see today, and it's hard to imagine how games like those could even be released today, with issues like enemies popping into existence right before the player's eyes, stuttering animations and all sorts of issues.
³I.e. the games I first played and programmed back on my Apple ][+ or on the mainframe at my dad's work.
4Hollywood's a great model for this -- sure, there was room for an indie mindset in film, too, but keep in mind that Skyfall, from a violent AAA series that began in the 1960s, was nonetheless the biggest selling in its history, despite largely following a similar formula to all that had gone before.

Posted by Brett Douville at 07:01 PM | Comments (2)

November 27, 2012

The #1ReasonWhy

This morning I discovered the #1ReasonWhy hashtag on Twitter -- a collection of thoughts about why women feel unwelcome in the games industry; I discovered it by way of Katie Williams's Alive Tiny World blog. I'm not smart enough to boil down my own anecdote into 140 characters, so I'll go ahead and post it here.

It was 2002 or so, perhaps 2003, and I was working at LucasArts. I can't recall now whether I was leading a programming team at the time or not, but by the time this happened I had led a team and shipped one or two projects, and had worked both with a female programmer and other female content people, artists and animators and designers.

LucasArts had a fairly good balance of women in those days; I think we were probably a bit ahead of the industry at the time, though it wasn't something I ever discussed with anyone there and I don't really know for sure. Over the course of my seven years there I worked with three different female programmers (one of whom was briefly lead programmer of a project I was on) and I recall at least a fourth who I never had the chance to work with -- about 8-10% of the programming staff were women. The distribution in art and animation was quite a bit higher, I had worked with a female lead artist and indeed the head of the art department was a woman. I can't specifically recall the numbers, and you'd have to go and look through old books of credits or LucasArts yearbooks to find out in any semi-scientific sort of way.

We were hiring and I had been selected to sit in on an interview; lead programmers often screened candidates by phone for the projects they were leading, and other leads were brought in to interview if a candidate was brought in for an in-person interview. I was part of a three-person interview team including the director of programming and a female programmer who had led a very successful PS2 and PC title; I don't know the financial numbers but it reached critical acclaim.

The candidate was a lead programmer on a FPS project in Texas; I can't remember more than that¹, not sure if it was Dallas or Austin. I think, based on the one question I can remember from the interview, that he was interviewing for a lead position, but he was certainly a fairly senior guy. We asked the usual introductory comfortable questions along the lines of "give us an overview of your career thus far and what you're looking for next," which were typical for us, before digging into technical or other questions.

After he had given us that, which ended with a description of his most recent experience as a lead, I asked him, "So, what was the biggest thing you learned in your first experience as a lead?"²

He didn't miss a beat before he replied, "Well, we had one rule on my team, and that was 'No hot chicks.'"³

I think I must have been visibly taken aback, because he struggled on with that but without the immediate confidence that he had started with. It's also possible that he remembered at that point that he was also being interviewed by a woman, because he went on to make some bumbling points about distractions and engineers' needs for focus, and I felt a rising sense of horror. I might have taken it for a poor joke, had he not doubled down with his explanation of how he came by this "rule".

I like to think he knew that the interview was over right then and there. Certainly all the interviewers did, and I'm pretty sure I never asked him another question. The director of programming took over the interview at that point -- the direction for interviewing was to make people feel like they had had a fair shake in their interview, to be good hosts, that sort of thing, as it was a small industry and you wanted your candidates to be able to say to other people who might interview at LucasArts the impression that we were fair but tough interviewers.

But a part of me, ever since, has wished that I had just stood up at that point, said, "Thanks, I think I have all I need," and left the room. I'm in a point in my career now where I feel more confident in my own choices than I did then, and willing to trust my instincts when faced with situations that are outside normal operating parameters laid down by policy. Being clear with how I feel about a response like that is how I would handle it if the same situation were to arise today.

We got through the rest of the interview; I think the technical interviewers came in next, I might have been part of the wave of "personality fit" interviewers and clearly we had established what we needed to. The director of programming gave an embarrassed chuckle to my female colleague and I and said, "I guess we know all we need to, and we'll get him out of here after that interview. Sorry about that."

I'd love to believe we don't have that sort of blatant sexism today; but I bet at that time there were teams or interviewers who would have chuckled along with the guy and said, "Man, I know it, you are so right." I'd love to, but I don't. I think he probably found a home somewhere else, and there are probably others like him. I'd love to think we're over that, and it's not a problem where I work... but I know it's out there. Knowing that it's out there is my #1ReasonWhy.

¹Or at least, I'm somewhat suspicious of my memories. We interviewed a lot of people those days -- LucasArts was attempting to grow rapidly while losing people to the dot com boom. We also still had a really great reputation.
²This is still a softball question, to some degree. What I usually look for here is specifics -- "I had this situation three weeks ago where this interpersonal thing happened and I resolved it in this way" -- but it's still fairly gentle, and usually just the sort of question that might give an interviewer more to draw out of the interviewee.
³This is a direct quote. I might forget any other number of things in that interview, detail-wise, but that one is completely pristine. It burned right into my brain, and not in a comfortable way.

Posted by Brett Douville at 08:11 AM | Comments (0)

November 06, 2010

Learning how better to lead at the IGDA LF

For the last three years I have had the pleasure of attending the IGDA Leadership Forum in San Francisco¹. It's a small and focused conference, which I think benefits it greatly - it presents three tracks of management talks and a small handful of keynote addresses. It's the sort of conference that I'd really like to see more companies sending their managers to, since on the one hand, in my experience game developers underinvest in the professional development and growth of their leaders, and on the other because I feel like the more perspectives we get on leadership, the more I'll personally be able to take away from the conference.

It's a terrific forum for developing your management skills, and I had useful, immediately applicable takeaways from every session I attended. Where else can you get:

  • Intel Engineering Manager Scott Crabtree distilling down more than eight books of information and giving out a citrus-scented handout with the critical information from his talk. This year, he addressed recent science in neuropsychology which helps to explain where we get our peak performance and how best to motivate the human animal.
  • PopCap Games Founder John Vechey describing the challenges his company has had in it's ten years and how they have continually surmounted them.
  • WB Games VP and General Manager Laura Fryer (formerly of Microsoft) discussing her approach to managing a cluster of studios in Seattle for success.
  • EVP for Core Games at THQ Danny Bilson on transforming the THQ business to a creative, IP-driven model rather than a stultifying, marketing and focus-driven one.
  • Realtime Worlds manager Joshua Harris on the use of models to pick leadership strategy. (You mean, we can use more than one? At the same time? With the same person at different points of a project?)
  • Riot Games (League of Legends) co-founder and president Marc Merrill discussing how they've engineered their culture to create awesome (awesome games, awesome service, awesome... profit?)
  • Kim Pallister on "intrapreneurship", Alex St John on the social space, Lucien Parsons on top causes for corporate failure (traps to avoid and how to avoid them), and more?

I subject to you that the answer is: nowhere. These are just the talks *I* attended, not even all of them, and it doesn't even speak to the benefit of having an opportunity to speak with managers and leaders like yourself. This conference is terrific - I can't wait to get back to work so I can get better at what I do.

If you're a manager in the games industry, or you have managers reporting to you, you owe it to yourself to come out or send them to the IGDA Leadership Forum next year. Your competitors are out here trying to figure out how to get better at capturing the lightning and putting it in a package to ship out to customers. We desperately need better trained leaders in the industry, and this is a proven place where they can come and improve their skills. This year I found an insight in every talk to make me better at my job, and to help my reports become better at their jobs. I really don't feel like I can afford *not* to go. Can you?

Note: I'm posting this from my iPad, so I'll come back once I'm at a PC to hook up some links from the above.
¹Last year I also had the opportunity to give a talk at the conference, which was really a terrific experience and, owning to my feelings about public speaking, somewhat terrifying. But it was a worthwhile experience for me, one that I would encourage other leaders to try some time.

Posted by Brett Douville at 03:23 PM | Comments (0)