We Should Patch Our Games

I’ve been hearing more and more voices crying out against patching recently, and I wanted to unpack some of what people have said. I think this is one of the many designer-to-player communication issues that crops up in the games conversation, and so here is a designer trying to improve on(“patch”) that aspect, so that hopefully we can have better conversations in the future.

I should make clear that I am talking only about patches to a game’s rules in this article. Probably few, if any, people would complain about the fact that some game-breaking bug was fixed in a patch. The interesting question is with regards to things like patching game balance, adding or removing features, and so on.

Firstly, I do understand the costs that patching a game has. It’s frustrating to have to learn new rules and incorporate them into your strategies. It’s annoying to have mastery be a moving target. Sometimes, in the case of physical games, a patch comes with a monetary cost and wastes materials. I agree with all of these concerns, and I have other concerns too which I’ll delve into in this article.

But despite those costs, it is absolutely in players’ best interest for developers to patch their games as much as is necessary. While frequent or large-scale patches to a beloved game can certainly be annoying, it beats the alternative.

 

What Is Patching?

In games, “patching” is simply the process of improving on an existing design. It is indistinguishable from all of the hundreds or thousands of “patches” built before a game’s release. Once people get a hold of the game, however, changes are then considered to be “patches”, because from a player’s perspective, something external is coming in to their game and “patching” it.

What many players don’t understand is that a game’s “release” is triggered at a somewhat arbitrary point. Let’s describe the phase “the game is finished” to mean “the developer ceases working on the project believing that it is just about as good as they can make it“. Let us also assume that we, as game designers, want to make the best games we possibly can.

Then again, we are also operating in a world of real life constraints. Because of those constraints, we have only two options for producing the best game we possibly can:

  1. Totally-Finished-NoPatch: Produce the game internally and continually iterate until the point where The Game is Finished, and then release the game. This is likely to take well over five years, potentially even a decade or longer. Most developers do not have the resources to operate that way, and further, you will likely be reaching a smaller audience who could otherwise be giving you feedback on your game.
  2. Somewhat-Finished-Patch: Develop internally until the game is “solid” after a reasonable amount of development time, and then patch the game post-release. This is what most developers already do. We get a game up to a point where it is definitely delivering a good amount of its potential value to customers, and certainly worth buying, but far from where it needs to end up.

Quality-minded developers, such as Riot, Valve, Blizzard, Sirlin Games, and I’m happy to say, Dinofarm Games, take option #2. Very few developers have the capability or desire to do option #1 (the only studio I know of that might qualify for this would be Jonathan Blow’s studio in working on The Witness).

However, there is a third way that is often confused with option #1.

 

“We’re Paying You To Beta Test Your Game!”

Here is a third option that developers could take, if #1 is impossible and #2 seems problematic to you:

3. Somewhat-Finished-NoPatch: Develop internally until the game is “solid” after a reasonable amount of development time, and then never patch the game again.

I’m sure you’ve probably heard the argument before that says that developers are using us players as free QA departments to test their “unfinished game”. This argument is totally flawed because it fails to understand the actual constraints of game development.

You getting a “totally finished game” on release day was never, ever an option, because almost no (arguably zero) studios have the resources to do that. The only thing that anyone ever released was a “mostly finished thing that we will patch up and make finished” or “a mostly finished thing that will stay as it is forever.”

If what you want is developers to use option #3, then you’re in luck, because that’s exactly what 99% of most developers already do! Most developers launch their game and just never patch it, with a possible exception of when an OS update breaks their game (and sometimes, not even then).

Would anyone really prefer to have a bunch of somewhat finished games floating around? It seems to me that it’s much better to have a developer produce one Totally Finished game than several somewhat-finished ones.

Before I move on, I need to point out that it probably really is exactly zero developers who have the ability to do option #1 (Totally-Finished-NoPatch). This is because only once you expose your game to the hundreds, thousands, or hopefully even millions of players that will make up its player base, is your game really getting tested in a way that can give you serious data on how it’s functioning. Even if you’re one of the fortunate bigger teams that can afford to hire a QA firm, that kind of testing just doesn’t come close to what you get when the game goes public.

If option #1 were possible, developers would be doing it. But we have essentially zero examples of this.

 

Worth the Annoying-ness

I think there are three primary reasons why people get frustrated when the game they love changes. I will start this section off by noting that, as a game designer, I have to admit that I am a little bit biased here, as patches, for me, are always a source of excitement. I love to look through changes and see what solutions other designers come up with for problems that crop up. With that said, I think everything I’m about to say stands for everyone.

Complaint #1Their dominant strategy, or thing that they were attached to personally is being taken away from them.

This is a straight-up bad argument that I will dismiss pretty quickly. It’s simply short-sighted. Sure, maybe you love your over-powered dominant strategy, but do you love that it makes the game a less positive experience for everyone else? Do you love that it might be a significant part of the game you love and its community dying off and being forgotten? A healthy game is a balanced game, and so you shouldn’t love any imbalance, even those you personally take advantage of.

The second half of this reason is a little bit better, and I can understand if you had a “favorite spell” in a game and then it was removed. This happened a few times in the Auro development. I would just say that if this does happen, try to remember that the system that supported that favorite-spell is still there, and if all you really liked was this one spell, then maybe you don’t like the game that much to begin with.

Complaint #2 They have to re-learn more rules.

