Strategic Servers

Responsibilities

The purpose of this server is to generate quests, handle trading, and serve as a register for parties. You must have a party to set out on a quest or travel to another settlement. These can be segregated per-settlement if network load demands it later down the line, or dynamically grouped into regions to balance load.

Scaling

Our network will facilitate the bare minimum of what can be considered a single-world MMO. The trick here to avoid the classic "ten thousand players suddenly decide to go to one location because a popular twitch streamer is there" problem is that the open world is not a real-time network, its structured more like a bulletin board.

When ten thousand people are "in" a city, it just means that ten thousand people are viewing a HTML page for that city and on the database, their official character location is that city. They interact with each other by making posts in the city, as if each character was a user on a forum.

HTMX or Data-star

To keep the interface very simple, we will do everything via HTTP and would prefer to handle all of our interaction in the strategic layer between the client and server with HTMX or Data-star. These two will be very similar at this layer, but the value of Data-star is that it might allow us to also use it with different plugins for the tactical layer.

Accounts

It is not strictly necessary to have users manually make accounts before they start playing. Essentially, visiting the website first checks to see if there's a cookie for an existing account that you can login with. If not, it can automatically create a new one. This is not necessarily the same cookie that actually stores credentials (which presumably expire), its just "Has an account existed on this client?". If it hasn't, create a new account automatically, if it has and the credentials expired, prompt to sign-in again. Accounts do not require emails, Oauth IDs, or any additional information. You simply have the option to add those later once you decide if you actually like the game. We might also prompt the user to do this the second time they load the website, and they can also do it themselves in the settings.

This will mean a ton of abandoned accounts from people (or bots) who visit the website then immediately leave. But the only thing that the server has to track are living characters and which account controls them. Since you can only make mortal characters by default and time advances regardless of whether or not you are actually playing, they will eventually be cleaned up.

There should also be no cost to inactive characters aside from storage and periodically checking whether they should have died of old age by now. Time does not actually advance until you log back in, at which point it advances all at once to 1 year behind the official time. If its actually a problem we can also just say that all characters only exist per-session (and for a day or so afterward) until you set up Oauth and warn players about this.

Tactical Servers

Every time characters encounter combat, stealth, or hazardous terrain they are provisioned a tactical server. A tactical server runs a headless version of the gameplay and all interactions are mediated through it, there are no peer-to-peer connections (for simplicity). The only gameplay-relevant events that originate from clients are input. Clients do not use a rollback system or anything to anticipate the future state of the server and process gameplay independently, they just have to wait for a ping roundtrip to see the effects of their inputs (for simplicity). This means that there would be a very noticeable amount of input lag, but the secondary animation system which exclusively runs client-side can mitigate this by beginning animations immediately and extending their duration. There is no PvP in the MVP, but we will eventually want to support it.

At the conclusion of a tactical simulation, the clients are referred back to the strategic server.

Websockets or Data-star

Websockets are the default choice for real-time communication on the web between the clients and server, but if we aren't trying to do rollback then it may be simpler to use Data-star. Data-star is built with server-authoritative applications in mind, but its unclear how friendly it will be to the secondary animation system since its goal is to eliminate client-side state.

Halbe: I proposed the idea on the Data-star Discord and the feedback is essentially that its certainly possible, and probably much simpler than doing actual rollback, but also much more complex than a purely server-driven state in which the client does nothing other than input and rendering. One of the devs said that he is working on a "Darkstar" plugin whose goals overlap with this, and that we'd essentially be reimplementing most of that, so it might be best to start with a purely server-driven approach then consider adding some client state for secondary animation later down the line.

PvE Combat

Network Rundown

1. Attacking Client declares an attack and sends input to server.
2. Server receives attack input and immediately decides what the enemy's reaction time is, informing all clients about the attack, whether it will actually hit, where it will hit, how much damage will it do, and when it will hit
3. Attacking client updates animation to account for the expected outcome, other clients are able to begin the attack and dodge animations at the same time (but may choose to render an artificial reaction time on the dodge) You cannot cancel attacks, or at least if you can then it has to be done double pingtime before when it would canonically hit so that there's no need for rollback

PvP Melee Combat (not in MVP)

Cheating

If we aren't doing rollback (and therefore the client doesn't have to have a 1:1 mirror of the simulation) then we do not care about detecting or preventing cheating. Having a pro-gamer level reaction time is less of a factor in combat than having good stats, so there's an upper-limit on how much of a problem cheaters are.

Network Rundown

1. Attacking Client declares an attack and sends input to server
2. Server forwards attack to all clients, which includes a tentative speculation of whether it will actually hit, where it will hit, how much damage it will do, and when it will hit based on the assumption that the defender will either not attempt to dodge, or will not dodge quickly enough
   1. If it takes the defender longer than X milliseconds to respond then they'll receive a direct/critical hit anyways so past that point it doesn't matter if you even try to dodge, the other clients can just assume that you didn't
3. Defender receives attack and may or may not respond with a dodge input in time
4. (optional) Server forwards dodge response to all clients
5. Clients receive dodge response and can now be certain of what will happen, updating their animations accordingly

PvP Ranged Combat

Option A: Similar to melee

Ranged combat can be treated similar to melee combat, where the duration of the attack is a function of both how long it takes to aim the weapon and how long it would take the projectile to reach its target. This should be good enough for bows, slings, and throwing weapons, which don't allow you to instantly loose a projectile (holding a bow drawn is exhausting) so its not that bad to say that pointing at an enemy and shooting is something that can plausibly take >0.3s. You cannot draw a bow first and keep the arrow held, then choose an enemy, and like with melee you either can't cancel attacks or can't cancel by the time that other clients believe that an arrow has been loosed. This will work poorly with crossbows and especially with firearms, both of which don't have to be loaded immediately before firing and the latter has projectile speeds that are too fast to work well here. They can still be functionally implemented though, as the attack duration just represents your character taking the time to aim at a particular enemy.

Option B: No dodging

To speed up ping duration, we don't assume that the defender can plausibly dodge ranged attacks (at least from loaded crossbows/firearms). Thus the outcome of the attack can be canonically decided as soon as the server receives it. This will sometimes be frustrating for players (though usually realistic), but it can be mitigated via luck.

Option C: Simulate projectile collision

Avoiding projectiles now has nothing to do with a defense calculation and is entirely simulated via physics. The accuracy of the projectile doesn't determine whether it will hit, but rather whether it will hit given that the defender does not adjust their movement trajectory or primary animation. This will make long-distance combat better, as otherwise projectiles will have to track characters that change their course if the server has decided that they will hit. But it is more complicated, and if we aren't doing rollback it will lead to scenarios where the primary and secondary animations are out of sync and a projectile which appears to hit actually misses or vice versa. Therefore this is not planned for the MVP.