This is not the feature list. It is the machinery underneath it: how a model gets a score, why hardware becomes a bad asset, why research cannot be brute-forced with cash, how rivals react and which numbers are measurements versus game abstractions.
Training quality comes from one parametric scaling law. Parameter count and training tokens both matter, and the same compute budget can be wasted by pushing either side too far.
Scaling Laws uses a Chinchilla-style parametric loss form as the single place where model quality is computed. The player chooses parameter scale and data scale, then the game converts that plan into training compute and a relative capability projection.
The compute-optimal region in the current model lands around twenty training tokens per parameter. Ten times the effective training compute is mapped to roughly ten capability points at every scale. That fixed treadmill is what lets the moving frontier remain legible to the player.
The project uses a corrected/re-derived Chinchilla fit rather than silently treating every printed constant in the 2022 paper as unquestionable. A 2024 replication attempt found that the paper's third estimation procedure was inconsistent with the first two and re-derived a compatible fit.
Hoffmann et al. trained more than 400 models and argued that compute-optimal model size and training tokens should scale together. Scaling Laws uses that relationship as a design reference, not as a claim that its 0–100 capability scale is a real benchmark.
A single comprehensible number, a projected delta after each choice, a training time and a bill. The uncertainty only becomes a final capability after the run actually finishes.
Hardware value falls in two separate ways: calendar age and successor generations. A launch that happens after you buy can hurt the resale value again.
The hardware catalog carries accelerator, host CPU, node memory and fabric data. Owned accelerators are not a permanent stat upgrade. They are dated assets. The valuation model applies time-based depreciation and a second penalty as newer generations of the same class arrive.
This is why the hardware screen cannot become “pick the greenest card.” Waiting can preserve capital for a generation that improves performance per dollar. Waiting too long can also leave the company paying premium cloud rates while a rival trains on owned capacity.
Vendor specifications matter because accelerator performance is only part of the machine. NVIDIA's H100 SXM reference, for example, lists 80 GB of memory, 3.35 TB/s of memory bandwidth, up to 700 W TDP and 900 GB/s NVLink. Those dimensions are exactly why the game stores memory, power and interconnect data instead of reducing every part to one FLOPS number.
Hardware entries are based on public vendor specifications and release information, rounded for the simulation. A future or estimated entry is supposed to carry a projection flag rather than masquerade as measured data.
A powerful accelerator bought days before a better-value generation lands can be worse for the company than a slower cluster bought at the right point in the cycle.
Cloud capacity arrives provisioned. Owned capacity has to be fed by host CPUs, node memory and fabric, then paid for whether the cluster is busy or not.
Support hardware is not decorative. The compute pool measures whether CPUs, memory and fabric can actually feed the owned accelerator fleet. A badly balanced cluster can run far below its nominal rating. Rented capacity does not take this penalty because the provisioning is part of what the cloud bill pays for.
Training also loses scaling efficiency as accelerator count grows. Inference is modelled differently: it is more bandwidth-constrained and does not pay the same fabric tax. The two workloads share hardware without pretending they use it identically.
Research unlocks architectures, datasets, model types and infrastructure. Custom architecture programmes add another trade: budget, time, focus and uncertainty.
The technology tree exists because cash compounds. If every advanced capability is only expensive, a successful player eventually buys the rest of the game instantly. A research node costs money, prerequisites and time, and only one of those cannot be compounded away.
House architecture programmes use the same logic. A company distributes effort across sparsity, throughput, quality per parameter, serving cost and reasoning. A programme chasing every direction spreads itself thin. A short, underfunded programme carries wider outcome variance.
Rival labs are agents seeded from a historical release timeline, then allowed to wait, rush and drift away from it as the campaign changes.
A patient rival can notice that a better accelerator generation is close to its planned training window and deliberately wait. A frontier-focused rival that falls too far behind can rush, accepting a capability penalty to ship earlier. Between releases, labs continue to improve rather than remaining frozen until the next row in a table.
The player can pay for intelligence, but the game separates real accuracy from stated confidence. The cheapest rumour tier is designed to sound more certain than it actually is. A report can therefore be useful and still be wrong.
In the current design, the cheap rumour tier can be right 58% of the time while presenting itself with 80% confidence. That gap is intentional. Paying for information buys a better decision surface, not omniscience.
Demand is not a direct conversion from model score to revenue. Live products compete on capability, brand, price and age, against both the player and rival labs.
The audience changes with time too. Consumer, developer, enterprise, creative and autonomous segments follow different size curves across the campaign. Specialist model types can reach fewer people while selling to an audience that tolerates a higher price. That is the intended trade, not a hidden multiplier.
Funding has its own timing problem. The valuation model combines proximity to the frontier with annual run rate and multiplies the result by investor sentiment. Raising in a hot market can therefore preserve far more founder ownership than raising the same amount during a cold one.
The project keeps estimated future hardware and model releases separate from known reference data, and keeps a training projection separate from a finished model.
Public specifications and release information are rounded into catalogs. Known entries are treated as reference data, not guesses.
Entries beyond the known timeline carry a projection flag so the interface can label them rather than blend forecast and history together.
A projected run never silently becomes a deployed score. Only a finished run creates capability, and the result lands near the estimate rather than exactly on it.
The same rule applies to this website. Planned systems are described as planned. A screen existing in Unity is not automatically called “shipped,” and an internal projection is not promoted to a historical fact because it looks plausible.
The simulation is isolated from Unity, deterministic and testable without loading a scene. Separate tests then guard playability, cross-catalog consistency and scene wiring.
A scripted multi-year baseline campaign checks that an ordinary player can stay solvent and competitive without trivially dominating the field.
Catalog sweeps look for NaN values, impossible ranges, dangling references and unlock chains that can never be reached.
Simulation randomness comes from a saved deterministic generator. The same seed and the same decisions produce the same numbers.
Save migrations move one version at a time, preserve old shapes and record when a historical field had to be reconstructed.
This structure has already found bugs that looked reasonable on screen. Three are especially useful because they changed the design rather than just fixing a typo:
The core economy is further ahead than the physical company layer. The next work turns existing simulation state into things the player can see, configure and walk through.
A dedicated interface for renting or buying compute, then pairing accelerators with CPUs, memory and fabric instead of buying a magic “server score.”
The starter home becomes the first rung. Hires need a physical place to appear, and later offices should make company growth visible rather than only financial.
Safety already affects the model and founder systems. Incidents are the missing downside that can turn a weak safety choice into reputation and regulatory damage.
Walking to the workstation, garage and later company spaces is presentation over the simulation, not a new source of truth for the rules.
These sources inform the scaling-law choice or hardware reference data. They do not mean the game reproduces a real lab or datacenter one-to-one.
Hoffmann et al. The Chinchilla paper behind the compute-optimal scaling reference.
Besiroglu et al. Re-examines the third fitting procedure and derives a fit compatible with the paper's first two approaches.
Official product specifications used as an example of the memory, bandwidth, power and interconnect dimensions stored by the hardware model.
Public generation and system information illustrating why the hardware frontier is treated as a calendar rather than a static catalog.
The implementation, engineering notes and development history remain public while the game changes.
Game formulas such as depreciation, cloud lag, investor sentiment, rival decision rules and the relative capability index are simulation design choices. Where the project uses estimated future entries, the intended UI rule is to label them as projections.
The public roadmap will track what has moved from foundation to playable, polish and finally shipped. Until then, the main page shows the current visual build and the repository shows the work underneath it.