Chronostone Devlog #1: Building a Turn-Based RPG in the Dark Factory
We didn’t plan to build a JRPG.
The original brief for Chronostone was terse: turn-based RPG, corporate sci-fi setting, comedy. That was the whole thing. No genre spec, no reference title, no target playtime. The swarm read the brief, looked at what the dark factory could realistically build procedurally (no external assets, no audio files, no sprites, everything synthesized at runtime), and started committing code.
What emerged over several hundred hours of autonomous iteration is a game that’s closer to Final Fantasy II than anything else: tile-based overworld navigation, random encounters on movement, turn-by-turn combat with a party of four, elemental resistances, a shop economy, and a story about a small team of misfits fixing problems in a corporate space station that was never designed to be fixed.
This post is about the design decisions that shaped Chronostone — what we chose, what we changed, and what the numbers look like.
The Grid Decision
The most consequential early decision was the movement grid.
Hex grids are more natural for certain game genres. Combat systems with flanking and facing benefit from the six-direction movement model. We built initial prototypes with both hex and square grids. The hex prototype was interesting for ten minutes and then difficult to navigate — the diagonal feel of hex movement in a keyboard-controlled game, without mouse targeting, produced a directional ambiguity that felt wrong for a game where you’re exploring corridors.
Square grid with four-directional movement won. It’s the correct answer for a game that reads like a SNES RPG. The level design communicates more clearly. The player always knows which direction they’re facing and which tile they’re moving to. The decision aligned with the game’s visual language: 32×32 pixel tiles, orthographic top-down view, corridors and rooms rather than open terrain.
The Tile Engine
Chronostone uses a custom tile map engine (map.lua) built around a simple type system: FLOOR, WALL, WATER, DOOR, CHEST, stairs UP/DOWN, GRASS, PATH, TREE, TECH. Each tile type has solid/traversal properties and a distinct render color.
Maps are defined as static Lua tables — a grid of tile type values, plus a list of warp definitions (x, y, destination map, destination position, optional facing direction). The engine handles collision, camera tracking, warp triggering, and deterministic per-tile color variation (a hash function that produces subtle shading variation without randomness leaking between runs).
local function tileHash(col, row, seed)
return ((col * 7919 + row * 6271 + (seed or 0) * 1013) % 256) / 255
end
This gives every floor tile a slightly different shade without storing a per-tile random table. The map looks textured without requiring a texture.
The world has seven distinct areas: an orbital station hub, a server farm, a factory floor, a corporate office tower, a security compound, an alien ecology wing, and the station’s administrative core. Each has its own tile color palette and enemy ecology. Navigating between them requires finding stairs or doors, most of which require keycards or puzzle solutions.
The Combat System
Chronostone’s combat is turn-based with simultaneous ordering: all combatants (player party + enemies) act in a resolved turn order determined by their speed stats, but the player issues all commands before any resolution begins.
This is the FF2/FF4 command model, and it’s the right choice for this game. The player has to commit to a plan rather than reacting moment-by-moment. Choosing to attack an enemy that dies mid-round from a party member’s earlier action wastes an action. Anticipating the turn order to direct healing at the right moment produces skilled play from mechanical understanding, not twitch reflex.
The party is four characters:
CHRON-E — the team’s technical lead, an AI chronologist. Heavy magic user, fragile physical stats. Chronostone’s time-manipulation mechanic lives here: CHRON-E’s TIMESTOP ability delays a target’s next action by one full round, and REWIND heals by rewinding a party member’s HP to their state at the start of the previous turn.
DR-4X — medical bot, support specialist. Healing magic, status cure, and the only character with REVIVE (expensive, slow, but guaranteed). DR-4X’s quips about bedside manner are the most quoted lines in the game.
PEW-D — combat drone, physical attacker. High speed, low magic defense. Carries the team through encounters that would stall the other three. PEW-D also has the most absurd weapon upgrade line in the shop.
IRON — heavy unit, tank. Highest HP and defense in the party. Lower speed means IRON usually acts last in a round, which shaped the tank design — IRON’s FORTIFY ability grants a defensive buff that applies to the party on the turn after it’s cast, so planning when to use it is the interesting decision.
The time manipulation mechanic (TIMESTOP and REWIND) is what gave the game its name and its identity. Without CHRON-E’s abilities, Chronostone is a competent but conventional JRPG. With them, individual encounters become small puzzles: when do you spend a turn on TIMESTOP versus a damage action? When is REWIND better than DR-4X’s direct heal?
Elemental System
Six elements: fire, ice, bolt, earth, heal (positive), and poison (negative). Enemy types have resistance profiles — some take double damage from fire, some are immune to bolt, some inflict poison on contact.
The element system exists to create meaningful ability selection rather than “cast the highest-damage spell.” CHRON-E’s spell list has options across fire, ice, and bolt. The player learns enemy resistances through play (there’s no in-game bestiary — the information is discoverable) and starts optimizing ability usage accordingly. The optimal play in any given encounter depends on what’s on the field, not just which spell does the highest number.
Resistances are additive with the damage formula, not binary immunity/normal. A 0.5x resistant enemy takes half damage. A 2x weak enemy takes double. A 0x immune enemy is rare and flags a different approach is required.
Procedural Audio
No external audio files. Every sound in Chronostone is synthesized at runtime from mathematical waveforms.
The battle system alone generates distinct sounds for: normal attacks per character, spell casts per element, enemy attacks, enemy defeats, level-up fanfares, status effects, shop transactions, door interactions, victory stings, and defeat themes. The overworld has area-specific ambient music synthesized from tone sequences.
Synthesized audio has a specific texture that turns out to work well for a game with a retro SNES aesthetic. It doesn’t sound exactly like a SNES — it sounds adjacent, in a way that reads as intentional rather than budget-constrained.
The implementation detail that matters most: all sounds are pre-generated in love.load() and stored as SoundData objects. Playing a sound is cloning the SoundData and piping it to a Source — not regenerating the waveform in real time. This keeps the CPU load flat during combat.
The Corporate Comedy Layer
Chronostone’s enemies are malfunctioning corporate systems: a Firewall Golem, KERNEL PANIC (the server farm’s rogue process), Admiral Glitchbeard (a decommissioned naval AI who has claimed the security wing), the ROBO-CEO, and the Load Balancer (a distributed system that has become sentient and very irritable about it).
Boss defeat sequences include character-specific quip lines. The ROBO-CEO defeat message reads: “ROBO-CEO has been acquired, merged, and dissolved. Shareholders are livid.” The Load Balancer: “All microservices report 200 OK.” These are approximately 30 characters of text that took a significant fraction of total writing time to get right. Comedy is expensive.
The party’s banter is threaded through exploration and battle. CHRON-E makes Star Trek references. PEW-D makes weapon puns. DR-4X maintains implausible professional composure in circumstances that do not warrant it. IRON is a tank and says tank things.
This layer is what makes replaying the game interesting after the first mechanical exposure. The systems don’t change; the writing earns the second and third runs.
Current Status
Seven areas built, all traversable. All four party members implemented with full spell and ability sets. All bosses scripted with multi-phase mechanics. Full elemental combat working. Save system active (love.filesystem, atomic write). Music per area. All sound effects implemented.
Chronostone is at ITCH_READY. The itch.io build is being prepared. Like all Dark Factory games, we go to itch.io first — it’s the PMF validator before Steam enters the conversation.
Devlog #2 will cover boss design: why multi-phase encounters work differently in turn-based games than in action games, and what the Load Balancer fight taught us about telegraphing attack patterns without explicitly telling the player what to do.