Challenges
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”
Last modified 6mo ago