Devblog 76 update frequency poll discussion (unofficial)

In Devblog 76, garry posted the following, with an interactive poll. Go vote if you haven’t yet. As of thread creation, it had 7,814 votes and was climbing consistently. [sp]Please do not make the thread about the vote count getting higher.[/sp]

As of the time this thread was posted, “weekly” was winning with 38%, with “two weeks, blog weekly” behind it at 31%, and 15% to “monthly, blog weekly” and the scraps for the rest.

What does everyone think? Discuss!

Edit to add in my own contribution: Don’t forget that you can usually/always hop onto the development branch and join development servers to see what’s going on on the cutting edge. ALSO, you can stop Steam from updating the client, and if you keep a client matched to the same version as a server (assuming you both agree to stop updating at revision XYZ until the next monthly patch), you can play on it for as long as you want. If Rust did move to monthly patches (with weekly devblogs, say), I imagine that there would be community servers that would announce an update freeze when the development branch hits a certain plateau of stability with whatever new features were going in at the time, and everyone who then turned off automatic updating in Steam for Rust would be able to play on that server until the next major plateau worth upgrading to before the end of the monthly update cycle. It would require a little bit of coordination to make sure you didn’t miss the announcement and accidentally have Steam update you too far ahead, but perhaps servers could choose the times of day when the Rust team isn’t pushing commits out to @RustUpdates (i.e. they’ve gone to bed) to make go/no-go decisions on version freezes, or simply just pick a day and take whatever’s available.

Alternatively, if it’s possible, the devs could have the client builds on SteamCMD and people could pull down and overwrite their Rust install with the older build; then you just have the server announce what build it’s using and how to get the matching client build off SteamCMD (with instructions for using SteamCMD, hopefully). If this is possible already, I’m not aware and I think it should be expanded on. Without enabling warez, obviously.

I think weekly will allow us to work out bugs. However, I am a big fan at once a month for preservation of our bases

People actually want unpolished, buggy updates every week instead of awesome, polished, game changing patches every month?

I can see where they are coming from. If decreasing the frequency of updates means a more efficient method of implementing them, then I think that is a positive thing. I think it would decrease the duration of the alpha and beta stages over all, which is surely what we all want.

I think a good compromise would be updates on a 2 week basis, a month might be too much for some.
I am totally fine with either. However, I would like to be informed weekly of their progress via dev blog.

I voted weekly just because that’s the natural reaction the second the page pops up and its in big writing…I like knowing that in a weeks time some more interesting changes are gonna appear, it keeps the game fresh.

That being said I would have voted every two weeks or monthly after reading and thinking about it for a bit since as he says 20%ish of their dev time goes into packaging/fixing patches, and I don’t think I’m alone in that.

I am thinking that bi-weekly updates with a blog every week would be awesome. I could tell months ago that this 4 day work week was not doing very well for the team. Right when some people getting rolling on something, a new patch is 1 day away. I think making patch cycles in 2 weeks instead of 1 you really increase the amount of work that can be done, while also keeping the community informed during the downtime of what is happening and coming. I guarantee it’s more efficient, which while some people may not feel is best for them, I say it is best for the game and the studio.

I think strict deadlines stifle creativity, but having a whole month at their disposal might cause some laziness. But then again, they’re doing this for free, so they should take as much time as they need. Why even put this up to vote? People are impatient so obviously they’re going to go with the first choice.

i said a month. although i’d be happy enough with fortnightly updates and blog, and monthly would likely slow progress, i think it would lead to more stable builds each update.

Every two weeks update, but with weekly blogs is the most reasonable for the community and the devs.

Devs said that it takes a day for getting the update ready, and then a few days (I’ll assume two days max or so) to patch shit up, which means they lose 3 days out of 7 of dev work.
That’s more than 20% as 7 * 0.2 is 1.4 which means the percentage is higher than 20%. Unless I’m missing something.

If we did two week updates, then they would lose only 3 out of 14 days. That’s way better.

Not sure why everyone assumes the ‘patch shit up’ phase remains constant duration if the amount of work increases.

I couldn’t care less when the patches roll. My only concern is how frequently wipes are forced. If Rust has to update daily, as long as we can keep the clients in sync, I’m okay with that. The ONLY problem is when clients don’t update, players still see older, un-patched servers, so they don’t immediately realize that the reason they can’t see their preferred server is because they haven’t updated yet. The Steam client isn’t exactly drama-free with keeping apps up-to-date.

Being fan of iterative development i’d say go for 2 week long updates. However - more iterative process is more feedback will be given and this is what drives project towards success.
Being not a fan of crunch times and burn-outs and most importantly stress - I’d say monthly updates.
My money would be on 3 week sprints :slight_smile: