DayZ- The Standalone

[sfscriv]

Here is the standalone website:

dayzgame.com/

Not much there, yet.

[sfscriv]

Could be fake:


AdrIneX
Mordor HQ Forum
27 OCT 2013

Wait, Rocket actually wants it so that BF4 and COD devour the casuals first so that more serious players can enjoy Day Z better?

[wobblyone]

I hope there is news soon.

[sfscriv]

Reddit
by Rocket
3 DEC 2013

>Rocket is being quiet again


Not entirely sure I agree with that. I allocate a fair amount of time to answering direct questions through social media. This is:
(a) more than I give to the media (b) out of my own time
What I don't do, I concede, is give dates for release. There are multiple reasons for this, the most important of which is that it is not just me who would be bound by this date: but the entire team which now involves about 20 full-time, onsite, people.

>is it possible that the game will be released before 2014?


The answer is very simple. It would be very difficult to argue anything other than "yes" as to whether such a thing is plausible. The real question would be "how likely", which is actually a question that should only be asked (and only answered) by those who can fully understand the implications and factors involved in answering it.
By this, I mean someone who understand the risks and variables involved with making something that has the architecture (but not exact operation) of an MMO.
I also think that question is the lesser when compared with "should the game be released this year?" That is the question that is asked whenever something is made that is releasable.

>Obviously, he has made countless promises that were broken.


In 2012 I said that DayZ had to be out by the end of the year to achieve what we wanted to. It wasn't, and we didn't. That cost us. That cost us in many ways. It cost me personally, because I had to spend another year in the Czech Republic that was unplanned. There's only one person to blame for all that and it's me, and I've been down the road of apologizing and explaining many times before.
While the difference between what I said and a promise might not matter to some, it matters a great deal to me. What I thought I was doing was being honest... "we have to do this, or else". Well - the "or else" happened and this is it.

>what do you, Rocket or anyone else working on the game, "think"?


What I think is simple. We are making a foundation. The foundation I believe that a multiplayer game of this nature needs. This came from a decade of modding ArmA, and involved me pushing programmers and team members to the absolute brink over the last year.
This is not a game launch that will be shoveled full of features, pretty artwork, or polish. What I want is very simple. I want a robust, well engineered, framework for the future. Something that we can test. It might be really rough around the edges visually... underneath it is built from solid steel.
When you cut all the bullshit, all the scandals with "promises", competitors, the "moment being lost", and hype wasted... it is so damn simple: make a good game.

Our first step is not the alpha you want. It is the alpha we need to build the future.

[sfscriv]

DayZ Forum
Quick Update
by Rocket
4 DEC 2013

Important note: Unless otherwise stated FPS refers to server FPS.

As most will know, we achieved quite a milestone with over 50 players on the server recently. While this is pretty normal for the mod, it's a big deal for the standalone as the architecture is entirely different and so much has been moved onto the server. So what does this mean?

The Situation
DayZ handles a minimum of 15000 dynamic objects. This is a huge amount of things to synchronize, in a MP environment. We implemented an entire rewrite of how objects are managed, linked with the "network bubble". Our chosen system was to implement an R-Tree approach and we have seen some success with this. Our aim was to reduce the massive FPS burden that all these dynamic objects bought, grinding the server to a halt. The main problem appeared to be scaling, in that the more players the worse it got.

Some details about server FPS:
◾Not strictly "frames per second" on a client more akin to "simulation cycles"
◾Max is 50 FPS
◾Max simulation of player is 25 times per second
◾Max simulation of zombie is 10 times per second

That means below 10 FPS, zombie behavior could be noticeably affected.

The Good news
We are no longer player number bound. It appears the server loses about 3 FPS per 40 players. We have only tested to 52 players currently. At that time, it was our first efforts with this number and we immediately found some missed areas of optimization, so with our next mass test we expect better results. The more players we threw at the server, its FPS numbers didn't change.

The Not-so-Good news
I was initially quite surprised because we still had a very high starting frame usage. 15000 loot items were using 1 FPS, that's right - just 1! But for some reason, 1000 zombies (despite all but 10 being at rest) were using a whopping 35 FPS. It didn't make sense and we've been going through this, optimizing and looking for the reason.

The Feedback from those involved
Overall, despite the performance concerns, with the server running around 8-12 FPS when under its heaviest load, the server was "reasonably responsive". Some people experienced inventory actions being a little bit slow occasionally, but generally it seemed things went okay.

Progress since the test
Since the test, we isolated two major crashes (resulting in server soak with constant players with no stability issue, no increase in RAM, and no decrease in FPS). We also optimized some areas. We're also busy hiding some areas and functions that are incomplete, as they either break or cause problems that we don't have the time to resolve before the Alpha's release. Perhaps one of the most serious gameplay issues we have at the moment is a very long time the player spends unconscious. It causes a problem for testing, so it's something we will be fixing before the release of the alpha.

