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.
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.
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?
I started with the game mechanics and game design principles first. Needed to refactor that somewhere the last few days and it’s painful to do this „midflight“. Iteration on UIUX is fine but iteration on game dynamics needs to be done carefully. Spent hours and hours studying mechanics and scale mechanics.
Sorry to read that you had a bad sign-up experience. Did a confirmation email arrive by now? I will look into the glitch with German in that particular screen.
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.
it's designed for once-a-day check-ins though, not minute-by-minute refreshing. buildings are fast in the beginning and take real time later to upgrade. more like working in a garden than playing a game. easier to walk away from than you'd think.
nice. honestly the test isn't the first session - it's the 5 minutes tomorrow morning when you check what happened overnight. that's where the genre lives. some alliances are already prepping excel templates and mapping the ocean grid systematically. didn't expect that this fast (or at all). :)
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.
it's designed for once-a-day check-ins though, not minute-by-minute refreshing. buildings are fast in the beginning and take real time later to upgrade. more like working in a garden than playing a game. easier to walk away from than you'd think.