This year’s Star Citizen convention, surprisingly named “CitizenCon” (or CitCon because I’m too lazy to retype), happened this past weekend in L.A., and was the first in-person event since COVID. Because of this, and because of community feedback, the normally one-day even was expanded to two in order to accommodate attendee wishes to comfortably sit in on panels and to check out the expo floor. I was on vacation during this event, so I am slowly catching up on the recorded presentations (not yet on YT, so I have to suffer through Twitch replays).

First up: thoughts on the keynote (there really wasn’t one) and the overview of the Star Engine, the heavily modified Amazon Lumberyard engine that runs Star Citizen.

Keynote

Chris Roberts appeared to thunderous applause. He said a few things to open the proceedings, but quickly dashed offstage to make way for the stuff people were actually there to see. Roberts has recently begun to resurface, having been conspicuously absent from Spectrum and any and all live streamed events. I have suspicions as to why we are seeing more of him now, but that will be covered in another post.

Star Engine

As mentioned, Star Engine (SE for short because lazy) is what CIG is calling their jacked-up Lumberyard platform. I’m not going to opine about this at length because I don’t know anything about either, so here’s the rundown of the presentation. It’s pretty lengthy.

Overview of the SE

We got a mini-keynote from Benoit Beausejour, the previous head of Turbulent (?) who is now the CTO of the SE team (??). CIG bought Montreal-based Turbulent this past year and has been working on integrating them into the fold. Turbulent is responsible for things like the website, launcher, and distro network (???), but has been handed the reins to build out additional star systems for the public test universe (????). I’m working off of remembered information here, people.

We then got a presentation from VP of Tech Marco Corbetta who went through several bullet-points regarding the SE.

The gist of this segment was that the Star Engine is a massive undertaking. I think we understood this instinctively, because game development is difficult, but these slides also kind of present as a mea culpa for why the development cycle of Star Citizen A) takes so long, B) lags behind itself, and C) has shifting priorities over time. Is it a reason, or an excuse? You decide.

Visual Effects – Clouds

Director of VFX Mike Snowdon took over to show us work that’s being done on clouds, ground fog, and planetary lighting. It sounds like a relative snooze-fest, and these pictures don’t do the results justice, but even watching Twitch’s lame-ass 1080p presentation, seeing the current implementation compared to the upcoming implementation (supposedly in 3.22) is pretty impressive.

Visual Effects – Fire

Next up, Ali Brown, Senior Director of Graphics and Procedural Tech to talk about everyone’s second-most-favorite destructive force, fire. Star Citizen’s fascination with fire effects is…a bit concerning. We’ve heard a lot about it in the past, and have seen demos that looked a lot like what Ali presented here (but with less technical breakdowns), which makes me think that CIG has some arsonists in denial on the staff.

Visual Effects – Water

If we have fire, we must have water, courtesy of CIG’s resident water-bender, Engine Programmer III Will Hain. Will’s famous for his single-handed implementation of Star Engine’s river technology, and this time he’s here to show off the way larger and smaller bodies of water will work in the (hopefully near) future.

Now, this may seem dumb on its face, but this was a heavily mind-blowing segment. A lot of games either treat water is something that confines players into the game-space, or as a tinted biome with different assets. Star Citizen, by virtue of being Star Citizen, is looking to make water a first-class system by cold-cocking H20 with a metric shit-ton of physics.

I took a lot of screenshots of this segment mainly because there seem to be more improvements to this relatively ho-hum feature than in any other feature presented during this keynote. Will talked about how the water works, their goals and reasons for working this damn hard on water, and provided some amazing examples of how water will behave when interacted with at scale — bullet-impact, player traversal, and ship proximity.

Again, these pictures don’t do the effects justice; watching the video is a much better way to experience the power of water.

As an added bonus, we got some water tech in the form of blood, sweat, and tears (I missed the sweat segment, so we only have blood and tears represented below). I don’t know how often our characters will cry, but if we want to, we can.

Scopes

I think I missed who presented this, or else my screenshot chronology is messing with me. Regardless, and oddly enough, there was a brief section on weapon scopes.

Currently, weapon scopes work maybe like how scopes in other games work; I say that only because if you’ve looked down the sights of a weapon in other FPS games, you’ll get the same sensation here in Star Citizen. Star Citizen being Star Citizen (SCbSC), this is not good enough, and scoping needs to be simulated as realistically as possible.

