• FEATURED

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

## What is the ideal patching frequency?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

14 replies to this topic

### #1Oogst  Members

Posted 05 October 2014 - 05:47 AM

I have written a blogpost about how often we think is ideal for patching a game that is continuously being added to (as we do with Awesomenauts). I am curious what your experiences are with this. Have you worked on a game that got continuous patches and additions after launch? How often did you patch, and why?

We have found that patching too often is a bad idea, because it makes the patches really small, which in turn makes it difficult to market them and build hype for the new content. So we now try to do a new patch once every 6 weeks, which gives us time to slowly reveal its features, do a proper semi-public beta and have a lot of content in each patch.

Here is my blogpost, explaining our reasoning further and how we do marketing for individual patches:

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

What are your experiences with patch frequency?

My dev blog
Ronimo Games (my game dev company)
Awesomenauts (2D MOBA for Steam/PS4/PS3/360)
Swords & Soldiers (2D RTS for Wii/PS3/Steam/mobile)

Swords & Soldiers 2 (WiiU)
Proun (abstract racing game for PC/iOS/3DS)
Cello Fortress (live performance game controlled by cello)

### #2StarMire  Members

Posted 05 October 2014 - 07:37 AM

Weekly, I think.  Much more delay than that, and people start losing interest.  People have short attention spans.

Runescape has had great success with weekly updates.  For really major updates that you want to hype, you can start promoting a few weeks ahead, but only if it's something really exciting.

### #3frob  Moderators

Posted 05 October 2014 - 09:45 AM

Depends on the game, and especially depends on the nature of the patch.

In the past when patching wasn't an option developers needed to invest in QA to ensure everything was covered. The game was done, filed away, and archived off of developer's machines three months before it was in player's hands.

Sadly these days too many companies send an incomplete game to manufacturing, then have a patch ready a few days before launch that implements all the features they knew were missing but convinced Sony/Microsoft to let them ship with, followed by a day 1 patch for the stupidly obvious bugs they didn't catch, a day 3 patch, a day 7 patch, followed by weekly patches for months. So many of these the product launch is a death march where product designers and producers made ludicrous decisions because they had the option to patch it later, ignoring things like QoL or scoping. Why properly scope the project, they might think, when we can keep even the most expensive and seldom used features, not bother with detailed tuning, and still make a six months release date; we'll just use a two year budget and a year of patches and make the six month launch date. The first launch is basically just a vertical slice demo of the game with the game turning into the real game after a year or so, but only if enough people buy the early bug-riddled incomplete version.

I absolutely hate the idea of regular patches for bugs, or regular patches for balancing, or regular patches for other defects caused by rushing a game out early. Usually it means product failures, which means bad customer experience, which means crappy game. Usually also those are indicative of failures starting at management and problems that go all the way down through the org chart. Wiser programmers flee when they see it coming. Too many studios these days are run by industry-inbred incompetence where they saw the bad habits at other studios and picked those rather than picking up the good habits of better software engineering methods. As an example, recently on Reddit there was an argument about a midsize MMO design, they had several hundred thousand MAU but they had zero unit tests in their server and back-end code, they were rewriting their (mostly untested) billing code on the fly and touting themselves as high quality because they followed a continuous delivery system, even though they had zero automated tests and none of the major protections in place used by smarter, more mature developers. Yes, they managed to deliver a game, but their software architecture was from the dark ages.

On the other hand, regular updates of additional content, adding 10 more levels, adding expansion packs, adding DLC, those I like to see fairly regularly when they make sense for a game. As long as the game is still popular then additions and expansions to keep it fresh are wonderful. I've been on long-tail projects with new DLC content released weekly for multiple years. If players are still engaged and want new building blocks for their toy and are willing to keep it commercially viable, let them.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #4Orymus3  Members

Posted 05 October 2014 - 09:47 PM

Hi Oogst.

I played Awesomenauts a few... years back I believe. From what I can remember, it was a good game!

