November Round-up

[SmashT 10907]

November round-up
A collection of the most interesting/newsworthy posts by Rocket and other devs this month all in once place. I'll update the post as I find them.

 

30th November

• Checking the placement of the new hay shacks in the forests of Chernarus, they are pretty tricky to find. #DayZDaily

 

29th November

Q: Is joining a server still going to take a long time in DayZ similar to the mod?

One of the biggest problems is that in order to enable Join-in-progress (JIP) the server keeps a log of things that happen. All this data, for the whole map, is sent to a player when they are connecting. This can be extremely substantial, and very demanding not just on bandwidth but on processing power (both for the server and client). This is one of the reasons that the network bubble is so important for standalone, and why we have focused so much of our development on architectural issues like this. [source]

 

Q: Part of the problem is the feedback from the UI. When it takes a long time to log in to a server, I can't tell if something has gone wrong and I need to abort

The main problem we have now is adequately preloading your client, which is the reverse problem you have listed. That is, the server has created your character and position - but your client hasn't caught up and loaded the world yet. It also means you spawn into game and see textures/models popping into existence. From menu to in-game can be as short as several seconds (if your game already preloaded the world before). We are now building our manual "queuing" system that will force the client to wait for x amount of time, depending on when they last joined a session etc... So the delay will be entirely arbitrary. [source]

 

Q:  Are waypoints/markers using the map removed, forcing players to orienteer instead?

Markers gone. Position gone. Little exploits allowing you to place next waypoint gone. GPS not in yet. Two compasses, orienteering and old brass one. Both fully animated. Will be probably adding PiP to help orientate them and use them but only basic functionality available for the alpha. [source]

 

25th November

• Smashed a couple of big bugs today (no more floating loot!). Feels good. #DayZDaily

23rd November
Rocket livestreaming DayZ and Q&A on Twitch (No sound for first 10-15min)

 
21st November

• I feel like there are more enterable rooms in this area then all of DayZ Mod. #dayzdaily 

 

21st November

• Shared this with my buddy http://twitch.tv/theofficiallou  -  @_SenChi__  did amazing work on Zeleno #DayZDaily

 
20th November
(WIP info on the revisions to pathing)

One of the the biggest problems we faced with zombie collision avoidance is the initial path when zombie gets a new target as there does not exist any trail-waypoints (breadcrumbs) so we rely on straight line. This sometimes leads through objects. We tried to employ path-planner just for initial path but this is not usable. Whole system is too connected with original AI and even after some hacking it show up that strategic path is too rough and operational path needs to be created too what is very performance/memory wise very demanding.
 
So we looked at:

• Players generate breadcrumbs even when they are not target to any zombie. Initial path could be constructed from part of that trail that is not obstructed by any other objects
• We employ simple obstacle avoidance algorithm so we try to construct initial path around obstacles. We want to avoid "cheating AI" as much as possible, this solution is the one we began to try.

The former analytic solution for avoiding obstacles was dumped and instead a complete dynamic pathfinder has been made which makes nodes from all obstacle corners, start/end points, create edges and perform a search on this graph. Graph will be updated only on demand and cached for some region around agent. Start/end node and their edges are the only generated every search.[source]
 
Q: Rocket we aren't all geniuses, this just looks like a spiderweb to me..
Sorry, I didnt realize reddit wouldn't let me add text AND an image. So I posted my comment as text below, hopefully that explains it. But you can see the dynamic pathfinder graph in action above. The zombie AI manager has analyzed the scene and the zombies will use this when they need to get to a target. [source]
 
Q: How much do you feel this is an improvement over the original system?
Well they don't run through the buildings, that's a good start lol [source]
 
19th November
(Quick update from Rocket)
This week has started off great I'll give some highlights:

• Realized that a whole bunch of people equate sounds with change so some poor person on the team is going to have to do some extra hours to put placeholder placeholders in. It's a pointless task but if it makes people actually check for different mechanics then fine.
• Going to put the extra zombie models back in, we just used one for testing because it was the only zombie we'd changed to the new engine simulation tag.
• Server FPS is stable at the levels we have been testing (40-50 FPS with ~10 to 20 players, 15000 loot items, 1000 zombies). We had a very nasty stability issue relating to massive changes in the way the engine handles it's array of objects. Dynamic objects (anything made after mission start) were all handled in two very large arrays. The only way of checking them was to iterate through them. Simply put, we made a smart way of the arrays with a "dirty" and "clean" array. This removed significant overhead (orders of magnitude) but because it was a radically different approach we had severe instability. Appears this has been done.
• Pistol is in and usable properly now, although it's just placeholder animation wise because it's borrowing from the rifle animations until subclassing is complete.
• Client FPS in cities may have a boost due to some changes in the way occlusion culling is used for dynamic objects. Not a focus for now but it was something found along the way.
• Lots of new content pouring in, such as meat of many different types in cooked, raw, rotten variants. Also lots of new fruit, new orienteering compass, a down jacket, the zombies are using gestures not animations now for attacks (can attack while moving).
• HTTPS implemented for game server <-> central server communication.
• Steam integration for the server browser such as friends in the server etc. A favorites tab. A friend on servers tab. Etc...

So where are we?

• I need to go back and focus some on the player flow from menu to ingame as this needs cleaning up as it doesn't really support the release yet.
• Verifying the instability issues we had.
• "Dress Rehearsal" needs to occur, which is an all-signing, all dancing test of a server.

Much more things as well but I'll try keep everyone posted when I can.
http://dayzmod.com/forum/index.php?/topic/152227-quick-update-for-19-november-2013/
 
