Join our growing community of fans and help us make Stellar Codex the awesome game we want it to be!

Download Link: http://www.stellar-codex.com/downloads/StellarCodexInstaller.exe

Minimum System Requirements (low settings)

• At least 2GB unused RAM
• Any GPU that supports SM 3.0 with at least 1GB vRAM
• Quad Code CPU
• Windows Vista or newer (DirectX 9 Compatible)
• 2GB free storage space

Recommended System Requirements (ultra settings)

• At least 6GB unused RAM
• Any GPU that supports SM 3.0 with at least 4GB vRAM
• i5 CPU
• Windows Vista or newer (DirectX 9 Compatible)
• 2GB free storage space

See you on our next event!

The outer space is massive, and the emptiness of deep space is always contrasted by the massive wonders it contains.

When designing a game set in outer space, we’re often confronted with the problem of integrating super-massive objects within the limited resources allocated to us from the hardware running the game. Even an asteroid mining base can be complicated to integrate without suffering frame rate drops.

An object as big as this can be seen from huge distances which forces us to have it loaded inside the level from the very beginning. This however adds stress to our graphics card, as it has to render a very complex object always, even when we’re not even remotely close to it.

To combat this issue, it is standard procedure to load a lower polygon version of the model that can be seen from afar, and then load the higher polygon model to replace it once the player moves closer to interact with the structure.

This however leads to another issue. Loading a complex model such as this while the player is fighting can drastically reduce the frame rate during loading time. In order to address the issue, we created a sophisticated asset streaming system which gave us the option to load an object over a long period of time, in order to spread the load over multiple seconds. This allows us to set how long we want the loading time to take; the slower the load, the smoother the operation becomes. By loading the higher polygon version over a time of 10 seconds for example, long before the player reaches it, we make sure the change is not noticeable at all.

However, our problems are not done just yet. The example mining base is an interior space; the player flies inside its corridors, from entrance to exit. This means that the interior spaces need complex collision systems, since dodging obstacles now becomes part of the game-play. And as with all physics related issues, colliders are heavy on the CPU.

First optimization in order is to replace the game engine’s mesh colliders which are extremely heavy, with simpler clusters of primitive sub-colliders (cubes, planes and spheres). This can take an extremely long time to set up, since all the work is manual, but in regards to performance, the payout is worth it.

Even with primitive colliders however, loading hundreds of colliders even when the player is far away from them still impacts performance; the physics system still checks them all, regardless of distance. And this results in constant frame rate drops. To combat this issue, we created a collision optimization system, in which colliders far from the player are turned off, while colliders close to the player turn on.

This drastically increases performance, as physics are only calculated around the player now, where it is most relevant.

Colliders are shown in green outlines

Having the above technologies already developed, we can introduce to the game a seemingly infinite amount of super-massive structures; as infinite as the universe ought to be, but still fitting inside our palms.

When creating a game based in outer space, one issue quickly becomes apparent – vast distances. In order for the scene to feel rich and full, we require landmarks that can be seen from huge distances, often from different orbits, like asteroid belts, planets, moons even suns and nebula. And that means that said landmarks must be huge in order to be visible.

This poses a problem when designing a scene. The player’s camera cannot render (or “see”) as far as is needed for those objects to become visible, because if it does, it will need to render all objects in-between; spaceships, debris, dust clouds, etc. These objects can pile up fast, causing low performance or even worse, game crashes.

There are various solutions to this issue; rendering everything to a 2D skybox, like a backdrop image, or selectively switching objects on / off are some popular approaches to solve the issue.

We have opted to use the 3D skybox approach, as it’s the most elegant solution, albeit most difficult to set up.

The 3D skybox exists between the standard 2D skybox backdrop and the normal scene where the game takes place. It contains a scaled down and low-polygon version of all distant landmarks (on a 1:100 scale in our case) and it’s typically rendered by a separate camera. The separate camera receives instructions from the main camera on how to rotate and move, in order for all images to sync.

Every frame, each camera outputs to the frame buffer what it sees, stacked in layers, much like we’d super-impose image layers in photoshop to generate a composite image.

Super-imposed layers forming final frame (Main Camera – movable objects and particle effects, Skybox Camera – Huge static structures rendered in 1:100 scale, 2D backdrop)

