Starwolves | Space Frontiers
The initial Space Frontiers vision [Update #1] - Printable Version

+- Starwolves | Space Frontiers (https://starwolves.io)
+-- Forum: Space Frontiers (https://starwolves.io/forum-1.html)
+--- Forum: Updates (https://starwolves.io/forum-2.html)
+--- Thread: The initial Space Frontiers vision [Update #1] (/thread-1.html)



The initial Space Frontiers vision [Update #1] - starwolf - 24-11-2022

Space Frontiers the game
The future and vision beyond the pre-alpha prototype
By Ramses

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

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

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

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

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

The main development of Space Frontiers takes place on our Gitlab instance. The project is also available on Github as a mirror, please star us Heart !
There are automated tools that generate documentation from cargo workspace by parsing the code comments and laying them out for the structured technical documentation website.

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

A showcase video can be found here.

[Image: editor_screenshot.png]
Media I screenshot from the Godot editor.

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

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

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

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

[Image: crates_screenshot.png]       [Image: plugin_builder_screenshot.jpg]

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

[Image: screenshot_pistol_crate.png]      [Image: screenshot_pistol_plugin.png]

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


[Image: screenshot_main_menu_crate.png]       [Image: screenshot_main_menu_plugin.png]

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


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

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

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

[Image: sfatmosss.png]
Media X a visual representation of the atmospherics diffusion module at work.

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

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

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

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

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

[Image: animation_tree.png]   [Image: bone_blending.png]

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

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

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

[Image: godot_material.png]    [Image: overdraw_screenshot.png]
Media XVII - XVIII screenshots from the Space Frontiers Godot prototype asset editor.

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

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

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

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

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

[Image: sfss.png]
Media XIX: A screenshot of the Godot prototype in action.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let's see if this forum can get populated.

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

Leave your replies down below!!!!


RE: The initial Space Frontiers vision [Page #1] - Archange1_ - 24-11-2022

It's refreshing to see someone pour heart and soul into a game


RE: The initial Space Frontiers vision [Page #1] - Skorpionyka - 25-11-2022

This project is surely full of potential , innovative ideas and gives a chance in a future to create an organized community of players and modders , that will become a major pillar of this venture. I wish the owner a significant amount of strength , perseverance, because such a road can be bumpy . Let's hope that more people gathering here to provide help, support. Let an Empire arise !  May the Creator / all cosmic forces bring success and fruitfulness with many years to come to this project.

Congratulations on the launch of your website ! Cool


RE: The initial Space Frontiers vision [Page #1] - starwolf - 25-11-2022

@"Skorpionyka" The future is desperately begging to be reshaped by people who sacrifice the present. Here is to a fortunate future for Star Wolves! And thank you Mrs.