Q: Will you be using the swimming mechanics from ArmA 3?
Swimming has not been ported from A3 yet. [source]
 
Q: Will falling into water from height still do damage?
Falling will not be adjusted until AFTER the alpha is out. But it will use ragdoll at that time. [source]
 
Q: Can we have a development roadmap?
We will be releasing an extremely comprehensive roadmap with the release of the alpha version.
Let me say this, in the past few months the development committment and resources of the project have massively scaled. We have moved into a new building, new people are being constantly hired. The roadmap is already looking far more ambitious than I ever could have imagined. While the initial alpha might be fairly limited on the face of it, the platform it provides for the progressive months of development is (in my opinion) nothing short of staggering. [source]
 
Q: It would be nice if you could give us an estimated release date? When do you hope it is out?
If I said when we hoped, everyone would take that as a promise. We have hopes but, as always, we won't compromise the whole project and rush something out. I had hoped the fact this has been occurring with nearly all PC launches would show the value in this approach to everyone. [source]
 
Q: I thought finalizing the flow into game wasn't going to hold back the release?
Finalizing the flow wasn't holding things up until the new R-Tree implementation identified that disconnecting clients character brain and inventory were not cleaned up properly. This is causing crashes and instability - and a great deal of report spam. I find it insufferable that people instantly assume I am lying whenever something doesn't match their desired world view. It's also not necessarily holding things up, we have to achieve the target and we're following multiple paths of resolution. Finalizing the flow wasn't holding things up until the new R-Tree implementation identified that disconnecting clients character brain and inventory were not cleaned up properly. This is causing crashes and instability - and a great deal of report spam. I find it insufferable that people instantly assume I am lying whenever something doesn't match their desired world view. It's also not necessarily holding things up, we have to achieve the target and we're following multiple paths of resolution. [source]
 
Q: You said the one thing you needed to achieve before alpha release was stability, but now you are saying you need to finalize the flow into game... So another lie?
That is part of our stability work. One of the major problems we have now is inconsistent state of the players character when respawning/logging in. When you die, sometimes you death is processed sometimes it's not, or sometimes there has been weird issues with the database. At best, it has been causing problems saving the state of the character. At best, it has been causing crashes of the entire server and all the clients connected. In order to make it more stable, myself and one of the programmers have been refactoring the client into game process so that it is more streamlined and robust. I may be bad at my job, wrong, and many other things, but I am no liar. [source]
 
16th November

• Orienteering anyone? #DayZDaily

 
Here are a couple of item renders

 

 
15th November
Been a while so here is a raw, unedited, roughly 10 minute gameplay video taken after spawning into a multiplayer test today. This is pre-alpha footage, so it makes no effort to mask the variety of bugs. Our whole focus is on getting the alpha out, which means focusing on Multiplayer (server) performance. Enjoy and see you soon!

 
Q: I hope you can disable that motion blur?
Yes you can. Most people (even in the project) hate motion blur but I love it. And it's my party, so my videos always have motion blur! hzzzaaah!
 
Q: What about mouse acceleration and an FOV slider?
fov slider yes, already in game. I think we either disabled mouse accel or there is an option for it.
 
Q: Was the hatchet stopping when it hit the zombie or am I seeing things?
At least someone noticed :)
 
Q: Was that a blocking animation I saw?
Yes but it doesn't work (yet)
 
