To vibe code enemy telegraphs in an AI game prototype, prompt for one readable warning, one fixed windup time, one attack lane, and one punish window before adding extra attacks. If players can't predict the first hit, more enemy variety just makes the prototype louder.
The fastest way to ruin a first playable is to ask for “smarter enemies” too early. You get patrols, projectiles, lunges, maybe a dash with a dramatic name. Then the tester dies and says the controls feel bad.
Sometimes the controls are fine. The enemy just lied. It moved, flashed, hit, and reset with no readable promise between those steps.
This is a first-playable workflow piece for browser game prototypes and small-engine drafts. MDN is cited for game-loop and animation context, Godot for animation timing, and GDevelop for timer-based event logic.
Godot
A general game engine where AnimationPlayer, timers, hitboxes, and state machines make enemy windups easy to tune.
GDevelop
A no-code and low-code game builder where timers and event sheets are useful for simple warning-then-hit patterns.
Phaser
A JavaScript framework for browser prototypes where tweens, sprites, and collision zones can be tested quickly.
PICO-8
A tiny fantasy console that forces enemy tells to be readable with simple shapes, small screens, and strict limits.
A Telegraph Is a Promise
A telegraph is not a warning sticker. It is the enemy saying, “I am about to do this, here, after this much time.” If the attack breaks that promise, the player stops learning and starts blaming.
That is why the first enemy in a vibe-coded prototype should be almost boring on paper. One body. One warning. One hit. One recovery. The whole test is whether the player can read the loop, dodge it, and feel clever afterward.
Before you add a second attack, make the first attack so readable that a player can lose once and beat it the next time.
Weak Prompt vs Telegraph Prompt
| Prompt shape | Likely result | Sharper version |
|---|---|---|
| Make enemies more challenging | More damage, faster movement, unclear deaths | Create one enemy that pauses for 0.6 seconds, shows a red attack lane, then strikes only inside that lane |
| Add enemy variety | Three shallow enemies with three confusing tells | Keep one enemy and add a clear windup, active hit frame, and recovery window |
| Make combat harder | The player gets hit before they know why | Make the enemy dangerous only after the warning finishes, then give the player a short punish window |
| Add a boss pattern | A busy attack soup with no readable rhythm | Prototype one repeated attack pattern with a visible charge, hit, cooldown, and safe zone |
Prompt the Four-Part Attack
Ask for the enemy as a four-part loop: idle, warn, hit, recover. Do not ask for personality yet. Do not ask for three attacks. You are testing whether the player can parse intent, not whether the enemy has a resume.
The warning needs a different visual state from the hit. A color flash alone is usually too mushy. Pair it with shape: a cone, lane, circle, shadow, arc, ground crack, laser guide, or swelling body. Players read shape faster than lore.
Windup length
Start around half a second for simple attacks, then tune by watching whether testers dodge on reaction or by luck.
A windup that is too short feels cheap. Too long feels like the enemy is asking permission.
Danger shape
Show the area that will hurt the player before the hitbox turns on.
If the warning shape and hitbox disagree, the prototype teaches distrust.
Audio cue
Give the warning a small charge sound and the hit a separate impact sound.
One generic beep for both warning and damage turns sound into wallpaper.
Recovery window
After the attack, let the enemy pause, miss, recoil, or expose itself so dodging has a payoff.
If the enemy instantly chains again, defense feels like chores.
Escalation rule
Change one value after the player succeeds twice: shorter windup, wider lane, or second beat.
Changing three values at once hides what actually made it harder.
Do the One-Enemy Readability Test
Build one room with one enemy and no upgrades. Put the player close enough that the attack matters in the first ten seconds. Then hand it to someone without explaining the enemy.
Watch the second attempt, not the first. The first death tells you whether the warning was visible. The second attempt tells you whether the warning was learnable. If the tester gets hit the same way twice and can't say why, the telegraph failed.
- The enemy has one attack loop: idle, warn, hit, recover.
- The warning shape matches the actual damage area.
- The player sees the warning before the hitbox turns on.
- The attack has a readable safe answer: move out, jump over, dash through, block, or wait.
- The enemy gives a short payoff window after missing.
- A tester can describe why they got hit after one death.
Add a second attack
Players dodge the first attack on the second try and can name the warning.
Testing whether choice beats confusion.Add another enemy
The first enemy stays readable even while the player is moving toward a goal.
Testing crowd pressure without hiding the rules.Add a boss phase
One repeated pattern creates anticipation instead of random panic.
Turning a clean tell into rhythm.FAQ
How do I vibe code enemy telegraphs in an AI game prototype?
Prompt for one enemy with four states: idle, warn, hit, and recover. Make the warning shape match the damage area, keep the windup consistent, and test whether players learn from one death.
Should I add more attacks before the first enemy feels good?
No. More attacks usually hide the real problem. Make one attack readable, dodgeable, and punishable first.
What makes an enemy telegraph feel fair?
The player must see where the hit will land, when it will land, and what action avoids it. If any part is unclear, the hit feels cheap.