Read this before anything else on the site

You cannot play Atomic Tick. There is no deployed server, no public API and no address to connect to. There is no demo, no playtest, no download and no browser client you can open. There are no accounts, so there is nothing to sign in to and nothing to sign up for — and because there is no backend of any kind, there is also no waiting list, no newsletter and no "notify me" box anywhere on this site. There is no date, and this page does not carry one.

What does exist is a large body of written design and a private codebase in which Tick resolution, order queues, maps, movement, combat and the content catalogues are implemented and pass their tests in development. That work runs on a developer's machine. It has never run for a player.

How to read the labels below

Built in code means it is implemented in the private repository and covered by tests that pass in development. It does not mean deployed, hosted, reachable or used by anybody.

In development means it is being actively worked on now and does not work yet. It is the only one of the four that describes work in motion.

Designed, not built means it is written down — often in considerable detail, sometimes with catalogues and decision records behind it — and there is no code doing it.

Not started means no work has begun. Where it appears under Deliberately later it has also been deferred on purpose, and each of those entries gives the reason. Neither case is a promise that it will happen.

Those four words are the whole vocabulary, and every page on this site uses them identically. Every entry states its label as a word. The glyphs and colours repeat the word; they never carry it alone.

Bucket one

Built in code

Implemented in the private repository, exercised by an automated test suite, and run in development only. Read every heading in this section with the words "on a machine nobody else can reach" attached to it, because that is where all of it lives.

Built in code

Identity and the clock

  • Account and actor identity, with permanent Character IDs and shorter public character codes.
  • The Shard clock: UTC-aligned boundaries, the one-minute lock lead, precompute, resolve, commit.
  • A missed boundary is skipped rather than queued — six missed boundaries produce one Tick, not six.

Built in code

Queues, snapshots and resolution

  • Order queues, queue locking, and the Tick snapshot that freezes intent at the lock while live state is read at each actor's own resolution point.
  • Deterministic resolution with derived, replay-stable randomness — a retry cannot reroll a bad outcome.
  • Acting order sorted once per Tick and immutable for the rest of it.
  • Concurrent resolution of independent Shards.

Built in code

Reports and the ledger

  • Tick reports, and an append-only Tick ledger behind them.
  • Database constraints carrying the design invariants: one completed Tick per Shard per Tick number, one outcome per actor per Tick, a Tick that commits entirely or not at all, and one authoritative location per item instance.

Built in code

The API boundary

  • A Fastify service covering emailed-code authentication, Shards, characters, the queue and reports.
  • It is code with tests. It is not hosted anywhere and has no public address.

Built in code

Maps and movement

  • Hand-authored atlases and painted regions, with region-driven gradual spawning.
  • A map generator with connectivity validation, kept for tests and throwaway Shards.
  • Eight-direction movement with the strict diagonal corner rule — a diagonal needs both shared orthogonal neighbours passable.

Built in code

Combat, items and Return Strikes

  • Combat and Engage; attributes; equipment on the universal slot set; Stamina.
  • Loot rolls and cadence-derived loot protection deadlines.
  • Unarmed combat and the martial_arts Feature flurry.
  • Automatic Return Strikes — reactive, never player-directed, never touching the queue.

Built in code

NPCs and content catalogues

  • NPC order policies: player and NPC actors share one identity model and one ordinary order path.
  • Server-served catalogues of Races, Classes, Jobs, Skills, spells, creatures and items, validated in both directions against the design documents.

Built in code

Operations and safety

  • Network isolation, loopback proxy trust, two-layer rate limiting and a security-verification script.
  • Encrypted off-machine backup tooling.
  • This static site, and a browser visual reference that renders fixed sample data and talks to no server.

Six, out of a vocabulary of roughly fifty

Six player orders resolve, and they are the entire implemented player vocabulary: Move, Hold, Attack, Engage, Collect and Equip. Each one is defined on the order vocabulary, which is also where the designed-but-unbuilt orders are listed. That catalogue runs to something near fifty entries once crafting, markets, magic, social and property orders are counted, and the other forty-odd are writing. The gap between those two numbers is the most useful single fact on this page.

Bucket two

Designed, not built