Now to answer your question, I believe it depends on the game, but generally speaking, quicker cadence is more desirable.

I believe the challenge comes from meeting, or rather, adjusting the expectations of your playerbase.

I've been involved in a variety of games with a weekly cadence, and this is where I've seen optimal results. Other games I've worked on that had a monthly cadence tend to miss going their full potential (oftentimes coming up with disappointing results in terms of player retention).

If you'd like you can take a look at Space Engineers. This is a great game, and they've been amazing a lot of success with their current weekly cadence.

As for your specific situation, is there any way you can increase cadence and content? (can you make a few hires or reallocate resources?)

I see that you're currently transmuting your problem into something else: since we can't have the cadence we'd like to have, why not make this incremental releases that we can market. The problem is that you're using this for user acquisition instead, which is an entirely different goal.

Are your issues with shorter cadence with retention or acquisition? (or monetization perhaps?)

Edit: On a last note, I would avoid using the term 'patch'. To more people this suggests you are fixing bugs, which also infers you develop bugs. What you really want to put forwards is the fact you're actively working in the game, and are releasing new content. 'Content Push', 'Release', etc. are all better terms to refer to what you're doing. This may not appear like much, but imagine that a player comes across a post about your game (it's the only thing he's ever seen) and he sees 'Patch'. He's likely to thing: here's another incomplete Beta filled with bugs, I'll give this a pass. My 2 cents

Edited by Orymus3, 05 October 2014 - 09:53 PM.

-=- My Articles -=-
Getting Games Done - Method and tools on how to start a hobby project and get it Done!

The Art of Enemy Design in Zelda: A Link to the Past - Reverse-engineering functional enemy design from applied example.

Retro Mortis - "RTS" - Article Series (4 Parts) on the history of RTS development (4th part finally released!!!)

### #5StarMire  Members

Posted 06 October 2014 - 04:10 AM

Edit: On a last note, I would avoid using the term 'patch'. To more people this suggests you are fixing bugs, which also infers you develop bugs. What you really want to put forwards is the fact you're actively working in the game, and are releasing new content. 'Content Push', 'Release', etc. are all better terms to refer to what you're doing. This may not appear like much, but imagine that a player comes across a post about your game (it's the only thing he's ever seen) and he sees 'Patch'. He's likely to thing: here's another incomplete Beta filled with bugs, I'll give this a pass. My 2 cents

Great point Orymus3, I'd never thought of that. Personally I don't have any negative feelings about "patch", but I can see how some people would correlate them to bug fixes for a buggy game that was pushed far too early.

Maybe call it "Free DLC"? Since DLC is good, and free is even better. Although we tend to think of DLC as optional, while a content push like this might be necessary for the game itself, particularly to continue to work with other clients if you're talking any form of online or co-op play (I'd just worried some people wouldn't understand what is meant by content push).

### #6Orymus3  Members

Posted 06 October 2014 - 04:58 AM

Release is fairly mainstream however.
Plus you can easily come up with means to make it enticing: "So what does the Holiday special release contain?"

-=- My Articles -=-
Getting Games Done - Method and tools on how to start a hobby project and get it Done!

The Art of Enemy Design in Zelda: A Link to the Past - Reverse-engineering functional enemy design from applied example.

Retro Mortis - "RTS" - Article Series (4 Parts) on the history of RTS development (4th part finally released!!!)

### #7frob  Moderators

Posted 06 October 2014 - 10:41 AM

Maybe call it "Free DLC"? Since DLC is good, and free is even better. Although we tend to think of DLC as optional, while a content push like this might be necessary for the game itself, particularly to continue to work with other clients if you're talking any form of online or co-op play (I'd just worried some people wouldn't understand what is meant by content push).

Update, or Themed Update. Expansion or Expansion Pack. Anything but "patch".

You may not have connotations of 'patch' == bugs, but I know I do.  When I read "patch", I think about zero-day patches and emergency bug fixes applied at launch. I think of installing recent patches on all the servers for a stupid bash bug.