The result is the illusion of a unified image, while in fact, it’s a composition of many separate images.

This technique, not only offers good performance relative to the other methods available, but also allows for clever ways to expand level design. By manipulating the 3D skybox camera’s movement, we can cause the 3D skybox to “approach” the player as he moves towards it, and then, through the use of LOD (level of detail) techniques, cause a seamless transition from the 3D skybox to an actual non-scaled scene which would load on demand.

This is precisely the way we’re able to perform planet drops from high orbit in Stellar Codex!

This very versatile single manned spaceship is capable of vertical and horizontal propulsion thanks to its 10 Ion Vector Thrusters, giving the pilot full 360 degrees controlled flight. These high powered Ion drives have short term afterburner capability allowing the spacecraft to exit planetary orbit through conventional flight, making it a trully all purpose combat solution.

Armed with ATEC’s dual Quad Blaster Arrays, it can fire non stop fully ionized plasma bursts to its target at blinding speeds, making short work of even the strongest hull platings in a matter of seconds.

Its destructive capability is further enhanced by MiliTech’s S-Grade MLRS Launcher, coupled with DataCom’s auto targetting IFF system, able to pick and quickly demolish targets at up to 400km distance.

In addition, Saber Fighters carry a payload of 8 Zero Strike Anti-matter warheads, making them a viable threat to even capital class spaceships.

Its major strength however is its revolutionary AEGIS energy shield, which effectively makes this spacecraft immune to all but the deadliest weapons known to man. This kinetic barrier not only protects the ship from incoming fire, but also nearly nullifies all acceleration forces impacting the ship, protecting the pilot and giving him never before seen maneuverability in the combat zone.

It all boils down to functionality. The game’s GUI is the only thing that stands in the way between the player and the game. A game starts and ends with the press of a button on your screen. The player might quickly forget a glitchy model that doesn’t display its texture properly, but a single unmovable window in the way of his firing aim, or a button that doesn’t always respond to his mouse input might cause him to discard the game and never touch it again.

Designing a proper GUI however, requires a proper framework supporting it. And here’s where video games make it hard. If a game is developed right, no two single games should look the same.

Each game has its own layout, its own GUI needs, and its own style of depicting that GUI on your screen. This fact alone makes designing a framework that supports more than a single unique game a nightmare, since it can get bloated quickly with options and functions that will never be used for more than one game.

And this is where Unity both fails and shines at the same time. Unity has made two attempts so far at a proper GUI Framework. Their first attempt came in the form of TextMeshes, GUITextures and GUITexts, three very simple primitive 3D objects that did nothing on their own without heavy coding supporting them, from the part of the developer.

The second GUI system, called OnGUI to differentiate it from the old GUI framework, chose a completely different approach. The entire GUI layout would now be written in pure code, without visual representation during the level design process. However, it would come with all sorts of options, like scrollable window menus, function ready buttons, and CSS-like styling. The issue this time was performance. A badly designed GUI framework can drop a game’s frame rate a lot more than multiple stacked post processing effects. And Unity’s OnGUI was an example of bad design.

OnGUI completely discarded .NET’s object oriented, fire and forget coding, in favor of a convoluted and bloated state machine that ran multiple times per frame and drained CPU cycle resources, cluttered with statements, checks and boolean switches. The end result for something a bit more complicated than a single menu button was a mile long spaghetti code that was unmanageable to say the least.

In addition, OnGUI tried to offer to the developer instant modability, allowing him with frame level precision to remove, change, reorient or add new GUI elements. This, however meant that no two GUI elements could share the same atlas anymore to make use of rendering optimizations, and the entire system would need to draw each GUI element at the beginning of the frame, and destroy it after it had been rendered, over and over, frame after frame, generating huge ammounts of garbage every frame on RAM.

Unity is currently designing its 3rd attempt on a GUI System, but also allows developers to create our own frameworks, that, surprisingly, turn out even better than Unity’s native GUI frameworks. On Unity’s asset store we have downloadable packages like EZGUI, and nGUI, that do everything Unity’s GUI do and more, at 1/10th of the resource costs.

Here, at CREAT3D, after some thought, we decided to develop our own GUI framework that will address game-level requirements that generic frameworks couldn’t possibly do. We call this GUI MagicGUI, and it will be used by all our future projects.