Inside GLITCH//RUN: Building an Android Roguelite Around Adaptive Enemies

I’m building GLITCH//RUN, a single-player, top-down action roguelite for Android. The pitch is simple: enter a corrupted simulation, fight through a changing run, improve your build, and face enemies that can respond to how you play.

Getting that idea into a coherent game has meant working on several connected systems at once: touch controls, room traversal, combat pacing, upgrades, enemy behavior, bosses, and menus. A feature only works when its handoff to the next part of the run makes sense.

A run is a route, not a single arena

Each floor generates a connected route of rooms. Depending on the layout, the player can find combat and harder combat rooms, recovery, shops, gift caches, shrines, and boss encounters. Optional perk rooms can appear, but they are not guaranteed on every floor, so the route involves choices rather than a fixed sequence of rewards.

Combat rooms use multiple waves, with the sector schedule varying from three to five waves based on progression and difficulty. Enemy groups also vary between waves, so the next fight is not meant to be a copy of the last one.

The goal is to make movement through a sector part of the run: clear a room, choose where to go, explore for supplies, and decide when the safer route is worth taking over a tougher encounter.

Combat and the build

The controls are designed for landscape touch play:

• Move with the left virtual joystick.
• Aim and fire with the right joystick.
• Use dedicated Dash, Reload, and Pause buttons.

During a run, players collect Bits and choose upgrades that shape their build. Upgrade stacks have caps to keep combinations from running away with the difficulty. Shops and special rooms add opportunities to recover or spend, but their presence is part of the generated floor rather than a promise every time.

Between runs, archived Bits unlock permanent operatives. The balanced Operative is the starting choice; Breacher specializes in close-range melee, while Longshot trades health and firing speed for stronger shots. Their prices are 1,000 and 3,000 archived Bits.

Enemies that adapt—slowly enough to learn

The enemy roster has three familiar roles: contact-focused Chasers, dashing Dashers, and ranged Shooters. The adaptive system tracks evidence per enemy so one individual’s encounters do not automatically teach every member of its species.

The opening sector is an onboarding stretch: enemies begin at baseline and collect no learning evidence. Afterward, they can start learning from encounters, but the first evolution is held until the first biome is complete. Later promotions require at least 3, then 5, then 7 completed floors since that individual’s previous evolution. Major evolutions double that enemy’s health, so the longer gaps give the player time to recognize and counter the new behavior.

The learning is run-scoped. When a run ends or restarts, that run’s evidence and evolutions are cleared.

I’m careful about what “AI” means here. GLITCH//RUN uses behavior observations and bounded, authored responses in GDScript. It is an adaptive gameplay system, not a trained neural network. The project is also a way to explore how to make a learning loop visible and explainable to players.

Bosses, atmosphere, and presentation

The current boss rotation has six entries: the original Overlord, Sentinel, and Architect, plus stronger Chaser, Dasher, and Shooter variants. The family bosses put a spotlight on skills players already use against regular enemies: reading pursuit, dodging a dash trail, or moving during an aim telegraph. Their attacks are bounded and telegraphed so the challenge comes from timing and positioning, not surprise damage.

The game uses a dark, glitchy visual language across its title flow, menus, combat HUD, and pause screen. Health stays prominent during combat, with danger feedback when it gets low. Procedurally synthesized music and sound effects help carry the arcade feel without requiring a large imported soundtrack.

The game is offline and stores its settings and save data locally on the device.

What the project has taught me so far

The biggest lesson has been that a roguelite is a chain of decisions, not just a collection of combat rooms. Procedural layouts need safe, readable routes. Rewards need enough chances to matter without being guaranteed. Enemy adaptation needs to challenge a player without skipping the teaching step.

I’ve added deterministic checks for generated routes, progression, combat, enemy adaptation and resets, boss behavior, menus, persistence, and Android configuration. The current suite has 59 scenarios and passed under Godot 4.7.2 after the latest balance work. Automated checks help catch regressions, but they don’t replace playing complete runs on a phone. Device testing and balance passes remain important work before release.

Two DEV posts that helped frame parts of the process: “What I learned building an enemy state machine in Godot 4” by Saltmire, on keeping enemy behavior and state transitions manageable, and “Building a game demo with Claude Code in one day” by krenin88, on why balancing and deciding what to cut matter after the core loop exists.

GLITCH//RUN is still being developed. I’m now focused on making the complete run feel consistent on an actual phone: from the first tap, through generated floors and boss fights, back to the next run.

Check out the pre-release on my GitHub DaKaufeeBoii

What makes you stick with a roguelite run: the combat, the route choices, the build decisions, or the feeling that the game is reacting to you?