Developer Appreciation

[Knight_Solaire 4]

Why fill your plate up with so much new content when there are several fixes that the entire team needs to just fix instead of adding in broken content. 

nearly 99.9% of the content, animations, loot etc are broken..Lets use the Zombies for example...........!!!!......

Go away troll. No beans for you.

[Dothrakii 2]

Go away troll. No beans for you.

What? Troll?

You have been reported

[kichilron 8550]

What? Troll?

You have been reported

 

Even though your report didn't really tell us anything, I will just answer your question you posted in this thread.

 

 

Why fill your plate up with so much new content when there are several fixes that the entire team needs to just fix instead of adding in broken content. 

nearly 99.9% of the content, animations, loot etc are broken..Lets use the Zombies for example...........!!!!......

 

Because that's not how you develop games. That way you end up with twice to thrice the workload, realistically.

 

It would look like this:

1. Add stuff
2. Fix stuff
3. Add stuff
4. Fix stuff

 

That's atleast double the workload, realistically three times the time needed for development.

 

This would be a concept you'd have understood by now if you'd read atleast a little bit of the Forum by now.

[kichilron 8550]

Just a quick information:

 

Multi-Account because you been banned before won't help your argument....

Edited June 24, 2015 by kichilron

[tux (DayZ) 325]

We are heading to 3rd quarter soon, based on the roadmap, which of them have been achieved? like 1? 

 

From Hicks via the /r/dayz subreddit:

 

The 4 Quarters layout of the roadmap is less a set in stone schedule, and more a layout of the path we intend to take. Think of it like setting up where you want to go on a road trip. You know where you want to go, and how much time you want to spend at each place - but small things come up here and there. That said, I'm still confident the initial implementations of everything should fall within the year - if not some things shuffled between quarters.

 

And why do you feel the need to change your text color?

Edited June 25, 2015 by tux

[hellcat420 212]

Ok, we clearly will not come to some sort of agreement on this.

That is because you have no clue what you are talking about? What you are saying is the equivalent of doing a full frame off restoration on a classic car and painting it before you do any bodywork or tearing the car down.

[scriptfactory 620]

Because that's not how you develop games. That way you end up with twice to thrice the workload, realistically.

 

It would look like this:

1. Add stuff
2. Fix stuff
3. Add stuff
4. Fix stuff

 

That's atleast double the workload, realistically three times the time needed for development.

 

In my experience the longer a bug goes unfixed the costlier it is to repair. I have my developers fix bugs as soon as they show up (within reason) and immediately write unit tests to (hopefully) make sure that they won't ever surface again.

 

