Starwolves | Space Frontiers

The first 50 registrants on this forum will receive a permanent special forum group and title! You can register here!

Netcode and physics corrections [Update #2]

Posted by: starwolf - 19-02-2024, 12:41 AM - Forum: Updates - No Replies

Netcode in Rust with ECS.

A pioneering first-person real-time low-bandwidth netcode replication framework with Bevy Engine.

By Ramses

Introduction
Online multiplayer games require accurate, precise and sophisticated code libraries that enable a medium to high amount of physics based entities and/or players in the game world without running into the infamous network bottleneck. The video-game has to be developed as such that physics gets calculated authoritatively on the server while clients aim to replicate and locally simulate the same world with precision, accuracy and with the ability to support a variety of latency scenarios while latency is ever-changing and dynamic. The latency of a connection is usually decided by geographic positioning between clients and the server. A problem with sending and receiving data over the network is that there is always some latency involved when a message was sent and when it was received. When the server sends positional data of an entity the clients will all receive it several milliseconds later. When you aim to replicate physics simulations in real-time across the net you need to take into account these problems.

Thankfully there have been useful resources on these issues. A very helpful YouTube playlist explaining the netcode model I have implemented is found here.

Netcode showcase videos

Media I: Mid-high latency test, ping differs between 20ms-70ms~ involves a server hosted in a datacentre located in different country and a VPN connection to intentionally worsen net conditions

Media II: Low latency test.

The entire netcode framework is open source and can be found on Github.

Plugins
At the time of writing Space Frontiers uses a fork of the renet plugin which provides a UDP-based standardized netcode game library that would offer things like DDOS protection with game server providers.
For physics there is also a native plugin called bevy_xpbd. The fact that this plugin is native and integrated with the game engine's ECS is great because it allows for some epic multi-world and multi-schedule processing.

Tickrates and syncing
The default tickrate of Space Frontiers is 60hz. This means at fixed a interval the game loop gets stepped sixty times per second. Each tick that gets processed has a unique integer ID tick stamp. When server and client send messages to one another they also send the stamp of the tick they're at. This way for each message that is received we can determine how much latency (in ticks) there is.

To initialize a new client connection the server sends the current tick ID its at and the new client adjusts its own tick ID to match it.

We also put the client a few number of ticks ahead of the server. The amount of ticks at which an individual client is ahead of the server depends on the (averaged) connection latency as ticks. This way when a client sends a message for tick x the server is at tick x - latency. So when the server receives the client message it can accurately insert and process the associated events in the server game loop with convenient timing.

The network is ever-changing so latency and increase and decrease per connection over time. This means that the amount of ticks at which the clients should be ahead of the server is subject to change. When the server detects a latency change it will make sync adjustment requests to the client and the client will then either freeze or speed up for a specified amount of ticks to reach the new desired client tick.

Latency
Clients obtain and send user input such as movement keys and mouse input to the server and the server forwards it to the connected peers that can see the player that sent the input. Since the client is put ahead of the server equal to the amount of latency and sending a message from the server to the client also takes an amount of latency to arrive: we receive those peer inputs at double the latency. This means when the server forwarded peer input at tick X, the client will receive it when it is at tick X + latency in ticks * 2. This means that the peer input message the client receives is several ticks old. If we were to just take that data and apply it without taking this latency into account we would be randomly applying data in in the game loop and the physics simulation would not bee accurate and the results will not look smooth in the render on the users monitor.

Client-side input & physics caching, rollback and prediction
Clients cache the physics data of each entity for every tick and store it in a Resource. Clients can spin up a new physics simulation, clone previously cached data and even add a set changes (ie position or input updates from the server). So the client always receives authoritative data from the server a few ticks behind the tick it is currently at. When we receive new data from the server we can go back in time to the tick contained by that specific message header and step the simulation to the tick the client is currently at and then apply those to the main world. Space Frontiers performs rollback physics simulation and corrections in a secondary World with its own Schedule and the results get sent back to the main World.
Since the core principles of ECS and Rust are data-driven it is actually relatively easy to cache everything and to restore previous physics states. It is simply a matter of querying physics components from physics entities and storing them in a map mapped by the entity id and the tick ID.
Essentially we can now predict the future and go back in the past to make physics simulation corrections.

[Image: cache_copying.png]

Media III: physics cache copying. Media IV: Fun times debugging peer input.

Consistent processing
To ensure consistent processing the client and server send messages in batches. Both the client and server send and receive one message batch per tick (per client).
This way the event loops stay consistent and no unexpected results happen when multiple batch messages have received for a single tick to process, the application will simply split those messages up and call them in the upcoming ticks from a queue.

SubApps and multiple Worlds
The physics rollback and prediction happens inside a SubApp. Which means that the systems and data are separated from the main world that gets rendered. This way we have two ECS Worlds. In a single step of the main world we can step and process the SubApp for any amount of ticks we desire. A correction is triggered by providing a start and end tick id and the correction SubApp will step this range of physics calculations and return the results. All we do is pass the caches of physics entities and player input to the correction and let it run the physics steps as fast as possible. There are some sophisticated systems written to do this properly. Because entity spawning and despawning has to be emulated too. We use the same worker threads as the main app, reducing thread overhead. Both worlds execute asynchronously but as is standard in any Bevy application the inner logic of each world is entirely parallelized through systems. I also made a purist synchronous implementation of the physics correction SubApp, but it is experimental because it causes jitter. However in theory it is possible to run correction physics steps completely synchronously to the main game loop for great performance gains, the down-side is that you would get one tick of additional latency.

Optimizations
The gridmap is split up into chunks in terms of data and collision. There is a compound gridmap collider for each populated gridmap chunk.
The correction SubApp is lean and runs a skeleton Plugin selection. This is important because with another player in the scene the client could easily be tasked to rollback and step several ticks worth of physics per client tick. At the default 60hz tickrate this means clients are expected to rollback hundreds of physics steps per second to achieve smooth results with a narrow execution time of 12 milliseconds per main world tick.
There are still several big steps that will eventually be made to optimize physics rollback, such as finishing the synchronous execution of the rollback World and reducing the amount of cache data that is sent between Worlds.

Afterword
Up next is integrating more 3D assets, like 3D character models, animations and hopefully to expand the gridmap with higher fidelity assets and to make the current default map larger.

Download and play Space Frontiers Pre-Alpha [Client & Server]

Posted by: starwolf - 02-04-2023, 07:58 PM - Forum: Downloads - No Replies

	(18+) As this game puts people in communities with servers that we have no control or insight over, the age rating is 18+. Subscribe and play Space Frontiers pre-alpha: STORE.STARWOLVES.IO Supported platforms: Windows, Linux, MacOS Intel and MacOS ARM. The store provides the download to a launcher that automatically updates itself and the client for you. Bug hunters are greatly appreciated.

The initial Space Frontiers vision [Update #1]

Posted by: starwolf - 24-11-2022, 08:13 PM - Forum: Updates - Replies (3)

Space Frontiers the game

The future and vision beyond the pre-alpha prototype

By Ramses

Author's Edit:
Thanks to @BevyEngine and @rust_gamedev for the retweets (follow us @StarWolvesStar).
Thanks to /r/rust_gamedev and /r/godot for the Reddit posts that have blown up and redirected 2,000 views from just Reddit within 8 hours (follow us /u/StarWolvesStar).
(25-11-2022) A technical misconfiguration caused the starwolves.io forum to not increment the view counter up until two hours ago. I have made manual corrections to not miss out on recorded views. This has been resolved and won't happen again.

As seen in the #40 November 2022 news letter by Rust gamedev!

Introduction
The game industry has seen numerous successful online community games. Online community games allow players to host and moderate their own server while providing each server the option to have a custom set of content and gameplay mechanics that its users can enjoy. Examples of this are Garry's Mod, Minecraft, Space Station 13, Rust and Counter Strike: Global Offensive community servers.
However, all these previous online community games have been limited in scale because they had been built with minds, frameworks and technology that weren't meant to go beyond certain limits. On-top of that the gameplay of these community games were designed to take place on a single server instance.

We are nearing 2023 and with Space Frontiers several leaps are being made by introducing revolutionary technology, revolutionary minds and revolutionary gameplay. The Rust programming language in combination with the Bevy game engine has proven to be very effective in creating these type of games with our prototypes. Space Frontiers is Open Source and comes with a proprietary license. I have now ditched object oriented programming in favor of Rust and Space Frontiers is being strictly engineered with an Entity Component System architecture(ECS). Rust and Bevy are data-oriented and extremely modular. The technology allows for blazing fast and automatically parallelized code execution. Not only does this engineering architecture unlock support for large game servers with many players, it also introduces modular practices for code and asset additions and replacements for core developers and for developers belonging to communities with customized experiences.

The project has been in development for two years and there is an existing prototype which involve a Bevy server and a Godot client. They can be found here. However the Godot client has been let go in favor of a new ported Bevy version. Right now the Bevy client is in the first stages of creation.

The main development of Space Frontiers takes place on our Gitlab instance. The project is also available on Github as a mirror, please star us Heart

!
There are automated tools that generate documentation from cargo workspace by parsing the code comments and laying them out for the structured technical documentation website.

Space Frontiers currently supports Windows and Linux. MacOS support will arrive with the new Bevy client.

A showcase video can be found here.

[Image: editor_screenshot.png]

Media I screenshot from the Godot editor.

Technical implementation of next-generation online community experiences
Server clusters
Another advantage to data-oriented game development is that servers are able to transfer existing entities to one another, unlocking great possibilities as it will allow communities to not just host a single server, but a cluster of servers that represent a partially persistent galaxy. This means multiple servers can simulate the same galaxy and players will effortlessly switch server connections while preserving their serializable components such as inventories and stats. Foxhole allows for somewhat similar gameplay.

It is critical to know that Space Frontiers will be a gateway to connect to and play on various separated galaxies with highly customized content and gameplay experiences. Each galaxy is a self-hosted server cluster belonging to a gaming community consisting of users who have formed a (somewhat) orderly community who hold the keys to their gameplay experience. It is not that players host servers themselves, rather each community internally entrusts one or more persons to own and host the centrally managed community server cluster for them. Space Frontiers galaxies do not interact with one another, rather they are a way to let players separate and join or create their own communities and let them decide which moderation style in combination with which customized gameplay and content they like the most. Each server instance of a cluster will simulate a space station or spaceship of various sizes. So a server cluster has the same selection of plugins and content as all the servers and clients that are connected to it. Space Frontiers will allow communities to provide affordable clusters of servers for authoritative computational power for up to hundreds of players that all play and work together in the same galaxy.

When the time is ripe we will implement integration with cloud solutions like OVH Public Cloud that provide a REST API with very affordable hourly server rates. I also have experience with their public cloud API.

Modularity
Space Frontiers offers users the ability to dive into the code and to expand/replace/create plugins without having to start a modified branch of the Space Frontiers virtual workspace. This is thanks to the use of modular Bevy Plugins. Each Bevy plugin is a Rust crate and therefore can be developed and tested as a stand-alone Rust project. Community content and gameplay additions and modifications are as simple as creating a brand new cargo project with the Space Frontiers dependency enabled in the Cargo.toml file and by hacking away at non-intrusive modular APIs and enjoying Bevy automatically and safely parallelizing the plugin while Rust ensures performance by the nanoseconds!

[Image: crates_screenshot.png]

Media II-III from the repository: Space Frontiers is a virtual cargo workspace which has split up its code into Rust crates, each crate has its own Bevy Plugin that adds functionality of either server or client depending on which binary is compiled. The code is strictly compiled and organized and there are absolutely zero cyclic dependencies between crates and plugins. Everything inside core/ gets accessed and thus shared by both the client and server, plugins detect which binary is compiled and carefully add their functionality to the game loop.

[Image: screenshot_pistol_crate.png]

Media IV - V from the repository: This is what the plugin builder for the laser pistol item looks like. The summoning process is modular and builds an entity in the frame it is being spawned. Other plugins could expand upon this.

[Image: screenshot_main_menu_crate.png]

[Image: screenshot_main_menu_plugin.png]

Media VI-VII from the repository: Plugins add all their gameplay and hot-(re)loadable-assets to the game loop. Ultimately the Space Frontiers project as a whole will consist of many smaller plugins. Before a plugin adds elements to the game loop it checks whether the server or client binary is running. As both depend on unique sets of functionality that reside in the same crate. It is possible for the server and client to replicate the same functionality by indiscriminately adding functionality to the game loop instead.

[Image: screen_shot_atmos2]

Media VIII - IX from the repository: The diffussion module inside the atmospherics crate. A struct assigned to all gridmap cells that are subject to atmospherics. It is up for a little improvement in the future.

Technical dependencies
The physics engine of choice is the cutting edge Rapier engine which offers blazing fast multi-threaded physics calculations and a modular plugin for Bevy. I have successfully integrated the Rapier physics engine with an atmospherics algorithm that adheres the laws of physics. The netcode framework used is Renet that offers a great modular plugin for Bevy.
The first upcoming problem that will have to get resolved when scaling up to more players is bandwidth as rigid bodies get their transforms shared at certain tickrates across the net. Ideally the physics world gets replicated so the clients can simulate and the server only has to send less frequent correction and positional data. Much like all other functionality of Space Frontiers, updating the way clients and servers perform entity positioning can be as easy as modifying and working on a single plugin.

A lot of gameplay functionality is split up into events, systems and resources. To fully understand how this works please learn about the ECS architecture and about the Bevy basics. It is easy for new systems to ergonomically tap into existing functionality loops and data events and expand upon it. This is why events are a key way to provide plugin APIs next to utilizing components.
The project currently consist of 34 core crates and 14 entities crates.

[Image: sfatmosss.png]

Media X a visual representation of the atmospherics diffusion module at work.

Persistent player characters and game worlds
Persistency will be implemented by working with a central database instance hosted by the belonging community that accepts multiple connections from servers within a server cluster. Bevy and Rust grant us the ability to easily serialize entities and to export them as scenes at run-time. Scenes can be exported, shared and stored as text or binary format. These scenes could be stored inside databases and retrieved later. MySQL seems to be the way to go. The database solution will make player progression, ship storage and retrieval, persistent items and inventories work in an automatically scaling cloud.

Security and responsibility
Client-side plugins will be a critical part required for success and simplicity. However, there are some security concerns with this approach. It is not a good idea to let clients pull a custom binary from each server to run as Rust code is not sandboxed and malicious actors could use this fact to their advantage. Therefore clients will share the same main binary for every server and all client-side modifications take place with a sandboxed scripting language that will be extensively hooked to the ECS engine.

Moddable and dynamic content
Space Frontiers does not work with highly detailed 3D models and textures that are supposed to look good from up close, instead we have picked an optionally orthogonal top-down view which keeps a certain distance between the world and the camera. This allows Space Frontiers to look fine while it utilizes low poly and pixel art textures which are easy to consistently create with Free Open Source tools like Blender and ArmorPaint. Even hobbyist asset creators and hobbyist 3D artists will have the chance to create a lot of assets for the game in short amounts of time.

Godot prototype
The functioning prototype is made with the Bevy server, a Godot client and Godot assets. It includes a netcode system that allows the server to call individual functions on Godot nodes inside the scene tree of the clients. Naturally this prototype has a very powerful API with features and functionality which are fully playable and discoverable right now.

[Image: sfeditorss.png]

Media XI screen shot from Space Frontiers and the editor: A view of the functional Godot map editor for the prototype with advanced features and functionality. It is good to know that each server will represent either a spaceship or station. So a map is nothing more than a (de)constructable gridmap that represents a modifiable space construction.

[Image: animation_tree.png]

Media XII-XVI from the Space Frontiers asset editor of the Godot prototype: the screenshots showcase the animation systems and rigging of the human male model.

For humanoid character models we use Mixamo animation integration. The current prototype supports advanced animations including blend spaces, bone filtering and more. The Godot prototype has advanced movement and combat animations. You can find an advanced example of the Bevy to Godot netcode here, this module manages the entire animation tree for humanoids.

Godot has been a powerful engine to work with and it is great for people who want to get into game development. It even supports hot loading of dynamic content and scenes and the prototype makes full use of that!

[Image: godot_material.png]

Media XVII - XVIII screenshots from the Space Frontiers Godot prototype asset editor.

New Bevy client
The new Bevy client will work with client-side Bevy assets and the netcode will be ported to work with client-side Bevy scenes which support RON as export format. Why yes, we have transcended JSON. Bevy supports hot-loading of assets and scenes. There is also a functional Space Frontiers map editor available that will be repurposed to work with the Bevy client. 3D assets are imported as gltf files and can be exported as scenes. In fact, at any time can a server decide to export certain entities to a scene, allowing people to persistently store and restore customized spaceships, items and inventories at run-time. For servers this is useful for creating automated world backups that serialize the entire world and export it to the central server so the backups could be restored and recovered on an old or new server instance if needed.
The client is still in an early development stage and the porting will take a while.
More in depth information will be posted about the Bevy asset system and associated netcode changes once they have arrived.

Preview of next-generation community gaming
Imagine Faster Than Light (FTL), Space Station 13 and FoxHole having a child.

The vision
Space Frontiers is an online multiplayer game in which players find themselves within a galaxy consisting of multiple sectors and spaceships. Active co-operative and PVP gameplay takes place in and around manned spaceships. Players have to work together to run and maintain a spaceship or a fleet of spaceships. Crew members are assigned different roles with different levels of responsibilities and authorization. The manned spaceships will be tasked to jump from sector to sector which can also trigger random events; events will include player antagonists, traitor roles, alien infestations and more. Events can be customized or steered by admins and events. Therefore player communication is key, putting emphasis on the chat with optional roleplay features. A wide variety of simulated spaceship and gameplay elements will be included to ensure these scenarios will be as fun as possible.

Space frontiers seeks to deliver an experience that offers very high amounts of supported players for decentralized gaming communities that provide their own selections of (both client- and server-side) content, mods, gamemodes, gameplay, moderation and plugins. Communities will be tasked to host a cloud of servers, rather than just a single server. This is to provide reliable authorative computational power for the partially persistent Galaxy they host. Each server within the cloud represents an active sub-sector of the Galaxy, usually with one spaceship. We intend to support galaxies with more than one thousand active players in real-time.

The current implemented gameplay features in the online prototype are proximity and radio chat, an inventory system, a pawn and humanoid controller system, an inventory system, entities and items as rigidbodies, a (de)constructable map, melee and projectile combat, atmospherics and gravity simulation and a 2D map view with overlay modes and the current available overlays are atmospherics data.

[Image: sfss.png]

Media XIX: A screenshot of the Godot prototype in action.

Universe and lore
Each community can write and implement their own lore, however the official branch will also come with its lore.
Sci-fi games need a good universe with the right lore. And eventhough it is a little early for me to get into the universe and lore right now, I can say that there are already basic concepts for the official lore. It involves two large human factions, the blue faction which is a patriotic resembling parts of America and a red faction which is communist resembling parts of China. A lot of inspiration could be found from sources like Mass Effect, Endless Space 2, Starfox and Star Wars.

Business and profits
The proprietary license states that once official accounts are introduced that people who host Space Frontiers servers must ensure that the connections they accept are correctly authorized with the main server. Accounts will be sold for money and we want to put the game on Steam. A pay-wall for accounts is not only profitable and beneficial for the development of the game, it also creates a barrier against malicious users who seek to intervene with the gameplay experience by bypassing punishment.
I want to give partnered communities of server clusters the chance to monetize their experience and provide micro-transactions.
In case substantial profits are made we want to add more partner options for partnered communities in which their team, also including developers and asset creators would end up getting paid from this source of income.
On top of that I would love to get in touch with hosting companies to see if we can create a profitable solution with them too.

Star Wolves
Star Wolves is a to-be-launched gaming community that will spearhead the development of Space Frontiers. It currently consists of up to a 80 members who have known me from my previous successful endeavors in the realms of exceptional gaming communities. We will be the ones to provide the first official 24/7 server cluster with our style and our gameplay experiences. We hope to show the rest of the world on how it is done and how this game should be played. Community server clusters will expand upon the same main "vanilla" branch. This means that all asset and gameplay improvements made to the Star Wolves server cluster will be obtainable by all other community server clusters, but they may have to update their own custom plugins first.

Space Frontiers is a long-term project that takes years to materialize. I am fully aware of the scope and kind of lifting involved and I am confident that this is the time that a game like this can come to life and be in the spotlights.
On a more personal note, as the founder of Star Wolves, I have been doing and trying entrepreneurship for 6,5 years now and I have never quit. Space Frontiers has been in development for about 2,5 years and there are many more years to give. Before I was doing entrepreneurship I was hosting and managing #1 European gaming communities for videogames like Garry's Mod and Counter-Strike: Global Offensive which came with forums, discussion servers and an excellent community.

Community-steered development
Leadership
The success of this video-game will to a great degree depend on the ability of the developers and project leaders to adapt the gameplay to the wants and needs of the community that will slowly form and grow around the game. I, Ramses, the project owner, make a personal promise and guarantee that in the future when gamemodes, gameplay features, balancing and meta-balancing become a part of the main branch that the implementations are steered by the input of the community with high quality control. In fact I want to leave the design and conceptualization of cool gameplay features to the hands of the community and contributors, but there are some criteria.

Since there is no game like this and big steps are taken, it is of critical essence that successful integration of both gameplay and technology take place. All community input will be subject to quality control. I am the first to recognize and admit that most ideas (including mine) are stupid and just because you can do something doesn't mean that you should. All gameplay ideas and plans must be realistic, not overly detailed and ideas must keep several values at its core: we must make use of social gameplay which involve up to hundreds of people working together in in-game hierarchies and this means the gameplay and technology must complement that instead of breaking it up and get in the way of it. We have to stay clear from implementing anti-social gameplay patterns and gameplay elements that contribute to a digital void. The digital void is felt by all regardless, such is the nature of a virtual reality socialization, but breaking it with poor game design decisions is an insult to the player-base.

Conceptualized ideas are not binding or coming with promise in any way as they will always remain subject to improvement, refinement, innovation and integration with other large systems.
Please note that ideas must be implementable, but also implemented. In our case a good idea worth keeping is one that we know how to implement and who is going to implement it.
As the main developer I know that I can spend 40+ productive hours per week into the development of this game and I will materialize the unified vision, a vision which will hopefully one day be created by the input of a large variety of people.
For the time being, I have the final word on what becomes part of the single integrated vision and I will veto against ideas that introduce the aforementioned problems.

It is entirely possible for other community clusters to take over the game with player-count in which case Space Frontiers development and priorities end up getting impacted and steered by these other larger communities.

Contributing
We invite people who are genuinely interested in the project to become a contributor with great passion and energy to help materialize it with us and to benefit from the profit potential. Contributors also enjoy permanent roles, titles and exclusive abilities to influence the long-term development process and community.

We're looking at an early development cycle and naturally a lot of concepts and visions will be created, shared and discussed years before their implementation. Materializing next-generation gameplay is a process that requires years of discussion, debate, refining, finessing and value ordering to make them all come together to a single vision with materialized implementations.

You should also be aware that the early development cycle means that we are not yet ready to accept the average content creating or modding contributor yet. The client is still in development and it will take a year before it is ready to match the server with functionality again. Contributions to the core are always welcome, but it is more challenging. Contributing to the project in its current stage is mainly reserved for enthusiasts who want to be a part of it from the very beginning.

FOSS Milestone
In the further future when a yet to be-decided amount of accounts have been sold: the codebase and assets for Space Frontiers at that moment and onwards will go
Free Open Source (FOSS) under The GNU Affero General Public License version 3 and Attribution-ShareAlike 4.0 International.

We want to give as much freedom and sovereignty to the community and users as possible while also trying to make profit. This means that the Free Open Source Licenses will come into play later. However a high amount of accounts must have been sold before this takes place.
When this milestone is reached there will be no legal requirements for authorized and official accounts.

Afterword
As you read this the prototype is being further ported, expanded and materialized. We are looking for contributions of all forms and shapes and we are willing to negotiate percentages of profits on a contractual basis on top of enjoying community privileges as a contributor. If you wonder whether you can or should contribute to this project with anything please do not hesitate to get in contact and let's discuss.
We need contributors in the form of community leaders, development leaders, lore writers, gameplay conceptualizers, Rust programmers, 3D artists, 2D artists, concept artists, test players, video editors, marketing advice, Gitlab devops and financial sponsors. Naturally an active member of the project that only gives great energy is also a valued contributor.

This forum and its journal will see more posts and updates about Space Frontiers and its development.
If this project is of any interest to you it would be appreciated if you signed up to our web forum and leave a reply! All replies will be read.

Let's see if this forum can get populated.

The first 50 registrants on this forum will receive a permanent special forum group/title. Sign up here!
The first 100 registrants on our Discord will receive a permanent special role.

Leave your replies down below!!!!

Welcome, Guest

You have to register before you can post on our site.

Forum Statistics

» Members: 661
» Latest member: Marekametry6710
» Forum threads: 16
» Forum posts: 20

Full Statistics

Online Users

There are currently 19 online users.
» 0 Member(s) | 19 Guest(s)

Latest Threads

Netcode and physics corre...
Forum: Updates
Last Post: starwolf
19-02-2024, 12:41 AM
» Replies: 0
» Views: 4.552

Download and play Space F...
Forum: Downloads
Last Post: starwolf
02-04-2023, 07:58 PM
» Replies: 0
» Views: 5.011

Gitlab Rust CI/Automated ...
Forum: Contributors needed
Last Post: starwolf
03-12-2022, 09:56 PM
» Replies: 0
» Views: 5.756

Rust programmers
Forum: Contributors needed
Last Post: starwolf
03-12-2022, 09:42 PM
» Replies: 0
» Views: 6.161

Financial rewards (Treasu...
Forum: Contributors needed
Last Post: starwolf
03-12-2022, 08:36 PM
» Replies: 0
» Views: 6.374

Digital art and concept a...
Forum: Contributors needed
Last Post: starwolf
03-12-2022, 08:22 PM
» Replies: 0
» Views: 5.922

3D Animators
Forum: Contributors needed
Last Post: starwolf
03-12-2022, 08:17 PM
» Replies: 0
» Views: 5.694

3D model and 3D character...
Forum: Contributors needed
Last Post: starwolf
03-12-2022, 08:11 PM
» Replies: 0
» Views: 6.351

Unique icons, logos and f...
Forum: Contributors needed
Last Post: starwolf
03-12-2022, 08:00 PM
» Replies: 0
» Views: 7.129

The initial Space Frontie...
Forum: Updates
Last Post: starwolf
25-11-2022, 02:18 AM
» Replies: 3
» Views: 25.986

Search Forums

(Advanced Search)