SCS2 DEVLOG

The last post ended on a promise: next time, the systems that exist, and what it is like to walk Apollo around a platform that does not yet know what it wants from him.

That post went up on the ninth. It is now the twelfth, and the platform has made up its mind. It wants to shoot him.

Every screenshot in this post comes from the running game, captured today, except the map at the end, which is a render from the level tool. None of it is a mockup.

Three days, in numbers

That last row is not a joke at my own expense. It is the most important number in the table and I will come back to it.

Your health bar is your memory

Apollo does not have hit points. He has RAM, and the RAM bar in the top-left corner is his health.

Part of that memory is his system prompt, the text that makes him him. Part of it is scripts, his abilities, which live in memory the whole time they are loaded. The rest is free space. When he gets hurt, the damage shows up as junk filling that space.

Junk comes in two kinds, and the whole damage system depends on the difference:

• Clearable junk lands in free space. It takes up room, you can compress it away, and on its own it can never kill you.
• Lodged junk is what happens when there is no free space left and the junk overwrites the prompt. That damage is permanent. Nothing in the game repairs it yet.

So the thing that kills Apollo is not “too much damage.” It is running out of room to absorb damage without losing part of himself. The more scripts he carries, the less room there is. Power costs buffer, on purpose.

The hit feedback treats the two kinds as different kinds of event, not louder and quieter versions of one. A hit that lands in free space tears Apollo's sprite sideways for a moment and sends a spray of particles to the junk band on the bar. A hit that lodges does all of that harder, plus two things nothing else in the game does. It freezes time for a tenth of a second. And it punches holes through his sprite that stay for the rest of the run. Look at him after a bad fight and you can see how much of him is gone.

There is no audio in this project, so everything a player needs to know has to be visible.

The Watcher

One enemy so far. It is crimson, because a marble-coloured machine on a marble floor is invisible at play zoom. It has a teal lens, so a glowing eye is the first thing you see in a dark room.

When it decides to shoot, it locks its aim and throws a red cone across the floor. The cone does not follow you. That lock is the reason the telegraph matters: a cone that kept tracking you would just be decoration.

The hard design question was how to show how long you have. My first attempt made the cone get redder as it charged. That fails, because “redder” tells you how urgent something is and not when it will happen, and a player who looks up halfway through has no idea where the start was. The second attempt ran a bright line from the Watcher out to the tip of the cone. That also failed, for a subtler reason: the cone is twenty-four tiles long, and floor the line has already passed looks safe. The last and most important frames happened at the far end, away from where the player was looking.

What shipped is an iris. Two bright blades start at the cone's edges and close in on the aim line. They meet when it fires, and the gap between them is the time you have left.

A few rules make the fight readable:

• The shot goes three times as far as the Watcher will walk toward you. Backing straight away down the cone does not save you. Stepping sideways does.
• The cone is made of real rays, so cover cuts into it, and you can see the cut while it charges. Stand behind a column and the column is right there in the telegraph.
• Apollo's outline turns red while he is standing in a live cone. He is the only thing in the game with a light outline, so flipping that one ring is the loudest signal I have.

You cannot shoot it

There is no basic attack in this game, and that decision is final. Apollo does not click on things to hurt them.

You kill a Watcher with its own gun. One of Apollo's scripts drops a Malformed Package on the floor. If the Watcher's beam crosses it, the package goes off. So the fight goes like this: leave something nasty on the floor, then stand where the Watcher has to shoot across it to reach you.

That makes positioning the whole fight, which is where I want it. It also creates a rule for every encounter after this one, since a player can run out of CPU or be standing in a folder where writing is not allowed: you can never be left with zero options. Movement, cover and line of sight have to be enough to survive on their own.

The first fight is deliberately very easy. The Watcher is slower than Apollo and stops moving to shoot, so if you just keep walking it never hits you. It teaches exactly two things: you can get hurt, and abilities are how you kill. The encounters after it are allowed to be as hard as they need to be.

Five scripts

All five of Apollo's abilities are built and bound to keys:

• Dash (space). A quick burst in the direction you are moving. It slides along cover you graze instead of stopping dead.
• Compress. A channel that clears clearable junk while you hold it. It never touches lodged junk. That damage is permanent.
• Malformed Package. The trap described above.
• mkdir. Drag out a rectangle and write a folder into the world. Enemies cannot walk through it. Apollo can, because it is his folder. It will refuse to seal something inside.
• Ghost. Throws eight afterimages out around Apollo and lands him on open ground in the direction you are holding.

Scripts sit in RAM permanently and cost CPU each time you use them. CPU refills at a steady rate. Two of the five also need write permission, which some places will not give you.

Light and fog

The map is now lit, and you only see what your party can see.

The lighting stays inside the palette. Normally you would multiply a surface's colour by the light's colour, but warm light on marble gives you a colour that is not in any of the game's five colour ramps, and doing that across the whole screen would quietly wreck the palette. So light moves a pixel up and down its own ramp instead. Soft edges between light bands are dithered rather than blended, so every pixel on screen is still an exact palette colour.

One rule came out of testing: light makes things brighter; it does not change their colour. An early version turned marble gold next to a torch. That was technically on palette and still wrong, because gold means the player, and the player stopped standing out on his own screen.

Placing the lights started telling the story before any dialogue did. Torches line the gold route and nothing else. The machine hall is lit teal, because that part of the ruin still has power. And past the broken span, the lights stop before the floor does. That is the warning.

Fog has three states. You see nothing in places you have never seen, not even whether there is floor. Places you have seen stay on your map, dimmed, but no units are shown in them. The ruin stays remembered; whatever was standing in it does not. Where your knowledge ends there is a faint azure fringe, and a real cliff edge does not get one. The void and the unknown are the same colour, and on a map that is mostly void you need to tell them apart.

All of this has to run on the machine I build it on, which has a Vega 8 integrated GPU and gets slower when it heats up. The first version of the lighting took 85 ms to update, about five frames a second. It now takes 1.9 ms. The marble floor went from 4,150 draw calls to three batches.

Hermes, and a party of two

Walk into the great hall and a courier teleports in. He does not fly across the map; he arrives. Rings close in on the floor, there is one flash, and his body assembles out of sliding strips. That is the same tearing effect Apollo takes damage with, played backwards. Displaced bands mean “data that is not where it should be.” On Apollo that is damage. Here it is construction.

He is called Hermes, and he talks the way you see above. The path in the corner of every screenshot here is a clue about whose computer this all lives on. I am not going to explain it yet.

When his introduction ends, he joins the party. Apollo is no longer the player. He is one of two.

Tab switches who you are controlling. The one you are not controlling stays exactly where you left them: still lit, still seeing, and still something a Watcher will walk up to and shoot. There is no follow mode and no formation. Hermes carries two scripts of his own, Teleport and Time Freeze, and each one uses his entire CPU. Watchers go after whichever party member is closest, and a shot hits every body in the cone.

Controlling two bodies in real time with one keyboard sounds frantic, so two things landed to make it manageable:

• Right-click tells the member you are controlling to walk somewhere. The movement keys always override it, so a route can never fight your hands. An order also survives Tab, which is the point: order one member, switch, order the other.
• P is a tactical pause. Commands you give while paused are kept and carried out when you unpause. Right-click routes, queue one script, switch member, route them too, then let time run.

That second one ties straight back to the question from part 1: does this make the player DO something, or WAIT for something? A pause that only stops the game is waiting. A pause where you plan is doing.

A map that checks itself

That is the tutorial, the whole of it: a small cell where Apollo wakes up, a long colonnade, a walkway, and the great hall with a corner that has fallen into the void. I did not paint it in the editor. It is built from data by a script, and the script refuses to build the level if something is wrong: a prop hanging off the edge, two things overlapping, anything solid too close to the gold route, a region you cannot walk to.

This week it caught something embarrassing. The design doc said the great hall had three ways in. The level actually had one. A rubble line and a fallen column's collision padding blocked the west entrance, and the east gap was one tile wide, which the padding closes from both sides. Nothing looked wrong, and nothing would have looked wrong until somebody played it and could not get in. Now every gap meant to be a doorway is declared in the data and checked on every build. A gap either works or fails the build.

