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 13, 2015

Latest Wednesday Workout Code

Here's the code we'll be starting from today for our Wednesday Workout, where we code a game in an hour or two. Today we're doing Breakout, over on my Twitch stream at 4pm EDT.

After, I'll post it up to my YouTube channel, so go ahead and subscribe to those if you're interested.

Posted by Brett Douville at 03:28 PM

May 07, 2015

Wednesday Workout: Asteroids

Download the final source from the stream here. It depends on the previous 'Common' code.

If you'd like to code along with it, you can get the latest version of the project template I start from here, and you can watch me code it either at my Twitch channel where it'll be archived for a little while, or on my YouTube channel. Sorry, in both cases I forgot to take down my "Will stream at 4pm" sign for a little bit but eventually the chat channel tells me so.

So, obviously, this is not a complete implementation of Asteroids -- here are some things you could do at home to "finish" it. I may get a chance to do a few of these things over the weekend, and if I do, I'll post another batch of code.

  • Tweaking. Most of the constants are just random numbers I came up with on the fly, and so balancing this to be the best Asteroids it can be would be a good place to start.
  • Scoring. I don't remember how scoring worked in Asteroids, but it was probably a per-asteroid increment, with a bigger bonus for killing the UFO, which reminds me:
  • Add the UFO. In the original game, this UFO would appear every so often and fire bullets at the player.
  • Add Hyperspace. Bind it to a key and give it a limited number of uses.
  • Draw a little triangle behind the ship when accelerating. 'Nuff said, should be fairly easy.
  • Particles! I'm pretty sure there should be a little particle effect (just points or small lines) when an asteroid splits up or disappears.
  • Add audio. I probably won't have time to do audio in a meaningful way until I write some boilerplate code to stick in there. So that's a place you might do some useful work. One for bullets, one for asteroids splitting, one for accelerating.
  • Finish off the game. Add an "attract mode" (just asteroids and and "Press Space to Start"), a proper number of lives, a respawn, a restart after you survive, an additional life when you hit a score threshhold, all that stuff.

Those are the things I can think of off the top of my head. Thanks for those who followed along! Be back next week with Breakout or Space Invaders, haven't decided which yet.

Posted by Brett Douville at 12:49 PM | Comments (0)

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)

April 30, 2015

Wednesday Workout: Coding the Classics

So, I've decided to start streaming some game development -- but I'm not yet at a point where I want to show the game I spend most of my time working on. A dilemma!

What I've decided to do instead is once a week, code up an old video game in the space of an hour or two each Wednesday at 4pm Eastern, over at my Twitch channel. There are a couple of reasons:

  • I often tell people who are trying to learn how to code games that I think there's value in simply coding up older, simpler games. But it's hard to know where to start, so why not go ahead and show how.
  • Longer term coding streams don't have a lot of closure; you aren't really putting a bow on the game at any time in the near future. I figure there's some value in something a little shorter term -- like an hour or two. See a game from beginning to end.

I did the first one on Wednesday April 29th (yesterday, as I write this post) and it's archived in two parts on my Twitch channel and also on my YouTube channel. I got really flustered with some non-working code in the middle, paused the stream, and came back.

It is really hard to code and talk and pay attention to chat/answer questions and all of that at the same time. I'll get better. Kudos to Casey Muratori and my friend and former colleague Jean Simonet for doing it on a regular basis. As well as anyone else who does it. Yikes.

Finally, I have a little bit of template code that I use to code this stuff up. You can download it here. Just right-click and "Save as", etc. There are build scripts in there for both OSX and Win64. You'll need to download your own copy of SDL2 and install it on either platform. (I go ahead and just put the DLL inside the Windows "Run" directory on my system, so it gets copied every time I make a new project, but haven't included it in the zip so as not to confuse OSX folks following along.)

Posted by Brett Douville at 01:56 PM | Comments (0)