Star Citizen Star Engine
Star Citizen looking at a dev response talking about CryEngine vs StarEngine the unofficial name for the Star Citizen Engine that has now branched off from Lumberyard (which is CryEngine based) and Star Citizen was originally using CryEngine 3.8 before that.
CI’s Clive Johnson replied with a list of some of the bespoke changes that they have made by them. It’s in no way exhaustive tho BUT it is work that has either seen completion OR has a working iteration it’s a big list AND I’ll link the starcitizen.tools wiki that has details on the specifics of each item should you want to know more:
Performance and Scale Features like 64 bit precision coordinate system & entity ID conversion allowing for the massive scale of the Star Citizen Play Area.
- Physics grids
- Zone culling system
- Game rules and game mode refactor
- Memory manager
- Batch & Background workers to use your PC Resources sensibly
- Fiber support
- Build system
- Crash handler
- Object Containers/Client & Server Object Container Streaming allowing for a sensible resource efficient way to have items loaded in and out seamlessly… so that Star Citizen doesn’t have Loading screens beyond the initial load.
- Megamaps
- Entity components, hierarchies, aggregates & lifetime policies – allowing entities to communicate more efficiently with the game simulation.
- Asynchronous entity spawning & removal
- Update scheduler
- Bind culling – Only tracking entities that are nearby a client.
- Spawn batches
- Serialized variables – sending just variables to client/server that have changed to save on bandwidth
- Network message queue
- Entitlement system
- Matchmaking
- Lag compensation
- Parallel network processing
- Headless clients – Artificial Clients for stress tests or to see how a system operates
- Network Entity replication
- Client crash recovery
- Diffusion – back-end cloud services
- General Instance Manager
- Persistence
- Item system
- Vehicle system
- Actor system
- Datacore – I actually don’t know what that is
- Weapon system
- Transit system
- IFCS
- Air Traffic Control
- Mission system
- AI & Subsumption
- GPU particles
- Motion blur
- Deferred renderer
- Lighting, Shadows & Volumetric rendering
- Planetary tech
- Weather effects
- Telemetry
- The Audio engine
- Render to texture allowing for the real time streaming of video/scenes to screens and projected in game rather than as a post process.
- Fluid & Cloth simulation
- Water/Ocean rendering
- VOIP & FOIP
- DNA character customizer
- Removal of older LUA legacy code
- UI & Building Blocks
- Signed distance fields – Tracking Distance data for effects & entities, so you can have more dynamic looking shields that deform around a ship OR atmospheric entry effects.
- Camera system
- Animation system
- Unification of first and third person perspectives
- Delta patcher – I remember the days where every patch required SC to be entirely redownloaded…
- Starmap
- Quantum travel
- More shaders than you could shake a stick at
- Debug server renderer
- Attachment system
- Atmosphere rendering
- Melee combat
- Cover system
- Interaction system
- Room System – That has atmosphere/gas composition changes tracked and moved.
- Actor Status – Hunger, Thirst, Oxygen
There are many, many more. Not to mention all the tools, scripts, backend services and web services needed to create and edit content, build the executables and asset files, deploy the servers, download clients and allow the game to actually run.
Server Meshing isn’t on the list as it still is being worked on and won’t have it’s first iteration for a while.
And CI are working on much more like the Gen12 Render, Vulkan Integration.
Are you also using new things from lumberyard or does a “fork” make that more difficult?
Having so many bespoke changes would make integrating changes from Lumberyard very difficult, if not impossible in some cases. There would need to be a careful evaluation of whether the gain outweighed the effort required or it would be easier/better to develop our own solution. As far as I am aware we haven’t integrated anything new from Lumberyard.
With the benefit of hindsight, would have building a new engine from scratch been the better decision? or for what reasons was using cryengine / lumberyard preferable?
The benefit of starting with an existing engine is that it allowed us to fairly quickly get a base level of functionality up and running that could then be built upon. Building an engine from scratch is a massive undertaking and for most of it you have very little to show apart from some basic looking tech demos.
Does this mean that StarEngine is basically all C++ now?
Yes, apart from shaders and scripting of missions and AI behaviour via Subsumption it’s all C++