When I see "Patch 37" I think "Wow, they've needed 37 attempts to make their game run. Sucks to be their customers."

However, if I see "Halloween Update" I think "Cool new costumes!"

If the update is required, make it about the new content:  ("You need to install the latest updates to connect to the servers. %s", theme_message) with an update-specific value of perhaps "Try the new witch and warlock costumes" or "Gifts for everybody" or "Get lucky with the new shamrock bowtie" or "Now with 50% more napalm" or whatever fits the update.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #8Oogst  Members

Posted 06 October 2014 - 11:48 AM

I absolutely hate the idea of ... regular patches for balancing

I agree that bugfix patches suck, but balancing is something that partially needs to be done on a live game. With a game as complex as Awesomenauts (which is a MOBA, one of the most complex types of games to balance) it is impossible to find ALL possibly overpowered strategies beforehand. There are just too many possible strategies. Planning to get it perfect at launch is very naive for a game as complex as that.

And even if you do get the perfect balance before launch, it is still not good enough: over time an active multiplayer community will evolve a meta where they all start doing the same tactics. Even if those tactics are not actually overpowered, just thinking they are overpowered makes them all do the same thing. This makes the game boring, since so many matches end up being the same thing. Even perfect balance cannot fix this, the only solution is to regularly patch to rebalance and change which tactics are effective.

I see that you're currently transmuting your problem into something else: since we can't have the cadence we'd like to have, why not make this incremental releases that we can market. The problem is that you're using this for user acquisition instead, which is an entirely different goal.

Not at all! We chose the new patch frequency not because of production issues, but because we think it is better for the game and community. In the first year of Awesomenauts we did patches much more quickly after each other, but each patch was smaller. We stopped doing that because we think doing bigger patches less frequently has more impact, and our experience so far agrees with this.

On a last note, I would avoid using the term 'patch'. To more people this suggests you are fixing bugs, which also infers you develop bugs. What you really want to put forwards is the fact you're actively working in the game, and are releasing new content. 'Content Push', 'Release', etc. are all better terms to refer to what you're doing.

Interesting point, I had never looked at it like that! Definitely something to consider!

My dev blog
Ronimo Games (my game dev company)
Awesomenauts (2D MOBA for Steam/PS4/PS3/360)
Swords & Soldiers (2D RTS for Wii/PS3/Steam/mobile)

Swords & Soldiers 2 (WiiU)
Proun (abstract racing game for PC/iOS/3DS)
Cello Fortress (live performance game controlled by cello)

### #9frob  Moderators

Posted 06 October 2014 - 04:23 PM

And even if you do get the perfect balance before launch, it is still not good enough: over time an active multiplayer community will evolve a meta where they all start doing the same tactics. Even if those tactics are not actually overpowered, just thinking they are overpowered makes them all do the same thing. This makes the game boring, since so many matches end up being the same thing. Even perfect balance cannot fix this, the only solution is to regularly patch to rebalance and change which tactics are effective.

Google:  Perfect imbalance in game design

You are right. If everything is perfectly balanced the game does become boring. Exactly equal gets boring fast.

You want it intentionally imbalanced, but perfectly imbalanced.  A usually defeats B, B usually defeats C, C usually defeats D, D usually defeats A, applied on multiple dimensions of the characters. Players can only choose a subset of the features to be active, so in every case there exist counters to all the different strengths but those counters may or may not be in place, based on other decisions by the players.

There are so many great examples of this.  In card games Magic is one. Every year they launch hundreds of cards in the core set, but a deck is usually based around only five or six key cards. With a few very rare exceptions, every good combination can be countered by multiple other combinations, but not by all combinations. I might be able to build a smashdown deck, but it can be easily overcome by control and evasion. I might be able to build an evasion deck, but it loses to a control deck or removal. I might be able to follow a removal theme, but struggle against a simple weenie-rush or against evasion. Each set usually includes five major themes and ten lesser themes, but limitations to deck size constrain your actions. Thus players need to constantly adjust their imbalance, and it is impossible for the system to reach equilibrium since when one strategy becomes popular there are multiple alternate strategies that can defeat it. In the rare event of an extremely overpowered card, yes, they need to make an adjustment, but it is usually to just one card out of the hundreds in the pool.