Q: It seems you are swinging with the mouse also, does it work if you swing too late (after the zombie has movied) and still connect with the zombie if you move the mouse mid-swing?
Yes. Tracing is done along the length of the axe during the animation. At least someone noticed :( Not all weapons do this. Most one handed weapons do it cursor based, because they just didn't work well without spacial awareness.
 
Q: Can you switch weapons while walking/running?
Yes you can. But currently the animation only works taking the rifle off your left shoulder. This week the animators introduced an animation taking an item off your right shoulder but it doesn't have the taking while moving animation yet.
 
Q: Sounds out of sync with the animations?
The animations changed after the sounds were made. Sounds will be remade once we have finalized the animations +actions. This is the reason we stopped doing new sounds, too much of the game is changing to have to redo the sounds each week.
 
Q: I was hoping to see the Mosin in action....
Mosin with scope and bayonet is probably one of the coolest items in game currently (there are two scopes for it in game now. Gotta leave something for our second date, or you'll never invite me to the prom!
 
Q: Looks good, but if you are focused on multiplayer testing why not show stuff with multiple people?
Chernarus is a big place. I had no time to edit so I just run around for a bit. You can see people disconnecting and connecting in the bottom left.
 
Q: Are these connecting messages going to stay in the game?
On the list to be toggleable .With default "off". We were going to remove them, but server admins probably want to be able to toggle them on.
 
Q: What about kill messages?
There are no kill messages.
 
Q: How does the game look on low settings?
I generally only play with settings on "low" (not very low, because that disables GPU). We use an internal executable that drastically lowers performance due to its debugging features, so we basically have to run it on low or we get a slideshow.
 
Q: Wow, that video looks amazing for low.
That's not on low. I'm not sure what that's on. I did that off a steam build. But most of my screenshots are on low.
 
Q: Are all the ArmA backpacks removed?
Yes. We are redoing them all for parity with the new items. The new backpacks all have straps. The old backpacks simply didn't look right because of the lack of detail. We currently have four different types of backpack, most these kinds with a few different color variants. More will follow.
 
Q: Crosshair?
Crosshair is only in for testing. It may still be in for alpha, depends on state of other game systems.
 
Q: From the comments I've been reading it seems new mechanics like the compass and needing a can opener etc are too complex?
It takes inspiration from rogue-like games. The game can't (and shouldn't try) to compete with great zombie games like L4D or dead island, or RE, etc... It's about the complexity and the decisions. Obviously, there is a fine line between "good" complexity and "bad" but the only way we find where that mark is, is by trying something and seeing.
 
Q: I noticed the exhaling wasn't synced with the visual breath effects.
It's not sync'd (yet)
 
Q: This is not what I expected, zombies still only appear to be a minor nuisance?
They're more like project zomboid now. One or two you're okay. But the ones that sneak from behind and bam... you're in trouble.
Do a little experiment, sit down and write the exact mechanics and math required to make the zombies act like a "threat". Put it into a decision tree. It's actually hard because all you can do is make them either faster or stronger. In the end, I opted more towards the tried and true zombie trope of more zombies
 
I spent a year on and off trying to make the zombies work, experimenting with different scripts. In the end I came to the same conclusion you discuss here. In making individual zombies a threat, you actually make these very frustrating situations. The game becomes very black and white. But by making zombies "manageable", that means that generally with the zombies you are okay. But if you don't have a good plan - you get in deep trouble. That's what we are aiming for.
I also have a great melee weapon. It would have been a very short playthrough with just my fists (I would have died in about 30 seconds). The wood axe is the second best melee weapon in game, besides the firefighters axe (and maybe the chainsaw).
 
Q: Badass axe!
True as well, that axe is the second best melee weapon in the game, after the firefighter axe. Although the chainsaw is good but limited fuel.
 
Q: Can the screwdriver be used as a melee weapon?
Yes. Actually everything is.
 
Q: Are you guys seriously keeping the ArmA 2 lighting effects?
The effects, as always, are controllable.
Regarding our lack of focus on replacing the rendering, unfortunately nobody has invented a "replace rendering for game engine" button yet. Perhaps you have, and just forgotten to post it online. If so, please let me know and I'd be glad to license it from you.
 
Q: Disappointing, this is what I expected a year ago, the longer you delay the more people are going to expect.
Then maybe your expectations were/are too high. And maybe, I'm giving you the chance to see the state of the project before you part with your cash. If you don't like it, don't buy it. You can it's say its shit, but at least I can say I did my best and I was honest about what was achieved.
 
Q: Why does it sound like the axe is firing bullets?
WHY DO PEOPLE NOT READ THE WARNING MESSAGE? Seek, and ye shall find.

• Some folks weren't crazy about the screenshots I've been tweeting, but this storm is just too much. #dayzdaily

• If you like that, you're gunna love this. #DayZDaily

P.S I am running on normal across all settings, save Anti Aliasing, which is on high.
 
There was a small trip, walked in Zelenogorsk and dressed up. I found knife and jacket, and the guy -screwdriver - Senchi

 
Q: Im guessing A3 rain will be used which honestly looks quite good. Visible on front of lights. Invisible otherwise?
Actually, both A3 and DayZ SA get their rain from Carrier Command :) [source]
 
Q: Will lights finally cast their own shadows and not shine through buildings?
In order to do this. I suspect we would have to drastically cut down on view distance. Fully dynamic lighting might simply be too complex for the scene. But we will examine this soon and see. [source]
 
Q: Killing players while they are half-way through loading into game is a big problem in the mod, will that be addressed?
Agreed. I'm not sure if I will get this done in time, but my current plan is to revise our system of spawning in a player. Currently you connect, and the server checks the central server to see if you have a live character. If so, it loads that in and switches control to you. If you don't it makes one and switches control. However, it often takes a few minutes longer than that to load in (the server auth process is lightning fast now). So what I am planning to do, is to have the player be told where their character will load in, preload that spot on the client, and then create the character. Unfortunately, that requires so revision of our spawning mechanic and we might not get a chance to do that rework of something that effectively "works" before the alpha is out. This is a good example of a known issue that is lower priority than getting the alpha out the door. [source]
 
Q: Can Chernarus Plus bring back the magic of exploring and learning the map? From my experiences in Stary, yes, it feels like a completely new map!
Agreed. Just today the finishing touches are being done on the new apartment buildings which are massive and fully enterable. We are actually a little concerned they have too many rooms, but that ship has sailed. These new residential areas around cherno are going to make it a very complex urban environment. [source]
 
13th November
Q&A with Rocket and Hicks on Steam DayZ Group Chat
http://dayzmod.com/forum/index.php?/topic/151837-dayz-sa-steam-community-chat-questionnaires/
 
12th November
Q: Any update on that bug that was holding back the release?
At the risk of creating an impending PR disaster, I'll reply by saying that it appears we might have solved our core work on this. However onPlayerConnecting is causing a crash with is making it difficult to verify the system changes actually work. Now, anyone quoting this please read. It is quite common after significant optimization to create crashes. C++ apps crash very easily when something is a little wrong, due to memory allocation. So this isn't some kind of disasterous news, it's really just no news. Just typical development.
 
Our initial test showed a stable framerate, but we can't verify it until we remove the crash bug because it occurs with connection/disconnection.

 

Q: How is the melee system coming along?

Feedback on melee depends perhaps on perspective. We are far, far beyond what we initially anticipated that we could do. However, this means that we now are the bottom of a different league, and it's natural to start comparing melee to games that do it much better.

So I kind of have mixed feelings on it. Some positive points:

• Bones moves when you hit body parts. i.e. you hit someone in their head, their head moves away from the impact in response.
• Ballistic damage, brute damage, and slash damage types supported.
• Bleeding occurs from points of impact.
• Damage is resolved by the server only
• Different weapons have different attacks
• attacks to different body parts cause different effects.