While this screenshot is nice, the effects are more apparent in video form. Know that scopes will now act like both realistic glass and digital representations, and standing next to another player and glancing over and through a scope of a lowered weapon, you will be able to see the effects; there’s no camera tricks of distant graphics going on here.

The Future of Planet Tech

Again, I think I missed whomever was giving this presentation, so I apologize.

We have four planets and a bunch of moons in the current alpha of the game, but CIG wants more. I had thought that giving Turbulent the task of building out systems would increase our rate of terraforming, but it seems that planet tech is still kind of in flux.

Here, the presentation talked about how machine learning, trained on the astrophysical realities of Earth, Mars, and the Moon, is in preliminary tests to allow CIG to quickly create a planetary base made up of realistic biomes shaped by planetary position in a system, time, and the interaction with natural and unnatural forces.

While this pushes CIG into the “AI” space, it sounds like this tech could mainly be used to set a foundation upon which customization can be made by artists and feature teams. The presentation did not leave me with the impression that one guy would be banging out prompts to generate complete planets. In fact, it was mentioned that this would free up designers to hand-add features on planets that would allow them to look and feel different, and for each one to offer different and unique features.

Vulkan Update

I did get this one: Ben Parry, Principal Graphics Programmer, talked a bit about Vulkan. It’s nearly ready! And he provided a slide to talk about what Vulkan will do for Star Citizen.

My main interest was in the speed department, as the game is currently optimized and relies on the CPU for more than it should (apparently). If Vulkan can double the performance for everyone, I am all for it. Oddly, Ben didn’t mention that last point: potential for Linux versions. No on in the audience seemed to mind.

StarCloth and StarHair

Senior Lead Physics Programmer Chris Raine had the unenviable job of talking about “StarCloth” and “StarHair”. Hopefully he also gets to fire the person who came up with these stupid names. This was a presentation featuring a player in a medical gown who was molested by a soccer ball that rolled around beneath the gown. This was to show us how the cloth simulation worked in relation to external objects, how it works against the wearer’s body, and how it can be effected by environmental conditions like wind, water, and explosions. Think scarves, capes, and flags. We did get a demo of a scene which I won’t talk about now, but which illustrated how one layer of cloth can change in subtle ways against another layer.

While this is nice, I hardly think it’s something that will make or break the game. I did like the above slide which explained how they increased performance by enabling some cloth to respond to stimuli, and how those elements would then affect the rest of the connected cloth.

The better part of this presentation focused on hair. Right now, Chris mentioned that hair works on a “pendulum” system whereby the hair is differently weighted to allow it to be affected by gravity. This does not work with wind or water, though, so the new system treats each spline individually — basically each strand of hair — to allow the hair to react as…well…real hair.

Maelstrom: Deformation and Destruction

Another mystery presenter, I apologize, though this might also have been Chris Raine. SCbSC, simply applying a pool of HP to a ship and calling it a day is not good enough. Ships should have target-able elements which should take damage, decay, and break apart exactly as we in the real would would expect them to (if we had the proper understanding of such physical forces, of course). To accomplish this, CIG has created a system they call “Maelstrom”, and it is being applied to vehicles, props, and even the landscape.

Maelstrom isn’t just for blowing things up. This is going to play a part in salvaging and repair as well, since the goal is to isolate parts of ships and vehicles that can be broken apart and put back together again.

Server Meshing and Replication Layers

Sr Tech Director of Online Tech Paul Reindell now ranks third in the CIG pantheon, behind Roberts and Tony Z. This man gave a presentation on the single most important tech on deck, the replication layer, and how it contributes to server meshing. Server meshing, apparently, is the Last Great Hurdle that CIG needs to overcome before the open stretch of road that is the nickel-and-diming of the game’s feature set.

What is the Replication Layer?

Pardon my faux pas if I mis-explain this, but here’s my understanding. In service games, clients connect to servers. Servers keep track of where everything is in a given space. When you see a chair, the server is the authority who put the chair there; the client only renders what its told, where its told to render it. When another player enters, that player’s position is reported to other clients by the server as well. There’s some client prediction in there that makes the movement of other players and other entities look smooth, but in the end, the server has the authority to tell all clients who or what is where, and when.