Several of the Smash Bros games also found an excellent level of imbalance. Dozens of characters to choose from, each with strengths and weaknesses that partially counter each other, placed in environments that often favor differing strategies on the combination of players. Skilled players can pick random characters and boards and still have exciting matches.

Lots of other examples of perfect imbalance in games, two is enough for this post. :-)

Edited by frob, 06 October 2014 - 04:26 PM.
typos

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #10StarMire  Members

Posted 10 October 2014 - 09:56 AM

Update, or Themed Update. Expansion or Expansion Pack. Anything but "patch"....

When I see "Patch 37" I think "Wow, they've needed 37 attempts to make their game run. Sucks to be their customers."

However, if I see "Halloween Update" I think "Cool new costumes!"

If the update is required, make it about the new content:  ("You need to install the latest updates to connect to the servers. %s", theme_message) with an update-specific value of perhaps "Try the new witch and warlock costumes" or "Gifts for everybody" or "Get lucky with the new shamrock bowtie" or "Now with 50% more napalm" or whatever fits the update.

Update!  That's the ticket

I love the idea of themed updates.  That would be exciting.

I'm sure it's easy to add a few new clothes and items to every update (depending on your game), even if the primary secret purpose is to fix an exploit or something.  I hope that wouldn't be seen as deceptive.

Sounds like a good solution to the naming problem.

Google:  Perfect imbalance in game design

You are right. If everything is perfectly balanced the game does become boring. Exactly equal gets boring fast.

You want it intentionally imbalanced, but perfectly imbalanced.  A usually defeats B, B usually defeats C, C usually defeats D, D usually defeats A, applied on multiple dimensions of the characters. Players can only choose a subset of the features to be active, so in every case there exist counters to all the different strengths but those counters may or may not be in place, based on other decisions by the players.

+1  I second this.

It's much easier to design a game when characters are fundamentally different in some way and rely on those unique abilities or specializations, and get strong enough advantages or disadvantages against others to make them meaningful.

If one is "more powerful" in an absolute sense, that makes more people choose that one... but then the one that beats that one becomes more popular too, because of the higher popularity of that first one (more victims!), and so on.  All characters remain relevant, because their true value is partially predicated on the rarity of their selection.

It's self-balancing.

### #11Oogst  Members

Posted 12 October 2014 - 06:01 AM

I have collected the opinions of a bunch of other devs on the ideal patch frequency into a new blogpost. Here it is, including opinons from the devs of Prison Architect and Don't Starve:

Other developers on the ideal patching frequency

I have also added Orymus3's quote on the word "patch" since I found that one highly interesting.  Orymus3: if you have made a game or want your real name or company mentioned in the post, then let me know and I will edit it.

My dev blog
Ronimo Games (my game dev company)
Awesomenauts (2D MOBA for Steam/PS4/PS3/360)
Swords & Soldiers (2D RTS for Wii/PS3/Steam/mobile)

Swords & Soldiers 2 (WiiU)
Proun (abstract racing game for PC/iOS/3DS)
Cello Fortress (live performance game controlled by cello)

### #12d000hg  Members

Posted 14 October 2014 - 05:10 AM

My understanding with iOS apps is you have to download the entire app every time there is a patch, personally I find it annoying to have to do a big download frequently just for little bug-fixes.

### #13Orymus3  Members

Posted 14 October 2014 - 06:58 AM

One thing I've seen work is staggered development. I've had to resort to that on a project I did (white label). Basically, we had two teams, each of which were on 2 weeks sprints, meaning we ended up delivering the equivalent of 2 weeks worth every week. A lot of this hinged on getting the build approved through very efficient QA testing (which we had to supplement with 3rd party QA-ing in a different timezone).

