Q: What about server hosting?
One of the reasons I think DayZ mod works is because responsibility (and reward) is divided, and "survival of the fittest" is alive and well.
We aren't in the business of managing servers. We don't have the skills or the background in the studio for that. We don't feel we need to own the revenue stream for everything, it is in the best interest for us - for there to be competition for hosting and providing the best, most economic, responsive, and active server's out there.
Q: Does the MMO architecture of the improved ArmA2 engine for standalone decrease the need for so much bandwidth when hosting a server? Hive and Player communication requires at least 2TB of bandwidth a month, from what I have seen?
The servers have been greatly optimized with an entirely new executable that runs on a light version of the game data (reduced up to 99% in some cases, drops all kinds of data the server doesn't need like textures). This means the server file is much smaller, reducing reading times for pbos, the optimization benefits are too numerous to detail here. This work is already done, and working, in the standalone.
Q: Will configuration of server settings be more simple?
There will be more options, and enforcing many settings will be done from servers. In some ways, it will be more simpler because there is no mission file. Also, you don't need a special mission file to support 50 or 150 or 200 players - just change the config value and go.
Q: Will hardware requirements for servers be significantly different?
The same or less, for greater number of players, is what we currently estimate and is absolutely our goal. But we need to see how it goes in the technology test - that's why we're doing this small scale test to find our left and right arcs.
Q: Will there be NZ servers at release?
I will personally be funding some NZ servers if OpenHost don't shit all over me again like they did with my USEC server (after 10 years as a customer, paying about $2000 a year)...
Q: Ability to use callExtension on *nix would be nice.
Everything is integrated into the executable now, no need for callExtension.
We want to have Linux as our preferred dedicated server executable, for obvious reasons.
Q: How are you going to prevent admins using admins tools to their advantage?
A: We have to start again from scratch with the implementation of these kinds of issues, with the standalone. But we have the lessons from the DayZ mod hacking problems. It is something that will continue to evolve and the reason for a staged release (and a delayed one for that matter).
Q: Is the humanity system going to be changed?
A: Standalone is changing so many elements of the game, it's best to stick with something "similar" for the initial release and then commit to experimenting and changing it until we find something awesome and it works. We are committed to doing things properly, instead of taking things that were written around the engine (often involving many workarounds and much complexity using arma's invented SQF language) - we are saying "what result do we want?" and then giving that to the programmers, and getting them to come up with the best solution. We'll take the lessons from DayZ Mod regarding these features, and code around them at the engine level. It is going to mean it takes longer, and needs more experimentation - but make no mistake, that will mean the difference between DayZ being a mediocre game and being something really special for the history books.
Q: What about character customization?
A: Well, you'll be customizing your skin as you scavenge - with different items of clothing. So skins are now a collection of may different clothing parts, greatly increasing diversity among characters.
Q: On stats (referencing shizweak.com server stats)
A: very cool. We always wanted to do this for the mod. Makes me more than ever want to not do this at the development level, instead we build a good API and let you folks do what you do best.... innovate.
Q: Have the zombie mechanics/behaviour improved?
A: For the development we decided to start with the riskiest prospects - i.e. the major sweeping architectural changes such as an entirely new inventory and object interaction system, an entirely new multiplayer framework (server/client). It is true, currently we haven't really looked at the zombie mechanics at all aside from:
1. Improving the animations
2. Redoing the models for performance improvements (quite drastic improvement on low-end cards)
Why?!?!? Because we know we can make the zombie AI better. We want to get all the tough things out of the way first. Will report back on this further when we have started the rework on the zombie AI.
To manage expectations further... it is probably going to take many months of patching and experimentation to get the zombies something at the acceptable point. Acceptable being "zombies are a serious threat to players". For the sake of example, Ondrej Spanel (lead BIS programmer) and others have still been patching ArmA2:OA AI in recent weeks, many years after the product was released. The AI will be revamped for this release, but then patched again and again to improve further. Zombie behavior is the weakest part of standalone right now, but it's also the least risk for us - because it's been done before in the engine in other projects.