Some negative points:

• The "gestures" system (animation method) is rudimentary and results in some weird looking animation bleeding at times
• When FPS is low, hit detection can limited. However, hit resolution is good so long as the server is above 10 FPS. Detection is made clientside, and then the resolution is requested from the server based on this.
• Feedback of hitting is not quite as good as we want. Just the body parts moving, sound effect, and contact splat of blood.
• Sounds have not been done at all, placeholder contact sounds are used from bullet damage (our audio designer has not started at the company yet)
• probably much more that I'm forgetting.

 

EDIT: I missed the biggest problem: controls. We are still revising how to actually control your "stance" and then reconcile that with controlling weapon "stance" in a cohesive and intuitive way, it might be some time before this is resolved. [source]

 
Q: What weapons will be available at launch?
100% confirmed for day one:
Rifles: M4A1, Mosin Nagant
Melee: Heaps. About 8 different two handed and one handed, from knives to bats to screwdrivers to chainsaw.
Pistols: One available, possibly more
 
Q: Will there be walkie-talkies on launch day?
Yes
 
Q: Can zombies damage your gear?
Zombie damage currently results in damage to items where they hit you, the same as normal player melee.
 
10th November

• Just discovered why zombies are warping through walls... because the walls don't exist. Whoops. #DayZDaily

Q: Can you elaborate?
The zombies aren't using the geometry to calculate their collisions, as this would be incredibly performance intensive. Instead they are using the "roadway" which are planes inside of buildings that say where someone can walk. Players use roadway + geometry, so this problem wasn't noticed. But basically, the roadways don't have sections removed for where there are walls. It's not a huge job, but we will need to go through and define the roadways properly to avoid these problems. [source]
 
Here is a good visual representation:

 
Q: How can you then prevent zeds "glitching" through walls with certain body parts then?
In a generic sense, because geometry is a 3D object. Roadway is a series of planes. This isn't entirely accurate, because roadway exists in three dimensions also.
Detecting the collisions of body parts, even for 50 objects, would be absolutely insane performance wise - let alone for 3000 zombies + 150 players. What we do is take an aproximated cylinder as geometry for the agent, and then see if that is still on the roadway. If so, the it's okay. We just stop the cylinder from going outside of the roadway. [source]
 
Q: Is fixing this a lengthy process, could it hold up the release?
This doesn't affect release, it's a good bug to find. It means we can make the zombies much better in interiors.
 
Q: Why do players use "Roadway + Geometry". Wouldn't the Geometry master over the Roadway?
Roadway defines what you can walk on. Sounds are generated based on this roadway surface. Geometry defines what you collide with. [source]
 
Q: Could different roadways have different sounds and different wear on shoes then?
Surface already affects deterioration of your shoes and/or feet and zombie noise. [source]
 
