To be determined: Minimum Specifications

Notice the terrain popping? We’re definitely working on that and other performance offenders.

 

Hi everyone. I’m Zabir and the newest member of the System Era team. My primary role at System Era will be to lead the engineering efforts going forward. Jacob and Brendan have done a great job on this front and I will attempt to lighten their workloads. However, with such a small team, all of us will continue to wear many hats. In this blog post I wanted to talk about two ways we are preparing for Early Access from a high level engineering perspective. It isn’t the sexiest part of development, but here is my process.

Engineering is an exercise in trade-offs between optimization and flexibility. 

First step of Early Access is to determine the quality thresholds with regards to performance and bugs. We want to balance optimizing for lower end hardware vs. wasting time optimizing features that may end up being cut or redesigned. Optimizing code also has a tendency to harden it – limiting the flexibility to suit design needs. We want to leave the door open for changes and only lock down finalized items.

We use the Steam Hardware Survey as a guide to actually select the min spec hardware. This monthly survey shows us the current range of hardware actually being used. We are targeting middle of the road goals and performance/min specs will only improve post Early Access launch. I’ve only worked on AAA games in my career, so it’s a strange feeling knowing we will ship Early Access less optimized than ideal leading to higher min spec on PC and lower frame rate on Xbox One.

The quality threshold  for bugs is similar to performance – we want to certainly fix major game breaking bugs, but are not super concerned with everything being polished. We’ve defined our bug priorities as such:

  • P0 – Crash bug, consistently reproducible. Or completely blocks game play progress.
  • P1 – Crash bug, not consistently reproducible. Or significantly impacts game play progress but worked around exists.
  • P2 – Impacts gameplay, but not always noticeable or easy work around.
  • P3 – Items to re-prioritize aka backlog.

 

We will use these categorizations to triage and prioritize our bugs. The goals is to not ship Early Access with any known P0s and fix as many P1s that time allows. We fully expect there to be issues, but more importantly we will make sure our forums and Trello board is fully functionally at launch for you to report those issues and find out what we are doing about them.

The second step of Early Access is to continue feature development based on your feedback. For example, you’ve already told us is our game “pops” – and not in a good way.

 

In the February timeframe I’ll begin experimenting with different LODing techniques and keep you updated on how those experiments go. I want to reuse our bug reporting tools to gather feedback and report progress on the feature development we do post Early Access. This blog will also be a channel to take a deeper dive into particular features.

Thats a high level look at two planned engineering efforts we have undertaken to make sure we can deliver a successfully Early Access. I’ve been programming professionally for 7 years at Epic Games, 343 Industries, and the DirectX team. I’m drawing on that experience to ensure our success but I can’t promise I won’t make any mistakes. I can promise that I will be honest – I will be genuine and through that hopefully you will gain an appreciation for the love, sweat and tears we are putting into Astroneer.

-Zabir

PS: Be sure to follow me on Twitter!