Case in point is that ghost sound that has been in the game for forever (it's even in Arma). If the developers had taken care of this bug as soon as it appeared it is much more likely that it would have been a relatively easy fix. They would know when the bug was introduced and could make an educated guess as to what caused the problem.

[doctorbadsign 645]

What? Sooo devs took my money, and you want to say that we should cheer them for their descisions? Thank you, but no. Money is their motivation.

They are moving in a wrong diriction, I'm not saying I can do a better game, but it seems to me that they don't know how to prioritize stuff. Performance -1, all other stuff should be less important. 

Who the hell in one's senses, would think "hmm, growing cabbages and tomatoes should be a thing in a zombie survival game".

 

Christ Almighty! Just because they add stuff like farming or new items doesn't mean they aren't working on performance issues!

 

There is more than one person there you know. If you had been paying attention to performance you would note a steady increase over time, not immense but it is there. The people who create models and textures are not likely to have the ability to work on performance issues, nor are all of the coding team. Different people have different specializations. Because it is easier to create items etc. We see more of them than we see performance increases, but it doesn't mean performance is not being prioritized.

[evil11 7]

That is because you have no clue what you are talking about? What you are saying is the equivalent of doing a full frame off restoration on a classic car and painting it before you do any bodywork or tearing the car down.

Oh another game dev expert. Go on kid tell me that firt you add stuff and then you fix it.

[BleedoutBill 1636]

In my experience the longer a bug goes unfixed the costlier it is to repair. I have my developers fix bugs as soon as they show up (within reason) and immediately write unit tests to (hopefully) make sure that they won't ever surface again.

 

Case in point is that ghost sound that has been in the game for forever (it's even in Arma). If the developers had taken care of this bug as soon as it appeared it is much more likely that it would have been a relatively easy fix. They would know when the bug was introduced and could make an educated guess as to what caused the problem.

Perfect example! Yes, the ghost sounds are annoying as hell and I'm sure that everyone will wholeheartedly agree. But, why fix the ghost sounds, when the legacy audio module is going to be completely replaced? That "sounds" (no pun intended) like a colossal waste of time to me.

 

While everyone (testers and players, alike) have been wringing their hands and complaining about the introduction of new weapons and clothing, in lieu of improvements to the core game, the devs have been busy breaking the game engine into individual modules and writing completely new modules which will replace the legacy code. We are getting a new renderer, new audio module, new loot economy, conversion to a more efficient scripting language, new NPC character controller, new player character controller, new NPC AI, new 64-bit server code and they have also even written a new 64-bit client, etc., etc., etc.

 

When you click on "I Understand" and fire up the game, there may not be anything that you can touch, or feel that will demonstrate just how new everything is under the hood, but that doesn't change the fact that an absolutely stupid amount of programming man hours was required to get us to where we are today and all of it (and more) is essential to get us to where we need to go. 

 

The devs are not doing what you would necessarily expect, because this is not a typical project. We have had access to a working game concept, as well as actual developer builds, long before this is typically customary. A lot of demolition will still have to occur, before the game can be rebuilt on a more sturdy and appropriate foundation. All the while, the devs have gone to great lengths to ensure that the developer builds remain reasonably playable.

 

Having said that, it is obvious that the devs do share some things in common with you. As long as I can remember, they have always been very aggressive with any bug that causes either a server, or a client crash. They have also been steadily addressing issues with any new modules which are introduced. Quite a lot of work has gone into sorting out the CLE, for example. They have no intention of spending any significant time polishing a turd, however if that particular turd will eventually be replaced, so long as the turd in question is not causing any major game breaking issues, A.K.A. server/client crashes.

[Accolyte 1727]

In my experience the longer a bug goes unfixed the costlier it is to repair. 

 

From my experience I agree with very little (if anything) from that post.

 

1. Unfixed bugs camouflage other bugs

How many times have you heard a tester say, “Good news, I’ve re-tested the bug you fixed and it’s working perfectly, but I’m now observing a new bug”? 

 

Also known as "Fixing the bug broke something else!" rather than another bug being camouflaged. Which is the one reason why you don't fix things before everything is in the game (as everyone keeps repeating) and which pretty much invalidates the rest of the article. Except maybe point 4, which never happens as long as you make sure bug report standards are upheld. 

Edited June 25, 2015 by Accolyte

[Bororm 1156]

From my experience I agree with very little (if anything) from that post.

 

1. Unfixed bugs camouflage other bugs

How many times have you heard a tester say, “Good news, I’ve re-tested the bug you fixed and it’s working perfectly, but I’m now observing a new bug”? 

 

Also known as "Fixing the bug broke something else!" rather than another bug being camouflaged. Which is the one reason why you don't fix things before everything is in the game (as everyone keeps repeating) and which pretty much invalidates the rest of the article. Except maybe point 4, which never happens as long as you make sure bug report standards are upheld. 

 

I think #2 and #3 are pretty valid.

[Accolyte 1727]

I think #2 and #3 are pretty valid.

 

They're not. #3 is the same thing again, yes, it would be nice to fix bugs as soon as they're noticed without anything else getting screwed up, but that just happens and it's not anyone's fault. Well it's not really. 

 

Which touches on #2. It's simply not possible to write flawless code 100% of the time. Even I, with my testing experience, cannot foresee every possible interaction and debug it immediately after/while implementing code (though I do a very good job of it nonetheless of course <_< ). And professional testers and developers understand this and therefore don't get upset if their features are reported as bugged/bugs aren't getting fixed.

[scriptfactory 620]

Also known as "Fixing the bug broke something else!" rather than another bug being camouflaged. Which is the one reason why you don't fix things before everything is in the game (as everyone keeps repeating) and which pretty much invalidates the rest of the article.

 

A bug is simply an unexpected result from software. If you do not fix your bug eventually other code becomes dependant on the buggy code.

Imagine it like this:

1. Function A makes calculations but has some rounding errors. It uses Math.floor() instead of Math.round() or something. Not the worst bug.
2. Function B is also dependant on function A. It always expects a rounded number.
3. Function C is also dependant on function A. It always expects a floored number because that is what function A is currently returning.

What happens when you change the result of function A to correctly return a rounded long? Function C now is returning incorrect results. This is just one way to bugs can hide other bugs.

 

 

It's simply not possible to write flawless code 100% of the time. Even I, with my testing experience, cannot foresee every possible interaction and debug it immediately after/while implementing code (though I do a very good job of it nonetheless of course <_< ). And professional testers and developers understand this and therefore don't get upset if their features are reported as bugged/bugs aren't getting fixed.

 

Professional developers have QA as a part of the development process. If a bug is found we add unit/integration tests to make sure the code is working as expected. TDD helps out a lot with this as well.

Edited June 25, 2015 by scriptfactory

[Accolyte 1727]

A bug is simply an unexpected result from software. If you do not fix your bug eventually other code becomes dependant on the buggy code.

 

 

Aye, but at some point you have to draw a line between development and bugfixing, otherwise you get stuck in an endless loop and no actual progress towards the final product is made. If you have a error in the code as deep as you describe, then it's a fairly critical issue that does indeed need to be fixed. This does not apply to every single bug however. Sometimes bugs are ignored as they are deemed non-critical to gameplay to conserve time and effort as I'm sure you know.

 

 

Professional developers have QA as a part of the development process. If a bug is found we add unit/integration tests to make sure the code is working as expected. TDD helps out a lot with this as well.

 

I know quite well how professional developers and QA work. I'm sure all public (and likely internal as well) builds of DayZ go through a sanity check that ensures basic functionality and stability. Again, you cannot add every single bug you've discovered to the basic functionality test case as with a game like DayZ we're talking about thousands/tens of thousands bugs. And even then a the sanity check cannot guarantee 100% stability as that can be dependant on hardware and the different nature of public environment. 

Edited June 25, 2015 by Accolyte

[scriptfactory 620]

 

Why fill your plate up with so much new content when there are several fixes that the entire team needs to just fix instead of adding in broken content. nearly 99.9% of the content, animations, loot etc are broken..Lets use the Zombies for example...........!!!!......

 

Just as a re-cap, I believe my original statement stands. The longer it takes to fix a bug the costlier that fix will be (in terms of developer time and actual money). In my experience I have found this to be true.

 

Aye, but at some point you have to draw a line between development and bugfixing, otherwise you get stuck in an endless loop and no actual progress towards the final product is made.

 

...

 

This does not apply to every single bug however. Sometimes bugs are ignored as they are deemed non-critical to gameplay to conserve time and effort as I'm sure you know.

 

I agree with this. I think our difference of opinion comes down to what should be deemed critical and what not.

[kichilron 8550]

Both sides have somewhat valid points, but this is not what the topic at hand is, I'm afraid.

 

I'm not even sure if the topic even has a reason to exist any more..

[Accolyte 1727]

I think our difference of opinion comes down to what should be deemed critical and what not.

 

It's not really a matter of opinion. A critical issue is an issue that creates a scenario where the game becomes unplayable, as in crashing, freezing, etc or potentially features not working at all. Zombie AI/animation or whatnot being poor at the moment may be a fairly big concern, but it's not a critical issue from development standpoint.

 

 

Both sides have somewhat valid points, but this is not what the topic at hand is, I'm afraid.

 

I'm not even sure if the topic even has a reason to exist any more..

 

Agreed. Don't think it ever actually was about developer appreciation anyway  :thumbsup:

Edited June 25, 2015 by Accolyte

[schwaBAM 200]

It seems that the devs only get to see the negative stuff on these forums.  There are quite a few people out there that I know that appreciate the direction of the game and the commitment of the devs (and I don't know many people mind you).  Thanks for all that you do!

Edited June 25, 2015 by schwaBAM

[kichilron 8550]

It seems that the devs only get to see the negative stuff on these forums.  There are quite a few people out there that I know that appreciate the direction of the game and the commitment of the devs (and I don't know many people mind you).  Thanks for all that you do!

 

 

I am sure the devteam knows that there are still a lot of people out there that enjoy the game. As with any product there's the very vocal minority of about 2-5% that may ruin the experience for everyone else.

 

If you're happy with a product, you're not likely to talk about it or even go out of your way to praise the team behind it. And that's fine. I'm sure we're all the same to a degree.

[DocWolf 146]

It's not really a matter of opinion. A critical issue is an issue that creates a scenario where the game becomes unplayable, as in crashing, freezing, etc or potentially features not working at all. Zombie AI/animation or whatnot being poor at the moment may be a fairly big concern, but it's not a critical issue from development standpoint.

That's a pretty good statement in theory. But sadly DayZ (like every other software around on the market) cannot be defined only by the developer point of view. The moment they decided to go public with the game marked the point from wich the "developer point of view" have to be integrated with the "customer point of view": DayZ in not in a closed alpha, it's an early access: a product of a closed/private company that decided to put it on the market.

 

With a disclaimer of course, but that counts only if you're an intelligent customer, and a lot of people don't go full logic when they have to decide if a product/service/whatever is good or not...there are bookstores of marketing tomes on that. Everything you do (and everything you don't do) in an early access game is visible to your current and future customer base and you should thread very, very, VERY carefully every time you write down what kind of features you want to introduce in the next patch or what kind of bugs are defined "non critical". Because everything stops being just "development" and becomes "development AND marketing"

 

Using your example: the infected AI is not a critical issue? If we're talking about DayZ closed alpha you're right, no one knows that apart from those directly involved in the development of the game and such a problem can be solved later. But in DayZ early access? It's a mind boggling problem because now everyone knows that your zombie game have pretty sub-par zombies and you don't fix it because it's not really a priority. Not only the early access players suddendly know that, but also people who don't play, the press, the web, everyone. Marketing, my friend. The moment you go public is all about marketing, PR and community management - not only technical milestones and deadlines.

Edited June 25, 2015 by DocWolf

[Bororm 1156]

They're not. #3 is the same thing again, yes, it would be nice to fix bugs as soon as they're noticed without anything else getting screwed up, but that just happens and it's not anyone's fault. Well it's not really. 

 

Which touches on #2. It's simply not possible to write flawless code 100% of the time. Even I, with my testing experience, cannot foresee every possible interaction and debug it immediately after/while implementing code (though I do a very good job of it nonetheless of course <_< ). And professional testers and developers understand this and therefore don't get upset if their features are reported as bugged/bugs aren't getting fixed.

 

They are, because I can say from first hand experience that I don't report every bug I find because it seems pointless to do so.  Because they likely won't be addressed, or already have been reported numerous times to no result.

 

And the fact that you're here (and we've all seen the devs do it too) defending some of these bugs, is #3.  Wasting time going over things again and again.

 

Regardless of if there's valid reasons to let those bugs persist for now, it can't be true of every single one of them and it does eat up time and it does make people jaded.  So yes, they are valid.

Edited June 25, 2015 by Bororm

[gcriseightysix 32]

Is there some way we can show the dev team some appreciation?

In this update, these guys seem to be working extra hard. If you just look at the time stamps on the exp. .57 tweets these people are working until the wee hours of the morning and/or starting at the butt crack of dawn. Now this is just what I've noticed, but I'm sure they have been working this way for some time now. And all over the forums is negative crap. I don't think that all the good work is appreciated, but expected. I know how it is to work like that, and it does make the passion for your work waiver. As for a long project like this, the team behind it needs to love it and the people that intend to use it.

Love the Dev team for what they've done, but I'm thinking over 3 million early access copies sold is thanks enough haha

[Senodog 96]

Give 'em a cookie

[Accolyte 1727]

That's a pretty good statement in theory. But sadly DayZ (like every other software around on the market) cannot be defined only by the developer point of view. The moment they decided to go public with the game marked the point from wich the "developer point of view" have to be integrated with the "customer point of view"

 

Perhaps, that's a bit different discussion however. The main point is that you can't really change the way games are developed especially with a relatively small company like BIS. They were always saying that the game is very rough around the edges and you shouldn't buy it unless you want to be 

 

directly involved in the development of the game

 

 

 

They are, because I can say from first hand experience that I don't report every bug I find because it seems pointless to do so.  Because they likely won't be addressed, or already have been reported numerous times to no result.

 

I don't really understand your point. Either way, the article talks about professional testers and developers. Professional testers report even the tiniest bugs as long as they haven't been reported before (at which point you are right not to report them too). Whether or not they're being fixed is the matter of priorities and severity of the bug as I said before.