Lanternal

A fast-paced bullet hell shooter, you play the role of a young mage who needs to defeat foes and capture their souls. At regular intervals a demon will appear requiring you to sacrifice some power in order to continue.

The engineering problem

A bullet hell wants a lot of enemies on screen, and enemies that chase you want pathfinding. Those two wants pull against each other: A* is a per-agent graph search, and running it for every enemy, every frame, is the standard way to turn a smooth game into a slideshow. Every additional enemy costs you twice — once to draw, once to think.

There is no time to build a flow field or a steering system in seventy-two hours. So the real question is not "what is the best solution", it is "what is the cheapest thing that holds for the number of enemies this game will actually have", and knowing where that number stops being true.

How I approached it

I built the enemy side: spawning, movement and pathfinding, plus the game's UI programming — all of it as Unity MonoBehaviours, which is the grain of the engine and the right call under a jam clock, whatever its long-term costs.

Spawning is where a jam game is won or lost, because it is the dial you turn after every playtest. Getting waves out of the code path and into something adjustable is what lets the design be tuned by whoever is holding the build, rather than by whoever wrote it.

The pathfinding was deliberately bounded rather than clever. Not every enemy needs a fresh path every frame, and a bullet hell hides an enormous amount of approximation behind motion and particles — the player is reading threat, not routes. Spending the budget where it is visible and skimping where it is not is most of real-time performance work.

What I'd bring to your project

Two things, and neither is engine years.

The first is knowing where the cliff is. A* per-agent per-frame is fine at ten enemies and fatal at two hundred, and the useful skill is recognising which side of that line you are on before it shows up as a frame-time problem in week six. That is the same instinct as knowing an N+1 query is fine on a seed database and not in production — which is a thing I have spent fifteen years being paid for.

The second is UI. It is where jam projects accumulate their worst code, because it is always the last thing and it touches everything. Wiring a HUD to game state without the two becoming one tangle is ordinary, unglamorous engineering, and it is exactly the kind of work a small team is glad to hand to someone else.

Scope & role

Enemy spawning, movement and A* pathfinding, plus UI programming — one of two programmers on a team of seven, alongside an animator, an audio designer, an artist, production and developer support. Unity, 72 hours, Ludum Dare 43. Player input and controls were the other programmer's.