that matches what i'm seeing - people want both. fast feedback loops in the first hour and stuff that still pulls them back three weeks later. hardest part is making the slow stuff feel like it matters before they've invested the time. still figuring it out with a lot of nice feedback from the community.
You mention resources calculated on-read and combat writes batched. When a fleet crosses from DO1 to DO2 and triggers combat, how are you handling that consistency boundary? Colocating everything into the target DO, or something else?
Also, actual alarm drift in prod with concurrent fleet arrivals? And client reconciliation when the countdown hits zero but the alarm hasn't fired?
durable objects: Most important is the Ocean logic for me. The source Island immedtiatley dispatches ships (fire and forget) and registers the fleet in the Ocean. When the alarm is triggered, the battle takes place within this single DO context: the defender's state is read and the results are written back. in parallel arrivals on the same island are serialized.
no cross DO transactions are happening. the problem won't be (yet) that fleet arrivals will be just miliseconds apart.
with alarm drifts: i havent observes that beahiuvor yet three is a drift check performed every 100 alarm cylces with self correction if necessary.
on the client sync part: countdown runs on the epoch by the server. hits zero, waits a sec for buffer, hard-reloads. if the alarm hasn't fired yet, next alarm cycle (shortly after) resolves it. safety net: any fleet 5+ minutes overdue gets cross-checked, with exponential backoff retry on failed return deliveries. no websocket push on this one as mentioned earlier.... the reload is the reconciliation.
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.
Was a big fan of Travian too and have thought about trying to remake something as a side project as well. Can you share any resources or have any tips as a place to get started?
Oh no, I remember those browser games, I will stay well away from them because they're the kind of thing that I will play for a month straight otherwise.
funny side note: this started as me nerding around with Cloudflare's stack on vacation, just seeing what was possible. been a 1.1.1.1 WARP fanboy from day one. didn't intend to ship a game. showed an early version to a few friends and they just... kept playing. didn't say much, just kept logging in. that's when it hit me that other people might want this too. so here we are. hope you like it.
33 comments
Also, actual alarm drift in prod with concurrent fleet arrivals? And client reconciliation when the countdown hits zero but the alarm hasn't fired?
Clean aesthetic.
no cross DO transactions are happening. the problem won't be (yet) that fleet arrivals will be just miliseconds apart.
with alarm drifts: i havent observes that beahiuvor yet three is a drift check performed every 100 alarm cylces with self correction if necessary.
on the client sync part: countdown runs on the epoch by the server. hits zero, waits a sec for buffer, hard-reloads. if the alarm hasn't fired yet, next alarm cycle (shortly after) resolves it. safety net: any fleet 5+ minutes overdue gets cross-checked, with exponential backoff retry on failed return deliveries. no websocket push on this one as mentioned earlier.... the reload is the reconciliation.
thanks and hope you give it a try!
Edited for typos.
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.