Sunday 5 October 2014

Why patching too often is a bad idea / The magic of the Vault

Recently I have seen quite a few games that launched with the plan to patch really often, especially Early Access games. Most of those games patch once a week or once every two weeks. This may seem like a good idea: iterate quickly and show clearly to the user that you really do the best you can to make good on the promise of improving the game. For a time with Awesomenauts we also tried to patch as often as possible, but by now we think that is actually a bad idea.

The main reason for this is that the more often you patch, the smaller the patches are. Lots of small patches means lots of hardly noticeable changes to the game. Why would a user come back to your game because of 5 balance tweaks, 3 bug fixes and improved graphics for 2 weapons? Why would a regular player be exited about this? The changes done in weekly patches are just too small to make an impact.

Combining a bunch of those smaller patches together creates something much more noteworthy. In a bigger patch once every one or two months you could overhaul the graphics of all the weapons instead of just two, do dozens of balance tweaks and fix a ton of bugs. Simply combining all the changes from a bunch of micro-patches into one bigger patch turns it from a bunch of uninteresting patches to one exciting patch that really improves the game significantly.

An important note here is that I am NOT suggesting that development should be slowed down. On the contrary: keep improving and extending that game as much as you can, just like we try to do with Awesomenauts! I am only suggesting to group the changes and release them together.



The goal of doing a games-as-a-service model where you are constantly improving the game is not only to improve the game, but also to excite the players. Keep them playing longer, bring back players who stopped playing and get new players. To excite players you need stories. Not literal stories, but things that players can discuss with their friends. Bigger patches are much more interesting to talk about.

Having bigger patches also allows you to create new 'stories' without additional development. You can give a patch a name and a theme simply by looking at the changes and finding some similarities. This way you can create a new story for the patch itself and make it feel like a big event.

Since December we have been doing active marketing for each Awesomenauts patch. We announce a patch beforehand and slowly reveal information about it. We have made a special website for this: Voltar's Vault.



A couple of weeks before a patch comes we open the Vault. At that moment it contains only locks. Then in the weeks up to the patch we gradually release more info on what is going to be in it. Usually we first give a vague hint, then a couple of days later we announce what it really is. This pushes anticipation for our patches enormously. Our community creates a Vault topic on our forum for every patch and posts hundreds of pages of discussion there, as you can see in this topic for patch 2.7. The more interesting the features are and the more suggestive (but cryptic!) the hints are, the crazier it gets.



The result is that we can create crazy hype for every patch and get big peaks in our playerbase whenever we release a patch. The day a patch launches we have twice as many players as on a normal day. Sometimes we can even create significant sales bumps ourselves. Those are small compared to the bump of a Steam sale, but Steam sales require getting lucky with Valve to get a slot. We can create sales peaks through hyped patches ourselves.

By increasing the size of the patch and adding a name, theme, Vault website and hints we can create real stories, worthy of discussing with your friends. In some cases even worthy to be picked up by press: a couple of big news websites (including Destructoid) often write about our patches. This only works because there is enough time in between patches to actually hype them, and because patches are big enough to make this worthwhile.

Note that if you look at our patch notes you might get a different impression. We do many more patches than I describe here. The reason for this is that we distinguish between major patches and hotfixes. A hotfix is a small patch that only fixes some immediate issues. Obvious bugs or even crashes should not be left in the game for a month, so we don't bunch up fixes for game breaking issues. Hotfixes generally don't add anything new: they just fix a broken game experience.

We started bunching features into bigger patches after we heard about how Valve went the same road with Team Fortress 2. Apparently they did weekly patches for quite a while, sometimes doing even two patches a week. They claim to have much more success with the patches since they bunch them up and give them a name and a theme. I tried finding the article where I read this but couldn't find it. Regardless, have a look at Team Fortress 2's patching history and you will see that Valve creates big patches with some time between (plus apparently a lot of small tweaking patches).



So far this post has mostly been about marketing. There is of course also a practical side to patching and continuous development. When we want to do big changes or add complex new features to Awesomenauts we need time to balance and tweak those. A big portion of that is done through semi-public betas on Steam. When we add a new character we need several weeks of beta to get his balance right for launch. This workflow is not very compatible with weekly patches.

Also, focussing on having something new ready every week probably requires incredibly short and focussed development cycles. This might sound good but I doubt production can be this focussed permanently for a year or more without burning developers out. Doing weekly patches requires really good management to keep it going and likely adds constant pressure on the dev team.

In the end patches are also a form of marketing: they need to create stories. Not literal stories, but things that are worthwhile to talk about. Things that press can pick up on, things that players can discuss.

PS: here's the follow-up blogpost to this one: Other developers on the ideal patching frequency

6 comments:

  1. The counterpoint is that holding back masses of patches all at once makes it difficult to balance effectively or gauge a tweak's impact on the game proper. Real players are always the people who need to be catered toward, and will approach the game differently than the developers. A seemingly innocuous change the developers implement might actually be a massive problem in a live build, and depending on the nature of the change, might have already been built upon too deeply to simply revert or remove.

    ReplyDelete
    Replies
    1. True, but we have semi-public betas for that. Also, significant changes need more than one week to cook internally before they should go to the public in any kind of way. I do agree that waiting really long and changing everything at once is risky, but 6 weeks between patches is not that long.

      Delete
    2. i waited 11 weeks for patch 2.6 ୧༼ಠ益ಠ༽୨

      Delete
    3. We prefer to patch faster than that but quality goes before speed.

      Delete
  2. I agree with the idea behind the "big patches" concept. But, does it really works with all kind of content?

    I believe that 2.7 beta had one of the most "bad-buzz generating" patch note regarding its changes.
    The most controversial thing(s) about 2.7 beta was obviously the droid changes... but not only. Changes done to the kill rewards and penalties, an also skills upgrades only working on enemy Awesomenauts... Throw in a new character and changes like the "Everything x10!" one, and the current players can just go "woah, that's a lot. I don't think I want such a big change".

    When I posted a few things on that matter on the forums, basically saying why these changes were good, I was greeted with quite a lot of disapproval.
    Then, I noticed something in some answers: some people didn't grasp the changes as one big step into a direction, but instead, were looking in detail at some part of it, even if everything was linked.

    So, I came to the conclusion that, current players (your everyday players) can quickly become overwhelmed by the number of changes, and strongly react to the patch to the point where they'll say things like "I'll leave the game if that goes live!".

    On the other hand, the new content was quite well received. People liked Scoop and the new menu music... It was the same with AI 205.

    And that's where and why I would draw a line between two types of new content for a big patch:
    - New stuff.
    - Changes to old content.

    So, in short terms, I would be a bit cautious about "big patches", especially regarding "core changes". People might get overwhelmed if too much is happening at once.
    I think that, regarding big changes, presentation is key. Presenting all of the changes as one big thing which needed tweaking here and there should be better than presenting every little changes independently.

    ReplyDelete
    Replies
    1. Yeah, changing too much at once is also problematic. Core changes would probably work better in smaller steps, but not weekly steps either.

      Delete