Star Citizen Technology Interview: Gaming for HW Enthusiasts Star Citizen HUD

When left uncorrupted by the technologically-crippling nature of consoles, PC gaming's propensity for visual and mechanical immersion provides an unrivaled entertainment medium for gamers. Even the cheapest, most stripped-down budget gaming PC has technology that far-and-away surpasses the capabilities of the current-gen consoles. Transistor count alone is indicative of the vast leaps made in the last 7 years: the Xbox 360's original Xenon CPU architecture (168mm^2) uses 65nm manufacturing process and sits on 165 million transistors, where a current-gen, 22nm 3570k offers 1.4 billion transistors on a 113mm^2 chip. Smaller, lower TDP, and more processing power.

Unfortunately, all the technology in the world doesn't matter if enthusiast-grade hardware is underutilized by console-bound games. Luckily, there are still game developers out there who push the limits of PC hardware: Crytek (Crysis), THQ/4A (Metro 2033), Creative Assembly (Shogun 2), and Cloud Imperium Games (Star Citizen) all provide tech enthusiasts a means to get the most out of new components.

We interviewed Chris Roberts, the lead space enthusiast behind Star Citizen, to discuss the game's technology, some of its gameplay mechanics, and their support of PC gaming. The game recently secured over $7m in crowd-sourced funding, split between more than 100,000 gamers. If Star Citizen isn't on your radar yet, it should be.

We covered topics ranging from the viability of SSDs for gaming (see also: "Do I need an SSD for gaming?") to multi-core utilization in game software, but before that, here's a brief overview of what Star Citizen is:

What Is Star Citizen?

Star Citizen is an up-and-coming space sim game built atop a heavily-modified CryEngine 3. The game aims to present space combat and space RPG elements in a scale we've never seen before, promising full FPS gameplay, dogfighting, and even teasing "on the planet" play.

It's impossible to adequately summarize all of the features we discussed with Chris Roberts in a single post, so I'll cover the items I personally find most intriguing:

In terms of scale alone, the game will be playable from the player character level all the way up to the giant battleship level; you can walk around the insides of a carrier (think Battle Star Galactica or Star Wars scale), interact with the ship, hop into a local defense fighter in an emergency, man the turrets, and even board enemy ships in first-person mode (it is CryEngine) and disable key systems, then spacewalk back to your docked ship. The game is customizable to your playstyle - mercantile work, piracy, and military are all viable approaches to play. It also features massively multiplayer systems (not in the traditional MMO sense) that will implement a persistent, evolving universe in the truest sense. The scope is gargantuan. Completely impossible to convey in a reasonable amount of space, so we'll let this video do the talking:

