“War” by Paolo Bunovino from the soundtrack “I Medici” 🎵
This weekend I combed through unpublished writing because I was limited in time. In 2020, I had pondered that decoupled microservices and distributed systems are patterns that should live outside of infrastructure because they are byproducts of agile not only byproducts of reliability and reducing failure. They were patterns that should also live in game design teams, or perhaps, already were.
There is value to understanding trends though we all have our own way to measure trends. Documentation? It spent a while bifurcated in games – engineering has their way(s) of doing it; design (art and systems) has a completely other way. But perhaps – those worlds are merging. They’ll perhaps be impacted by LLM too.
Some of the way I had produced documentation at Thrust ’12-’14 was done as decoupled documentation and some was intentionally “waterfall” to close a deliverable. In 2012 there was still in large part this concept of the “game design bible” which teams tried, painfully, to develop software around. Between 2010 – 2020, even when game designers were picking up programming skills and systems design roles were growing into more subject matter focused roles (Economy designers, Product, Systems Designers) and the cloud took off, the idea that everything would be designed up front, approved, and then executed was still being taught.
There was a post I kept in draft for 3+ years on Medium and never published – I was so unsure who else was seeing it. Was worried – would I look ahead? Behind? That post was a recommendation to publicly move on from the monolithic game design doc in the age of agile inspired by the style of Programming Sucks. Mostly, I believed, at that point the industry already had moved on but for some reason incoming talent did not know we had. Now? I think we’re seeing something really interesting in how we talk about the work that we do – across engineering, across design, across art and our teams.
Here’s that post from 2020.
Monolithic Game Design Docs Suck
“Programming Sucks” But for Game Designers
Let’s get rid of the GDD (game design doc) that serves all purposes. We’re secretly hoping all game studios have moved on, but aren’t really sure. These ancient texts are sometimes still taught to talent. Yikes.
Developing with a novella as the primary resource is like trying to put out a fire with a vacuum cleaner. It’s not the most efficient way to do it, but it is interesting to everyone on Reddit.
I once read a Puzzle Design Doc from 1996 that was later retracted from public view because the very famous game designer may not have actually had the legal bounds to release it. My take away? It was 72 pages.
PLEASE DON’T MAKE ME USE THAT TO DEVELOP SOFTWARE. 🙂
*Tocktocktock* “Do you have five minutes?” direct message in Slack on Monday morning. <insert name of an unlucky producer who replied> is expected to internally Google the mental backlog of the design team and remember the rules for a feature. Some passive-aggressive replies in the form of “Did you read the documentation?” are sent, but it doesn’t matter.
Jira ticket descriptions are getting outdated. There is already a disconnect between the team and the documentation.
We know the dangers of interrupting programmers — the same is true for everyone.
It is everyone’s job to be on top of past, present, and future and yet simultaneously not everyone’s job. Often leaders need to communicate to team members differently depending on their roles. The idea that one book is going to work for all people, who may not even be in the same building was likely challenging in 1996, but now with independent contractors, remote teams, purpose-built verticals, and utter chaos all the time, some are still teaching the LEGO Star Wars Millennium Falcon 7,541 piece manual of software development as if that is the tried and true source of documentation used in design — and if we are really unlucky sometimes it doesn’t even have pictures. Entire sections can conflict if not double-checked and updated. If this was a piece of software and not a document, we would call this a monolithic application.
“That gun is supposed to have an expected delay of .22 seconds between bullets and an ammo limit of 10” says server-side dev, Mike, who called an impromptu video chat after spending a day debugging that the delays he was experiencing had absolutely nothing to do with latency, but instead, values in a database.
“No it’s not. Didn’t you read the GDD?” said Brian. Brian is trying to look good because he wants his fix in and he really likes the way his settings feel. He’s like 50% sure it’s what was in the GDD even though if this hits Alpha, absolutely no players will survive his changes. He knows the producer dropped off so he’s just going to update the database (by modifying it directly) and document his change as part of a sort-of-related (but not really) pull request instead of bothering to verify because we’ll “balance it before the demo right?” Also, the likelihood the granularity of this was even in a GDD is questionable. It’s quite possible Brian just made up his settings.
The two programmers who were just hired, Andrew and Eric, read the GDD a-really long-time-ago, like 3 days ago in development time, while pulling the repo, plus it’s not their job to look it up either, right? Zoe’s taking notes in this meeting.
Zoe’s been on the project the longest and spends the next 5 minutes silently trying to look for an embedded chart in this trainwreck of a document in case she can help, but they’ve moved on and she’s the only one taking notes so she puts it in the background because she’s tired. There isn’t a chart anyway. It’s a placeholder number mentioned in some crossword puzzle of a chapter that even the designer regrets putting there. At this point in development land, actual design has moved from the game design team to the trust and passion of the programming team and this whole game is now being built on faith and assumptions the team is following this doc while not following it what so ever.
Zoe is actually a dedicated UI Programmer and doesn’t own that feature, but she’s the most tenured on the team and occasionally her perspective matters. She gets stuck with everything no one else wants to deal with for some reason including reminding the office manager when there is no toilet paper in the restroom. She also just remembered she needs the hex code values & fonts for the text from the art production team who only want to give her PSDs which makes her job harder, but this company can’t afford a technical artist or developing an art pipeline as it’s too small. It would be so great if art production listed them in a document instead of her having to open up the mock-ups in Photoshop and eye-dropper that text as well as cut out all their assets to be development ready.
She pipes up, “You know what would be great? A matrix.”
“Let’s make a tool!” yells Brian. Brian begins dreaming up an archaic (even in its dream state), unnecessary tool that right now a Google sheet would solve. With this kind of chaos you know this company is not blessed with a team of tools programmers. Somehow though, he makes the time to morph into one.
Meanwhile the producer, who dropped off because she thought it would be safe and that certainly nothing would get past her as she has complete faith and trust in her wonderful team to come to her with problems…moved on. She is listening to the Ori and the Blind forest soundtrack on repeat while she plans a future DLC roadmap. Executive management urgently needs a window into the future because they need it to inform cash flow. She’s on top of that like a hawk.
Brian has gone rogue. Brian is secretly thinking about building an AWS-hosted, weapons management admin even though this is a prototype. The new hires ponder if they should list this job on LinkedIn.
The CTO is unreachable today.
The CTO is currently up to bat versus the CPO by telling the CPO that he needs to instruct his team to cut 10 features in order to achieve a fully-playable Gamescom demo that won’t get obliterated by the press because there is no way programming can hit the unrealistic targets dreamed up by design in time. Production has told her this multiple times and she agrees. Also, both need the CFO to approve the hire of 3 other people to make that happen, but they are definitely only going to get…0. A budget review meeting was added to their calendars in the last 30 minutes.
Hopefully someone wrote the question down in stickies and cares to tells production to follow up with the game designers? The actual game design team who was not even mentioned is working on figuring out how to update the GDD to make what production promised marketing come true for that same DLC package anyone player-facing is now roadmapping. They won’t have time to test the values getting pushed to the internal stage environment this evening anyway – they’ll just wait for the next team playtest coming with the next client-build whenever that goes out…even those systems are no longer dependent on each other and this is a database value change.
The design team and management are way ahead of programming and under fire to stay ahead and no one talks to each other. And now it’s Tuesday.
Brian committed his tool that pushes to a database store of all weapons that no one has time to use. He started spending AWS credits after creating his own account with a personal credit card. The tool allows game designers to edit values from within the engine directly, but it’s not linked to the actual infrastructure the game is currently using. It’s basically a loosely business-justified toy someone may use at some point built in 5 hours. If Brian gets hit by the lottery bus this tool is useless. There’s an IT team but they just ensure everyone gets told to update their laptops to the latest OS – there’s no one really centralizing on AWS emails to make sure they get caught and root is a mailing list instead of a random…gmail.
No one is sure or has time to find out because: the build’s not fun either. No developers, only exec management, are playing because of the pressure to keep up with scope creep. Management is disappointed in the latest build and feels like the team is getting nowhere. It’s not entirely the documentation’s fault, but it’s clear that everyone on this team is sticking to this book club method of development because someone got a hold of the 2002 Fallout Bible and then tried to make it work in agile where even one question cannot be answered fast enough to keep up with change.
Pluto was still a planet in the 90s.
While a wordy GDD can be great starting point to get ideas out of a designer’s mind onto paper, it very quickly becomes a burden for everyone else on the team except for producers who can at least, in Jira, link to one document hoping it is maintained (The cake is a lie though: it won’t be maintained).
It is frustrating to manage at scale and over time. Maintaining giant documents is incompatible with release schedules and teams. Start-up founders without games experience think they can get something patentable out of…what are effectively books of ideas that can’t guarantee fun. This is at odds with the concepts of rapid, continuous iteration. Some still reference these medieval torture texts even though all of us have pivoted from waterfall and they no longer represent the workflow of design in relation to CI/CD, decoupling features, seasonal content updates, and DLC.
Designers are worried that if they say a new style of documentation is the right way to do things that it’s then going to be taught to incoming talent for the next 20 years. What if someone finds it on the internet and takes it as canon like the Valve Employee Handbook. Bonus: We absolutely don’t have the same documentation guidelines, terminology, and numerical referencing styles internally across companies for different size games and genres — there isn’t a one size fits all approach that works for a tiny team of 6 people working on hypercasual, mobile games that release in 3–6 month cycles versus a team of 200 working on a AAA console game for 2–3 years. But: If we look at the trends of microservices and decoupling in general software development, then we can begin to understand where game design needs to be.
I think we can agree that developers referencing a 70+ page GDD in a meeting with little to no annotated visuals is impractical and clunky. It doesn’t translate to agile where media must be re-consumed in order to develop it, fast. It’s not playable.
We have extensive development of cloud-enabled file management. Mock-up software. Infrastructure-as-code. Serverless compute and microservices. We have CI/CD pipelines and cloud distributions. Multiple alpha, beta, and production environments running simultaneously with different game settings or builds being tested. We have the ability to do blue/green deployments, server-side driven in-app campaign logic. We have not just highly-localized content, but AI/ML driven recommendations for purchases, and the complete control to have the person sitting next to us have a fundamentally different experience than ourselves all because design and data now inform games in real-time.
Expecting a development team to get on the same page using a single design “bible” is not only slow, but company-killing, in the same way monolithic applications can be. Game designers cannot continue to deliver this way at the current speed of software development.
In re-reading this post from 2020 I realized (1) it’s still not as funny as I would have liked it to be and (2) I didn’t really finish it and (3) documentation as a distributed concept and operating around that has come a long way in 10 years.
I do wonder if design documentation is embracing some of the ways we do documentation in infrastructure and engineering. Through Git, Wikis, and short docs – I believe game teams still struggle to share design docs publicly. My husband has been using Obsidian.md for his DND campaigns for a few months after trying One Note (which had nesting depth) and then Notion (where you have to choose between being a database item or a normal file) which forces you into a structure.
He chose Obsidian because writers can customize the markdown and you own the data and can sync it to Google Drive. He’s a big fan of the linking and I think this fits more in the “micro” and “decoupled” mindset if you will. The front matter is all YAML – apparently it’s taking what makes programmers comfortable and merging it with actual design capabilities. I am pretty excited for what these tools mean for creators because they’ve embraced the problem space – I am looking forward to the divides with which waterfall put game designers, artists, and engineers all into their own buckets (sometimes with leaders who wouldn’t even let those teams talk to each other) get destroyed and with those boundaries disappearing, new kinds of talent, and respect for those blended people, being our future.
Image Credit: NASA/JPL-Caltech/MSSS “Oct 19. 2022 NASA’s Curiosity Mars Rover Reaches Long-Awaited Salty Region.“
