GDC 2017 was my first GDC ever. So, I figured “Why not be an asshole about it?” and signed up to give two presentations. 6’ish months later I found myself at GDC, sweating bullets and shitting bricks. I should also mention that the longest presentation I’d ever given was about 10 minutes, and had signed up for a total of 90 minutes of speaking time. Anyhoo, both presentations went well and nobody died. And then, a month and half’ish later, my compiled speaker feedback arrived. It was largely positive. But, of course, there were a few people (4 in each session, based on the reviews) who took umbrage with ol’ Justy. And some of the negative comments bothered me. Not because people disagreed with me (that’s to be expected, after all) but because I couldn’t respond. But then I realized that not only could I respond (having a blog and all), there was an opportunity to discuss and engage some dissenting opinions. So, here you go.

Criticism For My First Presentation: Strategic Design, Or: Why Dark Souls Is The Ikea Of Games

I based my first presentation around the post “Strategic Design: Why Dark Souls is the Ikea of Game Development“. If you have read that, then you get the gist of the session. If you haven’t, the talk focused on how to use an understanding of your target audience to focus design and spending decisions, using the famous (in business circles) Competitive Advantage framework proposed by Michael Porter.

View the session recording (requires a GDC account for the time being)

View the annotated slide (publicly accessible)

Critic #1: “Useful presentation, but a bit obvious for experienced game developers. Still, novice developers will definitely find it full of sensible advice and insight into gamedev.”

I take Critic #1’s point, but I think he/she oversimplified my thesis. Absent any other comments of contexts from Critic #1, it seems that he/she was saying that experienced developers are already well aware of the need to make trade-offs and focus designs. Fair enough, but the meat of the session was the framework for making those decisions for maximum effect.

I could be totally off base on this one. Maybe Critic #1 totally followed me and found the application of Porter’s Competitive Advantage framework to be a blinding flash of the obvious. But that doesn’t quite hold water for me either. If that were true, we’d be seeing less homogeneity in design, fewer fast follows, less scope creep. And way fewer shooters. Few businesses in non-gamedev industries properly or consistently apply Porter’s framework, so I have trouble believing that our industry has a lock on in.

Perhaps I’m assigning the crimes an missteps of ineffective publisher marketing departments at the feet of devs, but the standard MO tends to be “Think up a design, attempt to execute, get forced into trade-offs by budget or time constraints, and make the best of it”. What I proposed was a framework we’re we can make those trade-offs proactively rather than reactively.

Critic #2: “Meh.”

Alright there, edge lord.

Criticism For My Second Presentation: Better Development Though Science

I culled my second presentation from various chunks of the “Game Planning With Science!” series. Specifically, parts 1 and 2 (to establish some process flow fundamentals) and the sections dealing with lean production. I leaned heavily on the famous Toyota Production System as a model for eliminating waste in sequential processes.

View the session recording (requires a GDC account for the time being)

View the annotated slide (publicly accessible)

Critic #3: “It’s 2017, and we are still seeing talks about straight lifts of other industries’ process frameworks, it seems.”

Putting the snark aside, I’m not sure if this person got upset because a) he/she’d rather see frameworks unique to games, or b) the notion of needing a framework from another industry is so antiquated/tiresome/regressive as to be ridiculous.

Either way, I don’t understand the gripe. Good ideas (and I’m speaking about the Toyota Production system, not my presentation) are good ideas, regardless of the origin. Proven good ideas, like TPS, even more so. Having completed business school, I can tell you, definitively, that EVERY industry combs every other industry for good ideas. This is why there is a market for Harvard Business Review case studies.

So why should the management of game development be above such exploration? Why would we want to be the one industry that only looks internally for new ideas? Especially when we have such an abysmal aggregate track record for effective management? Absent any other feedback or context from Critic #3, this just seems like a pretentiously silly line of reasoning.

