Very cool, though wouldn't using durable objects for a MMO type game become prohibitively expensive vs using websockets with a stateful server? I assume your game is not sending that many requests so its not too bad.
good question. it's not real-time - actions resolve over hours.... request rate per active player is single digits per minute, often zero. DO alarms handle the time-based stuff (fleet arrivals, combat resolution, resource ticks) so there's no persistent connection cost. so far costs have been negligible
compared to running an always-on origin.
websockets + stateful server would be the right call for anything realtime. for tick-based strategy with hour-long timers, DOs feel like the cleanest fit - i get per-island isolation, alarms, and storage in one primitive without managing a connection pool.
yeah, for the game tick i went the other way though. alarms fire on schedule, resources calculated on-read from timestamps. a player can close the tab for 8 hours and the world still moves correctly when they come back, without holding any per-session state.
Fair enough, I didn't mean to criticize your work in any way, or even buy into a criticism of it. I was really just pointing out to GP that their "or" was actually an "and".
no worries at all, didn't read it as criticism. fair correction too, DOs do both, i just leaned alarms-first for this use case. appreciate you keeping the thread accurate.
websockets + stateful server would be the right call for anything realtime. for tick-based strategy with hour-long timers, DOs feel like the cleanest fit - i get per-island isolation, alarms, and storage in one primitive without managing a connection pool.