A while back, my dad sent me a quote that I immediately stuck on the wall next to my desk. It’s applicable to his long career in geotechnical engineering, but it’s attributed to A. R. Dykes, who was talking about structural engineering:
“Engineering is the art of molding materials we do not wholly understand into shapes we cannot precisely analyze so as to withstand forces we cannot really assess, and done in such a manner that the community at large has no reason to suspect the extent of our ignorance.”
Swap “engineering” for “game development,” and I bet that quote resonates with my industry peers. It’s rare for a game to launch and look much like it did in prototype, or on paper in a design document. (This can be more or less true depending on the project, of course – the yearly iteration of Madden is dealing with a lot fewer unknowns than a risky prototype in an unproven genre.)
Beyond external factors – shifting markets, changing consumer preferences, and hardware improvements – figuring out how to make a game great takes time and iteration, and it’s never predictable how the audience will react.
“Molding Materials We Don’t Understand”
1991 was my last year as a college undergraduate. Still a bit directionless, I was bound for law school the next year, mainly due to the absence of any other obvious career path. I’d loved games since I was a kid, but “game designer” was still a rare and poorly-understood job title, and I didn’t have the programming skills of my more technical friends.
At some point, my roommates and I – gamers and geeks one and all – stumbled on TADS, “the text adventure development system” created by Mike Roberts. TADS is an object-oriented system for creating Infocom-style text adventures. Basic programming knowledge was required, but as I’d grown up a fan of all the old Infocom games, I was motivated enough to dig into it.
A growing understanding of the object-oriented, multiple inheritance structure of a TADS game was eye-opening; those early experiences influenced all my design work since. The breakthrough on the first game I ever created with TADS was realizing an object could be both a “FoodItem” and a “KeyItem” – leading to an edible “Cheez key” created by a goofy corporation that became foundational in the lore of a series of comedic text adventures I’d build through the rest of college and into law school.
Clever designers will spot an immediate problem – a key that was also food could easily lead a player to soft-locking the game. If the player ate the Cheez key, the matching lock could never be opened.
For a small indie text adventure in 1991, this might still be an acceptable outcome for the audience – essentially a comical loss condition. Fortunately, the structure of TADS suggested a more elegant answer.
Much later in the game, the Cheez key unlocked the Cheez door (which in the game’s code was both a FoodItem and a DoorItem!) But if you didn’t have the key anymore, you could just eat the door (albeit with some gruesomely-described side effects and regret.)
I’ve told that story a lot over the years. It’s silly, but it shows how the nature of the toolset used for building a game influences the end result. More recently, I’ve worked on games built with both Unity and Unreal and while there are plenty of common good development practices that apply to both, they’re different enough to change how teams execute on problems.
“Withstanding Forces We Cannot Really Assess”
Fast-forward ten years. With several industry jobs and shipped games under my belt, I joined Ensemble as a relatively seasoned designer in 2001. The studio was coming off a huge success with Age of Kings and was deep in development on Age of Mythology. Age of Mythology and Age of Empires III (alongside a final stint helping ship Halo Wars and a year of work on a couple of unshipped prototypes) would consume my professional energies for the next eight years.
A lot of folks know how the story ends – with the 2009 shutdown of the studio by Microsoft. It was a perplexing decision to many at the time; in terms of sheer revenue and profit generated, it’s hard to call Age of Mythology and Age of Empires III anything other than successes.
But by 2009, markets and consumer preferences had shifted. Traditional real-time strategy games fell out of favor, while the popularity of the Defense of the Ancients mod for Warcraft 3 laid the groundwork for the rise of MOBAs. Ensemble, though profitable, was an expensive studio to run – and despite its development teams clamoring for the chance to do something different, was clearly pigeonholed as “the real-time strategy group.”
Further, the sales data could be viewed in a way that suggested a studio in decline. In part due to the more accessible subject matter of Age of Kings – everyone likes horses and castles and knights – neither Age of Mythology nor Age of Empires III sold as many units as Ensemble’s crowning jewel.
Genres fall in and out of favor all the time. Real-time strategy games have made various comebacks in the years since. The success of They Are Billions and the recent releases of Company of Heroes 3 and Age of Empires IV suggest there’s still a fair bit of life in the genre. Even today, in mid-2023, the remastered version of Age of Kings is hitting over 20,000 daily peak users on Steam.
But in 2009, for Microsoft executives looking to make hard budget cuts, the decision to shutter Ensemble was not without its cold logic. And internally, where the team was very confident about the designs and mechanics of the games we were building, constantly measuring subsequent successes against the Age of Kings yardstick added a layer of doubt and angst to the process.
When a team is heads-down working on a game, it’s hard to take into account what market forces or shifting consumer preferences are going to do to their plans. Much like when a building engineered to withstand category 4 hurricanes is slammed by its first category 5, sometimes a great game – or a great team – can get smashed by forces entirely beyond their control.
“Done in Such a Manner that the Community…Has No Reason to Suspect the Extent of Our Ignorance”
The Cheez key anecdote is an illustration of how a toolset can influence games made with it, but it’s also instructive as an example of how random good game ideas can be. On large projects where there’s more upfront planning and design – or by-the-numbers sequels – there are fewer accidental choices. But I’ve never seen a project where the team does not make adjustments and changes to the original design before it ships.
Ensemble designers had a running joke about the Norse ox cart in Age of Mythology; the gist was that every designer liked to take credit for the idea. Whenever any idea got positive feedback, someone would say “yep, I thought of that when I thought up the ox cart.” (I think the actual idea was originally Greg Street’s, but don’t quote me on that.)
The ox cart was a mobile drop-off site for resources – a great differentiator for the Norse civilizations, thematically appropriate, and smart mechanically. It’s also one of those ideas that, while very sound on paper, required a ton of iteration to balance properly.
How much should an ox cart cost? How does being able to move a drop-off site upend the core game’s carefully-tuned random maps, which rely on placing resources at reasonably equal distances from all players? How fragile should the ox cart be when it’s attacked?
Someone who’s never built a game might expect that the original design document had all those answers laid out – charts of exact numbers and distances and rates. And yes, a good design spec might have a cut of that stuff as a starting point. But an experienced team thinking about the ramifications of the ox cart is going to know just how much those numbers will change over the course of development.
An open secret about game development is that most of the time, the team doesn’t know how it’s going to turn out. Oh sure, they’ll get more confident the closer they get to a finished product. On a big game with a multi-year development cycle, the last six to twelve months don’t have a lot of unanswered design questions; by then, it’s just knocking out remaining tasks until you get to the finish line. (If there are still a lot of unanswered design questions at that point, that’s a whole separate problem.)
But even the most organized and well-planned game project is part science and part art. Teams need space and time to come up with ideas like the ox cart and then to do the hard work of taking those ideas and iterating until they’re great.
Compared to the similarly creative but time-tested process of making a movie, game development is a unique challenge every time, especially with increasingly rapid changes in the market. With the number of new games released on Steam and other platforms every week, consumers have a ridiculous number of choices for how to spend their gaming dollars.
Making a game can be a scary ride. It’s as if developers are structural engineers building things on the sides of crumbling cliffs in an age of increasingly common disasters and shifting climates. As a developer, you often feel like you’re fumbling toward something fun, but can’t quite grasp it until all the pieces come together.
That’s why I’m always in awe of folks that ship anything, even less successful titles. It’s hard to get a coherent game across the finish line – harder, and more random, than the audience understands when they get their hands on the final product.
Regular blogs appear every Tuesday. Join the discussion in the comments! We’re also now on Threads – follow us at https://www.threads.net/@screegames.