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.
Indie Studios
What Makes This Game Tick?: Prioritizing Development Using Critical Mechanics
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.”
The Fallacy of “Free”
Cost is often a significant factor in project management – which is as it should be. But, much like using weight as your only measure of fitness, monetary cost in and of itself is not sufficient for proper decision making. You also need to consider the less obvious costs (and savings) of your decisions.
The Paradox of Planning
One of my favorite quotes revolves around planning. It came from Helmuth Von Moltke, a 19th century German Field Marshall: “No plan survives first contact with the enemy.”1. The implication here is simple enough: the plan that makes total sense on paper quickly falls apart when confronting the entropy of reality. And yet planning is essential for getting a team moving in the right direction. As Dwight Eisenhower said, “I have found that plans are useless but planning is everything.” And thus we arrive at what I like to call the paradox of planning: planning is the act of creating something that is simultaneously infinitely valuable and completely worthless.
Destruction and Creation: John Boyd’s Analysis and Synthesis Loop
Here’s a question for you: is dog-fighting (the airplane variety, not the literal kind) an art or a science? It’s obviously an art, right? Two pilots, and a wide-open sky – the possibilities for maneuvers and counters are positively endless. Endless, that is, except for this funny thing called “physics”. Far from being limitless, a pilot’s options are severely restricted by his altitude, speed, weapon load, and aerodynamic characteristics. The man the world has to thank for codifying this realization is one of history’s great iconoclasts: United States Air Force pilot John Boyd. But Boyd’s gifts to the universe were not limited to the military, and one of his last major labors before he died was a paper and presentation he called “Analysis and Synthesis” or, alternatively, “Destruction and Creation.”
Guest Post: On The Subject of Trade-Offs
My friends at Black Shell Media were kinda enough to host another of my scribblings, this time on the ever-present and ever-important notion of trade-offs: how to think about them, traps to avoid when dealing with them, and why it’s so important to know yourself when faced with them. Click here to read on: On The Subject of Trade-Offs
Conflict of Interest: The Fancy Mess of Scrum, Part 3
In Part 1 and Part 2 of this series, I talked about the functional issues of scrum. In this post, I want to talk about the larger, economic problem with scrum. Namely, what was once an idea designed to support other industries has become an industry unto itself. And with that comes what economists would call a “conflict of interest.”
A Comprehensive Guide to Indie Game Pre-Launch Campaigns
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?
Bottlenecks and Hindsight: Why Auteurs Make Horrible Economists
This post is about an empirical issue: the economic cost of being an auteur. When I originally posted this entry on Gamasutra back in 2014 it was not without its detractors. David Jaffe even dropped a line on it, saying he thought it was neat, while simultaneously implying that I was full of shit. Nonetheless, in retrospect, I still feel this idea is worth considering in an industry like ours, one that consists of both public personas and massive-team-based endeavors.
The Time Value of Fixes, Or: A Fix in the Hand is Worth Two in the Bush
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.