Rocket, slow down.

[hedich 0]

think you need to do some research into what a alpha build(ing) is friend.

Ahhhh yes' date=' that's right, because this is your run-of-the-mill alpha release isn't it?

99% of games or mods are NEVER publicly released at Alpha stage, and the rest are luck if they are released as Beta.

I'm not complaining that this mod is available to us to play when it shouldn't be, what I'm saying is this isn't your average alpha build(ing) is it? It therefore needs to be handled properly.

[/quote']

that doesn't change the fact that it is a alpha does it?

what did you expect in reply when making this thread?

[kriegar69@gmail.com 8]

Ok so 80% of you are idiots that didnt read the guys post, he said he wants them to slow down with features and speed up with fixes.

He also stated that he knows its alpha and that bugs are to be expected, but this just means that they should fix the bugs then add features not break the game.

In this sort of environment when a game has gone viral like this it is imperative that you fix content till its stable then test new content and once its proven stable release it to the public then fix the bugs and then rinse and repeat not just release new content and leave the bugs as an afterthought as this is getting to the game breaking point where people dont want to put time and effort into playing the game because there efforts will be crushed by bad game design.

Dont get me wrong I love this game and I love the developers and the ideas they come up with but I have to agree with this guy... they need to get their priorities straight!

[drumsetjunky 0]

Although I get the OP's point about this not being a normal Alpha with all the attention this mod has gotten. It doesn't change the fact that it is still Alpha(sorry to be a broken record OP).

I LOVE the fact that the game can change so much overnight. Yes sometimes it breaks things(but they are usually fixed within a matter of hours). But I look forward to each cycle of features/experiments that Rocket has for us.

The reason why you get frustrated with the development cycle is the reason WHY I STICK AROUND.

I've also been a part of testing an Alpha build before and let me tell you this is normal. I'm actually kind of dreading the day that this goes into beta and things really calm down and are more flushed out.

I think it would be prudent to have a few PUBLIC pre-roll out servers that people could test the newest/experimental builds that Rocket is conjuring up. This way Rocket could see what things are working before throwing them out to the entire raving hordes. Also he could try really far out there things that just come to mind without getting the heat from the community.

[JayMeHD 26]

think you need to do some research into what a alpha build(ing) is friend.

Ahhhh yes' date=' that's right, because this is your run-of-the-mill alpha release isn't it?

99% of games or mods are NEVER publicly released at Alpha stage, and the rest are luck if they are released as Beta.

I'm not complaining that this mod is available to us to play when it shouldn't be, what I'm saying is this isn't your average alpha build(ing) is it? It therefore needs to be handled properly.

[/quote']

that doesn't change the fact that it is a alpha does it?

what did you expect in reply when making this thread?

I expected exactly what has happened. People misunderstanding what I'm trying to say.

I never said this Alpha is a piece of shit and I dont want to play it. I never said the work Rocket and the team are doing is lazy and stupid.

I am merely voicing my opinion; which is that I believe the whole updating process needs a rethink. Hotfixes and updates flying out everyday that aren't doing what they're supposed to do isn't good. Why have the whole community getting pissed at major bugs when you can just privately release updates and test them before everybody plays them. In the mean time have a good stable alpha build (that lacks newer features but works almost flawlessly) available publicly. I don't see the downside to that approach?

[TheFired3mon 33]

I agree with you somewhat, but he should work at whatever pace he prefers. He's getting these fixes out fast, and I love it. But, as you said, he is adding new things that are game breaking (ie: hatchets/crowbars and them randomly dropping tons.) So far though, he seems to be releasing a fix for those game breaking bugs the next day. I'm content with what Rocket's doing and I personally hope he continues. Also, I didn't misunderstand what you said. Maybe the way I posted my reply makes it seem like that, idk. I'm still half asleep. Just woke up around 10 minutes ago XD.

[walrus2517 27]

JayMeHD - In reference to your latest update to your original post, they do have a small, closed team of testers who try out each update before releasing them to the rest of us. It isn't just Rocket throwing new code to 250k people and seeing how it works.

Rocket is going to work on this at his own pace as he sees fit regardless of anyone's opinion. If he feels like adjusting his current process he'll do so but if he's happy continuing along the current path you just need to get used to it. There are multiple posts everyday from people telling him what he should be doing in regards to the software development process.

A lot of people will try to define just what "alpha" means, but to me it means simply that Rocket is free to do whatever he wants. If people arent' happy with the progress, put the game down for a week or two then come back. If you really aren't happy, put the game down for good and wait until it goes gold.

[jingletard 0]

It'd be nice to stick to a schedule for updates (once a week or something) but I respect Rocket's development cycle which is HOLY SHIT I BROKE FUCK IT! RELEASE THE KRAKEN!

The biggest bitch for me is that the update servers seem to get hammered and the servers are slow to update once a point release comes out, but oh well. The only thing on my Christmas list is a weapon to start out with at spawn.

[earion 3]

tl;dr Slow down. Fix only bugs with hotfixes as and when needed' date=' and major patches should be released further apart.

[/quote']

Totally agree with almost everything you said.

It's an Alpha' date=' not a release. The time to focus on keeping things stable in an update is post-release. You need to learn that in alpha u just gotta deal with bugs, get used to it, or don't play until it's a final version.

[/quote']

Oh, sorry, but there is no such thing as a "standard release lifecycle".

In my line of work, alpha isn't supposed to be used in production like DayZ is. We sometime break that rule with the agreement of a specific customer. Then, oh, wait, our customer is having a couple of crippling bug with that alpha version - other bugs, he doesn't give a shit - what can we do ? Well, guess what : we release

product-2.4.1~alpha6.hotfix1.

As the "hotfix" name implies, it only contains... fixes. And we won't issue an hotfix if the bug isn't considered as crippling by the user. We actually made the mistake of doing differently in the past. Then, decided we would never merge new features again in an hotfix branch, *even we hotfix an alpha*. And that the need for hotfixes should be *exceptional*, even for an alpha. Worked. We now rarely use hotfixes, and in the worst case, we had 2 hotfixes for a single alpha. And have 1 hotfix for about 10 alphas. We roll a version every 2 weeks.

FYI, the version numbering scheme I use here is an example of Debian Linux standard packaging. In this example that means :

2.4.1 : version

alpha6 : it's the sixth alpha for 2.4.1

hotfix1 : woops, those two bugs on the 2.4.1~alpha6 were really shameful

This numbering scheme is certainly too complicated for DayZ ; it is just an example of what you can do with a scheme designed by people who learned release lifecycle the hard way, over the last 15 years at least, in a community driven project. I hope it will help you understand why the OP conception is, compared to yours, much closer to the state-of-the-art.

Another reason why Rocket and the team should consider closing Dayz to the public...at 250' date='000 testers you have more than enough people to develop a solid game.

[/quote']

Hum. What a strange idea. Why would it be any better than the OP suggestion of having a bunch of servers dedicated to testing the latest versions, for players like who don't mind taking the risk of dying/loosing their gear because of new bugs ?

I'll take the example of Debian again. They have at least three available versions at the same time, you are free to chose among them :

1. stable : thoroughly tested, recommended for safest production use.

2. testing : overall, suitable for daily use, but many bugs should remain in the corners. Please consider installing it over stable, it will help us track them down.

3. unstable : here we add all the latest features, but can be broken anytime. Only use it if you know what you are doing.

Consider that : stable=release, testing=beta, unstable=alpha. Sort of. Same-same, but really different.

Now, what about DayZ ? "stable" makes no sense. Normally, "testing" wouldn't. "unstable" is the only really acceptable qualifier.

However, now with a 6 digit userbase, the "can be broken anytime" criteria that comes along with unstable/alpha is simply not acceptable anymore. This amount of people can sure live with some existing bugs, but you can't expect *all* of them accept that after upgrading, those bugs might be worse than before, along with a whole batch of new ones.

Now, without even looking at the server list, I'm quite sure many servers are still running 1.7.0, though by now the majority should have upgraded to 1.7.1.4. So, it seems there is a natural separation between "testing" and "unstable". However :

1. The latest version of DayZ always seems to be advertised as the one you should install. Or at least, is not declared "unstable" enough, because apparently a majority of players/servers update in the first 24h/48h after a new release, and then complain loudly that it's broken. Clearly tagging it as "unstable", and not uploading it on the default mirror used by SixUpdater, could ensure that the release will only be used by players and admins willing to take the risk of installing something broken. Wait for these players/admin to "recon" and then, if no massive bugs are found within a few days, tag this version as "testing" so it is rolled on the remaining servers.

2. The community standard is to indicate the version number in the server description, but it is not enough. When considering settling down on a server - that is, taking advantage of server-only persistence such as pitching tents or repairing a vehicle, I'd like to know if the admin has an "unstable" or "testing" approach. So What I'd like to see in the server list is :

EU XX - DayZ UNSTABLE - 1.7.1.4 [3P:1][CH:0][VETERAN] - Hosted by Gooby

EU YY - DayZ TESTING - 1.7.0 [3P:1][CH:0][REGULAR] - Hosted by Gyboo

That means EU XX always update to latest version no matter what. And EU YY wait a "standard" number of days (3, 5, 7 ?) before doing so.

And perhaps also something like :

EU ZZ - DayZ FEELFREE - 1.7.1.4 [3P:1][CH:0][VETERAN] - Hosted by Boogy

To indicate that the admin gives no guarantee whatsoever of when he is going to roll the update.

EDIT: I KNOW IT IS A FUCKING ALPHA. Fuck' date=' every time somebody tries to suggest something or make a criticism here people instantly jump down you throat shouting "ITS AN ALPHA DEAL WITH IT!"

[/quote']

I don't know if the OP works in the software industry, but he begins to describe a release/testing lifecycle

- that is way more realistic than any other suggestions or reactions I have seen so far

- that, if investigated a bit more, could be really better than the one that is currently used for DayZ

To to my mind, people disagreeing with him have completely failed to make point in the replies I've read so far. I don't say it's a perfect plan, and it is nearly not formal enough, but consider it as some serious food for thought. Rocket, team, any reactions ?

Thank you dude, it's been a while I haven't seen such a constructive post on these forums.

---

Oh, and one more thing : the only thing I really don't agree about the OP is the title.

"Slow down" ? Seriously ? IDK, but this kind of proposal, once refined by the dev team, could actually speed up development. At least that's what I experienced myself. By separating bugs and features a bit more, you can identify and classify bugs faster :

- regression caused by new feature

- regression caused by bugfix

- new bug added by new feature

- new bug added by new fix

The more your system gets complex, the more having this kind of information becomes vital to streamline your workflow.

[JayMeHD 26]

tl;dr Slow down. Fix only bugs with hotfixes as and when needed' date=' and major patches should be released further apart.

[/quote']

Totally agree with almost everything you said.

It's an Alpha' date=' not a release. The time to focus on keeping things stable in an update is post-release. You need to learn that in alpha u just gotta deal with bugs, get used to it, or don't play until it's a final version.

[/quote']

Oh, sorry, but there is no such thing as a "standard release lifecycle".

In my line of work, alpha isn't supposed to be used in production like DayZ is. We sometime break that rule with the agreement of a specific customer. Then, oh, wait, our customer is having a couple of crippling bug with that alpha version - other bugs, he doesn't give a shit - what can we do ? Well, guess what : we release

product-2.4.1~alpha6.hotfix1.

As the "hotfix" name implies, it only contains... fixes. And we won't issue an hotfix if the bug isn't considered as crippling by the user. We actually made the mistake of doing differently in the past. Then, decided we would never merge new features again in an hotfix branch, *even we hotfix an alpha*. And that the need for hotfixes should be *exceptional*, even for an alpha. Worked. We now rarely use hotfixes, and in the worst case, we had 2 hotfixes for a single alpha. And have 1 hotfix for about 10 alphas. We roll a version every 2 weeks.

FYI, the version numbering scheme I use here is an example of Debian Linux standard packaging. In this example that means :

2.4.1 : version

alpha6 : it's the sixth alpha for 2.4.1

hotfix1 : woops, those two bugs on the 2.4.1~alpha6 were really shameful

This numbering scheme is certainly too complicated for DayZ ; it is just an example of what you can do with a scheme designed by people who learned release lifecycle the hard way, over the last 15 years at least, in a community driven project. I hope it will help you understand why the OP conception is, compared to yours, much closer to the state-of-the-art.

Another reason why Rocket and the team should consider closing Dayz to the public...at 250' date='000 testers you have more than enough people to develop a solid game.

[/quote']

Hum. What a strange idea. Why would it be any better than the OP suggestion of having a bunch of servers dedicated to testing the latest versions, for players like who don't mind taking the risk of dying/loosing their gear because of new bugs ?

I'll take the example of Debian again. They have at least three available versions at the same time, you are free to chose among them :

1. stable : thoroughly tested, recommended for safest production use.

2. testing : overall, suitable for daily use, but many bugs should remain in the corners. Please consider installing it over stable, it will help us track them down.

3. unstable : here we add all the latest features, but can be broken anytime. Only use it if you know what you are doing.

Consider that : stable=release, testing=beta, unstable=alpha. Sort of. Same-same, but really different.

Now, what about DayZ ? "stable" makes no sense. Normally, "testing" wouldn't. "unstable" is the only really acceptable qualifier.

However, now with a 6 digit userbase, the "can be broken anytime" criteria that comes along with unstable/alpha is simply not acceptable anymore. This amount of people can sure live with some existing bugs, but you can't expect *all* of them accept that after upgrading, those bugs might be worse than before, along with a whole batch of new ones.

Now, without even looking at the server list, I'm quite sure many servers are still running 1.7.0, though by now the majority should have upgraded to 1.7.1.4. So, it seems there is a natural separation between "testing" and "unstable". However :

1. The latest version of DayZ always seems to be advertised as the one you should install. Or at least, is not declared "unstable" enough, because apparently a majority of players/servers update in the first 24h/48h after a new release, and then complain loudly that it's broken. Clearly tagging it as "unstable", and not uploading it on the default mirror used by SixUpdater, could ensure that the release will only be used by players and admins willing to take the risk of installing something broken. Wait for these players/admin to "recon" and then, if no massive bugs are found within a few days, tag this version as "testing" so it is rolled on the remaining servers.

2. The community standard is to indicate the version number in the server description, but it is not enough. When considering settling down on a server - that is, taking advantage of server-only persistence such as pitching tents or repairing a vehicle, I'd like to know if the admin has an "unstable" or "testing" approach. So What I'd like to see in the server list is :

EU XX - DayZ UNSTABLE - 1.7.1.4 [3P:1][CH:0][VETERAN] - Hosted by Gooby

EU YY - DayZ TESTING - 1.7.0 [3P:1][CH:0][REGULAR] - Hosted by Gyboo

That means EU XX always update to latest version no matter what. And EU YY wait a "standard" number of days (3, 5, 7 ?) before doing so.

And perhaps also something like :

EU ZZ - DayZ FEELFREE - 1.7.1.4 [3P:1][CH:0][VETERAN] - Hosted by Boogy

To indicate that the admin gives no guarantee whatsoever of when he is going to roll the update.

EDIT: I KNOW IT IS A FUCKING ALPHA. Fuck' date=' every time somebody tries to suggest something or make a criticism here people instantly jump down you throat shouting "ITS AN ALPHA DEAL WITH IT!"

[/quote']

I don't know if the OP works in the software industry, but he begins to describe a release/testing lifecycle

- that is way more realistic than any other suggestions or reactions I have seen so far

- that, if investigated a bit more, could be really better than the one that is currently used for DayZ

To to my mind, people disagreeing with him have completely failed to make point in the replies I've read so far. I don't say it's a perfect plan, and it is nearly not formal enough, but consider it as some serious food for thought. Rocket, team, any reactions ?

Thank you dude, it's been a while I haven't seen such a constructive post on these forums.

---

Oh, and one more thing : the only thing I really don't agree about the OP is the title.

"Slow down" ? Seriously ? IDK, but this kind of proposal, once refined by the dev team, could actually speed up development. At least that's what I experienced myself. By separating bugs and features a bit more, you can identify and classify bugs faster :

- regression caused by new feature

- regression caused by bugfix

- new bug added by new feature

- new bug added by new fix

The more your system gets complex, the more having this kind of information becomes vital to streamline your workflow.

Only just noticed this post; you went into way more depth than I could and seem to be on the same page.

Thanks for taking the time to write such an informative post.