Ostomo notes


The vision outlined presents some very interesting problems, both technical and non-technical, that no game so far has needed to solve.


  • How is the game engine going to be architected?
    • Likely a strong separation between “world state maintenance” vs “viewers”. Similar to SL
      • Backend can be in flexible game engine like Bevy
    • Highly specified, deterministic procedural generation
      • Unprecedented in gaming world
      • Will allow massive amounts of third-party tools to participate
    • Everything except the natural world is player-built
      • Buildings
      • Vehicles (ships, planes, spacecraft, maybe even cars)
      • Heavily scripted with WASM/Racket/Lua/some suitable language
        • Server-side computation heavily rationed
        • Formal “gas” system probably doesn’t need to exist; throttling may work just as well
      • Computationally heavy stuff may happen client-side
        • Targeting algorithms
        • Autopilots/AIs
  • How can we have a “single-shard” feel with independently operated servers?
    • “Run it all on a blockchain/rollups/etc” is not going to work for a detailed, realistic 3D world
    • Idea: DAO-maintained reputation system that blacklists rule-breaking servers
      • Servers own areas of space
      • Some kind of rule assigns “unclaimed” space to servers.
    • Critical state is still on a trustless/near-trustless system
      • Asset ownership
      • Server list
      • PKI
      • Transparency logs for server state.
    • Server-state witnesses are broadcast in a P2P network to everybody who connects to a given server.
      • Assumption: inconsistency will be caught
    • Example 1: Alice kills Bob on Charlie’s server. Bob falsely claims Charlie’s server helped Alice cheat.
      • Appeals to DAO by submitting a human-readable complaint
      • Charlie uploads a server-state witness dating from at least 24 hours before the claimed event
      • DAO members each subjectively verify the server-state witness and sign it
        • This is not done on-chain, but can be at least partially automated
      • Complaint is closed, and Bob is punished for submitting a false complaint
    • Example 2: Witness inconsistency by a server
      • Directly kicks the server off the list, perhaps also destroying some tokens.
    • Example 3: In the middle of a war, Charlie’s server DOSes a major faction, leading them to lose.
      • Manual complaint
      • Manual resolution
  • On-foot gameplay is necessary and challenging: requires complex, low-latency physics simulation. Unsolved problem.


  • How to balance fake roleplaying with minmaxing?
    • False dichotomy
    • Meatspace economies don’t have this problem
    • Solution is to have a detailed world full of organic social interaction, and automate away the boring stuff
  • Setting? Sci-fi hardness?
    • See setting doc. In short, hard sci-fi with some plausible escape hatches.
      • Most importantly: wormhole-based FTL, as well as non-wormhole-based, but highly inconvenient and slow “preferred frame of reference”-based FTL
        • Wormholes are big and need to be in space to necessitate starships
        • Militarily analogous to railroads vs walking in late 19th century warfare
    • Hardness is necessary because there’s no “plot armor” to keep the world sane despite insane technologies.
      • For example, in Star Trek you never need to worry about people abusing transporters to transport enemies out of their ships into space.
      • In a game that’ll become the go-to combat strategy
      • “Real life is balanced”