Q: What about server hosting? Will Bohemia run them all initially?
BIS will run some servers through a hosting provider who will also run some. I think we will be able to handle 50-100k concurrents (this is from memory, i can't be sure of the exact numbers).
 
Q: What about Linux server hosting?
Linux compile should work, but we haven't tried compiling for linux yet. Our main aim was to finish the windows version first, then compile for linux and fix any bugs.
 
Q: Will the actual game support linux?
Would love to do a linux client build one day, but that's a very big maybe.
 
9th November (Progress Update)
We finished up for the day here just now. It was a good day, the focus has been:
Finalizing the flow into game
Not holding up release
All the basic stuff like, creating your character, joining a server, etc... Then some steam integration so you know which servers your friends are on, and such. We're using steams API, which while is it great being free of gamespy we're not sure whether external apps (like six or dayzcommander) are able to poll steam's servers. So we want to make sure our browser provides some improved functionality.
 
Optimizing/Bugfixing Dedicated server.
This is why we are not out. We need performance
We think we need a minimum of 15 FPS will 50 players, 2000 zombies, and 25000 loot items. Our latest tests have all shown some runaway systems in the code we have to tidy up. The variable synchronization system that was developed for work with the network bubble, is checking the variables very often. We're optimizing this. Also, there are many string comparisons. These have been refactored so references are used (lookup numbers) to speed up the process. things like animations etc... are generally recorded as strings - ArmA wasn't build to handle very large numbers of things so this has been a large area of optimization.
 
We also have a bug where sounds (which are temporary vehicles) are being queued up and sent to all JIP players. This causes us a steady loss of performance on the server.
The synchronized variables are also checked for each player, this is inefficient and we are refactoring that. It is our biggest obstacle to releasing the alpha right now. We know what needs to be done with it so we're working on that, then we will again reassess the performance.
 
Why not just say its not out on xxx day?
If I start saying "oh it won't be out then" people start asking me about the day after, and the day after. So it just encourages people to keep asking me when it is, and the "announced date" would be when I go "yeah, it could be out then".
 
What we have now
We have now something that provides basic functionality for 10-20 players. The new zombies are in, they provide excellent pathfinding outdoors, and improved pathing indoors. They are capable of breadcrumb navigation or line of sight. At low server FPS they will start to rubberband and glitch through walls much more often. They are very much a work in progress.
 
Client performance out of the cities is very, very smooth. We still have a bug in the cities that occurs (and shouldn't) that causes lower framerates. This will eventually be solved, but for now it is noticable when looking at center of cities. Overall, the feedback from the testers is that performance is much smoother than with the mod.
 
The inventory is a bit of a mixed bag. There are some mistakes we have made that, unless we delayed the standalone, we can't fix until later. But overall, I think it is a huge step up. Stacked items, wetness, damage, crafting, containers, clothing, weapons, pistol holsters, bags, melee weapons, chainsaws, masks, gloves, boots... you name it.
 
So, what next?
We keep optimizing the build. In the meantime, I would encourage everyone to checkout Project Zomboid which is now available on steam. This has been a massive design inspiration and I recommend it to everyone interested in DayZ. [source]
 ---
Q: If its not holding back release what is?
Read it carefully. Right now there are performance issues with the game servers. I think many other bugs and problems aren't an issue, but this is. The servers need to be smooth and dependable, even if the game and design are not so much. smooth frames at 20 players is not enough, we need more optimization and there are existing bugs that cause serious performance issues on the server. We know what they are, and we are fixing them. So we just complete that then reassess. [source]
 
Q: Could you not improve performance by caching textures in RAM?
Probably but I haven't tried it myself. We have some issues with textures that are causing a noticeable client FPS drop looking at center of cities. We'll get to that eventually. [source]
 
Q: Rocket, you said before that it was the zombies causing that issue....
Client side issue is associated with rendering. Zombies simulation is calculated on the server, and zombie rendering is very simple (one texture, one section = one render pass). So our main rendering is objects, buildings, etc... of which there can be many. I believe the issue mainly relates to how we are handling the textures (massive numbers of them). [source]

Q: Could you let us know if you will be announcing the release date once standalone is ready?
There will be no delay, when the server performance is achieved it will be released. There is no marketing strategy. Our aim will be to try and well publicize the issues with the alpha, and encourage those who are concerned about the state to wait a few months and pick it up then. [source]
 
Q: What about if it's ready on a weekend, is that likely for a release?
Certain days would obviously be better than others. Once the build is ready we will make an assessment for the exact timing, but I wouldn't imagine we would wait very long. [source]
 
Q: Is optimization as big of a hurdle as the network bubble? Is it network bubble v2, or knowing how the dev team works, do you think it's an "easy" fix?
Optimization can be very frustrating, and it's probably not as "fun" as creating something. But certainly optimization is probably less complex than developing code netcode architecture. It's fairly reactive... run app, watch what is happening... optimize the things taking the most time... repeat.
 
Q:Do u know a round about size of disk space for the SA?
About 10GB for client. About 600mb for server.
 
Q: Can you shed some light upon widely adopted theory here that we shouldn't be expecting 'imminent' release until we see about a hundred people playing on test server?
I don't think we will bother testing above 50. If that happened it would not be planned. If no compounding FPS issues are experienced at 50 we know it scales well, and it means your average ArmA2 dedi server can hold 50 and a super-server could do more. Every time we break the ceiling on player numbers, we get excited too :)
 
Q: So, if I hit W on a 250 ping server, does it take 250ms for me to see my character move forward? How much exactly is simulated on the client to reduce this delay? Or if you don't want to get into details, is playing with 250 ping bearable?
Can you count to 200ms? The main difference is that previously your client had a hell of a lot of work to do - and the poor server had a lot of information to send you. This meant bandwidth would be prioritized and on a busy server your 200ms became a very big liability. Now that the server doesn't send nearly as much info as it used too, things happen much faster for the network manager. This means that you get only the information you need. 200ms is actually a very short space of time, when you think about it. The issue is all the bloat added onto that 200ms by the client + server.
 
Q: Don't you think 15 FPS is low ?
Player simulation occurs 20 times per second Zombie simulation occurs 10 times per second
Anything below 20 FPS will affect player simulation. Anything below 10 FPS will affect zombie simulation. Above that, you probably don't notice a great benefit so much as not notice any bad things.
A couple of weeks ago the server was running constantly at about 5 FPS, and still functioning with the only main problem being rubberbanding zombies.
 
Q: So to clarify, you are working to touch up performance. But only so many people can work on that at once, right?
Actually performance is different from architecture. We currently have two "lead" programmers. Both are focused solely on performance. We have two senior programmers who alternate between bugfixing, performance, and network improvements. We then have two programmers on more longterm assignments: We have one programmer working on physics/ragdoll, another on rendering stuff. Finally we have one programmer on loot spawning and central server architecture. Additionally, we have 1 programmer coming on the project soon from internal, and 2-3 new programmers in various stages of the employment process. So, to cut it short, optimization is something that several people can work on. Even I've been dipping in! Also, artists are involved in optimizing art assets.
 
Q: Do u know any recommended system requirements for the standalone?
A good CPU. more than dual-core is probably a waste but CPU speed is most important. An SSD helps because there is a lot of texture loading. SSD for the game, separate one for OS would be my suggestion. More than 2 GB VRAM is probably a waste, game doesn't use it. Same for RAM.
Server wise, it's all about CPU. More CPU more zombies + more lot + more players. Bandwidth not a big issue (full server probably 4 Kbps out and 1 Kbps in). Ram non-issue (expect 400mb to 1gb on server).
 
Q: About the hardware impact on the game, I've read more than once that you've given incorrect statements, like SLI/CF wouldn't help, and now you're telling people "more than a dual-core is probably a waste". Please stop spreading this misinformation if you are unsure about it. more...
On the balance of things, ArmA has to do most things in one thread. it can offload some things. If you read Suma's comments from the things you posted (Suma is our lead programmer on DayZ), you will see that he says sometimes the output can be good, sometimes it can be counter-productive depending on the situation.
ArmA's AI is completely different from DayZ's AI. We have entirely removed the Unit, and the group. We only use a modified form of agent.
We're not talking about ARMA we are talking about DAYZ SA. So quoting OFP, and ArmA3, is not necessarily relevant.
If you actually read through Suma's comments you will see one of the main areas is multicore benefit is AI, which is entirely done on the server. There is no AI done on clients any more. ArmA still processes an AI entity brain even when the client is not local. So this benefit of threading is entirely removed, because it doesn't exist.
I'm not saying 4+ cores won't help, my opinion is that is is probably a waste. The cost of upgrading to a multicore from your dual core, versus the FPS benefit you actually get, has been minimal from my assessment of client performance.
 

Just discussed this with Fido, one of our (two) lead programmers.
There is a great deal of discussion and documentation on the BI forums regarding this, and I have to say I am no expert on clientside performance as I am not very concerned with that right now.
We just went through and studied the engines use of multiple cores. Two main systems can currently be offloaded to other cores:

• Rendering processing (texture loading etc...)
• File operations

Also in the engine, it appears that while an attempt has been made to move view geometry calculation to another core, this was never finished. So maybe it was finished in A3, but I am not sure. Currently, I have not noticed a great benefit in DayZ for a server having more than two cores. However, we have also identified that is should be fairly straightforward for us to offload a couple of the "big" systems we have on the server to another core. This will make a big difference. In terms of clientside, I don't personally notice a landslide difference with a great deal of cores and HT. But I haven't done detailed benchmarks. Internally, we're far more likely to put SSD's in peoples computers than we are to upgrade their CPU's. However, YMMV. EDIT: on another thread there was some guy who has done a great deal of benchmarking that should be used more as a guide than my own, anecdotal, experiences.

 
Q: What about hyperthreading? Would an i7 do better than an FX because of the differing threading support, or are we just talking raw clock speed here?
The app architecture is old, it's a 32 bit app. Like the vast majority of games, it's designed for previous gen processors. Games generally aren't designed to use six cores and etc... I'm no expert on hyperthreading but one thing that does help is raw clock speed on a single core. There is some multithreading stuff in the engine, i looked at it but I don't understand how it works. And I think that's all clientside anyway. I personally haven't looked into clientside CPU and my client runs fine for what I need. But on the server, it only uses one core. Which means raw clock speed is critical. It scales well enough with faster CPUs.
 
Q: Do you think putting the game on an SSD will increase the performance a lot? 
ArmA loads a tremendous amount of textures and models into memory only as it needs them. Internally we notice big differences and greatly reduced loading times. Internally we like to have two separate SSDs, one for the OS and one for DayZ, each in one of the high speed SATA ports.
 
Q: Do you continue to work on other game features (adding more objects, etc) or simply focusing on server performance atm? To put it in a different way and to avoid incurring hatred from reddit (all the effort into alpher, now!) are there other parts of the development team simultaneously working on future features, like vehicle and building mechanics?
Vehicle and building is not being worked on (yet) but is part of the roadmap. The current systems will be utilized by vehicles, such as the attachment + consumption systems. So we're laying the groundwork for that. Not all the team is working on performance, some of the team are working on more longterm stuff like rendering + physics/ragdoll.
 
Q: Will you be able to test the 50/server goal using internal testers or will this be something that essentially the alpha release will test ?
We will test it internally first absolutely. Actually, it is very easy to see the problems. The bugs we have now show up because they are compounding. That means they get worse quickly. So once these are solved the system scales very well.
 
Q: Do you guys know what needs to be changed to fix the performance issues, or are you still trying to figure out what's causing them?

• the sound queue.
• the state checking of "slow vehicles" array. This contains loot items. instead of checking 30000 items each frame (50 FPS on server), we want to have them in two arrays. a "clean" array that is never checked (because they are stationary, waiting to be picked up) and a "dirty" array that contains objects that are on a player - we would check these regularly. optimization has already occurred but its work has not been finished.

Let me put it this way. a week ago it was not possible to run the server in the current configuration. Not in ArmA, not in DayZ SA. So a benchmark is not possible.
 
Q: Is it worth to spend the safed bugs on another game (based on timeframe) or would you (honest opinion - not the salesman one) say "nah, just be patient"?
Even if you bought another game now, DayZ will still be there. I think that DayZ is going to be an interesting experience when the alpha releases, but it is still early in the products life. Only the basics are there. So even if you bought another game (like Project Zomboid!) DayZ will be there and better when you have the money again :)
 
Q: Will the initial server be capped to a certain number of players (below 60)? If so, do you plan on gradually increasing that number to measure the performance? Also, how many servers can we expect on alpha launch?
Server size will be dictated by the server itself. High quality servers will be able to run more players. The servers are very CPU intensive, but the bandwidth requires are greatly reduced compared to ArmA2. I would go so far to say bandwidth, and even ping to an extent, are not really that important any more. But server CPU is. We are benchmarking with what we believe is a typical ArmA2 dedicated server. We are aiming for 50 players for the initial release, scaling to the design limit of 150 (we feel more than that does not work for Chernarus).
 
Q: I personally 100% understand why you want these issues ironing out however they sound minimal when compared to the mod and that didn't exactly go down bad did it?
To quote Marek (our CEO), "really this is a new engine". While the rendering may look similar to how it was, under the hood it is entirely different. The netcode, the inventory, the AI, everything is touched there. Because of this, we have to be very careful because all sorts of things can go wrong. We have been discovering all these little problems. Small problems that you wouldn't see with 100, 1000, even 5000 objects become very noticeable when you have 25000 objects. This isn't about perfection - its about function. And also, the mod was a freebee alongside a functioning game. DayZ SA will require people to pay, many of those people feel they have already invested not just money (buying ArmA2), but time and support. Therefore there is a certain expectation of function that will prove the viability of the project. I believe that a well functioning multiplayer system demonstrates the viability of the project, even if the game design might be a bit lacking.
 
Q: On the side note, how large the dev team has become? You were moving into different building, expanding staff... Please, elaborate with some useful details.
20-30 FTE, with other externals.
 
Q: Updates are good. Screenshots are good. Just please make it clear that there will be no "hints" or suggestions in those images about when the release is going to be. Ones like the three bullets, no shit there's going to be bullets in the game. I think to EVERYONE it meant that there were only three days until release.
People will read into anything. And actually, I'm not saying it will definitely be weeks. Today it almost looked like we had reached the performance target, but the bug we fixed had a more subtle bug hiding behind it. I don't do clues and I never have, if I post a picture take it at face value. It's a picture of three bullets. There's no game in how we release this, we'll just release it.
 
Q: Will DayZ have the same god awful HDR/bloom effect? Eyes do not work like this. Half Life 2 as an example of doing good HDR, as it's very subtle in that game, yet a nice effect when you notice it. It's simply too jarring in Arma II, too exaggerated.
 
Currently in RV rendering is done in combination with simulation. This makes it very difficult to exchange your method of rendering. If the rendering is done separately from simulation, then it is easier to exchange rendering methods. This is useful for multi-platform development among other things.
 
Reading the comments in this thread makes my eyes bleed. Many games struggle with this issue, it comes down to mathematics. The game has this problem precisely because it tries to treat the camera of the player like a real eye, but it is not a real eye. Because it is not a real eye, it doesn't know where you are focusing. The engine tries to make a best guess about how to adjust the aperture setting. It does this in multiple ways, and the result is not always ideal.
 
A human eye changes this in a very complex way, it knows exactly where you are focusing because when you look somewhere your eye moves with it. With the game, your eye moves independently of the camera so the game has no the fuck idea what you are doing. Furthermore, the computer does not "see" the scene like you do. It just makes the scene, which means it needs it's own routines to try and sample the scene.
Saying "make it function like a real eye" is like telling a blind person to paint what you are seeing. It's not easy, or trivial, and shitting in programmers air vents isn't going to solve anything.
 
No, what I am saying is that it is quite simple to say "it should function like the human eye". But you have to make that behavior happen. And because the computer can't see anything except math, you must use math to achieve the effect you want. Comparing ArmA to HL2 is not going to help, because they are designed to achieve very different things. The size of the entire scene is much smaller in HL, therefore the way you calculate the total light is entirely different - allowing you to do all sorts of things with lightsources and shadows and, of course, aperture. In RV, the calculations are made for scenes kilometers wide.
 
People understand what you mean, it's not like programmers sit around and say "oh wow, that's how it is supposed to be?". But, like everything, it has a priority. We're focused on core architecture for now, because we plan to entirely replace the renderer so that we're not always reliant on DX. Whatever "fixes" we made to HDR now would largely be wasted as they would disappear.
 
Q:The reason the Alpha is being held back is performance issues, right? But that's it. It'll be an Alpha, it'll be on Early Access. The way I see it, you guys either push the Standalone out in November, or I guarantee you it'll be delayed into 2014.
Don't quite understand what you mean but perhaps I can clarify my position:

• The alpha has not been pushed back.
• The core of our game is multiplayer, we need clean performance there or the whole experience falls over

Trust me, when you are playing DayZ SA you will see that I am no perfectionist. But hopefully you will see the wisdom of looking out for what I believe was the biggest issue with the mod: multiplayer performance and security
 
8th November

• It's getting cold in Vybor, fortunately I found this ushanka hat.  :) #DayZDaily 

• Rise and shine! I'm waitin' for ya @Hicks_206 ! #DayZDaily 

 
Q: Will the standalone have the same 2D rain texture over the top of your screen as ArmA 2 on release?
Rain is currently being worked on for DayZ SA [source]
 
6th November

• Its been a long day, Dean has finally headed home - and its time for me as well. Can't wait to play with you all. #DayZDaily

 
5th November

• Mondays.. catching up on mail, check status of tasks pending from last week.. and taking in the sights. #DayZDaily 

 
3rd November

• I can confirm there will be bullets in DayZ SA #DayZDaily 

 
Q: When is the release date, is it November 5th?
DayZ will release once it provides the level of multiplayer performance and stability needed for us to have meaningful feedback from the experience. That isn't something that we just say is achieved, it actually has to be verified so that when we say it to you (by releasing) we have made, at the very least, a good faith assessment to confirm this.
 
The release date isn't a matter of deciding what day - its a matter of achieving an objective. The major obstacle in the way of that has been the network bubble.
 
I want to simultaneously derail the hype train and then recover it, in saying that we have finished making the network bubble. In fact, we have finished all major components required for an alpha release. However, we need to make sure they have integrated okay, and perform basic testing (a kind of acceptance testing) to ensure that we have actually achieved what we thought.
 
So please, please please - don't be hyped about a particular date, be hyped about our progress. Nobody knows the exact release date because there is not one. Once we have verified that we have achieved what we believe we have, and tidied up any integration issues, it will release. [source]
 
2nd November

• Oh lord, the zombies are so many and my crowbar is so small.. New engine-based Zombies are are an overwhelming success in MP test #DayZDaily
• So, it appears I can no longer use the docks in Chernarus coastal cities to escape zombies... #closeone #DayZDaily

Q: Engine-based zombies, what does that mean?
Scripted allows ~100 zombies, same as the mod in which they are locally controlled by clients. Native engine allows ~3000 zombies, all controlled on the server.[source]
 
Q: Can you provide any figures such as how many zombies would typically occupy a city like Cherno or Elektro?
Currently in the CBD of Cherno (there are four areas of cherno now), there spawns approx ~300 zombies [source]
 
Q: Why are the testers under NDA? I thought the closed alpha was not going to have an NDA?
We're not in alpha yet, so there is no closed alpha test. We're in pre-alpha. The NDA purpose is because little information tends to raise more questions than answers. Right now, the focus has to be on getting the multiplayer stability and performance needed for the alpha. [source]
 
1st November

• Sunshine in DayZ Standalone. Taken from our MP test today. #DayZDaily 

 
Q: I'd like to see some performance info, comparisons to the mod. Thats been one question on here asked a lot.. Get the hype train going again. Not some stupid screens of windows and looking at grass.

I can tell you now. Your mind will not be blown. But hopefully, it will be the good solid place to start. [source]

Edited November 30, 2013 by SmashT

[pr9inichek 252]

3000 zeds on server/ So little?

[SJKSJK 225]

Prudent business practice= release for the Christmas holiday.

You heard it hear first.

[Michaelvoodoo25 3120]

Remember Remember the DayZ November!

[SJKSJK 225]

When the ALPHA is released I have a feeling we will need to revisit the definition of ALPHA.

[zfleming12 395]

Sitting here half asleep from the lack of sleep last night, thinking....what exactly going to happen next? Is this the final lap? Ugh my brain is too broken today to think e.e

Edit: Okay now that I have had a few sips of cold tea.
 

With the new zombie system in place does that mean new zombies actions, movements, animations, etc or does that just mean that now they can be in large numbers and have a better pathing system?

 

Sorry for rather oblivious question in advance

Edited November 2, 2013 by zfleming12

[HumanBeing25 299]

I'm back. I've read Rocket's tweet about successful zombies - hopefully now nothing can stall the release much longer.

[HumanBeing25 299]

Would be nice if we could get a short 1 minute clip of the new zombies while we're waiting, and hopefully the zombies work like they do in Killing Floor the game.

[djshauny1 222]

Anything new people?

[zfleming12 395]

Anything new people?

Nope, it's Saturday so I believe people are on their weekend.

We really should start up the November daily thread or is smasht waiting on the devblog first? o.O

[voddler (DayZ) 367]

Anything new people?

There's some positive information about the zombies if you look at Rockets twitter.

https://twitter.com/rocket2guns/status/396339865735811072

 

This has been mentioned before by others in this thread :)

