https://starwolves.io/ Tue, 07 Apr 2026 20:56:51 +0000 MyBB https://starwolves.io/thread-21.html Thu, 12 Jun 2025 03:15:42 +0000 starwolf]]> https://starwolves.io/thread-21.html Starwolves.io is once again hosting a Space Station 14 server again.
You are welcome to show up, add the server to your favorites with IP: ss14.starwolves.io .
Scheduled play events take place every weekend day at 7pm CEST.]]> Starwolves.io is once again hosting a Space Station 14 server again.
You are welcome to show up, add the server to your favorites with IP: ss14.starwolves.io .
Scheduled play events take place every weekend day at 7pm CEST.]]> https://starwolves.io/thread-18.html Sun, 18 Feb 2024 22:41:29 +0000 starwolf]]> https://starwolves.io/thread-18.html 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.

 
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.]]> 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.

 
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.]]> https://starwolves.io/thread-13.html Sun, 02 Apr 2023 17:58:38 +0000 starwolf]]> https://starwolves.io/thread-13.html (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.]]> (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.]]> https://starwolves.io/thread-10.html Sat, 03 Dec 2022 19:56:17 +0000 starwolf]]> https://starwolves.io/thread-10.html self hosted Gitlab instance. The CI is slow. It needs to go faster. Please help.
More linting checks like Rust fmt should be performed with the CI. The CI should also test for run-time errors. Cargo doc tests are also required.
An automated deployment of newly generated documentation from the code of the master branch would also be great.

No experience required, just make it work nicely.

You can get in contact by all means.

Financial rewards.]]> self hosted Gitlab instance. The CI is slow. It needs to go faster. Please help.
More linting checks like Rust fmt should be performed with the CI. The CI should also test for run-time errors. Cargo doc tests are also required.
An automated deployment of newly generated documentation from the code of the master branch would also be great.

No experience required, just make it work nicely.

You can get in contact by all means.

Financial rewards.]]> https://starwolves.io/thread-9.html Sat, 03 Dec 2022 19:42:13 +0000 starwolf]]> https://starwolves.io/thread-9.html
Learning resources, guides, YouTube tutorial videos and heavily refined and iterated code documentation will be key to introduce programmers to Space Frontiers.
However, because Space Frontiers is in an early development cycle and currently undergoing porting procedures it is not in an ideal state to contribute to the core or to expand upon it yet. The aforementioned learning resources haven't yet been created. Ways to get familiar with the code is by helping improve the code documentation and/or code layout. The modules, code naming and code placing could also be improved, new standardized practices for crate modules could be introduced. The generated code documentation is also very basic and insufficient in some areas. There are also Rust clippy lint issues to be resolved. Using CLion by JetBrains will also show more possible code improvements.

The code repository has a private AI machine learning model at Tabnine. If you have a paid Tabnine account you can request access to it.

Development is done on gitlab.starwolves.io/starwolves/space

No experience required, you can learn on the go. You will have to get familiar with git and the Bevy game engine, sign the contributor license agreement for gitlab.starwolves.io account activation.

You can get in contact by all means.

Financial rewards.]]>
Learning resources, guides, YouTube tutorial videos and heavily refined and iterated code documentation will be key to introduce programmers to Space Frontiers.
However, because Space Frontiers is in an early development cycle and currently undergoing porting procedures it is not in an ideal state to contribute to the core or to expand upon it yet. The aforementioned learning resources haven't yet been created. Ways to get familiar with the code is by helping improve the code documentation and/or code layout. The modules, code naming and code placing could also be improved, new standardized practices for crate modules could be introduced. The generated code documentation is also very basic and insufficient in some areas. There are also Rust clippy lint issues to be resolved. Using CLion by JetBrains will also show more possible code improvements.

The code repository has a private AI machine learning model at Tabnine. If you have a paid Tabnine account you can request access to it.

Development is done on gitlab.starwolves.io/starwolves/space

