Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits)

I just started the game recently (about ten minutes of play), so I might have missed some details. But here’s my thought on offline progress calculations:

Since the game already knows the distance between towns and the train speed, it should be possible to determine the exact time required for any route.

Based on that, we could maintain a heap of scheduled events — such as train route completions or resource productions — ordered by their NextEventOccurTime.

Each time the system should pop an event from heap. Then:

  • Calculate the income gained, city demand fulfilled, and resources consumed

  • Reinsert the event into the heap with its updated NextEventOccurTime

The simulation would continue until NextEventOccurTime > TotalOfflineProgressTime.

This approach allows the game to approximate offline progress deterministically without simulating every frame or tick, which should make it computationally efficient.

That was my first thought, and in theory yes it's deterministic. But when I sat down to code it, I realised there's a bunch of factors that make it way more complicated: 

  • Cities produce set amounts in cycles over time, so can "run out" of stuff if trains take more than the city produces.
  • Trains make less money when they deliver to a city that already has enough of the stuff than it needs to progress to the next level.
  • It's possible to get a station upgrade automatically level's up a city. 
  • Trains actually take twice: Once when they arrive at a station, once just before they leave, in case the city produces while they are waiting, and assuming they're not already full.

The choice was either to replicate the entire business logic of the game for the offline progress. But then any time I fix a bug or make a change, I'd have to change everything in two places. Or refactor the game to allow it to step through the simulation without firing off UI events, resetting timers etc. Plus deal with edge cases like the player winning or triggering an achievement during the offline mode calculation.

At that point, it was too complicated and I was aiming for just a regular Steam app. So I parked it and said maybe I'll come back if/when I do a web/browser build. In the meantime the game launched on Steam and hasn't done well enough to justify the effort. Making a web build has proved to be more than just the one day's work I thought it'd be. My thinking was to upload the web build now that it is made, gauge the reaction and then decide if it's worth working on the game more or parking it again and taking the lessons to make a new game.

(1 edit)

All the factors you mentioned are already functional in the normal game loop. From a feasibility standpoint, these systems could be extracted into helper methods and invoked by the scheduler heap.
That said, I understand your concern. The scheduler would exist solely for offline progress and could be tricky to maintain.

In other idle games, I’ve seen three approaches to handle offline progress:

1. When the game is online, we can use circular array to log and calculate the avg income in the lase ten minute. This process should be reset at anytime any resouce income is negative. For offline progess, we can have (highest avg income * offline time). This is not prefect but much better than nothing.

2. If the game doesn’t rely on async processes, it’s possible to separate animation from game logic. By disabling animation updates, the core business logic could run at thousands of ticks per second. In practice, spending one real minute to simulate several offline hours is generally acceptable to players

3. Make offline progresses a consumable reasource. Consuming x OfflineSeconds could temporarily speed up the game by (x+1)*100% for one second. This makes offline time a meaningful and controllable resource, while still fitting the game’s design constraints.