Star Citizen is adding an additional layer between the client and server called the “replication layer”. This acts like the “controller” in a standard “MVC” application: it remembers where items are in a space and passes that info to the client (the “view” in MVC). It is not, however, the authority. It’s an authority, though, as multiple clients will query this replication layer for a given zone to learn what is where and when its there.

Behind the replication layer is the server, or “model” of “MVC”. The server still has the final say in everything that goes on, and it does so through the replication layer, so unlike traditional client-server games, Star Citizen has a three layer structure.

When these three parts are combined, we get some interesting behavior. First, if one server is responsible for several zones associated with a replication layer, when that server crashes, authoritative data cannot be shared between clients, but clients do not crash so long as the rep layer is up and running. Clients can interact with the more static environment during this time, but anything that needs to be ruled by the server will appear to be in stasis or a loop; the example given was another player character in an idle animation after the server simulated a crash (or “30k” as Paul mentioned and we players know it as). The other PC was still reported to the demo client by the rep layer, but the demo client didn’t get live updates about what the other player was doing. When the server returned, the other character went back to his normal, player controlled routine as if the event was only an egregious lag spike.

Second, multiple servers can interact with a single rep layer. This allows CIG to divide an area into smaller zones, each governed by a different server, but which share info between their individual replication layers. A player in zone 1 can still see everything in LOS controlled by other zones, and can interact with those objects at a distance (like to shoot them or use a tractor beam). Each zone has it’s own replication object tree (the graph in blue) which lists the objects associated with that zone. As an object moves between zones, it’s moved from one tree to another tree.

Third, because the replication layer has the info on what’s in known zones, a player can move seamlessly between zones with no loading screens. Zones can be put to sleep if no players are present (recalling that Tony Z mentioned that the Quanta(um) system will keep simulating NPCs and other events in those zones in the background), or zones can be activated and populated from the rep layer database on demand. This is how those simulated NPC activities can be instantly rendered for players who happen upon them.

I know I didn’t do this system justice (and probably got some or most of it wrong) but I think this segment, as technical and nerdy as it was, got the most applause out of any segment of the presentation. Server meshing, the term given to how servers control zones and interact with the client through the replication layer, is being sold as the means to allow a massive number of players to share the same universe. Right now, we are limited to about 150 players per server. There is currently no replication layer, and the game operates just like how other online games do — client and server direct communication. With the replication layer taking the brunt of the tracking, and the servers authoritatively controlling the world in smaller, discreet chunks, “server” crashes should allow players to remain connected, and it’s possible that multiple servers could connect to the rep layer to provide redundancy, giving the game some fault tolerance through good old fashioned — but heavily customized — server farming.

Closing Thoughts

The Star Engine presentation was enlightening, interesting, and exciting. As I was watching it, though, I was thinking about how all of this tech dumping was nice and all, but was not addressing anything about game play. Sure, fighting fires and blowing up buildings will directly affect game play, but as I have become aged and cranky regarding Star Citizen’s relentless focus on forcing PvP interaction even with the most benign and “soft” game mechanics, I felt that this was a self-congratulatory wank…but a necessary wank nonetheless.

I had heard a lot of people (not just the usual naysayers, but long time supporters as well) ahead of CitCon saying that CIG really needed to knock this one out of the park in order to assuage the fears that the project was incurring so much tech debt that implosion wasn’t just a possibility, but a certainty. I think that this Star Engine overview was a way for CIG to remind players where we are and how far we have come with the alpha. It’s also a way to show those concerned about the future of the project — through demos and examples made by the developers, not by the cinematic teams who polish everything before it goes out the door — that these future features are in active development with many at the point where they will be in the game in the next 12 months. These aren’t vague mock-ups, but real, working examples that are this ][ close to being inserted into the game. The underlying message is that no one is hanging out on Chris Roberts gold-plated yacht; it is all hands on deck.

Looking back through the screenshots, none of these features are critical to the game, though, with the exception of server meshing and the replication layer. Everything else is visual gravy that satisfies Chris Roberts’ desire to play God through his own sci-fi sandbox. I’m not saying that I don’t appreciate what these features are bringing to the table, so don’t misquote me. I just think that this keynote and presentation was one part cheer-leading and one part damage control that offers more hype. Granted, I don’t think addressing “my character fell through the floor of my ship again” or “I can’t access my cargo hold to buy or sell items, still” makes for great presentation material, but I have several more hours of video to scroll through.