No experience required, you can learn on the go. You will have to get familiar with git and the Bevy game engine, sign the contributor license agreement for gitlab.starwolves.io account activation.

You can get in contact by all means.

Financial rewards.]]> https://starwolves.io/thread-8.html Sat, 03 Dec 2022 18:36:21 +0000 starwolf]]> https://starwolves.io/thread-8.html Please understand that the project relies on my time spent programming. I already spend more than enough hours on my part-time job to cover my own expenses and the expenses associated with this project. It makes no sense for me to work additional hours to compensate contributors as it would keep me away from working on the same game we all want to succeed.

Contributors with financial incentive should understand that that the real financial price is gained from making the currently unattractive unfinished game to a more fully fledged and enjoyable game, so selling accounts becomes a realistic possibility. The proprietary license and free open source future with the contributor license agreement secure a financial monopoly for some who work on the project.

The game industry has the steepest Pareto distribution known to man and it is impossible to get funding and investments without starting the project in the name of a larger company or without this company being registered on the stock market. Starwolves, a registered Dutch company, as "eenmanszaak" (sole proprietorship) company and is willing to collaborate with companies and people.]]> Please understand that the project relies on my time spent programming. I already spend more than enough hours on my part-time job to cover my own expenses and the expenses associated with this project. It makes no sense for me to work additional hours to compensate contributors as it would keep me away from working on the same game we all want to succeed.

Contributors with financial incentive should understand that that the real financial price is gained from making the currently unattractive unfinished game to a more fully fledged and enjoyable game, so selling accounts becomes a realistic possibility. The proprietary license and free open source future with the contributor license agreement secure a financial monopoly for some who work on the project.

The game industry has the steepest Pareto distribution known to man and it is impossible to get funding and investments without starting the project in the name of a larger company or without this company being registered on the stock market. Starwolves, a registered Dutch company, as "eenmanszaak" (sole proprietorship) company and is willing to collaborate with companies and people.]]> https://starwolves.io/thread-7.html Sat, 03 Dec 2022 18:22:47 +0000 starwolf]]> https://starwolves.io/thread-7.html
Digital artists and concept artists are valuable.

No experience required.

You can get in contact by all means.

Financial rewards.]]>
Digital artists and concept artists are valuable.

No experience required.

You can get in contact by all means.

Financial rewards.]]> https://starwolves.io/thread-6.html Sat, 03 Dec 2022 18:17:14 +0000 starwolf]]> https://starwolves.io/thread-6.html
No experience requirements, but you have to be able to work create animations for Blender and learn about the Mixamo skeleton and rig.

To submit your work you will require access to our Gitlab instance and you will be required to sign the contributor license agreement for account activation.

You can get in contact by all means.

Financial rewards.]]>
No experience requirements, but you have to be able to work create animations for Blender and learn about the Mixamo skeleton and rig.

To submit your work you will require access to our Gitlab instance and you will be required to sign the contributor license agreement for account activation.

You can get in contact by all means.

Financial rewards.]]> https://starwolves.io/thread-5.html Sat, 03 Dec 2022 18:11:03 +0000 starwolf]]> https://starwolves.io/thread-5.html
The game still NEEDS various 3D assets to reach its full potential. Ranging from Mixamo-riggable 3D humanoid characters, to meshes of items and weapons, to the blocks the spaceships are made of. When there are more 3D character models we would love to include them in development and marketing videos with custom animations to tell stories.

No experience requirements. 3D assets will have to be either created with Blender or exported to work well with Blender. You must also UV unwrap the models. Textures can easily be created and modified with a tool like ArmorPaint.

3D humanoid character designers are of high value.

You will have to submit your work to our Gitlab instance and to get your account activated you have to sign the contributor license agreement.

Blender files of the used 3D assets can be delivered on request.

You can get in contact by all means.