Now, the game's not made yet -- the team has at least two years ahead of it for an initial release, though alpha/beta has been promised within a year for early backers of the game. It's tough to separate hype and cinematics from the real play experience (all the features in the world don't necessarily make a good game), but if nothing else, things are looking promising; in fact, a lot of features you see in the trailer are interactions that will happen in the game, albeit in first person. Here's another video to help give some perspective on gameplay:

I'll reserve my comments on his use of an Xbox controller.

We'll keep the rest of the speculation and in-depth mechanics discussion for future articles, but for now, let's stick to the scope of the game's underlying technology. Here's the order of topics, if you'd like to skip around:

CryEngine's multi-core utilization, accurate physics, and quad-core preference.

SSD discussion as they pertain to gaming; the future of gaming and SSDs.

Supported interfaces (Oculus Rift, stereoscopic 3D, Leap Motion, etc.).

Visual FX, graphics, and rendering tech in CryEngine 3.

"What kind of computer do I need for Star Citizen?"

Conclusion and other thoughts.

Time to take a look under the primary buffer panel.

An Engine for Enthusiasts: Multi-Core Utilization, Accurate Physics

When we recently looked at BlackSpace's technology, we were happy to learn about hardware-software interactions and get developer insight on the acceleration of high-end hardware support. As companies like nVidia, AMD, and Intel continue to offer resources to game developers (even indie startups), we've seen a larger push for SLI/CrossFire, 3D tech, multi-core utilization, and SSD support than ever before.

One of Star Citizen's fighter renderings.

Star Citizen aims to continue this trend. The game will be powered by a heavily-modified version of CryEngine 3, perhaps best known for its advanced graphics capabilities (HDR lighting, volumetric FX, SSAO) and native eight-core support.

CryEngine 3 is constantly receiving updates from Crytek, but as it stands now, the engine runs a separate physics thread, game/logic thread, and rendering thread, and occasionally spawns additional threads on an as-needed basis. Chris Roberts had this to say about multi-core support:

"Right now, whether you're on an i5 or an i7, you definitely want a quad-core CPU or better. Those cores are being used. In the setup we've got right now, there are at least three threads being used and it can go to more than 4 threads sometimes, but on the game side, 4 threads [max] is kind of where it's at."

We regularly receive the "i5 vs. i7" question on the forums, and while many games actually see a (very small) performance hit on the i7 due to hyperthreading overhead, Roberts hopes to utilize all the threads he can get his hands on: "Going forward, there should be an advantage with hyperthreading in gaming. I've got 6 cores and I'd like to use them all properly."

So the game can scale upwards nicely, due to native eight-core support on the engine's part, but I was still curious about the part that APUs and IGP-enabled CPUs might play in Star Citizen's future. AMD's A10-5800k APU is easily OC'd and is equipped with a 384-core (800MHz) 7660D GPU, which is certainly nothing to be laughed at. Intel's HD4000 is an admirable first step into the integrated market, but still has a ways to go before we'd recommend it over AMD's options for integrating gaming. CryEngine 3 scales well, but Star Citizen's focus on visual fidelity was cause for the question; here's what Roberts had to say on integrated chips for his game:

"I don't think they're out of the question. The [HD 4000] won't do it, but the way things are going, Intel or AMD may have an IGP/APU solution that's good enough to play this game in a year or two. I wouldn't rule it out at all -- probably by the time the game comes out, the IGP solution on whatever the new chip is will probably be able to run this game decently; not great - not as well as on a dedicated GPU—but on low settings?—yes, it's possible."

They're powerful chips and make for great living room gaming machines, so we're hopeful. We'll run benchmarks on modern chips once the game's out, of course!

CryEngine 3 also runs a software-side (non-accelerated) physics solution that Star Citizen will use to simulate real-time rigid body physics interactions. Each thruster will apply an appropriate amount of propulsion to respond to the player's input requests.

The thruster calculations are dynamically simulated, so if an enemy blows out one of your fighter's six thrusters, the ship will respond by dragging on the side corresponding to that thruster. This presents interesting gameplay mechanics for combat: Rather than simply blowing the enemy to smithereens, you could target their ability to move, target sensors, target all kinds of individually-checked components within the game, then commence piracy or raiding / boarding / thievery as desired. This also supports Roberts' focus on player skill rather than "bigger is better" for a ship approach -- a squadron of small fighters might be able to completely immobilize a massive Constitution-class ship, for instance.

A Move Toward SSDs for Gaming

After our exploratory "How SSDs Are Made" article with LSI / SandForce andKingston, we've kept a heavy focus on explaining solid-state drive functionality. The GN team is in complete agreement: SSDs are the next break-out component in the consumer-side PC gaming world. There's no excuse not to have them in any mid-range or better PC, and at this point, we've often recommended cutting costs on other components to invest in an SSD. It just doesn't make sense to run a 3570k, GTX 670, Z77 board, and be throttled by mechanical components.

Another rendering - this time of the Constellation.

We're always eager to hear from devs if they see a clear path to SSD utilization in games, and when it's a PC-only game, the answer is almost always "yes." Games that are developed for consoles and later ported don't really show any major gain, of course -- Skyrim was a difference of maybe one or two seconds in our load tests -- but high-end PC games will more readily exhibit those differences.

Just Cause 2 and Shogun 2 are fantastic examples of games that have significantly decreased load times on SSDs, given the large amount of data they're pulling. SSDs also help cover for memory limitations, cache misses, and caching out in games that stream data, like Just Cause 2 does (no loading screens when wandering around -- it's all streamed in cell format, a la the TES series).

It all comes down to the way the game handles its content loading. Whenever you see a loading screen in a game, it is almost a certainty that non-volatile storage is being accessed and files loaded into memory; that memory is then referenced for almost all interactions contained within the level/map that was loaded. In the case of games that don't use traditional "zones," to steal an MMO phrase, and loading screens, but rather stream data from non-volatile storage for constant cell/chunk updates, storage hits will be infinitely more noticeable.

For example, if you've modded Skyrim to use high resolution texture packs with large file sizes, you may notice an instance between cells (take the Whiterun/Riverwood transition) where there's a jitter or interruption of fluid movement. This is because the game is dumping data from one cell and loading data (from storage) into memory for the new cell; if you're on a mechanical drive, the drive has to physically move the header to each file's location on the platter, send that data to memory, and then jump to the next file. The best GPU in the world won't bypass that problem.

A side view wire/rendering of a carrier.

SSDs will, though. This potentially delves into deeper SSD spec discussion, so we'll point you to our "Understanding SSD Specs" article for that, but I want to briefly discuss how to prioritize specs for SSDs in gaming applications: We're all familiar with the IOPS vs. Sequential argument at this point -- sequential read/write operations benefit from increased transaction speeds, whereas random I/O operations are harder to measure in pure MB/s due to their, well, randomness. With exception granted to cut-scenes, games will almost exclusively be represented by prolonged 4K random read IOPS performance on SSDs. This is because games are loading countless relatively small files, which are then assembled to build the experience we're presented with in-game. Mechanical disks suffer during these tasks when heavily fragmented or otherwise occupied due to the sheer number of items being loaded (as opposed to a single, large sequential read).

I was elated when Roberts went into the SSD discussion without being prompted -- it's normally something I have to specifically bring up, but this proved to me that SSDs have come to the forefront of system building:

