Challenges

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

Technical

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

Non-technical

• 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”