# The game, explained simply Documentation: next (source: develop). Install the preview: `pnpm add @aephia/atlas-kit@next`. These docs follow develop and may include changes not yet published to npm. > A newcomer-friendly tour of SAGE C4: who you are, where you go, what fleets do, and why the game lives on a blockchain. Markdown source of https://develop.atlas-kit-docs.pages.dev/start-here/the-game-simply/ — see https://develop.atlas-kit-docs.pages.dev/ai/ for the full machine-readable surface. Imagine a shared space board game that never closes. Players form fleets from their ships, fly between star systems, gather and move resources, build things, trade with other players, fight, and improve their characters. The board and all the important game pieces are recorded on a public blockchain, so anybody can check what exists and what state it is in. That part of Star Atlas is called **SAGE**. This guide describes the current generation, **SAGE C4**, as Atlas Kit sees it on the **z.ink public test realm**. It does not try to cover every story, product, or future feature in the wider Star Atlas universe. ## The whole game in one picture There are two sides to the game: **the player** and **the world**. ```text You The galaxy │ │ ├─ Wallet ├─ Regions ├─ Profile │ └─ Star systems └─ Character │ ├─ Planets ├─ Faction │ ├─ Asteroids ├─ Council Rank and research │ └─ Starbases ├─ Fleets → ships, cargo, movement └─ Warp-lane connections ├─ Starbase storage and crafting habs └─ Claim stakes ``` Your **Character** is the point where those sides meet. It controls fleets, registers at starbases, owns production facilities, earns progress, and acts for your Profile inside SAGE. ## First: who are you? Star Atlas uses three related identities: 1. Your **wallet** is the keyring. It can prove that you approve an action. 2. Your **Profile** is your Star Atlas identity. 3. Your **Character** is that Profile's presence inside SAGE. The distinction matters. A wallet can control a Profile, but the two are not the same thing. A Profile can give different keys different permissions, and a Character—not a wallet—owns the SAGE fleets and progression state. You can also join one of the three player factions: - **MUD** - **ONI** - **Ustur** A faction is your side in the galaxy. Factions control territory and assets, hold resources, and have changing relationships with one another. They are not three fixed character classes with a simple permanent bonus. See [You](/guides/identity/) and [Factions](/guides/factions/) when you want the technical version. ## The galaxy is a map of connected places The Galia Expanse is divided into **regions**. Regions contain **star systems**, and each system is one point on a two-dimensional map. A system can contain: - planets; - asteroids; - connections to other systems; and - a shared starbase. The game interface may draw a beautiful solar system with stars and orbiting bodies, but the gameplay map is simpler: the system has one pair of coordinates, and its bodies belong to it. C4 does not store a separate Star account. Some systems are joined by **warp lanes**. Think of them as faction highways. A lane only works when both ends are controlled by the same faction, and using one charges an ATLAS toll based on the starbase level at the gate. The chain stores gameplay facts such as names, positions, bodies, connections, ownership, and starbase state. It does not necessarily store every piece of presentation. Visual star details, orbital animation, artwork, and system lore blurbs may be generated by the client or come from off-chain content. See [Starmap](/guides/world/) for the full world model. ## Ships become useful when they form a fleet You may own ship tokens in a wallet, but ships do not fly around SAGE one at a time. You import ships into the game, place them in your state at a starbase, and assign them to a **Fleet**. A fleet is one game piece made from one or more ships. Its ships combine into effective fleet statistics such as: - speed and warp range; - fuel use and fuel capacity; - cargo and ammunition capacity; - mining rate; - scan power and cooldown; and - shields, hull strength, weapons, and repair ability. A ship configuration describes one kind of ship setup. Fleet statistics describe what the assembled group can do together. Fleets also have separate places for ordinary cargo, fuel, and ammunition. Capacity matters: owning a resource does not mean every fleet has room to carry it. See [Fleets](/guides/fleets/) and [Cargo](/guides/cargo/). ## A fleet is always doing something A fleet does not have one simple location field. Its location depends on its current **state**. It might be: - **docked** at a starbase; - **idle** at a point in space; - travelling by **warp** or **subwarp**; - **mining** an asteroid; - recovering after destruction; or - transferring through a Claim Stake operation. This is a useful way to think about the game: a Fleet is not merely a bag of ships. It is a game piece in the middle of a particular activity. Movement comes in three main forms: - **Subwarp** is slower and uses less fuel. - **Coordinate warp** trades more fuel for a much faster trip and is limited by the Fleet's warp range and cooldown. - **Warp-lane travel** jumps between connected systems when faction control permits it, and charges an ATLAS toll. Starting a journey and arriving are not always the same event. Time can pass before the Fleet reaches its destination, and the completed journey may need to be settled before the Fleet can begin its next activity. See [Warp & subwarp](/guides/moving-a-fleet/). ## Starbases are the ports of the game A **starbase** is shared infrastructure in a star system. Fleets dock there, and it can host storage, markets, repairs, upgrades, and production. The shared starbase and **your state at that starbase** are different things. The port may exist even when you have never visited it. Before it can hold your cargo or escrowed ships, your Character registers there and gets its own local Starbase Player state. That local state can contain: - cargo stored at the base; - ships waiting to be assigned to Fleets; - respawn information; and - upgrades or other player-specific activity. Cargo stored at a starbase is not cargo aboard a Fleet. Moving goods between them is a real game action, and the Fleet must be docked there. See [Starbases](/guides/starbases/). ## The economy is a loop, not a single activity Most economic play connects several systems. ### Mining Asteroids hold resource deposits. A Fleet travels to an asteroid and extracts selected resources at rates determined by both the deposit and the Fleet. Mining fills cargo over time; it is not one instant “give me ore” button. ### Claim stakes A Claim Stake is longer-term infrastructure on a suitable planet. It begins with a hub, can add buildings for extraction, processing, power, and storage, and produces or consumes resources over time. Buildings need crew, construction takes time, and the Stake needs rent to remain deployed. ### Crafting Crafting has three pieces: - a **recipe** says which inputs become which outputs; - a **crafting hab** is the facility at a starbase; and - a **crafting process** is one recipe running there for a period of time. Starting a process commits its inputs and crew. Finishing the timer does not automatically collect the result; completion is another game action. ### Markets A local market belongs to a star system. Players post bids and asks for one resource at a particular price and quantity. This means there is no universal price for ore, fuel, or food: prices can differ between systems and change while you are looking at them. Faction markets are different. They offer goods on faction terms instead of using the player order book. Together, those activities create the basic economic loop: ```text travel → gather → transport → process → trade → improve → repeat ``` See [Mining](/guides/mining/), [Claim stakes](/guides/claim-stakes/), [Crafting](/guides/crafting/), and [Markets](/guides/markets/). ## Scanning and combat add uncertainty **Scanning** lets a Fleet search its surroundings. A scan pattern defines what the scan costs and what it might find. A scan can discover useful cargo or loot, or it can find nothing. Fleet stats and cooldowns limit how often and how effectively it can scan. **Combat** compares the ships, weapons, defences, and state of opposing Fleets. Attacks can miss or critically hit. Damage usually wears down shields before the hull. Chance is part of the result, so Atlas Kit can explain the inputs and current state but cannot promise who will win. Combat can leave Loot accounts behind, and hostile actions can interact with the game's outlaw state. Those are game records of consequences, not merely animations in the client. See [Scanning](/guides/scanning/) and [Combat](/guides/combat/). ## Progression turns activity into new options Your Character earns XP in categories such as piloting, mining, crafting, and combat. **Council Rank** records Character-wide progression alongside those activity-specific levels. Career levels award career research points and contribute toward Council Rank Renown. Research nodes can require levels and spend those points, ATLAS, and cargo. Unlocking one grants a perk, such as access to larger ships, more Fleet capacity, faster movement, or better crafting. Progress therefore has two parts: 1. do activities to earn XP and meet requirements; 2. choose research that turns that progress into useful capabilities. Faction contribution has its own rhythm. **Loyalty epochs** are time windows in which contribution is recorded. Accumulated ATLAS rewards can sit in a Loyalty bank until claimed. Reward configuration is versioned, so the rules for one epoch are not automatically the rules for every epoch. See [Council Rank](/guides/council-rank/), [Loyalty points](/guides/loyalty/), and [Rewards](/guides/rewards/). ## What “on-chain” changes about the game In a traditional online game, one company's server keeps the authoritative database. In SAGE, important state is stored in blockchain **accounts**. An account has an address, an owning program, and encoded data. That gives the game a few unusual properties: - The state is public to read. You do not need the official interface to inspect a Fleet, market, or system. - Reads are snapshots. Another player or transaction can change the state after you read it. - Time-dependent values are often calculated. A travelling Fleet does not need to write a new position every second; its current position can be derived from its journey and the clock. - Changes happen through transactions. A transaction can cost fees, move assets, and fail if the world changed before it executed. - Not all content needs to be on-chain. Artwork, interface layout, generated visuals, and lore can live elsewhere while gameplay state remains public. The chain is the referee for the final result. An app or SDK can check many rules beforehand, but it cannot overrule the game program. ## Where Atlas Kit fits The chain stores compact bytes for programs, not friendly objects for people. Atlas Kit translates those bytes into game-shaped TypeScript. Its simplest rule is: - **Nouns are reads.** Read a Character, Fleet, system, inventory, recipe, or market and receive a validated snapshot. - **Verbs begin as Plans.** Moving, transferring, crafting, trading, or fighting first produces an inert description of the intended transaction. A Plan does not sign or send anything. It lists the signers, accounts, preconditions, expected effects, and warnings. You can inspect and simulate it before a wallet is asked to approve anything. Execution receives an external signer for that one call, submits once, waits for a result, and then the app reads the affected state again. ```text read → plan → inspect → simulate → sign → execute once → read again ``` Atlas Kit is therefore a translator and safety boundary. It is not the game client, a wallet, an automatic player, or a promise that every possible C4 instruction already has a friendly planner. See [How Atlas Kit reads the game](/start-here/how-it-thinks/) and [How Atlas Kit changes the game](/start-here/how-it-acts/). ## A first expedition, from beginning to end Here is one way the pieces can connect for a new player: 1. A wallet creates or controls a Profile. 2. The Profile joins MUD, ONI, or Ustur and registers a Character in SAGE. 3. The Character registers at its faction's Central Space Station (CSS). 4. Ships and supplies move from the wallet into that CSS's player storage. 5. The player creates a Fleet, assigns ships, and loads fuel, food, ammunition, or other cargo needed for the trip. 6. The Fleet undocks and travels to a system containing a useful asteroid. 7. After arrival is settled, the Fleet begins mining selected resources. 8. The player later stops mining, returns to a starbase, docks, and unloads the cargo. 9. The resources can be stored, sold in that system's market, or used by a crafting process. 10. The activity contributes to progression, which can unlock research and make later expeditions more capable. That is not the only way to play. A player might trade between local markets, develop Claim Stakes, run production, scan, fight, contribute to a faction, or build tools that watch the public game state. But the same pieces keep reappearing: identity, world, Fleet state, cargo, time, and explicit actions. ## The small vocabulary worth remembering | Term | Plain-English meaning | | --------------- | ---------------------------------------------------------------------------------- | | SAGE | The Star Atlas game layer where Fleets travel, gather, build, fight, and trade. | | C4 | The current generation of SAGE, incompatible with older SAGE account layouts. | | z.ink | The public test realm where this C4 deployment runs, separate from Solana mainnet. | | Profile | Your Star Atlas identity. | | Character | Your Profile's player state inside SAGE. | | Fleet | One moving and acting group of ships. | | Starbase | A system's shared port and service centre. | | Starbase Player | Your personal storage and state at one starbase. | | ATLAS | The in-game currency used by markets, fees, and rewards. | | Account | One addressed piece of blockchain state. | | Snapshot | A validated view of an account at the time it was read. | | Plan | An inspectable, unsigned description of one supported transaction. | When one of those terms becomes important in code, the [full glossary](/glossary/) and [game map](/game-map/) are the quickest next stops. To read live state yourself, continue with [Your first read](/start-here/first-read/).