Technical outline

1. Server software: this is where all the game logic happens.

   • Manages all entities belonging to the organization with bevy_ecs logic. This will be quite straightforward

   • Runs WASM scripts for all entities, "infrastructure" WASM scripts for org logic, etc to make things highly modular

   • Combat logic, death logic, physics simulation, running server-side scripting, in-game market, organization in-game logic (including spawning people & building hospitals) etc.

   • Keeps a merkle log of game states

2. Client software: this is where the rendering happens

   • Ideally lightweight enough to run in the browser (through wasm + webgpu/webgl)

     • Better UX for "gaming while also doing spreadsheets"

     • Enables support for all platforms with a decent browser (e.g. iOS without going through app store)

   • Decoupling client from game logic means that we can have e.g. a different mobile-optimized UI

   • Support plugins such as voice control (convert voice to code client-side)

3. Server-server communication protocol

   • Subscription based; one server can ask another for all entities within a bounding box for example, which is passed around in a nice, compact datastructure. Problem: how to keep sync mostly honest / prevent organizations from spying on each other? Do we want that?

     • Another BIG problem: how does a given know which servers to query to fully populate the views of its users? Location-based DHT? Every server asking every other server does not scale.

   • Dispute resolution system based on the merkle log

4. Server-client communication protocol

   • Also subscription-based; client subscribes to all entities within a bounding box of their field of view/sensor view

   • Server gives client a compact object that represents the current game state, which the client renders

   • Client submits actions to the server like "turn off the engine", "run this script"

5. In-game chat network: routed through servers, location-based (players can discover & talk to people in their vicinity). Connected to out-of-game chat networks via bridge bots

   • Tricky: voice chat. Push-to-talk can get rid of a lot of issues (echo cancellation, variable latency, etc) but can make long conversations annoying

   • We probably also want IRC-like global channels instead of only "local shouting"

6. Game terrain & entities: files containing all pre-defined objects

   • A few main star systems that people start out in

     • Wouldn't organizations just decide this? Probably we don't need to hardcode anything?

     • Maybe we hardcode some things for the hardcoded organizations, which might be interesting for the story (e.g. maybe for the first few years of the game, the USE has planets that are far more developed than any gamer could build, making them attractive targets for conquest)

   • Some basic people, outfits, ships

7. Organization constitution, incentives, token, SDK for declaring property rights & laws, SDK for inter-organization alliances

   • example of property-rights software architecture:

     • wasm script on server that keeps track of property registry, debits people's OrgCoin accounts for property taxes, directs police to criminals, etc

     • wasm script on client that queries the server-script over some interorganizational standard RPC protocol to render property maps

       • this script can also query other organizations' property registries to display on maps too

8. Ship & base building playground / separate software

   • materials + blueprint --> 3D printer --> ship workflow

   • workspace enables people to test drive ships, to evolve features using genetic algos; overall very professional. Most trade will be in materials; blueprints will probably be put on github. Shipyard can possibly be a separate software

   • Base building can be either ksp-style or similar to shipyard

9. Procedural planet generator

   1. Large-scale galaxy map generator: generates the "datasheets" of the planets

      • Possibly we can do a simulation of a primordial solar system: a bunch of random blobs of different elements falling into each other with gravity, until stable objects with stable orbits form

      • If this is slow, we can train a "chemical composition of initial gas blob => stable solar system" NN

   2. Terrain generators based on how these terrains physically form; which ones to use on a given planet depends on the planet's datasheet (e.g., whether it has an atmosphere). For more complex details (the ones beyond craters and seams), run detailed physical based simulation offline to generate data to train approximation neural networks; at runtime, use these neural networks to generate coarser LODs (but fine enough that you have where the rivers are etc.) and then another NN (or some simple noise-based algo) to fill in details for finer LODs.

      1. Craters

         • Is crater frequency on the datasheet?

         • Tidally locked planets often have highly non-uniform crater distribution. Hard code? Or do we simulate stuff hitting the planet and train a neural network that given a solar system datasheet predict the rough crater direction of all planets in it

      2. Seams

      3. Fluid-caused erosion (wind erosion, water, volcanoes)

         • This is certainly the hardest part

         • Complex two-way interaction: fluid erodes planet, new shape then changes fluid flow, etc

         • Fluid flow is highly chaotic (navier-stokes equations)

      4. Plate tectonics for planets with molten interior + solid shell

      5. Life: single-cell, more complex, plants

   3. Gaseous planet large-scale + details generator

      • Can we run a huge 3D Navier-Stokes simulation to generate the cloud swirls etc, then train a NN on this?

10. Tutorial?

11. On-foot game play is tricky!