Floating around in the soup of game software are some interesting chunks that deserve some attention. Fortunately, we’ve been told about them.
The original engine used by Star Citizen was the CryEngine, which also contains modelling software and other tools for asset creation. As the scope of Star Citizen grew, its ambitions extended beyond the capability of CryEngine, and the team decided to move to Amazon’s Lumberyard, a free game engine based on CryEngine. At that time, porting from CryEngine to Lumberyard was relatively straightforward since Lumberyard based its architecture on the same version of CryEngine that Star Citizen was using.
The change from CryEngine to Lumberyard was announced in December of 2016 with version 2.6 of Star Citizen and since then Lumberyard has diverged from the CryEngine base. In December of 2017,
The Star Engine now sits on top of the Lumberyard base and the interface between the two has been blurred by significant modification and integration of the source code that Lumberyard provides.
GPUs have become the natural place to offload repetitive presentation calculations, and ray casting is a perfect example of a complex problem broken down into a discrete task. Research into this topic suggests that in the near future we will all be able to have the ultra-realistic lighting models that will be possible from Path Tracing.
Because Path Tracing is mimicking physical light much more accurately than ever before (including Ray Tracing), there will be no more need for artists and programmers to do the additional work necessary to create realism in games. This will reduce the scope of their tasks significantly and should lead to lower costs and faster production.
For the time being, fractions of the current technology are migrating step by step into the GPU environment where they are more capable versions of their CPU counterparts.
Normally a game environment (also known as a map in this context) would be loaded into memory in its entirety in order to simplify programming. OCS makes it possible to load parts of a map into memory when required, which includes the user selection screens that are shown before entering the universe. The mega map is the RSI label applied to a game environment that implies the use of OCS. Its purpose is to hide loading times and optimise memory use.
Object Containers (OCs)
Object containers are a proprietary game technology developed by CIG. The purpose of the containers is to partition the very large game volume into discardable chunks that will be manageable by a users’ PC. Each container sets the scope on what is visible and what can be interacted with.
A ship is also a container, but one that will move around the hierarchy.
The modular nature of the containers means that each containers’ resources can be loaded and unloaded from memory individually or transferred from one server to another.
It would allow a server to maintain a specific container within the game as desired.
The container outside the one you are in contributes to the background image and containers within yours would be shown by their exterior views.
Object Container Streaming (OCS)
OCS will reduce the number of elements in play at any one time which lightens the load on the CPU and RAM. The Streaming part of the title refers to how an environment is built during the game. Instead of loading all of the details of the game at once, only objects that are big enough that they could be seen will be loaded.
When an object goes beyond its viewable distance, it’s visible assets can be discarded leaving being a lightweight marker object with essential properties such as position and an id to allow it to act as a communications target.
In order for OCS to work correctly, the objects it deals will load asynchronously and be thread-safe. The information required to synchronise computers will be carried by serialised variables.
The highest risk scenarios occur when entities leave and then come back. The game will also have to work correctly for groups of people that are dispersed across a single Object Container and therefore have different views of the same scenario.
The game server will be making decisions about which entities are fully loaded or represented by markers. A client PCs entities are bound to the server’s entities and will be culled (streamed out) when the server’s version is removed.
Face Over IP
This game technology feature will provide the means for an in-game character’s facial expression to display those of the player. This technique has been given the name Face Over IP (FOIP) because the player’s avatar will be controlled by its user over IP.
An image of the avatars face will eventually be transmitted over IP in-game as well but this isn’t the primary reason for the name. FOIP works using standard webcams and doesn’t require preparation such as face markers. For best results, an RSI webcam has been developed with the following features:
- 60 fps for responsive lip synch
- A sensitive CCD for low light environments
- A narrow-angle to focus on the face
- High-resolution glass lens for accuracy
A side effect of having such accurate face tracking is that it supports head orientation tracking. Head orientation can be transferred to your in-game avatar, providing additional realism or allowing you to look off to one side of the game environment. This would help to glance at the information displayed on an off-screen monitor or to see what might be happening outside of different parts of a cockpit without interfering with the ship controls.
Star dudes, if you are pregnant with opinions and useful observations in the shape of corrections, suggestions, or enhancements, there’s no need to keep them to yourself, you can whisper them into my shell-like ear! let me know via the contacts page :o)