"For me, the big performance difference is an SSD. If you're going to invest some money in a system and your choice is a mechanical drive and an i7 or an i5 and an SSD, take the SSD every day of the week. That's going to be a massive performance difference. SSDs are definitely going to matter in Star Citizen because we're PC only -- we're going to be doing a fair amount of streaming, so... you know, you're going to be sitting on your hard drive. If you ever get into memory issues and you're caching out, then obviously it's much better on an SSD than an HDD.

I think part of the issue with a lot of games is they're built for consoles and they're constrained, but we're not. So an SSD is going to have a lot bigger impact on the Star Citizen experience than maybe it would do on another game. If it's a game that's specifically for a PC and it's heavy, then an SSD will make a big difference for you."

We also delved into level/loading methodology, though that's all still in discussion among the Star Citizen team. For now, here's what we know about "level" loading plans:

"I'm trying to see if I can have a fully-continuous universe where we just load in 'areas.' The higher-level concept is that areas stream in and out as you fly around. Imagine each area in space as being a section, or sector, or square -- and that area is streaming in. In a lot of cases that area will be an empty area, but in some cases it might have asteroids or a space station, or something like that."

If it works out as he plans, you can think of Star Citizen's "area" model as similar to Skyrim's cell loading methodology. Cells stream in and out of data as necessary in favor of a more seamless experience. Because Star Citizen will be primarily composed of empty space (as opposed to a filled environment, like any non-space game would have), that means the majority of asset data streaming will be centered around objects, like ships, asteroids, space stations, and other items that are summoned forth by procedural generation. A player entering your area (in multiplayer mode) with a large, uncached ship is an example of when storage will be hit. The faster you can access storage, the faster you can render that player on the screen.

Star Citizen's Supported Interfaces, 3D Technology, and HUD Design

An early concept of Oculus Rift.

System internals aren't the only item on the menu for Star Citizen, though. Along with all of its mechanical ambitions—FPS boarding gameplay, flight systems, crewed battleships, and planet-side missions—the game also hopes to fully-integrate all the control interfaces they can reasonably support. Here's a quick list of what we know -- though I'm sure we've left something out:

Support for Leap Motion, the motion sensing input mechanism; can be used to slide items around between multiple monitors and interact with the HUD, among other things.

Support for Oculus Rift, the new VR headset.

Support for 3D Vision and other non-proprietary 3D tech.

Support for HOTAS (Hands-on Throttle-and-Stick) input; support for other joysticks and gamepads.

Support for flight chairs and rudder pedals.

And of course, support for the trusty keyboard and mouse.

Roberts excitedly attempted to convey the experience of playing his game while equipped with 3D glasses and the other exotic peripherals, though conceded that these technologies are nearly impossible to explain without simply trying them:

"The HUD system is specifically designed to work inside of stereoscopic 3D. It's actually much cooler than, say, playing Crysis 2 in 3D, partly because space is perfect for 3D. If you watch any 3D movie, it's usually the flying sequences that tend to be best because you have distinct objects at different depths and you don't have the crosstalk of the rest of the environment or scenery that you get normally. You have the HUD and interface floating sort of in front of your eyes, sort of like Minority Report style, and you can see the cockpit around you -- it's really cool, one of the things where I think Oculus Rift will be awesome with Star Citizen and Squadron 42. The key thing with Star Citizen is you're not really running around that much, most of the time you're sitting in a seat -- in real life, you're also sitting in a seat -- so if you've got Oculus Rift on and a joystick in front of you, that's about as close to VR as you get, it will feel very natural.

The only thing that sucks about it is it's not really very easy to demo, it's a personal experience; you have to put the goggles on and do the experience yourself to try it out. Because we have stereoscopic 3D already supported, it's going to work very well with the Rift - you have zero crosstalk because you're essentially simulating exactly what happens in the real world."

For those who remember our 3D Vision review, you may recall issues we had with z-fighting (tearing/flickering textures) that required the disablement of key graphics options -- high-quality shadows, motion blur, AO -- in order to properly play certain games with the glasses. This was primarily a result of the games' programming/art assets, not necessarily the technology. The 3D software and hardware were unable to adequately interpret the multi-depth interference between objects/textures that were not created with stereoscopic 3D in mind. This wasn't necessarily a fault with stereoscopic 3D interfaces themselves, though it did often prove to be more effort than it was worth to properly tweak settings for compatibility.

This is all very different in Star Citizen for a few reasons: First, CryEngine has a global 3D software solution built-in, meaning support from the get-go; second, Star Citizen is a space game, and as Roberts mentioned above, environmental crosstalk is minimized given the game's existence in large, mostly-empty space. With Star Citizen's high-quality, high-resolution assets and detailed models, we suspect that the "3D experience," as long as it's supported throughout the dev process, should be more engrossing than all the games we've seen ported to PC in recent years. Cockpit-centric gameplay only helps further the game's feasibility as a stable 3D platform.

Continue on to page 2 for Star Citizen's HUD Design, complete with a HUD screenshot!