I would also push back against the notion that I proposed a “straight lift” of Toyota’s system. That’s an unfair characterization. I dissected TPS and explained how those activities map or compare to activities that we already use in game development (eg, user stories, automated testing, kanban). Then I explained how we can use those existing activities in concert with an eye to reducing waste.

If Critic #3 took some form of specific umbrage with the applicability of lean production to games, he/she didn’t elucidate. That is a conversation I would be interested to have.

Critic #4*: “The closing caveat of ‘discovery is necessary’ is all well and good, but depending on the project, discovery can account for 20% to 60% of the overall effort. A presentation of methodology that’s frankly hostile to prototyping concepts, should go into further detail on that topic.”

Some context:as part of the session submission process, you get an assigned mentor from the GDC board. As my mentor and I worked through the presentation, it became clear to me that I needed to distinguish between activities that your can systematize (what I called “process”) and those that you can’t effectively systematize because they are unknown (which I called “discovery”).

This line of thinking was the seed for the “Preface to Game Planning With Science”. In a nutshell, the outcome of discovery is hard to predict, because it is highly variant. But, if we can systematize and streamline our processes – the things that we know how to do – we can create more buffer to absorb discovery’s variance.

Now turning to the criticism, I get where this person is coming from with regard to the notion of operation science concepts being “hostile” to prototyping. I heard similar feedback when I was doing trial runs of the presentation ahead of the conference. There’s an inherent tension between systematizing process flows and the persistent need to build out and test gameplay ideas before committing to them. Between the need to eliminate waste and the fact that we will try things that simply won’t work. Between art and science. And that’s a fair criticism or counter-point to make.

Buuuuuuuuut…

However, I would rebut by saying that this argument is throwing the baby out with the bathwater. “Hostile” is a strong word. The notions of taking risks and being disciplined in our actions are not mutually exclusive. A person can both invest in a risky start-up and maintain discipline in her spending habits. There is a world of difference between spending time on a prototype that might not work and being laissez faire in its pursuit, a distinction between risk and waste.

For instance, are you clear on the objective of the prototype? Does the prototype explore a both well-defined AND disprovable hypothesis? Are you investing only the minimum amount of time and energy necessary to verify or disprove that hypothesis? WIll this hypothesis, even if proven true, provide value to the end user? Are you keeping the fast-n-dirty, ad hoc prototyping code quarantined from your production repository?

In other words, even in situations with unknown outcomes, a disciplined, rigorous approach is still applicable. In fact, discipline might be even more vital when lost in those exploratory weeds.

As I mentioned in my closing thoughts during the presentation, the goal of lean production isn’t to curtail experimentation or exploration. The goal is to facilitate MORE of it by eliminating waste: reduce the cycle time of experiments in order to run more of them in a given period.

Now, I would be remiss if I didn’t address a subtext in this comment: the notion that I did not adequately explain the prior four paragraphs in my session. And if not, then that’s on me. But, holy shit balls, I had a lot of ground to cover with this stuff!

---

Further Reading If You Enjoyed This Post

Strategic Design: Why Dark Souls is the Ikea of Game Development

Discovery Versus Process – A Preface to Game Planning With Science!

Lean Development for Games – Game Planning With Science! Part 9

---

Summary

So, there you have it. There are my rebuttals to two reasonable people and two snark barons. Putting the douchiness of some session comments aside, I do think it’s important to welcome and engage dissenting opinions, particularly when those opinions might reflect the feelings of other readers who stumble onto Breaking The Wheel. And formulating my responses to these comments is a useful exercise in clarifying both my own thoughts and how I communicate them.

So, thanks for the fodder you four! Even if you never read this post, you still helped me. Well, except for you, Critic #2. You’re just an asshole.

If You Enjoyed This Post, Please Share It!

*This very well might have been part of Critic #3’s feedback. GDC sends you feedback in one large blob of text, so it’s impossible to separate one note to the next. This comment was decidedly more constructive and snark free, so I read it as a coming from a different person.

“Responses To GDC 2017 Feedback” by Justin Fischer is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.