Edited November 2, 2013 by voddler

[Quanaril (DayZ) 114]

Or SmashT is thinking like "Nov 5th is 3 days away. No need for November Round Up thread" #conspiracytheoryforever

 

ps: I know alpha release is irrelevant to a round up thread.

[☣BioHaze☣ 7337]

When the game is released do the naysayers simply turn into generic haters?

[Wayze 549]

When the game is released do the naysayers simply turn into generic haters?

When the game is released the world, as we now know it, won't exist anymore.

Edited November 2, 2013 by Wayze

[RoKa89ARG 6]

TEOTWAWKI

 

my level of hype : OVER 9000

 

god dammit rocket, you have the network bubble, you have good zombies, release it !!!!

[Aporis 422]

TEOTWAWKI

 

my level of hype : OVER 9000

 

god dammit rocket, you have the network bubble, you have good zombies, release it !!!!

Still need to fix multiplayer performance and some teeny tiny tweaking, then if we can trust on rockets word its out

[djshauny1 222]

Still need to fix multiplayer performance and some teeny tiny tweaking, then if we can trust on rockets word its out

Wasnt that the whiole point of this network bubble? lol

[Aporis 422]

Wasnt that the whiole point of this network bubble? lol

Guess they still have some tweaking with that. lol

[HumanBeing25 299]

