Alright, real talk. Today’s post is inspired by a question asked in the forums, paraphrased:

“With early access titles you find a lot of people complaining that features are being added while bugs aren’t being addressed and I’d love to see what Gaslamp Games could say about this.”

This question makes me reflect back on myself 15 years ago, when I was an enthusiastic fan of games eagerly watching their development from the outside, being frustrated by waiting for patches, and, I’ll admit, not being very understanding at all about bugs and venting anger at developers. Now I’m here on the other side and I can see why things happen the way they do, I recall specifically saying, after launching Dungeons of Dredmor, “I understand now why things end up the way they do”.

Vaguely related example: Yesterday I argued myself into conceding that the most important thing I could do was another mockup for the character info UI widget.

(I was originally going to use the framing conceit of Dominions 4 game mechanics to explain the functioning of a small game studio, but Daniel helped me see that this will not necessarily make the process easier. And that Dominions 4’s game mechanics being comparable in complexity to running a small game studio says more about Dominions 4 than it does explain anything useful to gamers. So let’s not do that. Also rejected the “Eastern Front of World War 2” analogy as potentially a bit grim. Moving right along.)

Game development is a problem of satisfying a bunch of competing interests while trying to align a bunch of contingent sub-projects. Let me dig into an example loosely inspired by reality.

Say we’re making Clockwork Empires. An important feature of the game is the machine modules — the ovens, workbenches, beds, and other doodads in buildings that characters intaract with. “Just putting them in the game” is an action that holds a lot of requirements, especially considering we’re using a custom engine that requires an entire custom toolchain to implement assets. The question of creating and debugging the tools themselves aside, to create something like a table requires Sean to use Maya for modeling, 3D Coat and Photoshop for texturing, our custom importer (called “importer”) to create a packaged file with the appropriate render flags and animation associations (if any). Then he needs to edit an xml file that defines what modules exist and which buildings can build them. At this point he can put them in buildings, in game, and see how they look. (Though they still don’t do anything in the game, that’s a whole other mess).

Just the icon I happened to draw yesterday between scheduling the art team and scripting emotions.

And that’s the simple version of explaining the toolchain. I’m repeating the details because there was a ton of work that went into setting any of this up at all that took a frightful amount of development time (and I’m sure anyone with software development experience knows the perils of setting up a working toolchain, then making sure it keeps working as additional features are added).

So say we don’t have this whole toolchain and game feature working. We can still get work done making stuff, we just can’t test it. We can still have Sean working, making a ton of assets to go in when it does work. Meanwhile Chris can be taking Sean’s work and animating them (which has a similar toolchain) and adding particles (also a shorter but related toolchain). But without being able to test them in the engine, we create a risky and potentially expensive situation because those assets could require revision according to some problem we wouldn’t see until we implemented them. Say the particle placers were missing an essential component that meant that, even though they looked correct in the particle editor, they don’t work at all in the game. Then Chris would have to redo all of his work and re-export all the animations. Say we put two machine modules together that Sean made 3 months ago and the scale is totally wrong – now we’ve got a problem multiplied by the number of assets we thought we had completed already. That’s frustrating and costs time, both for Nicholas to circle back around and fix whatever went wrong, and for the artists to redo their work.

At every moment in game development, we’re juggling both the tools to make the game and the game software itself. Changing or adding anything can cause another part to break, and this might cause someone to not be able to do work or may cause them to have to redo work.

All that mess of interwoven requirements that can make each other explode? That’s just the artist toolchain, and we’re not even a live game yet. So let’s talk about bugs the player sees.

We’ve all played games, we’ve all seen bugs. Not all bugs are created equal. Some bugs totally stop the game experience for just some people. Some bugs are visually annoying for everyone. Who do you make happy first, a few people who can’t play at all or everyone who is just slightly annoyed? What is the cost of prioritizing one over the other? (The answer is not “stay up all night every night and fix everything” because that doesn’t work either: productivity will drop precipitously after doing that, like, for one day and then we end up outputting less bugfixes. And there are always more bugs being discovered … especially if anyone is crazy enough to add a new feature to the game.)

Let’s make it more complex. Who do we make happy here, what are our conflicting interests, what are the parties involved? Bullet point time:

• Customers: That’s you. Ideally. Gamers who pay money want a game that works, bugs fixed, looks great, and ideally some expansion packs in the future. Gamers also want the game as soon as possible because waiting sucks (and true, it does!).
• Gaslamp Games: That’s us! We need to make money. If costs exceed income, then we’re out of our jobs. We don’t want that to happen.
• Press: If no one hears about our game, then we don’t sell our game. If we don’t sell our game, then we don’t make money and can’t make games anymore. Customers lose, Gaslamp loses. We have to keep the people who write and talk about games (and their readers/listeners) happy, which means answering their questions, doing interviews, assembling press material, sending out press builds that aren’t super ugly.
• Marketing/Promo: Like Press, but it’s what we do. We need promotional trailers, cool logos, screenshots, a neat-o webpage, a mailing list, and a regular development blog to promote our game. These requirements do not directly contribute to the game and are often more visually-focused.
• Investors: Happily, we don’t really have these (unless you count the Gaslamp founding partners, and, I suppose, Canada in a sense). If we had investors meddling in our creative control, to say nothing of finances and release schedule, we could be forced to release a game we weren’t happy with too early. That’d make us very upset, and that’s why we maintain control of our own affairs. Plus, we can say stupid stuff on the blog and get away with it. Still, we need to make money by shipping a product.
• Distributors: You know, like Valve or whatever through stuff like Steam. They have their own set of marketing materials required as well as a toolchain (yay, toolchains!) for uploading builds and patches, plus feature integration like the Steam overlay, achievements, & etc.
• Probably Other Random Things I’m Not Thinking Of: like what if our accountant retires or if the power goes out in half the office or the bank loses someone’s paycheque, these things have to be taken care of if anything else is to get done.

One has to consider who to make happy first at what time, and what the cost is of putting off making someone happy while considering everything else that needs doing. Some of the above parties have set schedules that must be considered: print magazines must have their content like a month before the material is actually “on the new stand” (speaking of, I hear PC Gamer has a cool story about us this month and we’re waiting patiently for our copy to show up in the mail!).

A tester sent us this last week. Hopefully you can better appreciate the depths of our suffering upon seeing stuff like this. (Easy fix, actually; wrong rig on the clothed fishperson.)

What if we hire someone? They need to be brought up to speed on how everything works, have questions answered, learn how to use the tools and, god forbid, read documentation that hopefully someone wrote. What do we have any particular person doing?- should I be scripting fixes into the character emoting, doing concept art for game assets, reviewing work done by the art team, scheduling the art team, talking to our sound artist about upcoming milestones, doing UI mockups, washing the dishes, answering fan questions on a message board, or writing the weekly blog post?

Development is a huge, extremely complex problem that involves a ton of conflicting interests and unknown factors, not just internally and technical (how long does it take to fix a bug that might just be a typo or might be the fault of a totally botched game or technical system that would require a redesign involving input from all the parties involved), but also externally and involving human perception (how will the fans/press/youtube personalities/hardcore players/casual players/paying customers/potential customers/distributors/frenemies/Government of Canada react to whatever it is we’ve just done?).

It’s not easy, the challenges are many and absurdly varied, but of course we wouldn’t be doing this if we didn’t find it somehow ultimately rewarding. And hopefully that gives you a bit of insight into the sorts of concerns we have to balance in this work we do.

And I didn’t even use any Dominions 4 analogies!

…

Last minute addition: Daniel has pointed out that I never really answered the original question. Let’s review:

“With early access titles you find a lot of people complaining that features are being added while bugs aren’t being addressed and I’d love to see what Gaslamp Games could say about this.”

Sometimes a bug is a quick fix. Sometimes it’s the tip of a horrible ententacled iceberg of malevolent jankery that’s burrowed deep through your codebase and ripping it out will require an equivalent effort of re-implementing a major feature because that’s exactly what you’re actually doing. Unless you make a dirty hack to fix it – and make 5% of your user’s video cards explode. Meanwhile, you’ve promised to deliver spinning cogbears in next weeks update. Is breaking the promise of spinning cogbears worth fixing the bug? It might be. It might not be. Sometimes you can’t even know the answer until you (Nicholas) are (is) halfway buried in the Internet Hate Machine and the guts of the renderer while the art team is breathing down your neck about how your fix broke their particle editor and all Chris can do now is wash dishes and reset the Days Since The Last Musical Number tally. Or maybe the only person who can fix the pathfinding enthreshulator (Micah) came down with a bad case of Ghost Neck and can’t fix it until next week due to horrific excruciation, in which case the collective we can’t do anything about anything anyway but make lame excuses. That’s just a few hypothetical examples of bugs may persist while totally random features are completed.

Game development!