Financial rewards.]]>
The game still NEEDS various 3D assets to reach its full potential. Ranging from Mixamo-riggable 3D humanoid characters, to meshes of items and weapons, to the blocks the spaceships are made of. When there are more 3D character models we would love to include them in development and marketing videos with custom animations to tell stories.

No experience requirements. 3D assets will have to be either created with Blender or exported to work well with Blender. You must also UV unwrap the models. Textures can easily be created and modified with a tool like ArmorPaint.

3D humanoid character designers are of high value.

You will have to submit your work to our Gitlab instance and to get your account activated you have to sign the contributor license agreement.

Blender files of the used 3D assets can be delivered on request.

You can get in contact by all means.

Financial rewards.]]> https://starwolves.io/thread-4.html Sat, 03 Dec 2022 18:00:25 +0000 starwolf]]> https://starwolves.io/thread-4.html
No experience requirements, as long as you can create the desired assets. The submission process is likely to require several iterative improvements on your work before it is accepted. Multiple versions or concepts could be requested. You will have the chance to submit your work on our Gitlab instance. To get an activated account on gitlab.starwolves.io you will have to sign the contributor license agreement.

You can get in contact by all means.

Financial rewards.]]>
No experience requirements, as long as you can create the desired assets. The submission process is likely to require several iterative improvements on your work before it is accepted. Multiple versions or concepts could be requested. You will have the chance to submit your work on our Gitlab instance. To get an activated account on gitlab.starwolves.io you will have to sign the contributor license agreement.

You can get in contact by all means.

Financial rewards.]]> https://starwolves.io/thread-1.html Thu, 24 Nov 2022 18:13:24 +0000 starwolf]]> https://starwolves.io/thread-1.html 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 !
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.


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!

      

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.

     

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.


      

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.


   
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.


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.


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.

  

 
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!

   
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.


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!!!!]]> 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 !
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.


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!

      

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.

     

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.


      

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.


   
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.


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.


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.

  

 
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!

   
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.


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!!!!]]> https://starwolves.io/thread-3.html Thu, 24 Nov 2022 17:53:26 +0000 starwolf]]> https://starwolves.io/thread-3.html Security Policy
Security related information regarding Star Wolves product development and self-managed services.

Domain names
The domain names make use of DNSSEC.

Email postmaster
The email postmaster that sends emails to users for verification and recovery options only sends SSL-encrypted emails.

Server security
Server installations are deployed on Linux and have undergone routine security measurements. From intrusion prevention software, to whitelisting only specific static IP addresses with firewalls and by making proper use of Linux users, permissions systems and administrators use password vaults with randomly generated passwords and two factor authentication.
Services run on secure servers inside data-centers with optimal geographic positions. These data-centers are secured and only physically and remotely accessible by trusted people.

Service security
Web services are offered as HTTPS-only.
User and admins ervices that provide login portals have sets of minimum password requirements. Login functionality of our services comes either as rate limited or with captchas to protect against bots. Or both!
Backups are performed every month and are only accessible by persons of high authorization.

1. MyBB (starwolves.io forum)
MyBB is a free open source BulletinBoard project that has existed and matured for many years. It has undergone a lot of security analyses and updates. For this instance the security advises have been heard and many security related settings have been tweaked. The MySQL database has been secured.

2. Gitlab (gitlab.starwolves.io)
Gitlab community edition is an open source end-to-end software development platform with built-in version control, issue tracking, code review, CI/CD, and more. The security advises have been heard and security tweaks have been made to it as well. Gitlab is mature and backed by big business.

3. Matrix (comms.starwolves.io)
Dendrite is a new Matrix homeserver written in Go. It is free open source and currently still in an early development state. Matrix is a very secure messaging system and messages are only stored in encrypted forms inside the databases.