Still need to fix multiplayer performance and some teeny tiny tweaking, then if we can trust on rockets word its out

Trusting Rocket.. yea, I wonder where that leaves? :D

 

Wasnt that the whiole point of this network bubble? lol

He said something along the lines of "uh, oh.. um.. we um.. need a network bubble first.. uh, yeah"

[Elo 44]

Trusting Rocket.. yea, I wonder where that leaves? :D

 

He said something along the lines of "uh, oh.. um.. we um.. need a network bubble first.. uh, yeah"

 

He didn't, actually

[finalstraw 193]

Still need to fix multiplayer performance and some teeny tiny tweaking, then if we can trust on rockets word its out

 

I'm still curious as to how they plan to do seriously testing with only 20 or so people, surely the entire point of an Alpha is the larger scale testing. The lack of urgency to go to Alpha makes me think the game is still far from being ready.

Edited November 2, 2013 by -lOldBoyl-

[SJKSJK 225]

It must be nice to know you've got a HUGE paycheck to cash whenever you say go on the alpha.

[HumanBeing25 299]

It must be nice to know you've got a HUGE paycheck to cash whenever you say go on the alpha.

But Bohemia Interactive gets the profit, and Rocket just gets paid hourly--maybe THAT'S why he's been so slow?

[Zanders 65]

But Bohemia Interactive gets the profit, and Rocket just gets paid hourly--maybe THAT'S why he's been so slow?

 

Now your just being stupid and silly!

[Avallanche 121]

Now your just being stupid and silly!

Agreed.