Your character
There is no general character level in Atomic Tick. What a character can do is what that character has actually trained, which means two people of the same age, in the same Shard, can be completely different characters — and a Blacksmith never has to go fighting to get better at the forge.
Not built yet
No character exists. There is no public server, no account and nothing to create a character in. This page describes a designed character model, and a set of authored content catalogues that a private codebase already serves and validates in development.
One part of it is worth stating up front, because it is the largest gap on the whole project: actors cannot yet own changing Skill ranks. The catalogues, the requirements and the bands are written; the storage that would let a character get better at something is not built, and neither is the Train order that would fill it.
The core decision
No general level, no Class level, no Job level, no independent spell level. A character's numeric proficiency is the sum of their Skill ranks, and a Skill rank is the only progression figure the game stores.
The character is the sum of their Skills.
A character level needs experience. Experience needs a source. In practice, in almost every game that has one, the source is killing things. On a Shard whose roster is built around Jobs, crafting, gathering and trade, that would make combat the only real progression on offer — and a Blacksmith would advance by fighting.
Skills advance by doing the thing, which is exactly what a queue of atomic orders produces. It is also the only model in which a player who cannot fight this week still progresses, which matters a great deal on a persistent server people visit around ordinary life. And it settles the level-cap argument permanently: there is no level, so there is nothing to cap it at.
A total cap. One Skill tops out at rank 100, and a character holds at most 800 ranks in total — eight Skills at maximum, or sixteen at half, or any other shape you like. The reason is not balance. It is identity. Without a ceiling, every sufficiently old character eventually owns every Skill at maximum and they all become the same character, and Race, Class and Job would have gated only the opening and meant nothing afterwards.
The budget is the character. Choosing what not to learn is the decision.
It is also the only decision in this system that cannot be undone by playing longer, which is precisely what makes it worth making.
Attributes
The same six in every Shard template, fantasy or science fiction or apocalypse. They are capped and stepped rather than open-ended, and they are deliberately unsurprising: the interesting decisions in this design live in the Skill budget, not in an exotic statistic nobody can guess the meaning of.
Attributes decide whether you can lift it; Skill decides whether you are any good with it.
A character one point short of the Strength a mail shirt asks for wears it badly. Four points short genuinely cannot hold it up, and that is the one place a hard refusal is honest rather than punitive. Everywhere else the design would rather penalise you than remove you from the game, because a player who is refused an action has not been challenged — they have been sent away.
| Shortfall | Result |
|---|---|
| None | No penalty. |
| One to three points | An accuracy penalty equal to the gap. You use it, badly. |
| Four or more | Refused. This is the only hard refusal in the model. |
The worst single shortfall counts, not the sum. Two small gaps are not one large one — adding them up would refuse a character who is merely slightly wrong for an item in several ways at once.
The starting attribute budget at character creation is not settled, so this site does not print one.
Race and Origin
Race is the canonical character layer for species, ancestry, body family, synthetic nature or another innate form. Origin is the permanent formative background — the culture, community, education and prior life a character begins from. They are separate on purpose: where you come from is not the same fact as what you are made of.
A fantasy golem, a steampunk automaton, a science-fiction android and an apocalypse synthetic are one mechanical thing wearing four costumes. Filing them by genre would have produced four parallel sets of rules that all had to be maintained, balanced and explained separately, and any Shard that mixed genres would have had to pick one of them arbitrarily. Filing them by substrate produces one rule and four descriptions.
Every character in every Shard has the same slots:
main_hand, off_hand, head, body,
hands, feet, back and trinket.
A four-armed Race is described and drawn with four arms, and equips two things,
exactly like everybody else. A serpentine Race still has a boots slot.
Anatomy is art and description; slots are rules.
This is not a shrug about fiction. It is what stops every new Race from becoming a new inventory system, a new balance problem and a new set of items nobody else can use — and it is why a Race can be added to this game as content rather than as a rewrite.
Race or body family supplies the base image. Class supplies compatible dress, equipment presentation, pose, frame and overlay. Structured description covers everything else. It is static composed imagery: no animation is required anywhere in this game, and no sound is required to play it. Any interface sound added later is off by default, separately toggleable, and never the only thing carrying a piece of information.
Classes
A Class grants role identity, Class-scoped Skills, Specializations, resources, Features and signature Abilities. What it never grants is a number that goes up. Competence inside a Class is represented entirely by the Skills that Class owns, which is the same rule as everywhere else in the model.
The governing rule for Class access is stated twice in the design, in two forms: open unless there is a reason, and restrict at the door or not at all. A gate that can be checked when you walk in is a gate; a gate you discover forty hours later is a trap. Since a Class carries no level, restricting one costs the design very little and gains it very little, so the default is to leave it open.
How many Classes one character may learn, and how many may be active at once, has not been decided. That is a real open question in the design documents rather than an omission on this page, and this site does not invent an answer for it.
On the list of Class names
The design documents carry a long list of candidate Class families — Warrior, Guardian, Rogue, Ranger, Mage, Cleric, Druid, Bard, Marine, Psion, Pilot, Steam Knight, Fixer, Medtech, Scrapper, Relic Hunter and many more. They are illustrative of the range the model is meant to cover. They are not a shipping list, no Shard has ever been opened with any of them in it, and this site will not present them as one.
Jobs and Professions
Job and Profession are the same word in this design. A Job is a persistent productive, technical, commercial, creative or service identity — and a character holds them plural, on purpose. Being a Miner does not stop you being a Cook.
Designed, not built. The Job catalogue is authored and served by the codebase in development. Working a Job in play — gathering, crafting, producing, selling — is designed and has no code behind it.
Gating Blacksmith on Class would say a Fighter may not learn to forge, which is both false to the fiction and hostile to the solo player this game keeps designing for.
A character who cannot find a smith should be able to become one. On a Shard where a Tick is thirty minutes and the population might be small, that is not a convenience — it is whether the economy can exist at all.
Skills, Abilities and Features
A Skill is a specific practised competency with a visible rank and visible progress, trained through meaningful action, study or instruction. Scoped Skill ranks are the only numeric proficiency model in the game. Everything else about a character either gates access, describes them, or presents them.
The authored Skill roster is large and spans all five scopes. This site does not print a total, because the design documents and the content files currently disagree about what that total is, and quoting either would be quoting a number nobody has reconciled yet.
One Skill runs from 0 to 100 and sits in a named band. The band carries a proficiency modifier, so a reader can tell what a rank means without memorising a curve.
| Band | Rank | Proficiency |
|---|---|---|
| Untrained | 0 | −4 |
| Novice | 1–19 | −2 |
| Apprentice | 20–39 | −1 |
| Journeyman | 40–59 | 0 |
| Expert | 60–79 | +1 |
| Master | 80–99 | +2 |
| Grandmaster | 100 | +3 |
Rank zero is usable, at a penalty.
You may swing a greatsword you have never held. You will be bad at it. That is the same rule as the archer caught in melee, as encumbrance and as exhaustion, and it exists for the same reason: being refused an action removes a player from the game, and being penalised for one does not.
Practice is awarded by how hard a task was relative to your current rank, not by how many times you did it. Each rank costs more than the last, so the curve flattens instead of running away: cheap early, so a new Skill feels alive quickly; expensive late, so a grandmaster is an investment rather than a matter of having waited.
Trivial repetition stops teaching. That is the whole defence against training a Skill for months against something that stopped being instructive in the first week. Two further rules sit alongside it: an order rejected before it legally began grants no practice at all, and a genuine executed failure may grant limited learning, because trying something and failing is how people learn things.
For crafting, rank does not decide whether you may attempt a recipe. It decides how good the result can be — crude, common, fine, superior, masterwork. Every trade stays open to the person trying to enter it, and a master's work is still worth paying for.
Three more words with fixed meanings, because they are the three most often used to mean whatever a system needs them to mean.
martial_arts Feature rather than hard-coding a Monk Class.The altered body
Two separate systems, kept separate because they arrive differently, are governed differently and are treated differently by the societies a character walks through. Both are designed and neither is built.
MUTATION
A biological, magical, anomalous, environmental, inherited or acquired alteration, with declared benefits, costs, capacity, compatibility, stability, treatment — and a declared Shard response, because a settlement that fears mutation and a settlement that reveres it are both legitimate worlds.
AUGMENTATION
An installed cybernetic, mechanical, arcane, biological, technological or hybrid alteration, governed by compatibility, capacity, installation, maintenance and removal rules. It was fitted, it can fail, and somebody has to keep it working.
Neither is a free upgrade and neither is purely a penalty. Both carry declared capacity limits, which is what stops a character from becoming a list of installed advantages, and both are the kind of thing an NPC Guild, a Faction or a jurisdiction may have an opinion about.
Standing in the world
Attributes and Skills describe what a character can attempt. Everything below describes where they stand while attempting it — and on a persistent server that runs for years, the second list ends up mattering at least as much as the first.
Health and Stamina are universal. Effective actions spend Stamina; consecutive exertion raises the cost up to a cap; armour modifies it; rest decays the exertion again. The rule that matters is the last one: zero Stamina degrades accuracy instead of preventing action. An exhausted character is bad at things. An exhausted character is not locked out of their one action for the Tick.
Bare hands work normally in your own square and remain legal at one square away with an extreme penalty and reduced damage, so an unarmed character is never simply unable to participate.
At zero Health a character becomes Downed. The queue pauses, normal orders cannot be performed, and allies get a limited window to Revive — which costs the helper their entire action for that Tick, because reviving somebody is a real decision and not a free gesture. An unrevived character returns to a sanctuary under a temporary or curable consequence.
Neither revival nor sanctuary recovery restarts old movement or combat orders. You come back; your half-finished plan does not come back with you. Permanent death exists only in expressly marked Hardcore Shards, disclosed before you enter one.
Ordinary defeat matters without casually erasing years of character history.
Who you know, precisely
Seven words, one meaning each, written down once and used that way everywhere — in the design documents, in the codebase, in the reports and on this site.
This matters more than it sounds. Most games use "guild" for four different concepts at once: a player-created social group, an in-fiction institution that trains you, a building you walk into, and a shared bank. When one word covers four things, the rules for each of them leak into the others, and a player cannot reason about any of them without first working out which sense is meant. Every design conversation then has to begin by disambiguating its own vocabulary.
Once "Clan" means exactly one thing, the rules about Clans can be exact too. An Alliance merges no treasuries, no property, no storage, no leadership and no action opportunities — a sentence that would be meaningless if Alliance sometimes meant a friendship and sometimes meant a merger. A Party does not merge queues, which is the only sensible reading once a Party is defined as temporary and social rather than as a shared unit.
The same discipline runs through the rest of the social model. Reputation is recorded against one Guild, one Faction, one jurisdiction or one community — never as a single number describing whether you are a good person. Your standing with a Clan you joined is not your own reputation, and neither one silently becomes the other.
Designed, not built. Parties, Clans, Alliances, Guilds and Factions are specified in detail and none of them is implemented. What exists in code today is account and actor identity, permanent Character IDs and the shorter public character codes that a Give order or a market listing would refer to.
Where this has got to
The character model is the clearest example of the project's own stated risk: several broad catalogues and design chapters sitting above a narrower implemented action set. Here is the split, without smoothing it over.
Built in code
The six attributes exist in code and are used by the resolver.
Built in code
The eight slots, equipping and unequipping through one order that toggles both ways, and the displaced item returning to the pack.
Built in code
Including the martial_arts Feature check, which the resolver reads
instead of hard-coding a Class — the pattern the rest of the Feature system is
meant to follow.
Built in code
Races, Classes, Jobs, Skills, spells, creatures and items are served by the codebase and validated in both directions against the design documentation, so a catalogue entry and its documented definition cannot silently disagree. Prose totals written in the design chapters are not covered by that check, which is why this site does not print a Skill count.
Built in code
Account and actor identity, permanent Character IDs, shorter public character codes, and actors that can be reduced to Downed.
Designed, not built
The largest single gap in the character model, and the one everything else on this list waits behind. Skills are the only proficiency model in the design, and actors cannot yet own changing ranks.
Designed, not built
Catalogue requirements exist without competence affecting real actions. A rank would currently change nothing about how an attack or a craft resolves, because there is nothing reading it.
Designed, not built
One unit of valid practice to one Skill or track. The progression loop is fully documented and cannot run, because it is blocked on both of the two items above.
Designed, not built
Actors can already become Downed in code. Nothing can pick them up, nothing can recover, and no player-directed defensive stance exists — automatic Return Strikes are a different mechanism and they are not something you choose.
Designed, not built
Resolve one known spell once and pay its declared resources. Additionally blocked on an unresolved decision about how spells map onto Skills — which is exactly the kind of question that has to be answered before code, not after it.
Designed, not built
Gathering, crafting, production, quality, repair and building. The Job catalogue is authored; the work is not implemented.
Designed, not built
Both systems are specified in detail. Neither exists in code.
Designed, not built
Parties, Clans, Alliances, NPC Guilds, Factions, reputation, local law, markets, shops, property, quests and contracts, and companions, minions, pets, summons and workers.
Where this is
Nothing on this page is playable. The character model is written, the catalogues are authored and validated, and the parts of the resolver that touch a character — combat, equipment, Stamina, movement, loot — run in development with tests. The progression loop that would make a character grow does not run at all yet. The honest status page lists the whole project the same way, item by item.