https://dayz.com/blog/status-report-13-sept-2016

" Nous nous rapprochons de la 0.61 expérimental blablabla, on copie / colle des trucs que l'on a mis dans les précédent SR et hop vous en avez un nouveau ! "

Le pire c'est que j'ai vraiment regardé la date pour m'assurer que c'était bien celui d'aujourd'hui.

Je crois qu'ils parlent de nouveaux spawn dans les terres mais je suis pas sur

Bref c'est Dayz. Vous attendez pas à un truc de dingue je vien de regarder une vidéo de 45 min sur Tanoa en mode zombie, craft de base etc......................

DayZ 500 ans de retard.

On l'aura jamais le jeu, faut pas compter sur le modding. Je vais créer un poste à l'occasion pour transmettre mes pensées perso sur ce sujet brulant

C'est très maigre tout ça, heureusement ils ont rajouté quelques trucs sympas sur le trello: https://trello.com/b/5yzeFpo2/dayz . J'aime beaucoup la maison avec le lierre.

cool, avant ils disaient que les loups seraient sûrement reportés d'une maj, maintenant ils disent être plutôt optimiste quant à pouvoir les tester dans les premières maj expé de la 61.

Des nouveaux mobs à tuer, plus rapide que des zeds, curieux de tester ça (mais ca va être buggé, c'est sûr )

Bien plus intéressant que ce SR, voici la réponse d'Eugen Harton à un commentaire sur reddit (plutôt que de mettre le lien je copie-colle le tout car il semblerait que Brian Hicks veuille faire supprimer le message):

]dstar2002 16 points il y a 4 heures*

I am beginning to question the development architecture style of this game. As an Alpha, there is no expectation that you have to publish "stable" (production) code. But, we know the desire is to push code to experimental -> stable.
Now, I could see going months without a stable build, but going months without an experimental build is telling me that there is a serious problem between different tasks being merged into master. The projects architecture, which should be designed by senior development leaders, appears to have hit a stumbling point where adding new code to master continues to bring up more branch destroying bugs.
This is concerning long term. While they dont need to have experimental/stable builds as an Alpha, not being able to produce experimental builds to us outside of internal testing is very worrisome at this point.
This isnt a Brian Hicks issue, or the programming team overall, so go easy on them guys. Something is fundamentally wrong in the code base that continues to break, and short of re-writing a very large majority of the game, they will never get around it. Bohemia, it might be time to get some experienced senior developers to assume the project leadership role. Your reputation is starting to get a nasty hit, and if it doesnt stop soon, you might hit a point of no return with this game. Which would suck.
[–]eugenhartonLead Producer 33 points il y a 2 heures
There is a fundamental difference in how you view the subject and what is the underlying problem. But again its a hard one to understand without all the information. And putting that information out there costs a lot of time and causes giant overhead where people need to be focusing on the project.
We have a strong team with people that have 10s of years of experience. (and it has been that way for most of the timeline on the project, except early start) and unless I`m mistaken were hovering around 80-90 depending on how you count external sources. Which is a huge two site team for a company of this size. Yes were not GTA and cannot have hundreds of developers here in czech republic/slovak republic. The growth and numbers of people create overhead that would not come with faster development.
So here is how our process works.
Internal branch (code)
Internal branch (data)
Internal client repository
Internal server repository
Internal srvlet repository (backend)
Stable branch (code)
Stable branch (data)
Stable client repository
Stable server repository
Stable Srvlet repository (backend)
Tools repository
Console repository
Build pipeline with automation that covers pipelines for all branches and systems
-uploading builds to steam cdn
-buildings pbos
-navmesh generation
-building binaries
-building tools
and much more
Some jobs can be requested, some are automated, some are done during night. The time on the jobs varies greatly. Some are more time consuming, some less. With multiple slave to soften the time contrain and load. (you still have to understand that building a single version of executables takes 30-45 minutes (server,server64,tools,client,client64, and more)
The documentation process is covered by atlassian package of products for the most part. So we use confluence for documentation. Jira for tasking. So both sites (bratislava and prague) are in sync. There are rules for commit logs, documentation, meeting notes, daily reports on crashes, daily reports on build state and more.
We have a daily scrum for cross site cooperation and where we talk about what we have done day before and what is on plan that day. Each team (animators,designers,production,QA,engine,gameplay) is represented by a lead that covers organization within the team itself. All guys in the team are amazing with tons of experience and I believe in what all of us here do.
QA is going through couple builds daily (QA lead with two senior guys and testers (20-40 depending on the day) finding repro on bugs, reporting them to Jira, and using proper tags and labels to sort them in categories and pass them onto leads for respective parts of gameplay/engine etc. Leads distribute the tasks for team members and consult on daily progress.
When we branch and RC we shift a big part of the focus on getting it out.
However and here is something you have to understand. The development is flat and it has a good reason, without having base technology in the game (because its being worked on for better part of three years). You cannot have feature teams working on single feature, because the dependencies are far and wide and interconnected. There are base engine modules gettings changed and they are sometimes built with backwards compatibility in mind (when we can, and it can be separated, like sound engine), and sometimes they are part of bigger chunk of engine, because they cannot have the backward compatibility with modules of old engine. And as such can be merged into internal only when all of them are done. Sometimes they are running in tandem with old stuff while we test them.
So you have giant number of variables that change how the game behaves and tons of developer switches to test in the intermittent states of different parts of game. Lot of the work because of how time consuming engine development is, is done before the modules are ready because it would take insane amount of time if we would wait. All that while we change core tech, architecture etc.
All of that is quite complicated when you look how early the early access was in hands of the consumer base. With the success came goals to make the game much more up to todays standards. And I believe we can deliver. I can`t show you how far we are yet, because things are always in flux and we want to avoid making anymore promises. Because missing deadlines is never fun and even you are angry at us, we are even more.
Because of how games are made, and there is lack of understanding of the process, people never see how broken things can get, even looking at other games that are in early access not a lot of them are going through what we are so its really hard to find a good comparison. Most of these things that we do now, happen behind closed doors of large studios. And open betas/open alphas that get into publics hands are either on stable technology or they are not alphas/betas at all. Just a finished game thats underoging public testing.
The technology backlog to get game into this century was huge and were getting the snowball effect going. The technology debt is no small part of it. So I`m sitting here reading all these comments after spending 11 hours at work today trying to get a good set of features with the guys out while we march towards the release of beta/1.0 with all the people here. Its so hard to explain all this without going into too much detail/not revealing new stuff. But please know that we are not going anywhere, were going to finish this game and deliver what makes the DayZ we love so great.

Le 14 septembre 2016 à 00:34:47 Gadget_97 a écrit :
Bien plus intéressant que ce SR, voici la réponse d'Eugen Harton à un commentaire sur reddit (plutôt que de mettre le lien je copie-colle le tout car il semblerait que Brian Hicks veuille faire supprimer le message):

]dstar2002 16 points il y a 4 heures*

I am beginning to question the development architecture style of this game. As an Alpha, there is no expectation that you have to publish "stable" (production) code. But, we know the desire is to push code to experimental -> stable.
Now, I could see going months without a stable build, but going months without an experimental build is telling me that there is a serious problem between different tasks being merged into master. The projects architecture, which should be designed by senior development leaders, appears to have hit a stumbling point where adding new code to master continues to bring up more branch destroying bugs.
This is concerning long term. While they dont need to have experimental/stable builds as an Alpha, not being able to produce experimental builds to us outside of internal testing is very worrisome at this point.
This isnt a Brian Hicks issue, or the programming team overall, so go easy on them guys. Something is fundamentally wrong in the code base that continues to break, and short of re-writing a very large majority of the game, they will never get around it. Bohemia, it might be time to get some experienced senior developers to assume the project leadership role. Your reputation is starting to get a nasty hit, and if it doesnt stop soon, you might hit a point of no return with this game. Which would suck.
[–]eugenhartonLead Producer 33 points il y a 2 heures
There is a fundamental difference in how you view the subject and what is the underlying problem. But again its a hard one to understand without all the information. And putting that information out there costs a lot of time and causes giant overhead where people need to be focusing on the project.
We have a strong team with people that have 10s of years of experience. (and it has been that way for most of the timeline on the project, except early start) and unless I`m mistaken were hovering around 80-90 depending on how you count external sources. Which is a huge two site team for a company of this size. Yes were not GTA and cannot have hundreds of developers here in czech republic/slovak republic. The growth and numbers of people create overhead that would not come with faster development.
So here is how our process works.
Internal branch (code)
Internal branch (data)
Internal client repository
Internal server repository
Internal srvlet repository (backend)
Stable branch (code)
Stable branch (data)
Stable client repository
Stable server repository
Stable Srvlet repository (backend)
Tools repository
Console repository
Build pipeline with automation that covers pipelines for all branches and systems
-uploading builds to steam cdn
-buildings pbos
-navmesh generation
-building binaries
-building tools
and much more
Some jobs can be requested, some are automated, some are done during night. The time on the jobs varies greatly. Some are more time consuming, some less. With multiple slave to soften the time contrain and load. (you still have to understand that building a single version of executables takes 30-45 minutes (server,server64,tools,client,client64, and more)
The documentation process is covered by atlassian package of products for the most part. So we use confluence for documentation. Jira for tasking. So both sites (bratislava and prague) are in sync. There are rules for commit logs, documentation, meeting notes, daily reports on crashes, daily reports on build state and more.
We have a daily scrum for cross site cooperation and where we talk about what we have done day before and what is on plan that day. Each team (animators,designers,production,QA,engine,gameplay) is represented by a lead that covers organization within the team itself. All guys in the team are amazing with tons of experience and I believe in what all of us here do.
QA is going through couple builds daily (QA lead with two senior guys and testers (20-40 depending on the day) finding repro on bugs, reporting them to Jira, and using proper tags and labels to sort them in categories and pass them onto leads for respective parts of gameplay/engine etc. Leads distribute the tasks for team members and consult on daily progress.
When we branch and RC we shift a big part of the focus on getting it out.
However and here is something you have to understand. The development is flat and it has a good reason, without having base technology in the game (because its being worked on for better part of three years). You cannot have feature teams working on single feature, because the dependencies are far and wide and interconnected. There are base engine modules gettings changed and they are sometimes built with backwards compatibility in mind (when we can, and it can be separated, like sound engine), and sometimes they are part of bigger chunk of engine, because they cannot have the backward compatibility with modules of old engine. And as such can be merged into internal only when all of them are done. Sometimes they are running in tandem with old stuff while we test them.
So you have giant number of variables that change how the game behaves and tons of developer switches to test in the intermittent states of different parts of game. Lot of the work because of how time consuming engine development is, is done before the modules are ready because it would take insane amount of time if we would wait. All that while we change core tech, architecture etc.
All of that is quite complicated when you look how early the early access was in hands of the consumer base. With the success came goals to make the game much more up to todays standards. And I believe we can deliver. I can`t show you how far we are yet, because things are always in flux and we want to avoid making anymore promises. Because missing deadlines is never fun and even you are angry at us, we are even more.
Because of how games are made, and there is lack of understanding of the process, people never see how broken things can get, even looking at other games that are in early access not a lot of them are going through what we are so its really hard to find a good comparison. Most of these things that we do now, happen behind closed doors of large studios. And open betas/open alphas that get into publics hands are either on stable technology or they are not alphas/betas at all. Just a finished game thats underoging public testing.
The technology backlog to get game into this century was huge and were getting the snowball effect going. The technology debt is no small part of it. So I`m sitting here reading all these comments after spending 11 hours at work today trying to get a good set of features with the guys out while we march towards the release of beta/1.0 with all the people here. Its so hard to explain all this without going into too much detail/not revealing new stuff. But please know that we are not going anywhere, were going to finish this game and deliver what makes the DayZ we love so great.

Hrum.
Ok.
Quelqu'un le traduit ? Car certains, pardon BEAUCOUP, ont besoin de le lire et le comprendre.

Rajouter du contenu sur un jeu tout pété ?

C'est pas demain qu'on va pouvoir revivre de bons moments entre Stalkers

Le 14 septembre 2016 à 02:10:39 Grinchieur a écrit :

Le 14 septembre 2016 à 00:34:47 Gadget_97 a écrit :
Bien plus intéressant que ce SR, voici la réponse d'Eugen Harton à un commentaire sur reddit (plutôt que de mettre le lien je copie-colle le tout car il semblerait que Brian Hicks veuille faire supprimer le message):

]dstar2002 16 points il y a 4 heures*

I am beginning to question the development architecture style of this game. As an Alpha, there is no expectation that you have to publish "stable" (production) code. But, we know the desire is to push code to experimental -> stable.
Now, I could see going months without a stable build, but going months without an experimental build is telling me that there is a serious problem between different tasks being merged into master. The projects architecture, which should be designed by senior development leaders, appears to have hit a stumbling point where adding new code to master continues to bring up more branch destroying bugs.
This is concerning long term. While they dont need to have experimental/stable builds as an Alpha, not being able to produce experimental builds to us outside of internal testing is very worrisome at this point.
This isnt a Brian Hicks issue, or the programming team overall, so go easy on them guys. Something is fundamentally wrong in the code base that continues to break, and short of re-writing a very large majority of the game, they will never get around it. Bohemia, it might be time to get some experienced senior developers to assume the project leadership role. Your reputation is starting to get a nasty hit, and if it doesnt stop soon, you might hit a point of no return with this game. Which would suck.
[–]eugenhartonLead Producer 33 points il y a 2 heures
There is a fundamental difference in how you view the subject and what is the underlying problem. But again its a hard one to understand without all the information. And putting that information out there costs a lot of time and causes giant overhead where people need to be focusing on the project.
We have a strong team with people that have 10s of years of experience. (and it has been that way for most of the timeline on the project, except early start) and unless I`m mistaken were hovering around 80-90 depending on how you count external sources. Which is a huge two site team for a company of this size. Yes were not GTA and cannot have hundreds of developers here in czech republic/slovak republic. The growth and numbers of people create overhead that would not come with faster development.
So here is how our process works.
Internal branch (code)
Internal branch (data)
Internal client repository
Internal server repository
Internal srvlet repository (backend)
Stable branch (code)
Stable branch (data)
Stable client repository
Stable server repository
Stable Srvlet repository (backend)
Tools repository
Console repository
Build pipeline with automation that covers pipelines for all branches and systems
-uploading builds to steam cdn
-buildings pbos
-navmesh generation
-building binaries
-building tools
and much more
Some jobs can be requested, some are automated, some are done during night. The time on the jobs varies greatly. Some are more time consuming, some less. With multiple slave to soften the time contrain and load. (you still have to understand that building a single version of executables takes 30-45 minutes (server,server64,tools,client,client64, and more)
The documentation process is covered by atlassian package of products for the most part. So we use confluence for documentation. Jira for tasking. So both sites (bratislava and prague) are in sync. There are rules for commit logs, documentation, meeting notes, daily reports on crashes, daily reports on build state and more.
We have a daily scrum for cross site cooperation and where we talk about what we have done day before and what is on plan that day. Each team (animators,designers,production,QA,engine,gameplay) is represented by a lead that covers organization within the team itself. All guys in the team are amazing with tons of experience and I believe in what all of us here do.
QA is going through couple builds daily (QA lead with two senior guys and testers (20-40 depending on the day) finding repro on bugs, reporting them to Jira, and using proper tags and labels to sort them in categories and pass them onto leads for respective parts of gameplay/engine etc. Leads distribute the tasks for team members and consult on daily progress.
When we branch and RC we shift a big part of the focus on getting it out.
However and here is something you have to understand. The development is flat and it has a good reason, without having base technology in the game (because its being worked on for better part of three years). You cannot have feature teams working on single feature, because the dependencies are far and wide and interconnected. There are base engine modules gettings changed and they are sometimes built with backwards compatibility in mind (when we can, and it can be separated, like sound engine), and sometimes they are part of bigger chunk of engine, because they cannot have the backward compatibility with modules of old engine. And as such can be merged into internal only when all of them are done. Sometimes they are running in tandem with old stuff while we test them.
So you have giant number of variables that change how the game behaves and tons of developer switches to test in the intermittent states of different parts of game. Lot of the work because of how time consuming engine development is, is done before the modules are ready because it would take insane amount of time if we would wait. All that while we change core tech, architecture etc.
All of that is quite complicated when you look how early the early access was in hands of the consumer base. With the success came goals to make the game much more up to todays standards. And I believe we can deliver. I can`t show you how far we are yet, because things are always in flux and we want to avoid making anymore promises. Because missing deadlines is never fun and even you are angry at us, we are even more.
Because of how games are made, and there is lack of understanding of the process, people never see how broken things can get, even looking at other games that are in early access not a lot of them are going through what we are so its really hard to find a good comparison. Most of these things that we do now, happen behind closed doors of large studios. And open betas/open alphas that get into publics hands are either on stable technology or they are not alphas/betas at all. Just a finished game thats underoging public testing.
The technology backlog to get game into this century was huge and were getting the snowball effect going. The technology debt is no small part of it. So I`m sitting here reading all these comments after spending 11 hours at work today trying to get a good set of features with the guys out while we march towards the release of beta/1.0 with all the people here. Its so hard to explain all this without going into too much detail/not revealing new stuff. But please know that we are not going anywhere, were going to finish this game and deliver what makes the DayZ we love so great.

Hrum.
Ok.
Quelqu'un le traduit ? Car certains, pardon BEAUCOUP, ont besoin de le lire et le comprendre.

Si j'ai bien compris; le premier dit que bohémia est mal organisé et qu'il devrait laisser l'organisation du travail a des gens qui ont plus d'expérience.
Ensuite Eugène lui répond que justement, les gens dans l'équipe ont plus de 10ans d'expérience. Que leur équipe n'est pas aussi grosse que celle de rockstar.
Ensuite il évoque de phases de production, que ça prends du temps 0 développer.
Pour finir il explique que s'ils n'annoncent plus de dates, c'est qu'ils savent qu'ils ne pourront pas les respecter. Qu'ils font de leur mieux, et qu'ils sont fatigués de pas réussir a ajouter du contenu plus vite.
Il en a aussi marre qu'on leur reproche que le jeu n'avance pas alors que d'autres EA sont dans un état similaire.
C'est ce que j'ai compris, donc Bref: infos a rectifier/ajouter

Je pourrais pas le traduire celui-là sorry

Trad complète SVP. Aller demismurf un petit "gros" effort STP.

Le 14 septembre 2016 à 13:08:12 Demi-smurf a écrit :
Je pourrais pas le traduire celui-là sorry

Je comprends l'anglais, si tu veux je peux aider

Le 14 septembre 2016 à 16:58:04 Frolon44 a écrit :
Trad complète SVP. Aller demismurf un petit "gros" effort STP.

Si personne ne l'a fait je m'en occupe vendredi mais je ne peux pas avant sorry.

Ca dit:

Le Gars:
Lol vous vous touchez la nouille avec les milliards que vous avez eu grâce a Dayz SA mdr.

Le Dèvs:
Oué mais non bro nous on fait ca puis ca puis ca puis ca puis ca, donc ca prend du temps et puis si on va trop vite on risque de mouillé le PC avec l'eau du Jaccuzi !

J'ai bon ?

Première partie le post du détracteur. Assez agressif et des présomptions sur comment leur équipe est organisée et des conseils sur comment ils devraient s'organiser.

Deuxième partie la réponse d'Harton :
Des justifications et des propos rassurants sur l’organisation mais le projet semble clairement difficile (il le cache pas).
Il explique leur tendance à moins communiquer car ils arrivent plus à tenir leur prédictions.
Il a la béta 1.0 clairement comme objectif. Toujours positif et serein et il explique qu'ils sont pas forcément lents comparés aux autres dévs, on sait rien de ce qu'il se passe dans les autres studios (à prendre avec des pincettes).

Pour ma part je mis fie aux faits uniquement, indépendamment de leur com :
14 septembre 2016, toujours pas de 0.61 et le SR est bien faible.
Ce n'est toujours pas de bon augure pour la suite.
Selon l'état de la 0.61 qui va arriver en fin d'année jspr, on pourra se faire une idée plus précise de la faisabilité du projet. (à ce stade c'est pas fou d'imaginer qu'ils y arriveront tout simplement pas).

Moué du coup je viens d acheter arma 2 pour partir sur le mod. Raz le cul d attendre le standelone. Ca avance pas, on recule meme sur certains aspect c est abusé

Deuxième partie la réponse d'Harton :
Des justifications et des propos rassurants sur l’organisation mais le projet semble clairement difficile (il le cache pas).
Il explique leur tendance à moins communiquer car ils arrivent plus à tenir leur prédictions.
Il a la béta 1.0 clairement comme objectif. Toujours positif et serein et il explique qu'ils sont pas forcément lents comparés aux autres dévs, on sait rien de ce qu'il se passe dans les autres studios (à prendre avec des pincettes).>

La deuxième partie c'est nimporte quoi. Y'a quelques éléments de programmation mais leur shéma d'incorporation de code sur le branche "master" la branche ou ils ont leur dernier build, c'est totalement surréaliste.
Et honnêtement, c'est pas ca le problème, c'est qu'ils ne bossent tout simplement pas sur Dayz !
On se faisait insulter par les Fan-boys quand on le disait déja en 2014 et maintenant tout le monde pleure on les a laissé faire.

On va avoir le droit à une paire de maj, une bêta avec un soit disant optimisation en 3 mises à jour sur une année, et hop release commerciale ! (entre-temps ils auront fait plein d'argent pour préparer arma4 avec les mods hors de prix d'arma 3 !)

Pour ceux qui seraient encore sceptiques... regardez ce qu'ils ont fait de "Take on Mars"
Il a été vendu pendant un moment comme multi-survival sur mars... je crois bien qu'ils ont retiré ces infos là et que le multi n'a même pas vu le jour.

sorry pour le double post, mais j'oublie de mentionner la quenelle taille XXL avec "L'Optimisation 0.60 - moteur fait main baptisé Enfusion"
Traduction pour ceux qui ne sont pas débiles et qui se renseignent : passage sur le moteur d'arma3...
Soit disant 1 an de boulot hum...
Autrement dit, ils n'ont absolument rien fait du tout. migration d'assets, copier coller de quelques bouts de code et hop compiler... plus qu'à régler quelques bugs noyés dans la masse des bugs déjà existants.
Maintenant pendant quelques mois ils se concentrent à travailler sur le moteur audio -> importé d'arma3, et le moteur de lumières -> importé d'arma3

Après vérification, je citait Take On Mars... Toujours en Early acces sur Steam, dans 2 mois ca fera 1 an qu'il n'y a pas eu de "News" sur le site...
Mais même avec tout ça, je suis hyper surpris de voir que certains les défendent encore !