An AI game prototype enemy telegraph readability test checks whether players can see one attack coming, dodge it, and explain the hit before you add smarter AI. Build one enemy, one arena, three wind-up timings, and one visible hit window, then add behavior only after the attack is readable at normal speed.
Generated enemies tend to get ambitious too early. The prompt asks for a patrol, chase, dash, ranged attack, phase change, and boss pattern. The result looks like AI. It does not always read like a game.
Combat quality starts with the first warning. If the player cannot tell when one enemy is about to strike, a smarter enemy will mostly produce smarter confusion. The first test should be boring on purpose: one attack, one warning shape, one damage frame, one recovery window.
This is a practical workflow article for AI-assisted 2D combat prototypes. The sources point to official animation, event, and timer documentation because telegraph tests depend on visible timing and repeatable state changes, not on broad engine claims.
Chatforce
A text-to-game workflow for getting a 2D browser-playable attack test from a narrow prompt before you commit to a heavier engine setup.
Godot
A good fit when you want AnimationPlayer timing, call method tracks, hitbox toggles, and compact 2D combat scenes.
Unity
Useful when animation events, hitbox activation, character controllers, and later production tooling are already part of the plan.
Phaser
Practical for browser-first combat tests where animation start, update, and complete events need to stay easy to inspect.
GDevelop
Useful when visible event sheets and timers help the team reason about attack wind-up, active damage, and recovery states.
Smarter AI Is the Wrong First Fix
When a combat prototype feels flat, the reflex is to add enemy intelligence. Make the enemy flank. Make it predict the player. Make it use cover. That can be useful later, but it is expensive noise if the basic attack is unreadable.
A readable enemy gives the player three pieces of information: the attack is coming, the danger area is knowable, and the punishment has ended. Those pieces can exist in animation frames, color shift, pose change, shadow, sound, or movement pause. Pick one clear signal first. Do not stack five signals until you know which one the player actually sees.
If the player cannot read the first swing, the enemy does not need a brain yet. It needs a warning.
Four Telegraph Variables Worth Testing
| Variable | What it tests | Bad sign |
|---|---|---|
| Wind-up length | How much time the player needs to notice and respond | Players understand the attack only after getting hit |
| Warning shape | Whether the danger area is visible before damage starts | Players dodge away from the enemy but still cannot tell where the hitbox was |
| Active hit window | How long damage is actually live | Players blame the collision because the hit lingers longer than the animation suggests |
| Recovery pause | Whether the player gets a fair chance to punish or reset space | The enemy chains attacks so quickly that every dodge feels like delay, not progress |
Build the Attack as a Timeline
Do not prompt the enemy as a personality. Prompt it as a timeline. For example: idle for 1 second, face the player, show a 0.45 second wind-up, enable the hitbox for 0.12 seconds, then recover for 0.5 seconds. That gives you parts you can test.
Chatforce fits the first pass when you need a prompt-to-game draft that someone can play in a browser quickly. Use it to test whether the telegraph idea reads at all. Move into Godot, Unity, or Phaser when the attack timing is promising and you need exact animation events, frame stepping, custom collision tools, or a production combat stack.
Weak Prompt vs Telegraph Test Prompt
| Goal | Weak prompt | Better prompt |
|---|---|---|
| Add an attack | Make the enemy attack the player | Create one enemy with a single cone attack. Show a visible cone for 0.45 seconds before damage starts. |
| Test timing | Make the enemy harder | Create three variants with wind-up times of 0.25, 0.45, and 0.65 seconds. Keep enemy speed and damage unchanged. |
| Test the hitbox | Fix the enemy collision | Draw the active hitbox only during the damage window. Log whether the player was hit during wind-up, active, or recovery. |
| Test recovery | Make combat feel better | After each attack, freeze the enemy for 0.5 seconds so the player can move through the safe space or punish. |
Run the Test at Normal Speed
Frame stepping helps you debug. It does not tell you whether the player can read the attack. The pass test happens at normal speed, with placeholder art, under the same camera and input rules the prototype already uses.
Watch the first three hits. If the player says "I saw it but moved late," tune input or wind-up. If they say "I did not know it was attacking," tune the warning pose. If they say "I was already out," tune hitbox duration or shape. Those are different fixes.
Lengthen wind-up
Players understand the danger after one hit but cannot respond in time.
Fast melee attacks, dash attacks, and early boss swipes.Change warning shape
Players know an attack is coming but cannot tell where to move.
Cone attacks, area slams, lane shots, and attacks that start off-screen.Shorten active frames
Players dodge the visible attack but still take damage late.
Melee arcs, lingering hazards, and prototypes with generous collision boxes.Add recovery
Players dodge correctly but never get a moment to act afterward.
Action games where a dodge should create a short advantage, not just avoid damage.Only Then Add Enemy Behavior
Once the attack reads, smarter AI becomes useful. Now a chase state can choose when to enter range. A patrol state can create positioning. A ranged state can test spacing. Without readable telegraphs, those systems mostly change how quickly the player meets an unfair hit.
Keep the rule strict for the next prompt: the AI can change pathing or attack selection, but it cannot change wind-up, hitbox shape, active window, recovery, player speed, or arena size. If behavior changes and timing changes at the same time, you have lost the comparison.
- Use one enemy and one attack until the warning is readable.
- Separate wind-up, active damage, and recovery in the implementation.
- Keep arena size, player speed, enemy speed, damage, and camera unchanged.
- Draw or log the hitbox during early test builds.
- Test at least three wind-up lengths before adding new enemy behavior.
- Ask the player why they were hit before you explain the attack.
Add smarter AI after the first attack teaches itself. Readable combat is a timing problem before it is an intelligence problem.
FAQ
What is an AI game prototype enemy telegraph readability test?
It is a small playable test that checks whether players can see one enemy attack coming, understand the danger area, avoid the active hit window, and recognize the recovery state.
How long should an enemy wind-up be in a first prototype?
Test a few values instead of guessing. For many simple 2D attacks, try 0.25, 0.45, and 0.65 seconds while keeping the arena, player speed, enemy speed, and damage unchanged.
Should I add behavior trees before telegraph timing works?
No. Add behavior trees after the basic attack is readable. Better decision logic will not fix a hit that players cannot see, parse, or punish.
Sources
- docs.godotengine.org/en/stable/tutorials/animation/animation_track_types.html
- docs.unity3d.com/6000.5/Documentation/Manual/AnimationEventsOnImportedClips.html
- docs.phaser.io/api-documentation/event/animations-events
- wiki.gdevelop.io/gdevelop5/all-features/timers-and-time
- chatforce.com/text-to-game
- chatforce.com/game-studio