Technical outline
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 straightforwardRuns 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
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)
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
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"
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"
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
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
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
Procedural planet generator
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
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.
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
Seams
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)
Plate tectonics for planets with molten interior + solid shell
Life: single-cell, more complex, plants
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?
Tutorial?
On-foot game play is tricky!
Last updated