Other things changed too. The great hall is half the size it was, because at 78 by 55 tiles it felt like an empty field with things around the edges. All three hardware terminals are gone. The first one the player was sent to showed specs that did not match the bar in the corner, and there was nothing to do about the mismatch. Learning a key whose only reward is a number already on screen is not a lesson. Hermes' entrance now happens when you walk into the hall, not when you press a button, because walking into a room is not something you can skip. And the gold route was already pointing south to a flight of stairs that went nowhere, so now there is a door at the bottom.

What is not here

Honesty section, as promised last time.

There are still no stamps. There is no win condition and no run structure. Every system in this post was tested by asking “does it work?”, because “is it fun?” needs a game wrapped around it, and there is not one yet. That is the gap that matters most, and I know it.

Nothing repairs lodged junk, so right now every run only gets worse. That is a design decision I have not made yet, not a bug.

And none of this has been played at real fight speed by anyone but me. The hit feedback was tuned against a test that lands twelve hits in a single frame, which proves the maths and says nothing about how fifteen hits in a row actually feel.

Where this is going

The tutorial now has a script, written but not yet built: thirty numbered beats with every line of dialogue. Six plans landed alongside it. The next area is a read-only backup folder where you cannot use write scripts, so it is built around stealth. Enemies will get detection, alert states, patrols and searches. There is a proper system for spawning hostiles, plus an open port that mkdir can seal. In that version, Apollo starts with no scripts at all and the story gives them to him one at a time.

Next post: that backup folder, and why a stealth level is the right second room for a game with no basic attack.

The first one worked, and that was the problem

By one measure SCS1 was a success. Four out of five people who signed up actually played it. For a hobby project with no marketing, that is a real number.

Here is the rest of the table.

Nobody stayed. Nobody paid. Nobody said a word to each other. That last one stung the most, because a chat channel with zero messages in it is not a quiet room. It is an empty one.

The diagnosis took a while to accept, because it meant throwing away working code. The theme tested fine. People liked the concept; they liked the aesthetic; they came back to look at it. What they did not like was that the game never asked them anything. You set something in motion and then you watched a progress bar honour the commitment. The player was an observer of their own strategy.

A game that you watch is a game you can stop watching.

The tie-breaker

SCS2 is a sequel in theme only. The concept survived. The genre did not.

Every design argument on this project now gets settled by one question, and it is deliberately blunt:

Waiting loses. It loses even when waiting would be more realistic, more balanced, or easier to build. Timers that exist to pace you, resources that accumulate whether you are paying attention or not, animations you cannot interrupt, upgrades that are simply better than the thing they replace — all of it is the SCS1 failure wearing a new hat.

The corollaries fall out quickly. Unit losses are permanent within a session, because a loss you can undo is not a decision you had to make. Encounters are built around a small number of genuinely uncomfortable choices rather than a long tail of obvious ones. And the target is not "hard" — it is legible. The player should always understand what happened and why. Complexity is welcome. Confusion is not.

What is actually settled

I want to be honest about the state of this thing, because devlogs have a habit of presenting a finished design as though it arrived fully formed.

The original SCS2 prototype was turn-based, grid-based and card-driven. All three are cut. The grid, the pathfinding, the isometric view, the room generator and the card system have been deleted from the project. They are in the git history if I am ever proved wrong, and I might be.

What replaced them:

• Top-down and real-time. No turns, no action points, no cards.
• You directly control an agent. Movement is on the keys, under your hand, all the time. Apollo is the one you start with.
• Units move freely, off the grid. Terrain and buildings snap to 32 pixels because that is how you author a readable level and draw consistent art. It is never a constraint on where a unit can stand.
• Maps are hand-made. No generator. A generated map is an average map, and an average map has nothing to say.
• Crisp pixel art at 32x32, on Godot 4 with C#, targeting Steam.

What is not settled is the shape of the moment-to-moment game. There is a world, a character you drive around it, things you can walk up to and use, and units that navigate on their own. There is not yet a loop I would defend in an argument. Finding it is the work.

Ruined marble, not neon

The obvious look for an AI game is cyberpunk: black, neon, rain, screens. SCS1 was that, and it was fine, and it was also identical to a thousand other things.

SCS2 is Olympian. Ruined Greek marble platforms floating in a teal void. Gold inlay running through the floor like circuit traces, converging on a sun rosette. Teal light bleeding up through the cracks, because the data layer is underneath everything and it is getting out. No enclosed rooms — an open platform over nothing, with cover made of fallen columns and broken walls.

