God Bless Mark Cerny

For someone whose name commands attention to speak up in favor of learning our craft and becoming more efficient -- God bless Mark Cerny.

I can halfway understand spending tens of millions of dollars on development of a game that will generate $1 billion in sales. On paper, the ROI is clearly amazing. But it's still the case that those tens of millions are being spent unwisely in so many ways.

There are organizations that are bogged down with middle management such that true development is slowed by the cooks/kitchen ratio. There are studios where experienced developers could be making great games twice as fast but they're held back by publisher-side decisions that stunt or even reverse the progress of iterative creativity. And then there's the rampant inability to mesh wise business decisions with the reality of the R&D nature of making something fun.

It's not as though the industry faces a dearth of examples to learn from. We just seem to have a top-down unwillingness to learn from them.

IGDA Wisconsin Chapter Meeting 2/3/2011

This meeting was held the day after an enormous blizzard so attendance was a fraction of November's meeting. The hardy souls that did make it out were treated to an excellent presentation from Jason Compton comparing several aspects of TV game shows with video games. He made a number of intriguing comparisons such as how a seemingly tangential feature can sometimes have significant impact on the enjoyment of the game/show. He also noted several good examples of how an attempt to modernize or improve a show can actively detract from the enjoyment thereof, not unlike with video games. The only way Jason could have improved the presentation was by including the infamous William-Shatner-completely-loses-his-cool-and-throws-furniture clip from $20,000 Pyramid. Jason excluded it from his deck due to the poor quality of the video, but I have no such compunctions.


Aside from Jason's talk, we also had some discussion on the importance of tax credits for game developers in Wisconsin. It's a topic that has come up in the past, especially in light of the tax credits provided for film producers in the state. Making Wisconsin more attractive to game development studios and other areas of technical innovation is clearly of great importance, not just to a state that has been heavily invested in manufacturing but more specifically to the wide array of students participating in the various games-related fields of study throughout Wisconsin's schools. As an IGDA chapter I hope we're able to further our involvement in this issue.


As per usual, the meeting adjourned to Friday's for rampant socializing and exorbitantly overpriced burgers. In and amongst other discussions I was pleased to meet (hope I get the names right) Matt, Phil, Cat, and Patrick, a group of indie-devs-with-day-jobs who drove down nearly from Green Bay. That's quite a haul, you guys. I'm glad you made it.


And a quick shout out to my homies at Raven -- Andre Dusette*, Eric McDaniel, Brian White, and Nathan Rausch. Good to see you guys, as always.


*word to the wise: Don't play this guy in Cutthroat Caverns. He cheats. Not as much as Vondrak, but it's still pretty egregious.

A Few Different Ways To Look At Feedback Loops In Game Production

In my final year of my Computer Science degree I interned at Johnson Controls in Milwaukee, a company that deals in HVAC (i.e. heating and air conditioning) for large buildings. During my time there I learned about feedback loops. Here's the simplest possible diagram:

You've got some process that's running -- input coming from the left, output going to the right. But the final output of the system is branched off into a feedback loop that educates the system and alters the next cycle of output. An example would be your thermostat. You set it at 70degrees -- a setting called, oddly enough, the "setpoint" in HVAC parlance -- and the furnace blows hot air to bring up the temperature. In your house you've probably got a single sensor mounted in the thermostat that reads the ambient temp and informs the system that it's now hotter than 70 so it can turn off the furnace. The thermostat is the process, the sensor provides feedback, the furnace air is the output -- altered in accordance with the feedback and the desired setpoint.

Let's look at another example, this one from Scrum. In simplest terms:

Running a sprint for X weeks, the team's production is the process -- everyone's making textures, anims, code, etc. The current version of the game is the output. Your review at the end of the sprint provides feedback in accordance with the setpoint, which is set at Fun degrees. I could talk quite a bit on this loop since it's where I do a lot of my specialization, but let's move on to:

Here we step back from the work, and observe the game's start-to-finish creation as a process. Game idea is the input, shipped title is the output. The setpoint is probably still Fun degrees. But what result is generated from the feedback? In years past, the only answer was "a sequel" but these days you have other options such as  DLC and updates to live games (e.g. WOW, League of Legends, etc). This feedback loop is where a lot of the luminaries in our industry like to operate -- the realm of game design. If you know the name of a developer who doesn't work at your company, he or she is probably a game designer. Think Will Wright, Sid Meier, and the like. To be honest, this is my least favorite arena in which to operate. Let's move on to my final loop, the one on which I prefer to focus my efforts:

Here, the process is the continuing operation of your studio. How you do what you do. There are projects being shipped throughout this process, people being hired, fired, and laid off...that's the process. The setpoint is -- let's be honest -- money. If you're lucky, maybe you work at a studio that has a publicized mission statement aligned with great goals and a fun culture, but that's a wrapper around the real setpoint. Or perhaps, the $etpoint. As passionate developers, though, we prefer not to get hung up on that notion ("No way, you cynic! My studio is all about making fun games!" Of course it is. That's how you pay your rent, right? You hand the landlord a fun game?) so I'll bypass that topic and go on to the feedback portion of this loop.

When does your studio collect feedback about its process?
What does it do with the feedback? Does the feedback result in change?
Is there good logic at work to determine if those changes bring you closer to your $etpoint?

Want some answers? I know I do. Tweet 'em if you got 'em. @someproducer on Twitter

Starting Off The New Year -- At The Desk of FGP*

Having returned from Christmas holidays with my sister and her family, I've reassembled my work area (my laptop is also my desktop, workstation, fileserver, mainframe, and WOPR) and poured my first cup of coffee. Today I want to contact the good folks at Gamasutra about getting added to their Contractors page. Then I'm going to check in with some ex-coworkers and see how everyone's faring. Following that I'll send out my Production Study questions to some producer friends for their input (curious about the Study? send me a tweet or email -- I'd love for you to be involved!). If there's time left in the day I'm going to look into setting up Crashplan, Carbonite, Keepass (an unfortunate name, if you ask me), and Quickbooks Online. Please do send me any opinions you have about any or all of these software packages.

Gotta go. Coffee's getting cold.

*considering how many times it comes up, it takes far too long to type Fuller Game Production

Fuller Game Production

After leaving Raven earlier this year I took stock of my position in the industry. With 13 years of development experience and more than a dozen AAA products to my credit I knew I could add value to any number of organizations. But I wanted more than to be tied to one project at one studio for years at a time.

My greatest fulfillment as a developer has come from helping teams succeed. Maybe that sounds trite, but it's absolutely the truth -- I genuinely enjoy helping others. After much deliberation I came to the conclusion that the best way I could help the most developers was to go into independent consulting as a producer-for-hire, improving processes and filling in the production gaps for studios of any size, in any location.

I don't just want my current project to be well-managed. I want everyone to create a fun game that comes out on time, without overtime.
And with that end in mind, I present to you: Fuller Game Production

 Creating a video game is hard. I can make it easier.

When You Get A Chance, Recognize Excellent Service

I had a surprisingly good piece of customer service from a gate agent at SFO a few weeks ago. My flight was canceled and this agent worked with a few other folks to reroute dozens of severely irritated passengers. This gentleman in particular hustled his butt off and remained calm, professional, and courteous to the very last passenger.

So I told the agent's manager and sent an email to delta.com support. Apparently, it resulted in some sort of recognition for the chap. I couldn't be happier. People in service industries frequently get pooped on and, I suspect, rarely receive appreciation.

Here's the message for you, gentle reader...
Try to notice when someone does an excellent job on your behalf...and show some recognition. Chances are, they don't get nearly enough.

And CS... keep 'em flying.



---------- Forwarded message ----------

From: S*****, C*****
Date: Thu, Dec 2, 2010 at 1:20 PM
Subject: It's Appreciated! Delta Airlines observation November 6th, 2010
To: "keithfuller01@gmail.com" keithfuller01@gmail.com

Good afternoon Mr.. Fuller. I wanted to take a moment to personally thank you for personally giving the great feedback on the day I met you to my supervisor Gary and you went above and beyond and sent a personal email. I want you to know that it did not go unnoticed and I indeed got rewarded for it.

Whenever I receive positive feedback it's best appreciated when it's unsolicited ;-). It makes me feel that a "guest" really took the time to personalize it.

I hope that your holiday season is going great and I wanted to THANK YOU for acknowledging me. Enjoy the rest of your week!


C***** S*****
Delta Airlines
San Francisco
Gate/Ticket Agent

3 Things to Know About Smaller User Stories

Yesterday I attended a webinar by Mark Levison (graciously hosted by Donna Reed) about slicing user stories -- why to make them smaller, how to make them smaller, how small to make them, etc. Here are some of the points I took away.

Why Make Stories Smaller?

It's easier to estimate the work involved and easier to grasp the details. Further, when (possibly if, but probably when) you get partway through and start to realize how far off your original estimate was, you haven't spent as much time working on something that your product owner will pull the plug on after discovering how long it will take.

How Do You Make Them Smaller?

Mark had an entire page of possibilities so I won't get into enumerating them, but one of the driving thoughts here in breaking down the story size is that -- once decomposed -- you want to still be tackling a story that adds value to the project. You can find any number of ways to reduce story size, but make sure the resulting stories each add value.

How Small Do You Make Them?

The guideline Mark gives a team just starting off with Agile is to make sure stories are big enough that they take a couple of people a couple of days. If it's smaller than that it's really a task, not a story. (As an aside, he also pointed out that there's nothing carved in stone anywhere that says you have to use tasks when running an Agile project -- maybe that's something to bring up with your team.) So keep the story/task distinction in mind and don't break down anything too much.

My Thoughts

My assessment of Mark's webinar is that he gave a great, in-depth discussion on story size. It was accessible to beginners, but he answered some write-in questions that were more advanced in nature. Mark clearly has real-world experience in this realm and does a good job of clarifying the material. The idea of decomposing stories into reasonable size is applicable for game development, to be sure, so although Mr. Levison's talk was geared toward "standard" project development I'd still recommend this content for developers in the games industry.