Standalone Priorities - The Big One

[TEST_SUBJECT_83 465]

Stopped reading after this:

 

"Does anyone else feel as though the Dayz SA developers have their priorities way out of whack? I completely understand that this is an ALPHA - It's still just a fetus of a game - but my points are still valid."

 

You have no idea what is more important and needs attention first.

Edited March 20, 2014 by TEST_SUBJECT_83

[nautic 40]

Would you care to explain why?

 

Because there is no adding all features, and then fixing all bugs. You want ALL bugs be fixed, as soon as you take note of them. Because if you don't fix those 'broken windows' they become a burden, causing even more problems, dragging you down. If you got into this mentality, 'Ahhh, gash, i'll fix that later... like in beta .... because i have others things to do now!',  you just opened the hellgate to chaos. Regardless of pre-alpha, alpha, beta or stable: There should not be any postponing of bugfixing at any phase of development. Bugfixes should always be the highest priority at any time. While fixing Bugs, you might find serious errors in your code. If you'd built more and more code above this error, you are very likely of having a very hard time fixing it later. You might even end in adding a hotfix (which is not a satisfying solution) because you simply cant start all over again. If you happened to create a mess, you are unlikely to get out again.

 

Thus, when you develop software, professionally, you really really want to make sure that everything you add works as you intended it to. And you do this by creating automated Tests. Those tests tell you, at any time, if everything you made works as you intended it to. Sometimes you learn, that what you intended it to do, is not what it should be. And then you add more Tests, and change others, to refine it. When you add more features, or refactor you are likely to break things that worked before. And if you had no automated tests, who is gonna tell you? So in order to keep everything Stable, you really want these Tests.

Of course, looking at game development with all this 3d rendering, collision detection, network programming and stuff, things are not as trivial to test. In fact testing would be really hard. Imagine an end to end test, that had to load a map with two bots, one aiming at the other and shooting. Not an easy task. Yet, unit- and integration-tests should be straight forward.

 

So what i'm saying is this: If you'd follow these rules

 

Alpha=Adding all the features, fixing easy-to-fix bugs or game-breaking bugs(really game-breaking,like not bein able to respawn)

 

Beta=Fixing the resulting mess.

 

you're on the right track to create what i call a 'Software Nightmare'.

 

tldr: You don't defer bugs in a professional software development.

[rickyspanish 158]

Because there is no adding all features, and then fixing all bugs. You want ALL bugs be fixed, as soon as you take note of them. Because if you don't fix those 'broken windows' they become a burden, causing even more problems, dragging you down. If you got into this mentality, 'Ahhh, gash, i'll fix that later... like in beta .... because i have others things to do now!',  you just opened the hellgate to chaos. Regardless of pre-alpha, alpha, beta or stable: There should not be any postponing of bugfixing at any phase of development. Bugfixes should always be the highest priority at any time. While fixing Bugs, you might find serious errors in your code. If you'd built more and more code above this error, you are very likely of having a very hard time fixing it later. You might even end in adding a hotfix (which is not a satisfying solution) because you simply cant start all over again. If you happened to create a mess, you are unlikely to get out again.

 

Thus, when you develop software, professionally, you really really want to make sure that everything you add works as you intended it to. And you do this by creating automated Tests. Those tests tell you, at any time, if everything you made works as you intended it to. Sometimes you learn, that what you intended it to do, is not what it should be. And then you add more Tests, and change others, to refine it. When you add more features, or refactor you are likely to break things that worked before. And if you had no automated tests, who is gonna tell you? So in order to keep everything Stable, you really want these Tests.

Of course, looking at game development with all this 3d rendering, collision detection, network programming and stuff, things are not as trivial to test. In fact testing would be really hard. Imagine an end to end test, that had to load a map with two bots, one aiming at the other and shooting. Not an easy task. Yet, unit- and integration-tests should be straight forward.

 

So what i'm saying is this: If you'd follow these rules

 

 

you're on the right track to create what i call a 'Software Nightmare'.

 

tldr: You don't defer bugs in a professional software development.

 

I see where you're coming from I really do, in a perfect world that is probably the best way but when working to a deadline some things have to be fixed later because there is more important things to be doing such as adding the core features of the game. This doesn't mean by the way that no bugs will be fixed at all, but only priority bugs such as game breakers and serious performance issues. But some of the issues the OP talks about are not game breaking such as buggy sounds and hot key delay even if they are annoying, and can be put on hold while the developers work on getting all the features in before beta. Then when beta arrives the team can dedicate more time and more manpower on bug fixing rather than either splitting man power between bug fixing and features or concentrating on bug squashing alone in alpha and having zero game features/mechanics to show for your time (not a good way to impress the boss).

 

This also ties in with dean wanting to leave after alpha stage because his job will be done, and almost all the features will be implemented and all that will be left to do is bug fixing and performance stabilizing which is not his job. This also goes for the content creators who are making the items and weapons there job is not to fix bugs but to create content, so new hats and weapons will come regardless of bug fixing.

 

I don't know alot about software development to be honest but I'm sure bohemia, a very successful development company who have released 18 products do.   

 

Oh and I don't think zombie related bugs are really bugs because they are technically a work in progress feature.

 

Alpha is the stage after which all the foundations of the design are layed down and the key features are completed. At this stage the game should look like a basic form of it's finished product. Alpha is used as a base to work and implement improvements to during the next stage.

Beta is the second major milestone in development. During the Beta testing bugs/glitches are corrected and the code should be completed. There should be no more changes at Beta stage to the key elements of the game, as the game should be near finalisation at this point.

Gold Master stage is the complete game, and should contain no bugs, and the game should ideally be ready for manufacturing.

Edited March 21, 2014 by Ricky Spanish

[Pilgram 0]

Completely agree with Nautic, you don’t add variables on top of a problem that will make it much much more difficult to nail down later on; troubleshooting 101.  You will end up chasing your tail for ages on a problem that could have been corrected early on with relative ease.  The fact is you compound the problem with a variety of code errors that could be influencing what you are working on.  Create, test, fix, test – repeat.

 

Also, Beta is for fixing the bugs that you find during “Beta Testing”.  Alas the venerable bug hunters on their righteous quest to find the one spot in the game where you fall through the world. 

 

To Leo Balzac, your construction analogy is a bit off.  This is more like you have a cracked foundation, but continue to put up the building anyway saying you will get to it later.