Overall, the mood on development is quite upbeat. We're all pretty tired, as it has been very late and long working days. We had a new programmer and new designer start this week, and some assistance from the ArmA3 team to prepare the creation of our own audio team. We're looking forward to getting the Alpha out into Early-Access. I think that while some might be disappointed that this is not some feature-packed, graphically focused, masterpiece - we've been focused on addressing the major architectural issues and it's represented a massive body of work over the last 12 months.

We need a little more out of the server in terms of framerate. Just a little bit more, to ensure the inventory stays reasonably responsive. The remaining time will be spent tidying up remaining issues to try and give a more solid experience when we kick into the early access.

It really is an Alpha

I really can't emphasize enough - this is going to be an early access project on steam. It's a true-blue alpha. Massive areas of the engine were entirely reworked, involving a large team of people over the last 12 months. Much of what these achievements will enable won't be seen for many months - so I really plead for anyone who is on the fence to take a skeptical approach - watch streams, read reviews, watch some let's play and form your opinion. You could always come back to the game in three, six months time and buy it then.

Buying early will be a recipe for disappointment, it's a chance for those who want to be part of that whole process. For them, the process is as much as part of the game as the whole experience. For many, this is the opposite of what they want. To enable a smooth launch, we really are targeting it at a core audience who want to get deeply involved in a very barebones experience that is a platform for future development.

[sfscriv]

DayZ Forum
Another Quick Update
by Rocket
5 DEC 2013

So a bit of a progress report on the day that was.

We finished yesterday hopeful but cautious, as the server FPS was just not where we needed it to be realistically. Today was a day of highs and lows. I'll try and explain the difficulty we experience right now in the optimization.

The Challenge
The system was never designed or conceived to run such a huge amount of dynamic entities, over 11000 currently (in addition to the 2 or 3 million static map objects). So each system we refactor, redevelop or fix we bump into the next bottleneck. I think perhaps it is not unlike fixing traffic congestion, you fix it in one area only to find you have moved it somewhere else. This is what we are doing, trying to adapt and redevelop a system designed to handle perhaps 100 dynamic objects in a local area to one that handles tens of thousands distributed over tens of kilometers.

The Progress
We achieved some real success. We broke some things in the process, but nothing unworkable. As an example, we were refactoring how the "bot client" (a system that acts as a handling pot for messages sent to connected computers) handles error calculation (figuring out the difference between current and past, to see if it needs to notify clients of updates). Previously it was not only checking everything, all the time, but the engine was also checking with the bot client to see if it had received its messages. This is redundant as they are part of the same application; messages will always be received by the bot client.

However in optimizing this system (which involves the calculation of hundreds if not thousands of potentially different state management scenarios) we missed a few things, and this results in weird out of sync errors in inventory between the client and the server. Nothing that stopped many people playing, but an example of the pitfalls and challenges faced with optimizing.

Zombie pathing, collision, and tracking is "on par" with the mod for now, and in order to achieve what we want we need to redo the internal engine targeting methods to be more in line with the scripted targeting methods per the mod. This will take some time, so it's been timeboxed to be completed after the release of the alpha.

Our new programmer was straight into work, creating a sound system change that allows different footstep sounds to be played for different shoes worn. Awesome! Now if only we had the sounds to fill them in! Our big brother A3 has been loaning us people, including the A3 sound lead, to help set this function up. Some audio changes are already creeping in which is great to see and will be much appreciated for those joining into the alpha.

The Result
This puts us pretty much in the situation we need to be for server performance, assuming the remaining state calculation errors can be resolved quickly. Our new architecture can support much more, so the future will involve us tearing down the remaining bottlenecks but for now; they seem to offer a good enough structure to push forward on. This is good news. We'll be doing a full review of server performance tomorrow based on tonights metrics and make a decision regarding the server performance.

The Status
As I said yesterday, there is going to be quite a few bugs and problems - but our aim is to mainly turn off the unfinished features so that the bare-bones system largely just works. I think this gives people a good impression, rather than a bunch of unfinished stuff that simply doesn't work.

The real challenge for us now is to figure out what must be fixed versus what can be left until after alpha and redone from scratch properly.

[sfscriv]

DayZ Forum
Forum Discussion
by Rocket
5 DEC 2013

I missed probably my favorite new "win" of the day, which was getting a working pistol holster into the game (chest holster). That was a high point, and allows us to do "proxy in proxy" enabling us to put slots on backpacks to further extend the carrying capacity of survivors (i.e. two melee item slots on the outside of backpacks).
................
Rather than say "it has a shot for a particular date" I hope people are really thinking "it has a shot for a decent state". Because that's what matters most, I think.
................
The development of the last few weeks really consists of:
1. "Yey! it's finished! I've merged the awesome thing that I was working on for months and will solve everything!"
2. "Why didn't that solve everything?"
3. Lots of scratching of heads, denial, etc...
4. "Conference room everyone, bring the whiteboards"
5. Investigation
6. "Aha!" moment
7. Checkin. Compile. Checkin. Recompile. Checkin. Recompile again
8. Repeat from 1.

[sfscriv]