A hit on the central crystal produces a small burst of physical shards. The player can move the Spark, a living cursor, to collect them. Machines gradually take over extraction and collection. That gives a resource a short, visible journey before it reaches the player's balance.

The interesting implementation boundary is the moment that journey becomes credited income. A production rate, an object moving through the scene, a spendable balance and progress towards the next reset each answer a different question. Keeping those states separate helps describe what a machine actually does and which part of the economy a purchase improves.

This article follows that separation in the current implementation of SPECTR, a 2D incremental game built with Godot.

The Core and the opening production system.

Give each stage a clear job

The opening loop contains three distinct operations:

create a shard in the world
        ↓
collect or deliver its value
        ↓
credit resources and record earned progress

A producer affects the first stage. A collector or drone helps with the second. The player spends the credited balance on purchases that change the system.

That distinction makes the choice between machines concrete. More production increases the available output; collection determines how the physical flow is gathered. Watching shards around the Core gives the player information alongside the purchase list.

It also creates a communication responsibility. A number describing production cannot explain every detail of received income by itself. Collection, temporary effects and later progression rules still matter. A transport capacity value should therefore not be presented as a universal cap on every source of income.

Settle income in one place

SPECTR uses a shared credit operation when value becomes income. After the applicable adjustments, the credited amount updates the spendable shard balance, the amount earned during the current run and the corresponding concentrate output from refinement.

The core accounting relationship can be illustrated like this:

on credited income:
    spendable balance += credited amount
    earned this run   += credited amount
    concentrate      += conversion of credited amount

This is a simplified model of the relationship, not a copy of the game's function or a complete formula for its modifiers.

Keeping the related changes together gives the economy one boundary to reason about. Collection by the Spark and delivery by an automated collector arrive at the same accounting stage. Refinement follows income that was credited; it does not need a second interpretation of how much the player received.

The practical question becomes: which event is allowed to settle this value? Creating a visual object, claiming it for delivery and paying it out are distinct events. Treating all three as income would count the same value more than once.

Keep purchases separate from earned progress

SPECTR's Resonance reset becomes available after enough income has been earned during a run. That accumulated amount is separate from the spendable balance.

Consider an illustrative account with 20 units earned and a purchase costing 15. The purchase leaves 5 to spend, while the run still records 20 earned. These numbers demonstrate the accounting distinction; they are not the game's opening prices or a balance recommendation.

That separation lets the player invest in production without moving an already reached reset threshold away. A purchase changes purchasing power and the system's future output. The earned-progress record tracks what the run has achieved. A Resonance then starts a new run and resets the run-specific economy while keeping the intended permanent progression.

The same distinction helps when explaining a progress bar. The underlying eligibility check can use accumulated earnings even when the interface presents progress on a scale chosen to make growth easier to read. A presentation change should not silently change the economic threshold.

Expanded production after the second Resonance.

Let automation change the route deliberately

The physical opening loop does not mean every later reward must travel through a collector. The implementation includes direct-credit effects. One late upgrade routes part of production directly into income and reduces the corresponding physical production share.

That changes how automation feels while retaining the accounting boundary. The direct route still settles income through the shared credit operation. The economy needs to account for the split, so the same production is not also emitted at full value through the physical route.

Other rules affect shards already in the world. A collection upgrade can recover part of the value of an older grounded shard, and expiration has its own partial-credit rule. A shard being carried for delivery is excluded from that expiration payout. These are useful places to examine lifecycle ownership: a pending delivery and an expiry event must not both settle the same item.

These details also limit the advice that can be given to players. An uncollected shard invites attention to collection, but the relationship between visible objects and all income becomes more varied as upgrades open. A single bottleneck formula would flatten those differences.

Use the world to explain the economy

The purpose of this structure is visible in the opening scene. The player starts with an action, sees its output and completes a collection. A machine then takes over a recognisable part of that sequence. Automation has a job the player has already performed.

Later interactions add timing and coordination around the established loop: Heat, vines, beam connections and Alloy enter at different Resonance stages. Colour and life return to the valley as progression continues. The story reaches Dawn after five Resonances; optional collection goals and continued progression remain separate.

For a developer adapting this pattern, the useful questions are concrete: where is value created, which event settles it, what does a purchase spend, and which progress record should survive that purchase? Clear answers make the simulation, the interface and the explanation to the player easier to keep consistent.

SPECTR: Rekindle the World is a Windows game by Artificial Galka. Game information and existing media and the Steam page provide context for this case study.