I've alluded several times to "Ostomo", a decentralized, open-source, open-world, hard science fiction space MMO that — until I get around to building it — unfortunately exists only in my head and some GitBook notes.
The decentralized open-source MMO part is easy to understand: MMOs are possibly the open web/"web3" app with the biggest delta compared to the "web2" status quo.
The hard SF space part deserves a bit of explanation. Of course, hard SF games are rare, and it'd be nice to have a game that fills that niche — especially since I do rather enjoy well thought-out science fiction settings (one of my favorite websites is Atomic Rockets).
But the real reason is that Ostomo's setting and gameplay falls entirely out of a technical limitation — an open-source game cannot have client-side anticheat. There's a surprisingly tight pipeline from "decentralized MMO without anticheat" to "hard SF in space".
"Cheating" is just permissionless automation
Given that we can decentralize a server-auth architecture (a complex discussion for another day), we can avoid really blatant logic-violating cheats like invulnerability or teleportation. But there's also many "cheats" based on client automation that will break most MMOs: aimbotting, AFK grinding, and the like. Combine this with a permissionless network, and you'll even get automated griefing!
The "anti-cheat" approach is to try to use spyware and human moderation to catch people trying to cheat.
A different way is to make the game cheating-neutral. That means that the game mechanics are such that no sort of client-automation "cheating" can significantly change gameplay.
An automation-first game design
This means that the game will be designed to officially support automation. Any actions that the game rules allow a human user take can be delegated to arbitrary, user-written code.
This has a ton of implications for the entire game design:
We immediately see that the setting needs to be a highly automated world. Otherwise, the inevitable client automation will lead to extensive immersion-breaking — "human archers" actually puppeted by advanced fire control algorithms are not part of any reasonable medieval fantasy setting!
So we need a science-fictional future where most things that can be automated are automated. But how far in the future can it be set?
It can't be too fantastically in the future — current-day automation algorithms, though sufficient to simulate near-future automation due to circumventing the whole sensor/actuator problem, wouldn't fit in a 31st-century transhumanist society ruled by superintelligent AIs. And an open-world setting with all sorts of fantastic technology, but 21st-century computational power, would probably fail in all sorts of self-contradiction.
The "Goldilocks zone" is likely a near-future, hard-SF settings similar to the that of The Expanse. Incidentally, it's the TV show that convinced me that space-opera-style combat is possible in a scientifically realistic setting:
With automation comes automated griefing. Mitigating this without anti-cheat puts hard constraints on the topology of a single-shard, open-world setting.
Small game worlds (say, much smaller than planets) are bad — small numbers of griefers can easily paperclip-maximize the world and ruin the game for everyone else. Even if resource constraints make a competitive paperclip-maximizing game fun for some players, there's simply not enough room on a small map for everyone to have fun. Really big game worlds are also bad, since travel time becomes prohibitive. The actual interesting area of the game will still be small and vulnerable to automated griefing.
What we want is a world that's small enough to traverse, but big enough to be hard to fill.
There's basically one science-fictional setting that is both really big and quite traversable: outer space, with some form of faster-than-light travel. The exact scope of outer space can range from anything from a solar system to the entire universe, though in keeping with a common SF trope we'll arbitrary pick "one galaxy" as the game world.
(We'll talk about the exact form of FTL travel a bit later)
Most MMOs have what I call "magic fairy socialist" economies: mission m always produces x units of money, and x money always gets you item y. No real economic production or exchange happens, and in fact, unauthorized trades between players (e.g. trading in-game items for real money) quickly leads to a ban, whether through anti-cheat or human monitoring.
This completely fails in the presence of permissionless automation. The entire game will devolve into automated bots running whatever task produces the most "gold/hour", using it to buy the most sought-after items, and selling them for real money, until everything is so hyperinflated to be worthless.
What we need is an extensive, user-driven market, like that of EVE Online. Nothing pops out of thin air in exchange for destroying money — instead, all production is done through user-directed crafting, and all purchases and sales are between real users. Basic economics dictates that any "free lunches" are quickly snapped up, and the eventual gameplay is highly organic and dynamic rather than focused on most-efficient-grind "meta"s that developers must centrally "balance". This often means emergent economic activity that no game designer could come up with — what other MMO has had massive world wars funded by player-run in-game gambling empires?
Such a market is crucial for automated, grind-free gameplay that's any fun. And with the cornucopia of complex trades enabled through automation, in-game markets will incentivize even more rich and complex gameplay than the heights of EVE Online.
This also lets us entirely get rid of the staple of MMORPGs known as the "mission" — they'll be endlessly exploited by bots on one hand, and on the other hand sufficiently deep emergent gameplay would render them pointless.
With permissionless automation, clever players will exploit violations of physical laws just as ruthlessly as violations of economic principles — especially with a user-crafting economy. There is no plot armor to prevent Star Trek transporters from being used to teleport enemies into space. What starts as a reactionless drive will quickly spiral into infinite free energy (since reactionless drives violate conservation of energy), then extremely cheap relativistic WMDs...
In short, "unobtanium" is okay. Compact nuclear reactors and similar items that are "mere" engineering challenges will not break the game, and webpages like the famous Atomic Rockets Engine List have tons of examples of well thought-out future engineering achievements.
But blatantly unphysical "handwavium" is not, because people will exploit the unphysical parts for advantage and soon the whole game becomes unphysical.
There is one exception to the no-handwavium rule: the setting needs faster-than-light space travel. Not only is does this enable the setting to be "easy to traverse but hard to fill" to deter griefing, travel times that aren't years long are really important for anything even happening within the gamers' lifetime! (KSP and similar single-player games get away with time acceleration, but that won't work for an open-world MMO)
Here we must tread carefully. Like with other unphysical technologies, allowing FTL without breaking everything in physics is notoriously difficult. In particular, relativity tells us that unrestricted FTL travel is equivalent to travelling backwards in time! Leaving aside all its metaphysical paradoxes, backwards time travel — and even regular relativistic time dilation for that matter — will not work in an MMO that runs in globally synchronized Earth time.
Happily, there's quite a bit of prior work in the hard-SF community in coming up with paradox-free FTL. Two of my favorites are:
- Loop-free wormholes: used in the Vergeworlds RPG setting. The physics are a bit complicated, but in short, a set of physical constraints can eliminate time-travel paradoxes from networks of wormholes, which form shortcuts between widely separated points in spacetime. These constraints turn out to be extremely interesting from a gameplay/setting perspective — for instance, it implies that wormhole networks strictly form tree topologies, making nodes close to the root of the network extremely strategically important. Intentionally forming constraint-violating wormhole connections to break existing connections can even form a sort of causality attack and is widely used in warfare.
- Special frame of reference: found in the venerable "Relativity and FTL Travel" webpage by Jason W. Hinson, as a way of quasi-scientifically explaining Star Trek warp physics. Here, the basic principle of relativity that there is no special frame of reference is broken — we introduce a special frame (say, "subspace" or "hyperspace") relative to which all FTL travel happens. With respect to this frame, no paradoxes happen, and this frame essentially defines a sort of Newtonian, "objective" spacetime coordinate system. No existing physics has to be broken; we just have to posit this frame as being yet undiscovered.
So we know that some form of FTL travel that doesn't totally break non-FTL physics is possible. The exact form to pick, again, must return to the overall principle of gameplay that doesn't degenerate under mass permissionless automation.
The eventual solution I settled on is somewhat of a combination of the above two ideas. This will be fleshed out more as I get closer to actually building Ostomo, but in broad strokes:
- Around 300 years before the game setting, humanity first discovered how to build wormhole tree networks. This forms the motivation for the formation of a highly centralized state that rules with an iron fist through the control of the necessarily single-root wormhole network. (Note that unlike Vergeworld wormholes, these wormholes are huge and anchored in space rather than sitting on planets, making space travel still use space ships rather than cars).
- Eventually, special-frame-of-reference FTL (the "slipdrive") was discovered, contemporaneous with a massive civil war that tore the wormhole empire apart.
- By the time of the setting of the game, wormhole networks are still used for bulk peacetime transport, since massive amounts of cargo can traverse vast distances through a wormhole connection. These wormhole networks are synchronized to the "slipspace" frame of reference and do not need to form tree-shaped networks. A weakness is that wormhole mouths are very capital-intensive to build, and easily destroyed in warfare.
- Slipdrives are much more expensive to operate and much slower (~10,000-100,000 c in ideal conditions) than traversing a wormhole. But they avoid the capital cost and vulnerability of wormholes and can be fitted to any starship, and are the staple of transport during wartime, as well as along sparsely traveled routes.
This "hybrid FTL" scheme largely falls out of balancing rapid traversal (wormholes) with anti-griefing — if the only FTL is wormholes, wormhole-bombing terrorists can quickly ruin the game, but with a slower but more inconvenient backup, it "merely" becomes a casus belli for a spicy in-game war.
Instant, FTL communications cannot be avoided — it's called Discord. In-universe communication tech would need similar latency to avoid immersion breaking.
(Given that this would be a decentralized game, this means that in-game chat would probably be based on some sort of confederal Matrix-like protocol...)
In summary, an anticheat-free open world MMO must be an automation-first MMO. And being automation-first immediately leads to the entire Ostomo setting:
|Near-future, hard-SF setting similar to The Expanse
|Outer space in one galaxy with some form of faster-than-light (FTL) travel
|User-driven market with user-directed crafting and real user purchases and sales, similar to EVE Online
|No blatantly unphysical elements, except for FTL travel, which is handled with care to avoid breaking physics
|Combination of wormholes and special frame of reference to allow rapid traversal without time paradoxes. Wormholes for bulk transportation and slipdrives for independent and wartime transport.
|Instant, FTL communications with similar features to Discord
Of course, we haven't answered the technical question of how to implement such an open world in a decentralized fashion, or filled out the exact worldbuilding of the setting. I look forward to writing more blogposts about those pieces; in the meanwhile my half-baked thoughts can be found in the Ostomo GitBook.