Road to release #8
April 5, 2016 Ubergames
Greetings former and future denizens of Agon,
This week’s update is going to be about growth at all levels, be it at the project level as a company, but also within the game as a player or regarding game performances.
We have done some steady progress on our ongoing tasks and have put to work our new employees on improving the first impression a player would get when trying Darkfall for the very first time. We have also welcomed another new team member that will be dedicated to monitoring and metric analysis tools for our server infrastructure, and later, for balance and economy management systems. He will also be of great help for scalability and other server infrastructure improvements.
Overall, we’re on track with our expectations, now that we have the full source code we can progress unimpeded, and our velocity should only increase from now on since we can now legitimately parallelize our development efforts.
What we have done:
- We have done a first iteration of hardware monitoring tools.
- We have improved our deploy scripts and infrastructure to have several internal servers to increase our QA and continuous delivery abilities.
- Progress on preparing the client’s distribution is slow but steady. The patch server is looking good, but we need to complete everything around it.
- We had our new team members make a presentation on their first experience in game and start work on solving the issues they noticed.
- Which means we have a very small but meaningful day one patch ready to go with only quality of life improvements.
- We are continuing to grow our team, widening our skill sets to incorporate new resources that will be useful for the future.
What’s next:
- Completing our blocking tasks to distribute the client. Sleep is optional until then.
- We can now switch to work on software monitoring tools, in preparation for the stress test.
- We will continue to work on our early patches, as it occurs in parallel with our InDev work.
- We would like our website rewrite to come along some improvements, including a darker theme for the forums.
Growing the New Player experience:
This week, we’ve been asked on our forums about our intents regarding the tutorial and, in general, how we intend to make the game more accessible for new players. Which was coincidentally the theme of our week internally.
Last week was the first week of two of our new recruits, and their first task, once they got setup, was to just try out the game with a completely fresh eye.
They come from outside the Darkfall community and their gaming background is in games like Darksouls, hardcore hack and slashes and real time strategy games. These are no carebears, they just never got the chance to play Darkfall before. We made them note every little details that bugged them and prepare a presentation about how their first impression felt.
Their conclusion was: “If it wasn’t our job to try the game, we would have rage quited”.
Of course, this was to be expected, as even back in 2009 the game was already criticized as a very clunky experience, and nowadays in 2016 standards are much higher. On a positive note, they both recognized the potential of the game and are looking for more. The early quests actually were praised for how they show many aspects of the game and how the system was worth expanding upon. We have a tall task in front of us to smooth out the first impression a player has in our game. Which is why we assigned them, for now, on quality of life tasks. It is a great first dive into the code base for them, but also, who else but new players could be in charge of improving the new player experience?
This shouldn’t impact our early updates, since they are added resources, and there will be a bit of QOL in each patch, accompanying gameplay features that serve veteran players as well as newer players. We feel it will be a much welcome, if not necessary, bonus for our early roadmap.
Growing the game’s performances:
In the same vein of reacting to player comments, we’ve been asked about making a 32bit to 64bit change, and all we could say then was that we had to choose our battle, and that we chose dx11. We figured that it may be an interesting read to explain our motivation.
The first part is that server side, porting to 64bit is in our opinion not only useless, but also dangerous.
The main advantage of a 64bit architecture, and the one most commonly sought after, is the ability for programs to assign much more memory. The way the technology is setup, each physical machine hosts up to several dozens smaller programs that handle various specific tasks. The individual memory of each program doesn’t need to be that large, and it is better to increase the server performances by adding more hardware and spawn more copies of the software. At this point, we don’t even know what the bottlenecks are, and this will be the purpose of the stress test to determine.
As of the risks involved, you wouldn’t want one of these program to be able to grow and eat up all the physical memory of its host. It is better to have it crash when it reach its limit and not impact the rest of the cluster. Another risk is the need to upgrade to 64bit version of all libraries, which could potentially have a wide variety of side effects that would be very hard to pin point and not worth the efforts.
However, on the client side, there is a potential advantage to switch to 64bit.
As the overall assignable memory is shared between graphical memory and ram, memory can become a bottle neck. A bottleneck that is often handled by loading and unloading assets based on use, which contributes to the loadlag. But to make 64bit work, it wouldn’t be enough to just switch compilation flags, we would need to adapt all libraries and handle any potential side effects, then drastically change the way asset loading works in the game to see any benefits. This would require heavy changes for no guarantee of results.
Which is why we chose to go for dx11. By adapting from dx9 to dx11, for equivalent efforts, we would have guaranteed improved performances and at the same time access to improved graphics. It would also facilitate the parallel loading of assets which would alleviate the load lag too. In addition, from our investigation, it will most likely be better to refactor for multi threading before even considering a switch to 64bit.
We hope you enjoyed this week’s insight in our decision making. See you next week.
Link to discussion thread.
.
