nautic

Thanks for part 1, nice insignt. I have two Questions though: 1.) Did i understand correctly, that with the enforce scripting language, you are creating your own embeddable scripting language from ground up? 2.) If yes: Why did you choose to do so, rather than building on an existing mature embeddable scripting language https://github.com/dbohdan/embedded-scripting-languages? It appears to me, that creating a completely new embeddable scripting language is not at all a trivial task. Actually, its easily a huge project in itself, and it's very likely to be very immature in its first versions. Although many other Requirements in the DayZ Standalone game and also Enfusion Engine, will heavily rely on the maturity of this scripting language.

Actually, the design of the game is one of the best i have ever witnessed. Its the implementation that blows (so far). But i have faith that its going to improve.

alpha and beta is a flawed concept in general. it allows a pretty stupid excuse to leave known issues open, and defer them to a later stage of the project. what this creates is a huge amount of backlog, and a broken state for a long time. i see many problems with this approach - you are not really evolving your game in iterations. in an optimal scenario you make design decisions based on what is already there. but in an alpha you have to make design decisions based on a broken shape, while imaging how it would be. but you'll never know if it will ever become how it should be in the first place. how are you supposed to design without a real feedback? it is like balancing zombies while they are still running through walls - ridiculous - a game usually has a limited budget. what happens if the size of the backlog gets too long, and extends the planned budget/time. are you gonna cut stabilizing/fixing/balancing your game at this point, in order to meet the budget/deadline? - in most scenarios it is exponentially harder to solve 10 issues instead of 1 issue, because the solving of a single one could affect another. leading to a rat-tail of changes, and a never-ending debugging/bugfixing/changing. this is the 1bug solved, 10 new bugs scenario. - defering stabilization is a pretty big risk. it is basically intentionally creating technical debt. it increases development costs overall, slows down development until stagnation, and is a potential project killer. in my opinion, a game project should be like every other modern professional software project. you should keep it stable and well crafted from the very beginning and for every feature you add. this way, you create a game that - actually evolves - you can make design decisions for, based on real feedback - is stable enough to be released to the community at any version - keeps changing at a steady pace of course dayz is a different scenario. they are not starting from scratch, but with an already broken engine...

it is becoming worse. also at the experimental. you cant even go to the nwaf anymore without assuming there could be a hacker. i was just shot camping crouched in a bunker, by a guy who seemingly had no idea that there was walls around me. he repeatedly fired against the walls with some kind of automated rifle. out of 5 times i was at the nwaf this is the 2nd time i saw a hacker there.

the proned 180 was possible with the old mouse controls also. so this cannot be related to 1:1 input. if they wanted to follow this track they had to change mouse controls for proned/sitting position only

The state is very kontroverse. At the one hand many things are really good. On the other hand one might assume that it could be way better by the time. I love the game, and i enjoy playing it. Sometimes i feel like getting trolled by the devs :-). Like when the zombies infinite loop starts. You just gotta wait.

hit a guy 996meters far with my mosin. he started bleeding but didnt die. he was standing still, and i aimed like 2-3meters above his head. this was a pretty awesome moment :-)

Just requires 5 letters. A L P H A

Well, in my opinion, this step should be kind of automated. One way would be that the Zombies recognize obstacles by the 3d Objects themselves. The other way is that the outlines would be generated automatically by an algorithm. So that you are free to change the map at any time, because you can easily regenerate the outlines automatically. So for me, there is no argument to wait for everything being designed so they can finally make the outlines. That would be a flawed process in my opinion. You could never easily just change the map design later on, without creating a rat-tail of postwork and testing. But you have to easily be able to redesign the map at any time. You just have to.

Lets rename all the Hardcore servers to 'Regular'. And all the Regular servers to 'Pussy mode'

The Zombies need to be a real threat in order to force players to hold together. It's good that they got harder, but i still don't like them because: - The Path-finding is not good enough. - They run through walls. - They are stuttering and hard to aim at when they are closed by and running. It feels like aiming with 4fps. - Respawning is good, but they should not respawn in range of a player. You need to be able to clear an area! - Zombie-Aggro is totally random. Some recognize you from miles away, while you can just walk by others. - I think they should be just a tiny little bit slower, but thats a matter of taste. - I think they should additionally have another type of attack, where they hold you tight (like being handcuffed), which they'd only do if you're unhealthy, low on blood or out of breath. And if you cant get out in time, they bite and infect you. Some hours later you would get unconscious, die, and wake up as a lootable Zombie. Still carrying all the same gear that you had. Looking like you, just a bit more like a Zombie. And controlled by AI of course (NPC). This would allow new kind of Drama and Stories :)

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.

Sorry but, this is total bullshit

Snow Drop looks awesome. But for a game like dayz it really depends on the mapsize. The further you can look, the more you have to render. I think most engines are not optimized for huge maps, but for smaller ones. They try to create as much detail as possible, to create a realistic view. But the amount of details they add might not scale for maps as huge as dayz.

although i am also not very happy with the current state of the game - even though it is alpha, it makes me kind of sad reading all the lame comments like 'he has all the money, no more patch needed'. you should be grateful that they decided not to deliver a seriously broken version to the stable branch. it was the right decision. obviously they are dealing with problems that are not as easy to solve for them. so just be patient and have a little faith.