As an add-on to this article and video, we would strongly recommend reading or watching our previous “Star Citizen Zoning & Instancing” interview, as it is cross-referenced several times during multi-crew talking points.
The above video spends a significant portion of time covering game engine overhauls to allow CryEngine's full cooperation with Star Citizen's demands. Once these basics are overviewed, Roberts dives into the specifics of multi-crew combat and provides a play-by-play of the team's upcoming Gamescom presentation. We've gone through the most critical points and recapped them below, for those who'd prefer a written version.
Star Citizen's 64-bit Game Engine and Logistics
(Above: A block diagram of CryEngine's art compiler).
CIG CEO Chris Roberts immediately indicates that “all the studios around the world are working on multi-crew,” further stating that “we're going to show the next generation of it at Gamescom – that's in about three weeks' time or so.”
Multi-crew fuses all the existing modules into a build that will begin to resemble Star Citizen's core mechanics. The new module is linked by dependencies with the forthcoming “Star Marine” FPS patch and previous Arena Commander (“Dog Fighting module”) releases; multi-crew cannot exist without each of the prior modules. This makes multi-crew uniquely complex.
Roberts cites the move to a 64-bit engine as a major milestone for the Cloud Imperium Games team, emphasizing that the move to 64-bit will allow greater precision and size for positional space. Of the move, Roberts said:
“There's a bunch of stuff that's really exciting. [The move to 64-bit] is less about 64-bit compile [and] more about 64-bit positional space […] Pretty much every 3D engine works in 32-bit, which is great for a normal FPS – because you usually don't have maps that are bigger than, say, 8km x 8km – but for us, we've got star systems that are millions of kilometers across and the precision of 32-bit just isn't enough.
We've spent about 8 months now – it's done – moving the engine over to 64-bit world space coordinates. The last part of it was moving rendering over so it became camera-relative. The GPUs themselves generally don't work in 64-bit – they work in 32-bit – but since you generally won't be able to see millions of kilometers away, the visible range is inside 32 bits, but the overall system space is much bigger.
[…] There's tens of thousands of files, so it took a while.”
Most current GPU architectures utilize a 32-wide asset warp (also called a “wavefront” by AMD, both of which indicate a collection of threads), though some new architectures are making the move to 64-asset wide wavefronts or warps. There's a lot more to it than that, of course. The matter of GPU architecture and its software link is something we discussed heavily in our recent AMD R9 Fury X review, for those curious about a hardware-level overview of gaming-centric limitations.
Speaking to data structures and containerization for Star Citizen, Roberts revisits the topic of instancing and zoning at around 3:00 and again at 4:15. This was discussed in detail (for about twenty minutes) in our previous interview. Roberts once again highlights a challenge unique to the space sim genre:
“At Gamescom, we're going to be showing a world map – just a small portion of it, but if you were to fly from the starting location to the ending location, it'd take you two-and-a-half hours at top current dog-fight speeds. I think it's several hundred thousand kilometers in distance; we'll do some sort of a quantum jump between them, but it's all on the same map and the same scale. What's really nice is we've got [the 64-bit move] and the second piece of technology that the engine group has built, which is called the 'zone system.'
One of the big challenges – and this is something we definitely need for multi-crew – is the zone system is what enables us to handle sparse / dense data. In most FPS games, it's 8x8km, the density of the level is very consistent […] there's a lot of objects and interest in small areas. In space, you can have huge areas of nothing and then areas of high density, like a space station, an asteroid, or a big ship with people inside it.
We needed a method of handling this data and culling it, updating, and organizing it in a way that was optimal. Typical engines use octrees, which aren't not good for the sparse data we have, so we […] break things into zones. You can have a big multi-crew ship – everything attached to it is one zone, inside is another zone, and that ship can exist inside space – like around a moon, [also a zone].”
Roberts explains that the zoning system is a means for containerization of game data, ensuring data streaming and dumping of content resultant of the player's actions and location. This allows more efficient rendering on a per-user basis as the game will cull-out (won't render) data that the user can't meaningfully utilize.
The CIG CEO further notes that this tie-in to visibility culling is “the only way to get really big capital ships and [bandwidth] heavy multi-crew ships working properly, [and] is one of the reasons the hangar can run slowly with big ships.” Roberts tells us that the old models for the Constellation and Freelancer are ~2.5 million polygons each, with ~1.5 million comprising just the interior. In a real-world scenario, only a select few clients will need to actively render that interior geometry, the textures, and other data – easily comprising hundreds of megabytes – and so that space is instanced for those players. An outside ship, although it might be engaged in trade or combat, does not need to see the toilets and geometrically intensive interior of its opponent.
Roberts walks us through the old rendering pipeline to underscore the importance of the new zoning and instancing system:
“The way it was done originally was very brute-force: It just all gets thrown in the renderer and it decides what it's going to cull-out; whereas our newer system has that all plugged-in to the zones. It's intelligently culling-out geometry, objects you don't need to update if you can't see them […] that's what enables the promise of Star Citizen – these huge, massive areas. […] It's all there in a detail you normally don't get.”
Later in the video (7:00), Roberts tells us that some initial data streaming tech is in Arena Commander 1.1.5.
Star Citizen World Map & CIG's Gamescom Plans
(Above: Part of the interface revealed at PAX South).
Buried in the above engine discussion is an important spoiler: Star Citizen's world map is slated to be revealed at Gamescom, if all goes to plan, and will give players an interactive look at the game's universe. At around 6:13 in the video, Roberts rapidly talks through an outline of the team's hopes for Gamescom:
“We're going to show [multi-crew] at Gamescom: You're going to start in a space station, you're in a room, you get out, the space station is huge – you'll see this gas giant outside, you'll go out to the landing pad, get into a cutlass with your friends. They'll all get into the Cutlass – which will all be its own zone running in the local grid – this is why we have the physics partitioned for each individual ship, so it can fly around and you can be moving around the ship irrelevant of where the ship's going.”
When asked if loading screens will appear between these transitional periods, Roberts firmly emphasized that all data will be streamed without interruption from loading screens.
The Cutlass' interior should be running its own instance independent from the outside, both physically and visually. It is our understanding that shots fired upon the hull of a ship may be reflected internally to occupying players, but that physics processing will be individually computed on a per-ship basis. This reduces client-server load and frees-up bandwidth in the pipeline.
Arena Commander – the dog-fighting module – has hosted a very limited player-count through now, but just shifted to initialize 8v8 support. Roberts explains one of the primary contributors to the current player count limits:
“One of the issues with more players in Arena Commander was that all the ships are really heavy [(geometrically)]. When you blow a ship up and recreate it, just building that ship takes a bunch of time on the main thread and that creates a stall both on the client and the server, so that's where you get this lag when you play a match and you see ships skip. We've been working to stream stuff in the background; even though it's loading lots of data, it's not stalling the client or the server, so that will reduce lag. There's still a lot more work to be done for it, but it's built to be dynamically streaming background.”
Tentative Timelines for Multi-Crew Free Flight
Roberts hopes – but hasn't fully guaranteed – for a Gamescom reveal that shows the player character walking around “in incredible fidelity.” Spoiling AC 2.0, Roberts envisions that players will be able to get into their ship, fly somewhere, exit and EVA to another ship, and so forth.
At around 8:00 in the video, timelines are tentatively brought-up for the forthcoming Star Citizen FPS and multi-crew modules:
“Our goal is to get Arena Commander – the multi-crew stuff – out four to six weeks after the FPS drops. We have some integration to do because FPS is on a separate code branch right now [from] the multi-crew stuff, so once FPS is out, we've got to drop that back into the code branch, integrate it, get it working again, get rid of any conflicts or bugs or problems, and then finish multi-crew. Our real goal with multi-crew is [to] have huge maps and just set it up in a free-flight mode and have places for people to play around and see what happens. It's really going to be a playground to see what the persistent universe is like.”
For those who didn't see the FPS progress update, it is tentatively anticipated that the FPS module will launch sometime in the next 3-5 weeks. Chris Roberts strongly emphasized that all timelines are, again, tentative and should not be regarded as hard ship dates. In the FPS update interview, Roberts explained that CIG's development methodology is fairly transparent and that these are dates which would normally be considered “internal.”
Concluding the interview, Roberts reminds us that the “original intention of Star Marine [and other modules] is that they're testing grounds for the bigger system.” Roberts hopes that players are as excited as he is for the progress:
“I'm really excited by where we're at with multi-crew. Hopefully people will be impressed by what they see when we show them at Gamescom. It's a real system that has extensibility and we're going to show you getting into one ship, taking off, flying, EVAing into another ship, powering up... All the stuff you've seen in machinima videos and have thought 'if I could do that in a game, that would be awesome.'
I'm super excited because a lot of the technology we've spent a lot of time working on – that you really can't show because it's deep down in the bowels of the engine – is now coming to fruition. […] You haven't had the ability to ever do this in a game before.
Last year, we hadn't had Arena Commander out and we thought we'd have it out closer to March / April, again, like Star Marine. It was getting pretty rowdy on the forums, [but] then we dropped v0.8 of Arena Commander and then the rest of the year went pretty well. […] [Fans] could see there were visible changes and alterations in gameplay and that we were responding to what people were saying.”
Addressing questions regarding the relative silence over the last few months – this is at about 12:00 – Roberts recaps 1H15's events:
“On the AC side, we stopped updating it maybe in April or May – shortly after PAX East. We thought FPS would be earlier and we didn't want to overload the QA guys. At the time, it looked like the FPS patch could drop five weeks after the most recent AC patch, with a 2-3 week cadence; and, of course, FPS took longer and we never went back and updated Arena Commander.”
1.1.5 was just deployed.
Roberts notes that, following 1.1.5, an incremental 1.1.6 is anticipated within a few weeks' time, going live at Gamescom, followed by Star Marine (1.2.0) on the PTU. Star Marine lives on the same codebase as Arena Commander and will begin the process of integrating Star Citizen's various subsystems.
“Tentatively, I'd think that multi-crew potentially is a CitizenCon release. Again – tentatively,” Roberts laughs.
“I think it'll make a big difference because, right now, everyone judges the space combat flight experience in the microcosm of single-seater ships flying around […] we have to have control schemes and systems that handle everything. It's pretty hard to judge where everything sits until we get them in – like, is this ship overpowered or where does this ship sit in the overall scheme of things? […] I'm really excited to get multi-crew in there because it opens up the palette.”
In the more distant future, escort missions are expected for deployment as an early test for the mission system's integration with other modules.
As we've stated countless times before, Star Citizen is still in full development and is not presently in a state representative of its long-term release candidates; the game is still taking backers through its website. We always advise that gamers interested in hardware or software pre-orders invest an appropriate amount of time to research prior to financial investment. Backing a game's development means waiting.
- Steve “Lelldorianx” Burke.