In my last post, I talked about critical mechanics and how to use them to prioritize work. In this post I want to talk about an easy way to turn a critical mechanic into a task list using a very simple concept: the use case.
One of the hardest aspects of managing game development is prioritization. And nowhere is prioritization more difficult than in the earliest days of a project. If you don’t know what your game is, how the hell are you supposed to prioritize the work? I’ve struggled with this problem in the past and eventually ended up stealing a solution from the start-up world in the form of something I like to call “critical mechanics.”
Failure is a fact of life. And the more you try to push the boundaries – of your abilities, or your career, or anything else – the higher the probability of failure. There is no inoculation against it. Sooner or later you are going to fall right on your ass. You can’t stop it from happening, but you can control how you respond to it. Here’s my script.
In a day and age where new titles hit the market on a daily basis, being able to stand out from the crowd is super important. In 2016, 4,207 games launched on Steam. Steam doesn’t let you launch games on weekends, so that’s approximately 16 games per day. How do you differentiate yourself from the 15 other games launching at the same time as yours?
On January 28th, 1986, seven astronauts boarded the Challenger for its tenth launch into space. Its previous missions had included the first space walk and, at various times, the first American woman, African-American, Canadian and Dutchman in space. 73 seconds after lift-off, the Challenger broke apart, killing the entire crew. Why? Because the fuel tank exploded. So, the solution, of course, is to send the next shuttle up with a fuel tank that doesn’t explode, right? Only if you assume that the exploding fuel tank was a 100% isolated incident, completely unrelated to any other events. If that sounds fishy to you, it should. And this is where root cause analysis comes into play, a practice colloquially known as “the five whys”.
One of the more interesting characters I’ve encountered in my wanderings through the internet is a man by the name of Jocko Willink. He’s the author of Extreme Ownership and a business consultant. Oh, and an ex-Navy SEAL and a black-belt in jiu-jitsu. So, the man knows a thing or two about getting shit done under arduous circumstances. And his personal mantra is “Discipline equals freedom.” And the more I study operation science and the more I learn about software development, the more I see his point. So, in this post, I’m going to walk you through a multi-step process for testing code and how a little QA discipline can avail a lot of freedom.
You remember that time you plugged your HDMI cable into your PS4 upside-down and fried it’s video card? Or that time you clamped your ski-boots into your skis backwards and almost killed yourself on a black diamond slope as a result? Or that time you put a k-cup into a Keurig machine sideways an sprayed hot coffee all over the kitchen? No, you don’t. Because you can’t do any of those things. Those products are all designed so that they can only be used in the proper manner. The grooves on the HDMI connector, the specific clamps and catches on skis and boots, and the tapered design of Keurig k-cups mean that the proper application of the product is as obvious as its improper use is impossible. Welcome to the world of poka-yoke (poh-kah yo-kay).
The Merriam-Webster dictionary defines power as (among other definitions) “possession of control, authority, or influence over others”. Nothing terribly shocking there. But it’s worth digging into how power induces that influence. There’s the obvious, overt “Do this thing because I said to do the thing.” We’re all familiar with that one. But there’s also a different form of influence that comes not from influencing people, but circumstance. And on any given day, this informal power is far more likely to cause you grief.
The premium game model of development has a general cadence: pre-production, production, alpha, beta, and certification. There are variants of course, but that tends to be the gist of it. Alpha, beta, and cert are, of course, where we divert our attention from making features to the grueling task of fixing bugs. And, dear lord are those weeks painful. One house of cards to the next. But that’s just how it’s done, right? Yes that’s how it’s done. But it’s also incredibly inefficient. This model of delayed quality assurance means we fix bugs when it is maximally expensive to do so: at the end. After they’ve been buried under other bits of code that rely on those bugs being broken in exactly the way they are broken.
If you’re both the entrepreneurial type and the game developer type, then Tom Ketola is your guy. Tom and I were brothers-in-arms at Wideload Games, where we shared a love of profanity, terrible fashion sense, and a complete disregard for status quos. Tom’s career includes stints at Activision, Jaleco, Konami, and Midway. And that’s just his career in the games industry. He’s also been involved in a number of start-ups, and seen the good, the bad, and the ugly of contracts. After reading my post about conversations for studio co-founders, Tom had a, shall we say, voluminous round of comments on the nuances of shares, acceleration, and vesting. Rather than abandoning me to badly interpret his thoughts, he took pity and offered to share his experience with all of you. I leave you in his capable, knowing, manly hands. Enjoy!