This one is much more valid. It is annoying to have a strategy or group of strategies you were getting good with or developing change on you because of a patch. Further, releasing big patches frequently, in a sense, does limit the overall accessible-depth of your game (watch this video for a good explanation on what I mean by depth; but chances are, you know what I mean already). The reason is because when the system changes, your understanding of it breaks down at least a few pegs. So you could be unable to ever reach the deepest, most interesting parts of a game if, as an extreme example, the rules were dramatically changed every day. You’d just spend all your time learning and adjusting to basic rules.

While this complaint is more valid than the first one, it’s still worth doing, despite this complaint. First, we should keep in mind that many players will start playing the game after “today’s patch”, in which case, they are simply getting a better game without any of the downsides. But even for those players who have to “re-learn” things, it’s still worth that sacrifice in overall depth if we end up with something that’s truly rare: a polished, balanced, and truly finished game.

That brings me to the third complaint – one that almost never is actually the case, and no one complains about out loud, but may actually be a reason for many people’s gripes regarding patching in some games.

 

Patching’s Dark Side

I have a lot of admiration for Riot Games for what they’ve been doing with League of Legends over the past few years. They’ve had a really progressive attitude and have taken the game in a good direction overall, with numerous smart changes that really do improve the game. I also love reading their patch notes, and I’m personally inspired by their “patch rundown” series where they walk through the reasonings behind changes.

However, things like this concern me. (Watch at 13:45):

Quote: “One of our biggest philosophies for League of Legends is we want to keep the game fresh, we want to keep the game changing…”

This is not what patches are supposed to do, and I do fear that a lot of these patchwork game designs – systems that have no actual core mechanism or inherent depth – could be using patches in the same way that MTG or numerous other games use content: to artificially keep a dead system alive. In other words, patches could be used as a game’s iron lung.

This is Complaint #3, the silent complaint that people don’t often make, but I think is there, under the surface – that developers are just changing the game just to change the game. That is not good, and that is not what patches are for.

Patches should be delivered in an attempt to bring a game closer to completion, not to keep solution a moving target.

Now, I’m not actually sure that Riot actually does what this guy suggested. From looking at their patch notes and following their changes closely over the last year or so, I would say they do seem like they are – addition of new champions aside – trying to hone in on the optimal League of Legends gameplay. I think they’re slowly (again, very slowly, because every new champion is a step backwards) moving towards being the best game it can be.

However, if anyone was doing what this employee suggested they’re doing, and if it’s not obvious why that’s bad, it’s because “perpetual changes” necessarily means that you’re not always improving the game. Obviously, “the optimal design” is kind of a theoretical thing, but, you can get a game to a point where making any improvements becomes very difficult. In this case, adding anything, taking anything away, or changing things at all will generally make the game worse.

In fact, the better your game is, the more likely frequent changes are to be harmful, since it’s more and more difficult to come up with any changes that further improve the game.

 

Communication

Patching is a good thing! Ultimately, we all want the same thing: our games to be the best they can be. They can’t do this on release day, I’m very sorry to report. They will need to issue patches, and when they do, I think it’s in all of our interests to try and understand what the developer was going for with the patch.

At the same time, it’s very important that developers do their best to communicate their reasoning for making the changes that they make. I tried my best with the crazy Auro 1.29 patch to explain everything we did. For us, that ended up to be four articles and a podcast episode (all can be found here if you’re interested). While I wanna go the extra mile in terms of patches, I think it’s equally important to go that extra mile in terms of communication.

I would also suggest to players that they need to try and communicate their complaints as clearly as possible to us developers. It’s in players best interest to figure out what the design goals are for a given developer. Being aware of a developer’s goals will save everyone a lot of time and effort on various forums yelling past each other.

Let’s drop the “don’t patch your game”-style complaints, and instead figure out, together, how we can better patch our games.

 

  • Gerard Comerford

    Good article, Keith. However, you’re writing on the erroneous assumption that developers are still developing to the standard set by the constraints of an exclusively non-online disc-based era: developers couldn’t patch. Obviously, this isn’t the case currently and the option to release a patch has irrevocably changed development timelines. Developers are releasing broken games to get their games out in lucrative release periods, and without the constraint of an exclusively non-online disc-based era, they can gamble on the state of their current build and if the gamble fails, they can pay it off with a patch post-release.

    The perfect example of this is the Master Chief Collection: released in November 14 and released broken. Look, that behaviour is never going to endear gamers.

    From a design point-of-view, I think patches that alter the game mechanics are a slippery slope and should be altered with extreme caution. It’s like altering a Honda to be a McLaren; if the game mechanics are that bad that you have to change them, then you should start developing a new game.

  • I did mention that stuff that is literally “broken” should of course get fixed, and yeah, when games get released, nothing should be “broken” in the technical sense. And I do agree that there could be developers who are perhaps sort of lazy and release things with a “eh, who cares, we’ll fix it in a patch” attitude, although I have no evidence that this has ever happened. I mean I know games get launched broken, but I don’t know that that’s because of any kind of laziness.

    “Slippery slope argument” – then isn’t this true before release, too? It’s not that the game mechanics are “that bad” necessarily, but that they “could be made better by making proposed change X”. My argument is that you should do it.

  • Max Hospadaruk

    “It’s like altering a Honda to be a McLaren; if the game mechanics are that bad that you have to change them, then you should start developing a new game.”

    The part you’re missing in this comparison is that with a game it’s not “it will be too hard to bring this Honda up to standards; we should start with a better car.” It would be more like “it will be too hard to bring this Honda up to standards; we should scrap it entirely and build a completely new car out of pieces of scrap metal.” In no way would it ever be less work to develop a new game than to improve an existing one.

  • Paul Spooner

    Excellent article. I was not aware that these other viewpoints even existed. Keep up the good work!