The end-result was astonishing, but I don't know how long this strategy can be employed before the build eventually breaks, and you miss a deadline.

Staggered development only works for as long as your player base knows it can trust you to deliver on time. The minute you break that bond, (most/all) added gains are lost.

I have also added Orymus3's quote on the word "patch" since I found that one highly interesting.

Orymus3: if you have made a game or want your real name or company mentioned in the post, then let me know and I will edit it.

I'm good with anonymity, although that's a moot point since my username has been tied with at least 2 articles on game dev (which means my "real identity" is fairly easy to uncover). Given that the bulk of my experience comes from the industry, and not from being an indie (I have yet to score in that regard), putting my name up there would hardly give the thought more credibility ;)

If you can, you should really inquire to Keen Software House regarding the success they've had patching Space Engineers weekly!

EDIT: Eh... I replied with my google account anyway, so my name is written in bold in the comments section. Ah well...

Edited by Orymus3, 14 October 2014 - 07:06 AM.

-=- My Articles -=-
Getting Games Done - Method and tools on how to start a hobby project and get it Done!

The Art of Enemy Design in Zelda: A Link to the Past - Reverse-engineering functional enemy design from applied example.

Retro Mortis - "RTS" - Article Series (4 Parts) on the history of RTS development (4th part finally released!!!)

### #14Oogst  Members

Posted 14 October 2014 - 09:34 AM

Staggered development like that is an interesting idea, I hadn't heard of it before.

It does sound too rigid though. What if you want to make features that are bigger than two weeks of work? New characters we make for Awesomenauts take several months to develop.

I think if we felt the need to do weekly patches it would work better to just let devs develop their stuff in however much time is needed. New things would by default be excluded from the release build and then every week we would pick what we want to release that week. With a good overview of what is ready and how far along other things are I think it would be possible to select features in such a way that you have weekly new content consistently. I think this approach would work better with a larger team and various development times on new features.

This is all purely theoretical though because my main point was that bigger patches less often is better for publicity reasons.

Edited by Oogst, 14 October 2014 - 09:34 AM.

My dev blog
Ronimo Games (my game dev company)
Awesomenauts (2D MOBA for Steam/PS4/PS3/360)
Swords & Soldiers (2D RTS for Wii/PS3/Steam/mobile)

Swords & Soldiers 2 (WiiU)
Proun (abstract racing game for PC/iOS/3DS)
Cello Fortress (live performance game controlled by cello)

### #15Orymus3  Members

Posted 14 October 2014 - 10:58 AM

Google:  Perfect imbalance in game design

http://extra-credits.net/episodes/perfect-imbalance/

Pretty good video on the topic.

It does sound too rigid though. What if you want to make features that are bigger than two weeks of work? New characters we make for Awesomenauts take several months to develop.

Split your team in 4, and work 4 week cycles. Still deliver each week, but 4 teams have 4 different ETAs.

I think if we felt the need to do weekly patches it would work better to just let devs develop their stuff in however much time is needed. New things would by default be excluded from the release build and then every week we would pick what we want to release that week.

That seems to be what they do for Space Engineers. They just deliver that which is "done done". Sometimes, they happen to release something that is clearly a stepping stone to something else too because they are halfway through and can cook up something that emulated the final feature. Also gives them a chance of evaluating the issues with it before making a full release.

Bottom line is, you've probably tried many strategies. If you stuck with yours, then it's because it works for you, and ultimately, you need to "do what works".

Do you feel your strategy is optimal for your team, project and player base?

Edited by Orymus3, 14 October 2014 - 10:59 AM.

-=- My Articles -=-
Getting Games Done - Method and tools on how to start a hobby project and get it Done!

The Art of Enemy Design in Zelda: A Link to the Past - Reverse-engineering functional enemy design from applied example.

Retro Mortis - "RTS" - Article Series (4 Parts) on the history of RTS development (4th part finally released!!!)

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.