A tactics game that lives inside an e-reader.

E-ink is a bad fit for most game genres: refreshes are slow, there is no color, and anything that moves leaves ghosts behind. Turn-based tactics gets along with all of that. Nothing moves until you decide it should, a grid board is high contrast by nature, and a battle can sit on the screen for a week without costing any battery.

The tighter constraint is memory. CrossPoint exists to render EPUBs in 380 KB of RAM, and a game has no business endangering that. The game gets whatever is left over, and the reading side should never notice it has a neighbor.

The rules engine is a plain C++ library with no Arduino headers, no HAL, and no logging. The same source compiles into the firmware, into a GoogleTest suite, and into a desktop simulator. Most of the development happened against the second and third of those, with the actual device checked now and then.

A battle lives in one Game object made of fixed-size arrays, with no pointers inside and no heap allocation once it exists. The activity allocates exactly one, 5,640 bytes, and frees it on exit. A 48×32 map is a byte per tile, and the visibility, explored, and danger layers are bitfields of 192 bytes each. Keeping the object trivially copyable started as a size decision and quietly turned into the save format, which comes up again below.

There are no dice. Damage is attack × (100 − defense)%, minimum 1, with defense stacked from unit, terrain, and race and capped at 60%. On a screen this slow you cannot hide randomness behind an animation, so every attack shows its exact outcome before you commit. The tension has to come from position instead.

Defenders counterattack if they survive and can reach you. A melee hit with an ally directly behind the target does half again more damage, and counterattacks get the same bonus, so a careless pincer cuts both ways. Stepping next to an enemy ends your movement, and walking out of contact takes a free hit on the way. Fog hides enemies outside sight range; terrain you have explored stays on the map, but the monsters in it do not.

Monsters start dormant, which is what makes the hidden-base maps explorable instead of a rush on turn one. One wakes when a player unit enters its aggro radius, when it gets attacked, or when a fight breaks out close enough for the pack to notice.

An awake unit scores every reachable tile against every attackable target and takes the best pair. Kills score high, pincer positions get the flank bonus priced in, and a lethal counterattack mostly rules a move out. Targets are weighted by threat, so a thunderer or a mage left uncovered is exactly what it will go for. When nothing is in reach, it walks down a cached distance field toward the nearest player unit. I assumed this would need something smarter eventually; so far, greedy with flank awareness has been unpleasant enough to play against.

The panel is 800×480 at one bit per pixel, single-buffered to save RAM. Everything on the board is built from that one bit: terrain as line icons, unexplored fog as a dark dither, explored-but-unseen tiles as a lighter one, danger zones as hatching under the unit plates, and units as 16×16 sprites drawn at double size, with enemies inverted.

Moves and cursor steps use the panel's fast refresh. Transitions that pile up ghosting, like entering a battle or ending an enemy phase, force a full flash, and a pause-menu entry wipes the screen by hand for everything in between. Enemy turns play out one action per repaint, because an instant AI turn on e-ink just looks like the board rearranged itself while you blinked. The danger overlay gets recomputed on every draw instead of cached, which sounds wasteful and costs about a millisecond. Next to a refresh that takes hundreds of times longer, it is nothing, and it means a hidden enemy's threat can never linger on screen after vision shifts.

An e-reader spends most of its life switched off, so the game assumes it will be powered down mid-battle and reopened days later. Because the state object is trivially copyable, serialisation is a raw byte copy of the Game, wrapped in a magic number, a format version, and a CRC of the level file.

Battles checkpoint after every completed enemy phase and on the way out of the activity. There is no save button. On re-entry the CRC gets checked against the level file, so if you edited the map since, the stale save is dropped instead of resuming a battle on terrain that no longer exists. The level list marks battles you are in the middle of and battles you have finished.

Levels are plain text files dropped into /tacticson the SD card, written in any editor or uploaded over the reader's web file transfer. The parser handles exactly the YAML subset the format needs and rejects everything else at load time with an error message rather than a surprise later. Story interludes are .story text files that sort alongside the battles, and filename order is the campaign: win a battle and Continue opens the next file, whether that is prose or a fight. Each subfolder of /tacticsis its own campaign.

Two ship with the firmware. The Deep Road follows three dwarves against a goblin flood, and The Broken Crown is a human civil war, each five battles with story pages between them. Making a third takes a text editor and nothing else.

I did not trust myself to re-balance five battles by hand after every rules change, so the test suite plays them. A greedy bot that knows about flanking, focus fire, and parting blows runs every shipped battle on every push, and each battle asserts a band of surviving units rather than a bare win: the floor catches unwinnable, the ceiling catches a walkover. Because the bot loads the real files that ship on the SD card, it also catches plain mistakes, like a base nobody can reach or a unit standing inside a mountain.

The bot has earned its keep. The knight originally moved seven tiles and flattened everything in testing, and the goblin slinger exists because the bot showed a melee-only monster roster could be kited to death from range without taking a single hit back. The same engine also links into a desktop simulator that takes commands on stdin, draws the board with the same art code the firmware compiles, and dumps a bitmap after every action. Every frame on this page came out of it.

The branch adds roughly 7,800 lines, but only six files that existed before it: two to register the activity, two for the home-menu entry, the English string table, and the host-test build list. Everything else, from the engine to the campaigns to the simulator, is new files.

CrossPoint is someone else's active project, and this game is a guest in it. The less it touches, the easier it rides along when upstream moves. In practice, rebasing the branch onto a newer upstream has so far been a non-event, which is the property I care about most.