4. Store (store.starwolves.io)
The store is a custom Node.js solution that accepts credit card payments with Stripe. We do not store any sensitive payment or personal information on our servers, instead these are stored on the servers of Stripe. The store has rate limiters installed and user passwords are hashed using Argon2. Input on all POST and GET methods are validated server-side. SQL queries that involve input are escaped. Sensitive endpoints are whitelisted by IP address. The store is exclusively served over a secure https connection. Server-side API keys have been stripped of as much permissions as possible.

Security of high authorization persons
Persons with high levels of access are expected to practice digital hygiene. This is reserved for server maintainers, administrators, DevOps and the like.
Required digital hygiene points:

1. Manage your device(s) accounts with access to high authorization accounts(1) responsibly, professionally and maturely and only entrust it to people that you explicitly entrust with all this data (people whose full identity you know) and people that have to your estimations a low chance of maliciously making use of your device(s).
   
2. Usage of two-factor authentication for all relevant accounts(1). Two factor authentication secrets must be stored inside a password protected ENCRYPTED application (like Android app Aegis) or other secure password vaults with TOTP features.
   
3. Usage of a password vault with randomly generated strings as passwords for the relevant authorized accounts(1).
   
4. Usage of device and disk encryption supplied as features with operating systems for devices that have access to relevant authorized accounts(1). For Windows users, this includes BitLocker + character PIN on boot.
   

For persons with such access: A full identity exchange including verification of legal personal identification documents through trusted services (ie electronicid.eu) are required. 


Footnotes:

1. Accounts that have high levels of authorization to one or more of our servers, services or products. ↩ ↩2 ↩3 ↩4
   

]]> Security Policy
Security related information regarding Star Wolves product development and self-managed services.

Domain names
The domain names make use of DNSSEC.

Email postmaster
The email postmaster that sends emails to users for verification and recovery options only sends SSL-encrypted emails.

Server security
Server installations are deployed on Linux and have undergone routine security measurements. From intrusion prevention software, to whitelisting only specific static IP addresses with firewalls and by making proper use of Linux users, permissions systems and administrators use password vaults with randomly generated passwords and two factor authentication.
Services run on secure servers inside data-centers with optimal geographic positions. These data-centers are secured and only physically and remotely accessible by trusted people.

Service security
Web services are offered as HTTPS-only.
User and admins ervices that provide login portals have sets of minimum password requirements. Login functionality of our services comes either as rate limited or with captchas to protect against bots. Or both!
Backups are performed every month and are only accessible by persons of high authorization.

1. MyBB (starwolves.io forum)
MyBB is a free open source BulletinBoard project that has existed and matured for many years. It has undergone a lot of security analyses and updates. For this instance the security advises have been heard and many security related settings have been tweaked. The MySQL database has been secured.

2. Gitlab (gitlab.starwolves.io)
Gitlab community edition is an open source end-to-end software development platform with built-in version control, issue tracking, code review, CI/CD, and more. The security advises have been heard and security tweaks have been made to it as well. Gitlab is mature and backed by big business.

3. Matrix (comms.starwolves.io)
Dendrite is a new Matrix homeserver written in Go. It is free open source and currently still in an early development state. Matrix is a very secure messaging system and messages are only stored in encrypted forms inside the databases.

4. Store (store.starwolves.io)
The store is a custom Node.js solution that accepts credit card payments with Stripe. We do not store any sensitive payment or personal information on our servers, instead these are stored on the servers of Stripe. The store has rate limiters installed and user passwords are hashed using Argon2. Input on all POST and GET methods are validated server-side. SQL queries that involve input are escaped. Sensitive endpoints are whitelisted by IP address. The store is exclusively served over a secure https connection. Server-side API keys have been stripped of as much permissions as possible.

Security of high authorization persons
Persons with high levels of access are expected to practice digital hygiene. This is reserved for server maintainers, administrators, DevOps and the like.
Required digital hygiene points:

1. Manage your device(s) accounts with access to high authorization accounts(1) responsibly, professionally and maturely and only entrust it to people that you explicitly entrust with all this data (people whose full identity you know) and people that have to your estimations a low chance of maliciously making use of your device(s).
   