Written down, in most cases in more detail than the built work, and with no code behind it. These are the named gaps in the project's own register, in the order they are queued to be closed.

  • Designed, not built

    Per-actor Skill rank and practice storage

    Skill ranks are the only proficiency model in this design — there is no character level — but actors cannot yet own changing ranks. Until this exists, nothing else in progression can. It is the first gap for a reason.

  • Designed, not built

    Skill proficiency in resolver outcomes

    Catalogue requirements exist without competence affecting real actions. A character's Skills currently change what they may attempt, not how well the attempt goes.

  • Designed, not built

    Train

    Grant one unit of valid practice to one Skill or track. The progression loop is documented end to end — bands, practice awards, the rule that trivial repetition stops teaching — and it cannot run. Blocked on the two gaps above.

  • Designed, not built

    Rest and Revive

    Actors can already become Downed. Neither the recovery order nor the revival order exists, so nothing can currently pick them back up.

  • Designed, not built

    Drop and Use Item

    Items can be collected and equipped. They cannot be put down as a ground entitlement, and they cannot be consumed or activated.

  • Designed, not built

    Guard, player-directed

    Automatic Return Strikes are built. A defensive stance the player actually chooses is not, so defence is currently something that happens to you rather than something you can order.

  • Designed, not built

    Cast, and the whole Magic module

    Three spells are authored. Spellcasting as an action does not exist, and the module behind it is additionally blocked on an unresolved decision about how spells map on to Skills. Every mention of Magic anywhere on this site is design, not code.

Whole systems that exist only on paper

  • Crafting, gathering, production and quality.
  • Jobs in play — sixteen are authored, none can be worked.
  • Parties.
  • Markets, shops and auctions, and the escrow behind them.
  • Property, estates and rentals.
  • Quests, contracts and bounties.
  • Local law, jurisdictions and reputation.
  • Clans, Alliances, NPC Guilds and Factions as playable systems.
  • Companions, minions, pets, summons and workers.
  • Notifications, quiet hours and absence warnings.

Two gaps worth stating separately

Public policy and deletion operations. Draft privacy, terms and support text exists. Drafts do not prove actual retention, deletion, moderation or data-safety behaviour, and no qualified legal review has happened. Account deletion by tombstoning is specified and there are no accounts to delete.

Recovery and service objectives. Backup and security tooling exists without declared recovery-point or recovery-time objectives, without a measured restore on record, and without alert thresholds. Tooling that has never been tested under failure is not an operational commitment.

Bucket three

Deliberately later

Deferred on purpose, each with the reason it was deferred. Nothing in this bucket is a commitment that it will be built at all — a deferral that quietly becomes a promise is how roadmaps start lying.

Not started

The Android client

A native Google Play client, in Godot 4.7.x, considered only after the browser game is complete and operating reliably — and only if discovery, install, re-engagement and notifications justify maintaining a second client. The decision gate on that has not been answered.

Why later: the browser client is the permanent, complete, primary game and the accessibility-complete surface — the only client required for the game to be finished. Android is explicitly not a full-parity client, and long-tail systems may stay browser-only behind an authenticated handoff. Everything that is not Android — desktop, iOS, everything else — uses the browser.

Not started

Vehicles and a ship layer

A separate hex-grid layer for vehicles and ships, treated as its own complete design domain rather than an extension of the character game.

Why later: the character game has to be complete without it. A layer that the base game depends on is not a layer, it is a missing half.

Not started

Arenas, competitive zones and Hardcore Shards

The expressly marked spaces where players may harm one another, and the Shards where death is permanent and disclosed before entry.

Why later: the overworld is cooperative by default and the exceptions have to be marked. Marked exceptions are only meaningful once the ordinary, unexceptional game works.

Not started

Optional cosmetic support

If support is ever offered it is cosmetic or voluntary recognition only. Nothing is on sale, no store exists, there is no payment path, no advertising on any surface, and no in-application purchase in a first Google Play release.

Why later: core access and progression are free by binding decision, and what may never be sold is written down as a law rather than a preference. That list is worth more made now, before there is any money involved, than afterwards.

The gate

What has to happen before anyone can play

Five things stand between the codebase and a person taking their first Tick. None of them is stood up. They are listed in the order they gate each other, and no date is attached to any of them.

  • In development

    The browser client

    The active product focus, and the largest single piece of remaining work. What exists is this static site and a visual reference that renders fixed sample data against no server at all. What is missing is the game itself: sign-in, Shard and character selection, the Map, the Queue editor and Tick reports, and then Character, Skills, inventory, equipment and settings. The rule the client is being written under is that missing actions must be shown honestly rather than simulated — an interface that pretends to have Train would be worse than one that says it does not.

  • Not started

    A deployed API and database

    The API boundary is written and the schema carries the design invariants, but nothing is hosted. No server has been provisioned, no domain points at one, and there is no address a client could call. This is the step that turns a codebase into a service, and it has not been taken.

  • Not started

    A Shard actually running on a schedule

    The resolver is exercised on demand by tests. No Shard is holding UTC boundaries continuously anywhere, which means no Tick has ever resolved for anybody but the developer. A persistent world that nobody is keeping the clock for is not a persistent world.

  • Not started

    Accounts

    Sign-in is designed as a six-digit code sent to an email address and exchanged for a session token, with no password stored anywhere and an email address as the only personal data collected. None of that is operating. There are no accounts, nothing to sign in to, and no list to join in the meantime.

  • Not started

    Operating a service, rather than owning code that could

    Backups that have been restored from, alert thresholds somebody answers, moderation and support that a person is actually behind, and legal text that a qualified reviewer has read. Running a persistent world is an ongoing obligation to the people in it, and taking it on before it can be met would be the least honest thing this project could do.

