Other developers on the ideal patching frequency

Last week I wrote a blogpost about how we think it is better to have a bigger patch once every one or two months than to have really small weekly patches. I was curious what other developers' experiences with this are, so I asked around for more opinions on this. Since patching on console and mobile is so different I looked for developers who have a game on Steam, which is the platform that enables regular patching best.

Someone also pointed me to the Valve talk where they explained the importance of communication around patches and how this helped them grow Team Fortress 2. This is an incredibly interesting talk, so be sure to check it out:



Here are the replies I got from fellow developers:

Jamie Cheng from Klei
developer of Don't Starve

"While I have lots of opinions, I think it comes down to "it depends". Personally I think many devs try to do it the Valve Way only to find they don't really, truly understand why it works for Valve."

Mark Morris from Introversion
developer of Prison Architect (currently in Early Access)

"I guess the update frequency is linked quite closely to the style of development. For us, we wanted to produce quite meaty chunks (the hope being that we would get press coverage for individual updates). A month gave us enough time to develop decent additions, but was at a frequency that would still be engaging for the players. I could see weekly working, but I think that each update would be a lot less polished and would have a much more iterative development feel about it."

Kimiko from Berserk Games
developer of Tabletop Simulator (currently in Early Access)

"I think it would also depend on the game. For us in Early Access, we are one of those who patch every week or 2 weeks. Our game is a different spectrum compared to ones with stories, weapons, & what not. So patching each week works well for us. We're only doing this for Early Access though or for "bigger" updates, we'll spread it out a bit, like when we add in Oculus Rift or some of our other bigger stretch goals. Once we are out of Early Access, then we'll spread our updates out every month or so."

"There's only two of us and we work well putting out our patches each week, because it's usually about tweaking things, fixing bugs and implementing a feature. TTS is more for people to create their own games, so for us, it's better to get things out to help our users out more. Once we feel TTS is at the point where the community has the tools they need to create their own games to their fullest abilities, then we'd go out of Early Access and we wouldn't need to update every week anymore. But my point is, is that we'll still update after Early Access, but we won't have that greater need to do it each week like we do now, because it's at that "completed" stage and we'd focus on the bigger picture of adding in the bigger things from our Kickstarter stretch goals, and find ways to improve it in general."

"I think we probably spoiled our community because of our weekly updates and who knows what the uproar will be if we switch to monthly, but it's probably something we'd do gradually and we'd let our community know since we're pretty transparent. [...] As long as we keep our community in the loop, that's most important."

Pete Angstadt from Turtle Sandbox
developer of Cannon Brawl (recently released out of Early Access)

"I think the regularity of update scheduling, whether it's a week or a month is probably the most important part. That and communicating the schedule to your audience. [...] Vlambeer has a weekly schedule which they communicate to players with their livestream. Other games I think have done 'in-game' countdown timers to the next patch, or at least had the latest patch notes visible in game. If we had to do it over again, I would have gone with a very regular monthly patching schedule and included patch notes in game."

Roel Ezendam from Ragesquid
developer of Action Henk (currently in Early Access)

"We recently switched from bi-weekly to monthly updates for our Early Access game Action Henk. The biggest improvement that we have noticed is that we have far less overhead that's being spent on finishing and releasing the update. With a short update cycle the game constantly needs to be in a stable state, which makes it harder to work on larger features or a big overhaul. It also just takes time to publish the update and check if everything is working properly. These bi-weekly updates basically put us in a constant state of crunch, whereas the monthly updates give us a bit more breathing room."

Erik Johnson from Arcen Games
developer of AI War: Fleet Command and The Last Federation

"We've found that patching often isn't a bad thing if supporting your core community members (in effort to expand your core community) is your aim. [...] Anyway, I agree that this isn't a solid way to market the game in the main, but that's where our larger, more content-focused updates and DLC releases come in. I've found you can't tap the well too many times no matter how you slice it (unless you're in that fortunate position to have a sizable audience just begging for more) as far as reaching out to new players -- but a consistent stream of smaller updates keeps the community you already have established active and growing. That said, we do find that even our most popular games occasionally hit periods of patch ennui for both our community and our development team. :)"

Josef Vorbeck from Chasing Carrots
developer of Cosmonautica (currently in Early Access)

"We update Cosmonautica in 2 week cycles. We even did this before Early Access, because it's our standard rhythm with two week sprints. And we think, that we can deliver enough in two weeks to make these updates meaningful. Also we think that it's crucial for an Early Access title, that the players see constant progress during the development. These days Early Access has a mediocre reputation, because some devs are leaving their games or decide their games are finished, even though more features were planned. With our update cycles and constant communication we're trying to earn the trust of the players. It just works for us, the response so far is really great. And of course it's important for us to get the valuable feedback from our players on a regular basis. But after our final release we might switch our update rhythm to aim for larger content updates which deliver their own story, as Joost stated."

While digging for opinions I also got a replay on Gamedev.net from a user named Orymus3 who wrote a really interesting remark on the term "patch" itself:

"I would avoid using the term 'patch'. To most people this suggests you are fixing bugs, which also infers you develop bugs. What you really want to put forward 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 think: here's another incomplete Beta filled with bugs, I'll give this a pass."