2. Usage of two-factor authentication for all relevant accounts(1). Two factor authentication secrets must be stored inside a password protected ENCRYPTED application (like Android app Aegis) or other secure password vaults with TOTP features.
   
3. Usage of a password vault with randomly generated strings as passwords for the relevant authorized accounts(1).
   
4. Usage of device and disk encryption supplied as features with operating systems for devices that have access to relevant authorized accounts(1). For Windows users, this includes BitLocker + character PIN on boot.
   

For persons with such access: A full identity exchange including verification of legal personal identification documents through trusted services (ie electronicid.eu) are required. 


Footnotes:

1. Accounts that have high levels of authorization to one or more of our servers, services or products. ↩ ↩2 ↩3 ↩4
   

]]> https://starwolves.io/thread-2.html Thu, 24 Nov 2022 17:48:20 +0000 starwolf]]> https://starwolves.io/thread-2.html The following rules apply to Star Wolves platforms and services such as the SS14 server and the official Space Frontiers Discord server.


0. Regarding minors. 
(I) NO minors below the age of 16 are allowed to be present or to partake in our server or services unless they are accompanied by parental consent AND by parental supervision.
(II) Orderly and respectful conduct from adults around or towards minors is a standard that you must do your best to uphold at all times.
(III) In and around the SS14 server and the default 16+ Discord channels you must always assume minors are watching and present, which means you must moderate your own behavior accordingly. Do not be overtly rude, vulgar or mean to other users; instead resort to pinging or messaging staff members to resolve issues.
(IV) The SS14 server and the default 16+ Discord channels prioritize light-hearted, playful & mutually courteous and respectful behavior.
1. No NSFW conversations or content.
(I) No extreme vulgar, overly violent, disgusting, brutal or sexually explicit conversations or content.
2. With respect to freedom of speech.
(I) We offer everyone the freedom of speech and freedom to offend inside our designated 18+ Discord channels. However, this freedom is not a given in our Space Station 14 game server or in the default Discord 16+ server channels.
(II) But to a reasonable extend that doesn't result in the degeneracy of our chat. Please, dependent on the severity of the offending speech you may have outed, consider how often and when you would like to repeat it in this server.
(III) We also offer a place to discuss controversial topics, but when you discuss or mention such topics ensure you do so with the right motives. It is easy to provoke a lot of emotions and chaos in the chat by being careless with what you write.
(IV) Jokes about sensitive topics are okay but refer to Rules 2.II and 3 . We will do our best to allow for genuine jokes, but we keep our eyes out on controversial jokes a bit more. Just because sometimes the motivations aren't always to truly try and make people laugh.
3. No bad trolls.
(I) Please ensure that the persona you represent in our server is "real enough". Ie not just some shady impersonal account that constantly attempts to disrupt and only acts in non-contributive and disrupting patterns (no bad trolls basically).
(II) If your account shows similarities with that of a bad troll you always invoke the chance of a potential misjudgment from our moderation team due to the unchangeable nature of the internet.
4. No unnecessary toxicity.
(I) Do not start malevolent flame wars with other toxic members, if people join this community with the sole intention to troll or be non-constructively mean, they should be removed from the group.
(II) Creating flame wars with all kinds of insults and toxic/nasty behaviour towards one another is a bad display for public channels. If you want to fight someone and they hate you too, start the fight in DMs.
5. Do not break the relevant Terms Of Service on the platforms we use.
(I) Corporate and/or public community platforms like Discord have great reach and advantages. We do not want our community banned on those places. For the importance of freedom of speech freely access our self-hosted discourse platforms such as our Matrix server (currently offline).
Staff Rules:
1. Punish users with an escalation method.
(I) Severity of punishments are decided by the severity of the violation and depending on if the violator has previously been warned or punished before for (similar) violations.
(II) The stair-case to punishment escalation involves several timeouts before more severe punishments are made.
(III) If the violator is suspected to violate Rule 3.I the escalation staircase could be bypassed when there is a shortage of time/staff-manpower or if a wave of trolls is active.
2. Punishment code of conduct.
(I) Incorrect punishments deem to be corrected and apologized for.
3. Staff code of conduct.
(I) Staff members are not expected to aggravate members or situations for the sole sake of causing chaos.
Report disruptors and rule breakers by tagging or DMing staff members.]]> The following rules apply to Star Wolves platforms and services such as the SS14 server and the official Space Frontiers Discord server.


