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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ostomo.gitbook.io/ostomo-notes/challenges.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.