Effective game planning is one of the hardest aspects of video game management. Every video game is a journey into the unknown to one degree or another. Inaccurate development estimates and forecasts are a major source of cunch. Too often, developers simply do the project management equivalent of eye-balling a cut in carpentry. Rather than providing an estimate based on data, the plans we give to publishers, investors, and backers is a writhing pile of guesstimates.
But what if there was a different way to go about project planning and estimation? Or managing asset creation pipelines? What if we could apply some science to the black art of project planning? We can!
Welcome to “Game Planning With Science!”
The links below will take you to a series of tutorial articles. They feature a mix of operations management, statistics, and just a pinch of management psychology. These articles are not conjecture or intuition. These are scientific principles taught in cutting edge business schools, but placed within the context of video game development.
And don’t forget to check out the Management & Operations Resource Page!
“Game Planning With Science!” Table Of Contents
In order to understand how science can be leveraged in the creative process, it’s important to distinguish the “process” part from the “creative” one. The preface presents a simple concept for understanding this distinction: the discovery versus process framework. By understanding how discovery and process differ, and how they relate, you can identify where a scientific approach to management will be most beneficial. The preface ends with an overview of the remaining posts in “Game Planning With Science!”
The techniques of Operations Science (also called Decision Science) were developed to manage industrial factory processes and global supply chains, but they can also easily be applied to games, both in terms of feature and asset development. You don’t need to be an Amazon or an Apple to benefit from good operations management. Part 1 lays some groundwork by establishing process flow basics: Critical Paths, Bottlenecks, and Little’s Law.
In Part 2, I’ll walk you through how to assemble a capacity chart, and how you can use it to optimize your asset-creation pipelines and add resources where they will do the most good.
In Part 3, I’m stepping away from direct operations management to discuss some basic concepts of statistics. Riveting, I know, but also essential if you want to be able to forecast accurately and confidently. There will be some heavy lifting in this post, but hang in there. A better understanding of statistics will not only change the way you see and treat your own data, it will also make you a more informed consumer of the information the rest of the world vomits at you every day. And of the brazen fast ones people will try to pull on you with bunk interpretations and stylized facts (hello, Congress).
In Part 4, I cover one of the most fascinating aspects of statistics: the Central Limit Theorem. Why does one aspect of statistics deserve its own post? BECAUSE IT’S FRIGGIN’ RAD, THAT’S WHY! Also (and probably more importantly) it allows us to make predictions even if we don’t have a lot of data.
At the end of the Part 4, I acknowledged that it’s no mean feat to track the time per individual feature without some heavy duty project management software and a team that is superlatively disciplined about tracking their time. In Part 5, I’m going to give you my favorite tool for getting around this problem: Story Points
Game Planning With Science! Part 6 is a tutorial for specifying and estimating features with user stories while accounting omitted variable bias and mitigating the impact of social proof and anchoring.
In Part 7, I offer another tutorial. This time, we’ll apply the tools we gained from Parts 1-6 to forecast development over time.
“No plan survives contact with the enemy” as the saying goes. For all of value of using the techniques in “Game Planning With Science!”, following a plan is never as valuable is responding to change. When a plan no longer suites reality, you need to toss it aside and create a new plan. Understand the change, adapt to the change, then overcome the change.
One of the biggest obstacles to effectively forecasting the feature development is the variance we encounter. There’s only so much we can do to curtail the variance of discovery, but we can do a lot to reduce the variance of process. And that’s where lean development comes into play. The same principles that made Toyota the worlds largest car company can help you improve your production practices.
The grooves on HDMI connectors, the 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. And this same approach is applicable to video games. Welcome to the world of poka-yoke.
A traditional factory model is a “push-based” production system. “Upstream” stations (those earlier in the process) push work to the “downstream” stations. The machine that makes cans sends them to the machine that fills them with soup, which in turns sends it to the machine that applies the lid. The alternative to push-based production is “pull-based” production. Simply put, instead of Activity 1 pushing work to Activity 2 as soon as 1 is done, 2 pulls the work from 1 when it’s ready for it. And kanban is the most famous pull-based system.
As a developer, you’re almost perpetually flat to the boards. There is always too much to do, too many fires, too many needed fixes. You can’t create more time in the day, or more days in the week. But you can do the next-best thing: eliminate repetitive tasks using automation. Enter jidoka, which translates as “autonomation”.
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.
A commonly held belief is that it’s best to batch work – to handle similar tasks in large, consolidated chunks. But this particular notion is flat-out wrong. Batching may avoid switching costs, but it greatly protracts flow time, which, in the long run, can end up being far more expensive. Which is why the Toyota Production System introduced the concept of heijunka – “leveling”.
On January 28th, 1986, seven astronauts boarded the Challenger for its tenth launch into space. 73 seconds after lift-off, the Challenger broke apart, killing the entire crew. Why? This is where root cause analysis comes into play, a practice colloquially known as “the five whys”.