0. Regarding minors. 
(I) NO minors below the age of 16 are allowed to be present or to partake in our server or services unless they are accompanied by parental consent AND by parental supervision.
(II) Orderly and respectful conduct from adults around or towards minors is a standard that you must do your best to uphold at all times.
(III) In and around the SS14 server and the default 16+ Discord channels you must always assume minors are watching and present, which means you must moderate your own behavior accordingly. Do not be overtly rude, vulgar or mean to other users; instead resort to pinging or messaging staff members to resolve issues.
(IV) The SS14 server and the default 16+ Discord channels prioritize light-hearted, playful & mutually courteous and respectful behavior.
1. No NSFW conversations or content.
(I) No extreme vulgar, overly violent, disgusting, brutal or sexually explicit conversations or content.
2. With respect to freedom of speech.
(I) We offer everyone the freedom of speech and freedom to offend inside our designated 18+ Discord channels. However, this freedom is not a given in our Space Station 14 game server or in the default Discord 16+ server channels.
(II) But to a reasonable extend that doesn't result in the degeneracy of our chat. Please, dependent on the severity of the offending speech you may have outed, consider how often and when you would like to repeat it in this server.
(III) We also offer a place to discuss controversial topics, but when you discuss or mention such topics ensure you do so with the right motives. It is easy to provoke a lot of emotions and chaos in the chat by being careless with what you write.
(IV) Jokes about sensitive topics are okay but refer to Rules 2.II and 3 . We will do our best to allow for genuine jokes, but we keep our eyes out on controversial jokes a bit more. Just because sometimes the motivations aren't always to truly try and make people laugh.
3. No bad trolls.
(I) Please ensure that the persona you represent in our server is "real enough". Ie not just some shady impersonal account that constantly attempts to disrupt and only acts in non-contributive and disrupting patterns (no bad trolls basically).
(II) If your account shows similarities with that of a bad troll you always invoke the chance of a potential misjudgment from our moderation team due to the unchangeable nature of the internet.
4. No unnecessary toxicity.
(I) Do not start malevolent flame wars with other toxic members, if people join this community with the sole intention to troll or be non-constructively mean, they should be removed from the group.
(II) Creating flame wars with all kinds of insults and toxic/nasty behaviour towards one another is a bad display for public channels. If you want to fight someone and they hate you too, start the fight in DMs.
5. Do not break the relevant Terms Of Service on the platforms we use.
(I) Corporate and/or public community platforms like Discord have great reach and advantages. We do not want our community banned on those places. For the importance of freedom of speech freely access our self-hosted discourse platforms such as our Matrix server (currently offline).
Staff Rules:
1. Punish users with an escalation method.
(I) Severity of punishments are decided by the severity of the violation and depending on if the violator has previously been warned or punished before for (similar) violations.
(II) The stair-case to punishment escalation involves several timeouts before more severe punishments are made.
(III) If the violator is suspected to violate Rule 3.I the escalation staircase could be bypassed when there is a shortage of time/staff-manpower or if a wave of trolls is active.
2. Punishment code of conduct.
(I) Incorrect punishments deem to be corrected and apologized for.
3. Staff code of conduct.
(I) Staff members are not expected to aggravate members or situations for the sole sake of causing chaos.
Report disruptors and rule breakers by tagging or DMing staff members.]]>