Adventure Simulator is a web-first pseudo-MMO using data-star, Wasm, and WebGPU to make a sort of game which has been impossible to build until now.
The golden age of browser-based web games yielded a number of “pseudo-MMO” games, like Neopets and Club Penguin,1 whose markets have since largely been captured by mobile games and native desktop games. However, new technologies like Wasm, WebGPU, and data-star allow us to make a kind of web-first game that has not been possible to do until recently: one with near-feature and performance parity with native applications.
We aren’t building a normal web game which uses Wasm and WebGPU to run in the browser. We are building a hypertext “bulletin board” game which can act like a normal game when needed, like in combat, and where most of the game logic isn’t even running in the browser but rather streamed, via data-star, from the server.
A traditional MMO relies on a central, authoritative server which maintains the live state of the game world, runs simulation logic in real time, and pushes state updates to clients dozens of times per second. Designing and implementing this server presents a host of enormously complex networking challenges.2 Our plan is to sidestep these challenges by representing our world as a bulletin board:3 a database contains information about players, places, and quests, and players interact with this world-database by making discrete actions through an asynchronous, web-style HATEOAS interface. When players do need real-time action, e.g. when they engage enemies in combat, we create a private virtual server just for their party. Since any real-time networking can quickly become dangerously complex, we intend to keep as much state as possible on the server, using server-sent events to push updates directly to the client as events happen.4
Player characters spend their downtime in settlements: persistent, bulletin board-like social hubs where they can purchase equipment, join parties, and embark on quests. When their party sets out on a quest, players will load into the real-time, WebGPU-rendered combat simulation when they arrive their destination or are randomly attacked along the way. When the real-time simulation is no longer required, players transition back into the discrete hypertext format.
To query a player’s current location, the client sends:
GET /players/42/location
The server responds:
{
"name": "Forest Clearing",
"description": "You are standing in a quiet clearing surrounded by tall pines. A dirt path leads north.",
"entities": [
{ "type": "npc", "id": "wolf-7", "name": "Hungry Wolf" },
{ "type": "item", "id": "herb-12", "name": "Healing Herb" }
],
"_links": {
"self": { "href": "/players/42/location" },
"north": { "href": "/world/zones/forest/path" },
"pickUpHerb": { "href": "/players/42/actions/pickup/herb-12", "method": "POST" },
"attackWolf": { "href": "/players/42/actions/attack/wolf-7", "method": "POST" }
}
}
If the player clicks “Pick Up Herb”, the client doesn’t calculate anything locally; it just follows the provided link:
POST /players/42/actions/pickup/herb-12
The server asynchronously processes this and returns:
{
"result": "success",
"message": "You picked up a Healing Herb.",
"_links": {
"inventory": { "href": "/players/42/inventory" },
"returnToLocation": { "href": "/players/42/location" }
}
}
When someone else visits this same clearing:
GET /world/zones/forest/clearing
They might get:
{
"entities": [
{ "type": "npc", "id": "wolf-7", "name": "Hungry Wolf" }
],
"note": "Someone recently picked the herb here."
}
The herb is gone because it is a shared resource in the database: no live simulation needed, just a persisted state change.
The nearest games for inspiration are Mount and Blade, Battle Brothers, Starsector, and to some extent Kenshi.
Like the former three, the world of Adventure Simulator is separated between the “tactical” layer (a real-time simulation) and the “strategic” layer (which advances in discrete chunks of time, generally after fast travel or resting). We have the same basic gameplay formula: a player recruits a party to adventure with, defeats enemies in randomly generated missions, and uses their hard-earned rewards to buy equipment.
Like in Kenshi and Battle Brothers, players can control multiple characters, though Adventure Simulator characters can be either mortal or immortal. Mortal characters offer a more roguelike/extraction-esque experience, with fast progression and frequent deaths. When one of your mortal characters dies, any wealth not on their person will be inherited by your other characters. Immortal characters offer a more conventional RPG/MMO experience, which emulates the cost of mortal characters with costly respawns and slow healing.5
If there is any design choice in particular that makes our approach unique, it is specifically that we relinquish the vision of having a continuous, immersive world. Kenshi clings to it despite all the systems of the game going against it,6 and it makes real sandbox MMOs impossible for networking, but we look to singleplayer games like Starsector and Mount and Blade which chose to have a strategic layer, not because they had to for networking, but because their gameplay loop would be really boring and repetitive without one. You can actually walk around cities in Warband and Bannerlord, and zero players actually do this outside of sieges because walking around is boring. Thus, we take the basic design of those games and combine it with the one infamous problem which their design incidentally solves: MMO networking.
The world of Adventure Simulator is a fantastical version of Earth. Warhammer Fantasy players or readers of pre-Tolkien fantasy will be familiar with the idea: essentially, the setting is historical Renaissance Earth with generic fantasy elements inexplicably sprinkled throughout.7
The heuristic here is to place fantasy elements in places that don’t fundamentally alter historical conditions too much. Elves generally keep to forests or fictitious islands; Dwarves dwell within mountains; and creatures like Orcs, Goblins, Beastmen, and the Undead either roam as hordes or infest caves, crypts, and abandoned Dwarven settlements. To the extent that the kingdoms of Men interact with these fantastical elements, it is generally in hiring heroes to deal with the nuisances caused by hostile fantasy creatures. Elves and Dwarves are uninterested in Human political squabbles over borders and wars of succession, and fantastical enemies never really pose a strategic threat to Human kingdoms, so the historical and fantastical elements of the setting can generally avoid stepping on each others’ toes.
For the MVP, the playable section of Earth will be limited to Italy.8 In the long term, we will gradually expand to all of Europe and beyond.
Below are some guiding principles for Adventure Simulator development.
We tentatively intend to keep everything GPL-3.0, but we are willing to hear out the case for other licenses.
Adventure Simulator is not designed solely to facilitate a fantasy game. Its open-source nature means that modders can come in and take it in all sorts of unexpected directions in the future. They may create total conversions to other fantasy settings, sci-fi, or… something else.
It should be easy for players to create content for the game, and to that end, we use low-fidelity procedural assets to greatly reduce the barrier to entry. This doesn’t mean that we don’t care about fidelity at all; it means fidelity must necessarily come from procedural iteration rather than a trained CG artist. The system Nintendo uses for Miis, for example, is a better example of how we might approach a character creator than, say, Baldur’s Gate III. But that doesn’t mean that we’re going for an especially cartoony art style, either; there’s nothing preventing a system like that from applying to more realistically proportioned characters (as Nintendo did, more or less, with Breath of the Wild and its sequel).
We would like the underlying gameplay systems to be realistic, as the real world can generally offer an unambiguous answer to any design question. It’s not always easy to find out what that answer is, nor is it always easy to implement the real world solution without resorting to simplified abstractions,9 but all the imperfect answers at least point in the same direction.
The real world is not always as fun as a game ought to be. Fortunately, there are two ways to get around this:
We can abstract away the parts of the real world that are not particularly fun.
Holding W to walk 50 km between settlements is not particularly fun, nor is resting for several months to heal a serious injury, but if we put these activities in the “strategic layer” of the game (separate from the real-time “tactical layer”), a player can skip them by fast-forwarding in time.
Likewise, micromanaging inventory is not particularly fun, but as the game becomes complex enough to necessitate this, we can also add tools to automate it, such as setting a desired weight limit and value/weight ratio for loot.
We can design the non-real parts of the world to be more fun.
Being that this is a fantasy world, the fantastical elements are free variables for us to balance the game with. Suppose real-life combat is too fast for it to be viable to reliably dodge most attacks. We can simply give common fantasy enemies like Goblins, Orcs, and Skeletons such poor melee skills that an agile player character can reliably dodge them. Or suppose stealth is too frustrating with realistic detection ranges. We can just ensure that these fantasy creatures tend to have very poor eyesight.
We are in the process of registering with Open Source Collective, a 501(c)(6) that handles the legal and administrative overhead for facilitating donors to pay contributors. The two founders, Bruno Segovia and Adler Halbe, are willing to contribute serious portions of their incomes to see at least a prototype of this through. Their contributions will largely be in the form of cash, however, as their day jobs from which this cash originates are pretty intensive. But they will be available most days, especially in the evenings (PST), to offer guidance and help coordinate the project.
Once the game works well enough to start hosting (and is sufficiently fun to be worth anyone’s time), we will try and transition to a more sustainable funding model: one where players may have a single character per account for free but multi-character accounts require a subscription fee, which we use to hire more developers and pay for server costs.
Everything will remain completely open source and non-profit throughout this. Adler and Bruno have no intention of profiting from this project. They simply wish for it to exist.
All positions are remote-only and with no Zoom meetings (unless you actually want them). Contact halbe@adventuresim.org to apply.
Design and implement the asynchronous strategic layer of the game: the database, HATEOAS interface, and gameplay systems.
Design and implement the real-time tactical layer of the game, both the server and the client. If you think that you are a cracked 10xer wizard that can do both layers, you can apply for both and negotiate for up to $80k.
Design and implement a plugin to generate models for game objects. The plugin, like the rest of the game, will be tentatively GPL-3.0, but if you want a dual license or MIT/Apache, we’re willing to negotiate.
If you think that you can help in some other way, like writing or testing, send an email to halbe@adventuresim.org.
And actual MMOs, such as Runescape and AdventureQuest. ↩
This unified server has to handle massive concurrency, synchronize thousands of players in real time, ensure consistency so everyone sees the game world, and maintain low latency. However, we don’t have to do any of this on a bulletin board because there are no active connections to maintain. As soon as the server responds to your request, it forgets that you exist. ↩
You can think of a bulletin board as halfway between a Discord server and an Internet forum. Think of an imageboard: the threads are more live than reddit or forums, less live than chatrooms. The benefit of the format is that it works both synchronously and asynchronously; you can have a nearly live chat with a guy on /tg/, but the format also works even if you’re the only live user on a given thread at that time. This isn’t an unheard-of inspiration for a fantasy RPG; Dragon’s Dogma’s internal project name was “BBS-RPG” due to the “custom mercenary character” system. We would be taking the idea much further than DD did, of course. ↩
We end up rendering a sort of network-driven “immediate mode” view of the world. ↩
Mortal characters will probably be randomly generated by default. The idea is that players who prefer custom characters will naturally gravitate to the immortal option. ↩
Even at 4x speed, which most computers can barely handle simulating, you’re still spending most of your time watching your characters travel or rest. ↩
The year is approximately 1543 AD: the height of Charles V’s transatlantic empire, the year the Portuguese reached Japan, and the earliest possible time in which all major cultures of the world are at least indirectly aware of each other. (Any later and your combat has too much “shot”, not enough “pike.”) ↩
Renaissance Italy offers huge cultural and geographic diversity in a relatively small area: within a few hundred kilometers, you have bustling urban centers, Alpine mountain fortresses, rural farmland and villages, and ancient Roman ruins. With warring city-states and feuding families aplenty, it also offers the perfect economy for professional adventurers, and all the while, it is instantly recognizable even to non-historians (think Leonardo da Vinci, Machiavelli, and the Medicis). ↩
Quantum physics is not in-scope for the MVP, to say the least. ↩