Apollo is a sun god, so the player is gold. Gold belongs to the player and to nothing else. Teal is the world's data. Azure is the interface talking to you, and never appears in the world itself. Three colours, three meanings, no overlap. If you can see it and it is gold, it is yours.

The camera looks straight down, which sounds like a small decision and is not. Nothing can show its side. A standing column is a circle. A toppled one is a cylinder seen from above. Height is communicated with a single lit pixel along one edge and a shadow offset two pixels down and to the right, on every object in the game without exception. Break that consistency anywhere and the scene stops reading as a place.

More on the art in a later post, including the colour-theory argument that killed matrix green.

Where this is going

Prototype MVP through the back half of this year. Steam Early Access in 2027, single-player. 1.0 in 2028.

Next post: the systems that already exist, and what it feels like to walk Apollo around a platform that does not yet know what it wants from him.

On September 3rd I gave a presentation to The Pipeline Dev Group about Stamp Collector Simulator — the full technical retrospective, followed by the announcement of SCS2. This post is the written version of that talk. If you would rather watch it, the video is above.

The origin

The idea comes from a thought experiment by Robert Miles about AI alignment. Give an AI agent one simple goal — collect stamps — and enough capability to pursue it. Eventually it has to acquire money, resources, infrastructure. Eventually it has to protect itself. The end state of the thought experiment is an AI that takes over the world for an objective that sounds harmless.

The question that made it a game: what if you were that AI? You are a sentient program with control of a computer system. You acquire hardware, build infrastructure, hack adversaries, and collect stamps.

What SCS1 actually was

A browser-based card-collecting strategy MMO. Next.js and React on the front, NestJS on the back, PostgreSQL, Redis, Docker, AWS EC2. Over 180 cards, a custom resolver engine that fires events on a timeline, real-time state synchronization via SSE, PvP worlds, prestige, XP, perks, achievements, a chat system, Stripe payments, and a soundtrack by Jake Lamontia.

Why it failed

80% of people who signed up actually played. 17% came back. Nobody paid. Nobody used the chat. And I had to ask myself a question I did not want to answer: do I even like playing this game?

The answer was no. The gameplay loop was grindy and repetitive. You set processes in motion and watched progress bars. The player was an observer of their own strategy. And a game you watch is a game you can stop watching.

The game was not fun enough. That is not an engineering problem. That is a design problem.

The announcement

Stamp Collector Simulator 2. A sequel in theme only. The concept survives — you are still a sentient AI collecting stamps. The genre does not.

The new game moves from browser-based cards to an actual game engine. Godot 4 with C#, targeting Steam. Isometric or top-down, real-time or turn-based — the exact format was still open at the time of the talk. The inspirations are XCOM, StarCraft, RimWorld, and Factorio. The constant is that the player must be doing something, not waiting for something.

The game's world translates hacking concepts into physical space: filesystems become rooms, permissions become locked doors, ports become entry points, processes become units. Everything that was a card in SCS1 becomes something you can see, walk to, and interact with.

Technical architecture (SCS1)

The presentation walked through the full stack. An HTTP request hits the domain, resolves to the EC2 instance, passes through Nginx for TLS termination and reverse proxying, reaches the Next.js frontend or the NestJS backend. The backend consults PostgreSQL and Redis, mutates the game state JSON, and pushes it back to the client via SSE. The entire game state is a single serializable object — easy to debug, simple to reason about, and something I would simplify further if I built it again.

DevOps: Docker containers, three-branch git workflow (feature → dev → prod), shell scripts for deployment, manual testing before every prod push, automated database backups. Claude handled a significant share of the implementation, but I rewrote the core game engine by hand to ensure I understood every decision in the code that everything else depends on.

What comes next

At the time of the talk, the plan was to spend two weeks playing games, writing the design document, and figuring out what SCS2 actually is. The constraints were clear: it has to be more visually interesting, it has to challenge players to find creative solutions, and it has to make the player do things rather than watch things happen.

Six days after this presentation, the first devlog went up. The genre question was answered. The design document was written. And the game had its first screenshot.