To be completely plain about it

Not one of those five is finished, and the last four have not been begun. There is no date on this page for when they will be, no estimate, no target, no countdown and no "coming soon", because the studio does not know and would rather say so than guess in public. If a schedule ever appears here it will be because something is genuinely being scheduled.

The project's own assessment

Far more is designed than is playable

The main risk is no longer architectural uncertainty. It is depth mismatch: several broad catalogues and design chapters sit above a narrower implemented action set.

From the project's own risk register

That sentence is the most useful thing written about this project, and it was written by the person building it rather than by anybody reviewing it. Put concretely: twenty-eight Classes and thirty-two Specializations are authored, and no character can hold one in a way that changes an outcome. Twenty-five Races are authored across six substrates. Sixteen Jobs are authored and none of them can be worked. A large Skill roster exists across five scopes, and no actor can own a rank in any of it. Meanwhile six orders resolve.

This is the characteristic failure shape of a one-person project, and naming it is cheaper than pretending otherwise. Writing is fast and code is slow, so the design runs ahead; the danger is not that the writing is wrong but that a website starts describing the written half in the present tense. That is precisely what this page exists to prevent, which is why it is linked from the primary navigation rather than buried, and why the home page states the same thing in its opening block rather than at the bottom.

The reason the risk is described as no longer architectural is worth keeping too: the hard part — a deterministic, replayable, explainable resolver that commits a Tick atomically or not at all — is the part that already works. What is left is a very large amount of ordinary building.

Verification

How to check this page is honest

Space Junk Industries is one person. This page is written and maintained by hand: there is no pipeline that reads the repository and regenerates it, so it is exactly as current as the last time somebody sat down and revised it, and no more.

The codebase is private, which means you cannot verify any of the "built in code" claims yourself. That is a real limitation and it is not going to be solved by this page insisting harder. What you can do is watch whether the claims change in the right direction, and whether the things that get announced are the things that were listed as next.

The day-to-day progress is on Discord, not here — commits, screenshots, dead ends, things that turned out harder than expected, and the occasional thing that got deleted. A status page updated by hand every few weeks is a summary. The Discord is the working record, and it is where a claim on this page can be checked against what was actually happening.

If you find something on this site described as working when it is not, that is a bug in the writing and worth reporting the same way you would report a bug in the game. The email address below reaches one person directly.

What would make this page dishonest the failure modes
  • Moving something into "built in code" because it nearly works.
  • Describing designed systems in the present tense anywhere else on the site while this page is careful.
  • Quoting a test count without the commit and date it belongs to.
  • Leaving an item marked built after it stopped working.
  • Letting "later" quietly turn into "planned", and "planned" into a promise.
  • Adding a date to make the project look closer than it is.
Written down so that they are harder to do accidentally. Every one of these is a way an honest page becomes a dishonest one without anybody deciding to lie.

Where to ask, and what you will get

The Discord is where development is posted and where a direct question gets a direct answer. For anything that does not suit a public channel, [email protected] is the only address that reaches anybody — there are no mailboxes at this domain, so any address you see ending in the site's own name would be wrong.

What you will not be offered in return is a signup, an early-access slot, a place in a queue or a mailing list, because none of those things exist and this project would rather have nothing to give you than something fake.

Something you can play today

The studio's other game is playable, in alpha

If you came here wanting to play something rather than read about something, Astral Sovereignty is live and playable in alpha right now. It is by the same one person, built on the same scheduled-tick skeleton, and it is a genuinely different game.

The two games, side by side
What is being compared Astral Sovereignty Atomic Tick
Can you play it Yes — alpha, playable now No — in development, nothing deployed
Scale An empire across a galaxy. A person standing on one square.
Orders per tick An empire issues many orders each tick. A character receives at most one action — and that constraint is the entire game.
What persists An empire is a position you build. A character is someone you become, and ordinary defeat is meant to be survivable.
Conflict Space is competitive by default. The overworld is cooperative by default; competition is confined to expressly marked spaces.

What the two share is the skeleton: scheduled ticks, orders as editable intent, reports you can actually read, no advantage for being awake, and rules that apply identically to everyone.

It is an alpha and it is described that way on its own site. Playing it is also the closest thing available to trying the idea underneath Atomic Tick: orders you commit to, a clock you do not control, and a report afterwards that explains what happened. If that rhythm suits you, the FAQ is the next thing to read here.