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.
Not that I know. Maybe Cloudflare experiences an issue in your local region? At this moment the workers are serving a few hundreds request from all over the world.
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.
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.
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.
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.
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.
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.
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.
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.