Hogwarts Legacy is a single-player game, and its clock, weather and quests are written with that in mind. In 0.3.18 we added a shared world clock: everyone in a realm sees the same time of day and the same type of weather. This post covers how we designed it, what we ran into while building it, what went wrong in the first days on sandbox, and what changes in 0.3.20.
Design
The first decision was where the clock lives. A server that ticks a clock and broadcasts it has to keep that clock running, survive restarts and send updates to every player. We went the other way:
- The realm doesn't run a clock. When you join, it sends your game one short description: when the realm's day zero started, how long a weather window lasts, the odds of each weather type and a seed.
- Each game computes the time of day and the weather from the server's clock with the same formula the server uses. Final Fantasy XIV works this way. There is nothing to stream and nothing on the server to drift or restore after a restart.
- The game already tracks the server's clock for movement smoothing, so the description only carries the real time at which that clock started. That avoids stamping the time into the message itself, which would have been wrong by however long a loading screen held the message.
- Weather is shared as a type (clear, cloudy, rain, storm, fog) and shown as that type's weather in your own season, so rain in winter shows as snow. Seasons and dates stay per player; they're part of your story progress.
- The description is a new event in the existing reliable event stream and is only sent to games that say they support it, so older launchers and older realms are unaffected.
Both sides compute the formulas independently, in Rust on the server and C++ in the mod, so we generated a shared set of test files from the server and check the mod against them byte for byte. If the two ever disagree, a test fails before anyone sees a different sky.
Implementation: testing the game first
Before writing the mod side we spent a session testing how the game behaves, because most of what we needed isn't documented:
- Quests change the time and weather in ways a mod isn't told about. We can't see a quest's time change as it happens; we can only notice the clock moved by more than it should have.
- The game's clock speed can't be changed. The setting exists but has no effect, so the only tool is setting the clock. That rules out the usual way of correcting clocks, which is to run slightly faster or slower until they match.
- Testing showed that setting the time while keeping the date moves the clock back on the same day. Going from 23:50 to 00:30 that way sends the clock back almost a full day. So the mod moves forward with the game's "advance time" call and only ever sets the time back within the same day.
- Quests freeze the clock with named locks, and the game releases them when the quest step finishes. We can read whether the clock is frozen, but not which quest froze it.
- The obvious way to set weather (an override the game keeps per quest) can't be read back reliably, and setting it to "none" doesn't give the game its weather back. The game also has a weather stack with an owner and a "restore what was there before" flag. We push the realm's weather onto that stack and pop it to hand the sky back to the game.
- The game's clock actually runs at about 31 times real time, not the 30 its settings say, so every game slowly drifts ahead of the realm.
We then ran the feature against real quests on one PC with a test bot as the second player: logging in, the Day One clock lock, a quest that jumps to 17:00, a class that sets its own weather, fast travel, the pause menu and leaving the realm.
What players in our Discord ran into
The first real sessions found things our test runs didn't.
- Two players compared their games side by side. The time matched, but the weather didn't. One of them had been held by the game's Day One story lock for the whole session. The mod pauses while a quest holds the clock, and in 0.3.18 that also handed the weather back to the game, so that player never got the realm's weather.
- A player finished a Summoner's Court match and an NPC stopped moving. The match freezes the clock; when it released it, the mod caught the game up by almost two game hours. NPCs follow daily schedules, and skipping that much time in the middle of a quest left the scene waiting for an NPC who was scheduled somewhere else.
- Loading screens briefly report a different weather, which caused the mod to reapply its weather behind them.
Our logs only recorded counters, not names, so in 0.3.19 we added logging of why the clock is paused, which quests are active and which weather each game is showing. Most of the analysis after that came from reading those logs next to the game's own quest and NPC schedule data.
How other projects handle this
Skyrim Together syncs the hour but not the date, because changing the calendar breaks quest timing. GTA and Red Dead roleplay servers turn time sync off for a player during scripted content and back on afterwards. Final Fantasy XIV shows story weather only to the player in the story. The common rule: the story owns your clock while you're in it, and the shared clock waits for a safe point to take over again. We also had the code reviewed against these findings, which turned up more cases of the same kind: small backward corrections re-triggering the castle's night schedules, and a quest's time set behind its own loading screen being overwritten. And using the "Wait" at a Floo flame was undone by the sync a second later.
What changes in 0.3.20
- After a quest releases the clock, your game keeps the quest's time until the quest moves on, or for up to five minutes of play, then catches up.
- A quest's clock lock only freezes your time; you keep the realm's weather. Quest cutscenes and exclusive sections still show the quest's own weather.
- The clock is no longer moved backwards while you play. The small lead your game builds up is settled behind loading screens or in menus.
- A time a quest sets during its own loading screen is kept, and a short reconnect no longer drops it.
- When a quest is holding your clock, the chat panel says so, and again when you're back on realm time.
- Waiting at a Floo flame does nothing inside a realm, since the clock is shared; the chat panel tells you why. It works as usual outside a realm.
- No more weather reapplied behind loading screens, and the logs now record why the clock is paused, why it's off, and which weather each game is showing.
What we learned
- A single-player game assumes the player owns time. Anything that moves the clock has to treat quests as the owner and step in only at safe points.
- Test the game before designing around it. The clock speed, the midnight behaviour and the weather stack would each have broken a design based on how things look from the outside.
- Test against real quests, not just the open world. Our test runs covered a handful of quests; players covered dozens in a day.
- Log names, not counts. A counter tells you something happened; a quest name and a weather name tell you why.
- Prefer rare, forward corrections. A clock that's a few minutes off is far less noticeable than an NPC whose schedule just ran twice.
Reporting problems
If the time or weather looks wrong, or a quest gets stuck, send a report from the launcher and post the WR code with roughly when it happened. The logs now show what the clock and weather were doing at that moment.
← Back to News