Please remember that all assets shown are currently a work-in-progress.
We want to start off by thanking the community for their recent questions around performance and optimization. This is an extremely relevant conversation around the industry as we’re seeing the largest of studios struggle to meet performance goals as games become more and more complex to develop. We are very mindful of this, and our goal continues to be a smooth experience regardless of where you play Six Days.
Frankly, every developer is struggling right now with a convergence of contradictions. While it was acceptable ten years ago for shooters to play at 30fps, every player now expects at least 60fps. Players also want these games to display 4x more pixels, much more sophisticated lighting, more post-processing and special effects, and much smarter AI and physics—all while needing to perform at twice the speed.
This actually wouldn't be a problem if we could just build all our games for processors that can handle 4K graphics and sophisticated AI. But, the range of capabilities within PCs currently marketed as "gaming PCs" is very, very wide.
The only way to accomplish performance in a sophisticated game is through "multi-threading." Earlier game software would tell game hardware what to do through a single series of instructions that were sent sequentially to the computer's processors, one after the other. In contrast, multi-threading divides these instructions into separate threads that the processor handles simultaneously. For example, the game's AI might be on one thread, the game's rendering on another thread, the game's physics on a third thread, and the game's audio on a fourth thread.
The real challenge with multi-threading is that all these threads must stay in sync with each other. This isn't just so the audio from a weapon plays at the same time the AI has fired said weapon, for example. It's that all these instructions and data are flying around independently in all these different threads, and the whole game will crash if any of these threads gets a nano-second out of sync.
Performance can be examined under two different lenses—CPU and GPU—and we want to provide an update in each area, along with some charts our engineers use to help optimize performance.
Let’s start with an update on CPU. While Six Days is currently running at an acceptable “steady state” on average, we’ve also identified intermittent hitching that is represented by the pattern of spikes in the graph below. These hitches, albeit brief, cause slowdowns that impact player performance. After identifying when the game spikes, our engineers then investigate ways for the game to more efficiently handle the process that was causing each spike. A few months ago, we had more than three dozen separate factors driving these spikes. Today, we have just half a dozen.
We have a similar graph for our latest pass on GPU performance, and you’ll notice intermittent spikes in this area as well. Like our CPU spikes, we've eliminated the vast majority of GPU spikes during the last few months. For example, we found that some of our graphics systems were calculating certain processes during gameplay and throwing them away, rather than pre-calculating them and then caching them for future use. As you can see, there are still a few spikes left to fix.
Let’s round this entry out with a discussion on networking—more specifically player connectivity and matchmaking. For context, players can find others to play with in two ways. The first is through our automated matchmaking systems, which try to optimize which players to join together based on their internet connectivity. The second is through invites sent directly to their friends or to those they've played with recently.
We recently hosted a studio-wide playtest to test our matchmaking feature and identified a bug that would sometimes cause lobbies to form with only 2-3 players, even if there were 4 players available to play. This has already been fixed, and players can now matchmake reliably into full fireteams of four players based on our testing so far.
As far as game invitations go: we’re tweaking our in-game notification system to allow for a number of special use-cases when players invite their friends to play. Currently, when invites expire, notifications are dismissed for both the sender and receiver of the invite. This isn’t super helpful when a player receives a Steam invite before launching the game, for example. Improvements we’re making to the UI can better communicate where invites are sent and how long they remain valid.
Of course, with a team of more than 55 people currently working on the game, these items are just a sampling of the work we've done during the past few weeks on Six Days.
