A natural way to think about an enemy is to ask how smart it is. That makes sense. An enemy exists to challenge the player's character, pressure him, and test his abilities in the game. So we quickly ask familiar questions.
How does it chase the player? How does it choose an attack? How does it flank, hide, predict, react, and adapt? Those questions matter, but they are not the first questions I ask when I prototype an enemy.
The first question is simpler:
What is the toy?
And right after that:
What is the main threat?
An enemy is not only an obstacle. It is not only damage with a body. It is not only a state machine pretending to be alive.
A good enemy is an interactive toy that happens to oppose the player.
The player should be able to read it, test it, feel it, predict it, fear it, manipulate it, defeat it, and sometimes even turn it into a tool.
Do not prototype smart first
Smart enemies are not automatically good enemies.
A very intelligent enemy can be unreadable. It can track too aggressively, change behavior too often, cancel its own tells, punish experimentation, and make the player feel cheated instead of challenged.
A simple enemy, on the other hand, can create deep gameplay if the interaction is clear.
A walking creature can teach timing. A shell can become a weapon. A projectile can become spatial pressure. A jumping hazard can become rhythm. A charging creature can become a test of anticipation.
The enemy does not need to be complex to be rich. It needs to be playable as a toy.
If this toy can work with another toy in a combinatory way, even better. It can become a chain of possibilities.
Before asking how intelligent an enemy should be, ask what pleasure, pressure, and feedback it creates.
One enemy, one dominant verb
The fastest way to clarify an enemy prototype is to give it one dominant verb.
Not a list of abilities.
One main verb.
It chases.
It blocks.
It jumps.
It charges.
It shoots.
It hides.
It explodes.
It pushes.
It pulls.
It transforms.
It patrols.
It redirects.
An enemy can do multiple things, of course. It can even have a set of actions. But one action needs to be predominant.
The dominant verb is the center of the enemy’s identity. It tells you what the player will mainly do around it.
If the enemy charges, the player reads direction, waits for commitment, dodges, then counters.
If the enemy shoots, the player reads cadence, spacing, line of fire, and safe windows.
If the enemy blocks, the player reads obstruction, vulnerability, angle, and timing.
If the enemy transforms, the player reads before and after.
When an enemy has too many verbs too early, the player cannot build a clean mental model. The creature becomes behavior noise.
A strong enemy can become complex later, but its first readable identity should be simple.
The body should explain the behavior
An enemy’s body is not decoration.
The body should help explain what the enemy does.
A charging enemy should look like it can carry force.
A jumping enemy should look compressed, elastic, or leg-driven.
A shooting enemy should expose direction, barrel, mouth, arm, eye, or focus.
A blocking enemy should show mass, width, shield, shell, or rooted posture.
A fragile enemy should look fragile before it breaks.
A dangerous enemy should communicate danger before contact.
The player should not need a tutorial to understand the first hypothesis.
They should look at the creature and think: I probably know what this thing wants to do.
That hypothesis does not need to be complete. In fact, a small twist is often good. But the first reading must be strong enough to invite play.
Prototype the readable loop
A good enemy does not need a large state machine in the first prototype.
It needs readable states.
I like to start with this structure:
> Exist
-> Notice
-> Prepare
-> Act
-> Impact / Result
-> Recover
-> Exit / Back / Return
This is not a programming law. It is a prototyping lens.
Do not build a giant behavior tree to discover the core. Prototype the smallest readable loop first. Then, if the toy is alive, increase the complexity.
This structure forces the enemy to become readable as a sequence of moments.
The enemy is present in the world.
It may idle, patrol, breathe, blink, sleep, wait, float, hide, guard, or loop through a simple environmental behavior.
This state establishes life and baseline expectation.
The player sees the enemy before the enemy becomes a problem.
Silhouette, posture, and idle behavior should already give a clue about it.
The enemy becomes aware, activated, aligned, or relevant.
It may face the player, raise its head, change posture, pause, look, aim, or shift rhythm.
Notice tells the player: something has started.
Without Notice, the enemy can feel unfair because danger appears without a readable relationship.
Prepare is the telegraph.
The enemy winds up, crouches, charges, opens, inhales, aims, flashes, locks direction, bends backward, raises a weapon, or builds energy.
This is one of the most important states in enemy prototyping.
Prepare is where fairness is born.
The player should understand what kind of danger is coming, when it may happen, and what direction it will probably take.
Act is the danger.
The enemy jumps, shoots, bites, lunges, explodes, drops, blocks, swings, pushes, pulls, summons, or moves through the space.
This is the moment of pressure.
The cleaner the Prepare state, the more intense the Act state can be.
If the warning is clear, the action can be strong.
The action resolves.
The enemy hits, misses, lands, bounces, breaks, collides, passes through, creates a hazard, changes the terrain, or triggers a reaction.
Impact is not only damage.
Impact is consequence.
The player needs to understand what happened because of the action.
Recover is the fairness window.
The enemy pauses, cools down, lands, shakes, gets stuck, opens vulnerability, reorients, reloads, retracts, or becomes temporarily safe.
Without recovery, pressure becomes oppression.
With recovery, pressure becomes rhythm.
Recover is often where the player’s counterplay lives.
The enemy either leaves the loop or returns to it.
It may die, disappear, transform, become captured, become a tool, return to patrol, return to its initial position, rebuild posture, or reset the encounter.
This final state defines whether the enemy is disposable, cyclical, systemic, or transformational.
The enemy is not readable because it has states. It is readable because the transitions between states say something to the player.
Prepare is more important than surprise
Surprise is powerful, but it is dangerous.
If the enemy hurts the player before the player can form a fair expectation, the surprise becomes distrust.
Readable enemies can still surprise the player. But the surprise should usually come from context, combination, variation, or escalation, not from hiding the basic danger.
A first encounter should teach.
A later encounter can twist.
This distinction is crucial.
The first time the player sees an enemy, the prototype should help them build a mental model. Later, the game can ask them to use that model under pressure.
This is why anticipation matters so much.
Anticipation does not make enemies weaker. It makes enemies playable.
Recovery creates rhythm
A strong action needs a clear recovery.
If an enemy attacks forever, tracks forever, shoots forever, or instantly chains into the next threat, the player loses the feeling of rhythm.
They may still survive, but survival becomes noise.
Recovery gives the player a beat.
Read.
Prepare.
Dodge.
Counter.
Breathe.
Repeat.
That rhythm is what turns danger into a learnable pattern.
The player can improve because the enemy gives them something stable to understand.
This does not mean every enemy should be slow. Fast enemies can have rhythm too. The recovery may be short, but it must be readable enough for the player to feel the structure.
Many enemies attack space, not the player
A strong enemy does not need to be a direct damage dealer.
Sometimes the best enemy changes what space means.
It blocks a route.
It controls a platform.
It forces timing.
It pushes the player away from safety.
It occupies a traversal line.
It creates a temporary unsafe zone.
It changes visibility.
It makes the player rethink distance, height, exposure, or commitment.
This is a powerful prototyping question:
How does this enemy change the player’s relationship with space?
A projectile is not only an object that hurts. It can be a moving wall.
A wind enemy is not only an attacker. It can be a spatial modifier.
A lava hazard is not only damage. It can be a rhythm printed into the level.
When I prototype an enemy this way, I stop asking only how the enemy attacks. I ask what new spatial rule appears because this enemy exists.
Constraint can make movement better
Freedom is not always better.
A completely free enemy can become harder to read, harder to predict, and harder to enjoy.
Constraints often make enemies more playable.
A chained enemy has readable range.
A projectile with committed direction creates timing.
A patroller with a stable route creates planning.
A jumper with a clear arc creates anticipation.
A turret with a visible facing direction creates spatial logic.
A rail-based enemy creates speed without chaos.
In enemy prototyping, constraint is not a limitation by default. It can be the feature that makes the toy understandable.
The useful question is not: how much freedom can this enemy have?
Collision is character design
Collision is often treated as implementation.
It should also be treated as personality.
What does it feel like to touch this enemy?
Soft?
Heavy?
Sharp?
Elastic?
Sticky?
Explosive?
Mechanical?
Fragile?
Alive?
A stomp that squashes an enemy does not only remove danger. It says something about the creature’s body and the player’s success.
A recoil does not only move an object backward. It communicates force.
A bounce does not only redirect velocity. It communicates elasticity.
A shell does not only slide. It becomes a new relationship between the player, enemy, and level.
The contact tells the player what the enemy is.
The useful question is: what constraint makes this enemy readable, charming, and learnable?
The enemy should have an emotional job
Every enemy should have a mechanical role.
But it should also have an emotional role.
It can create tension.
It can create comedy.
It can create urgency.
It can create intimidation.
It can create curiosity.
It can create relief.
It can create mastery.
It can create mischief.
This emotional role changes prototyping decisions.
A funny enemy can be dangerous but still approachable.
A scary enemy can use sound, posture, and distance to build dread before contact.
A precision enemy can make the player feel clever when they understand the timing.
A chaotic enemy can create laughter if the cost of failure is low enough.
The emotional job helps decide the enemy’s silhouette, animation, timing, sound, recovery, and placement.
Do not prototype only what the enemy does.
Prototype what the enemy makes the player feel.
Before mastery: threat. After mastery: tool.
Some of the best enemies have two lives.
Before mastery, they are threats.
After mastery, they become tools.
The player first fears the enemy, then understands it, then uses it.
This is a very strong emotional progression.
A shell can become a weapon.
A projectile can become transportation.
A heavy enemy can become a pressure tool.
A flying enemy can become a movement form.
A perception enemy can reveal hidden information.
A cannon enemy can become player-owned power.\
When prototyping this kind of enemy, the AI version should teach the player version.
Before the player controls the mechanic, the enemy should demonstrate it in the world.
The enemy silently answers:
What can this form do?
Why is it useful?
Where does it belong?
If the enemy demonstration is weak, the player-owned version will feel arbitrary.
Let the environment invent part of the enemy
Theme should not be decoration only.
A good enemy often feels like the world expressing itself.
Lava can become timing.
Wind can become displacement.
Water can become propulsion.
Electricity can become rails.
Poison can become area denial.
Sand or stone can become weight.
Plants can become extension, growth, grabbing, or rhythm.
When I prototype an enemy, I like to ask:
What mechanical behavior naturally belongs to this environment?
This prevents the enemy from feeling imported. The enemy starts to feel native to the world.
It does not only live in the level.
It expresses the level.
Simple behavior, rich placement
If an enemy needs too much intelligence to become interesting, the enemy may not be the real source of depth.
Sometimes the level should do the work.
A simple projectile becomes interesting when placed across a narrow bridge.
A simple jumper becomes interesting near moving platforms.
A simple patroller becomes interesting when the player needs to carry something.
A simple charger becomes interesting when the arena has fragile walls.
A simple flying hazard becomes interesting when its rhythm crosses another rhythm.
The enemy does not need to contain every idea inside itself.
A strong enemy is portable. It can create different situations when placed in different spaces.
This is why enemy prototyping and level prototyping cannot be separated.
The enemy is a behavior.
The level is the sentence that gives the behavior meaning.
Teach the enemy like a mechanic
An enemy has a learning flow.
Do not prototype only its behavior. Prototype how the player meets it.
A useful progression is:
Show the enemy safely.
Let the player observe its loop.
Ask for one simple interaction.
Add terrain.
Add timing pressure.
Combine it with another element.
Reuse it later with one twist.
This gives the enemy time to become part of the player’s vocabulary.
The first encounter should not test everything.
The first encounter should make the player say: I understand the basic idea.
Then the game can build.
Variants should change one axis
Enemy variants are tempting.
Make it faster. Make it bigger. Make it shoot. Make it fly. Make it explode. Make it split. Make it invisible.
This is how variants lose identity.
A better rule is to change one major axis at a time.
Change the speed.
Or the terrain.
Or the timing.
Or the vulnerability window.
Or the attack range.
Or the movement surface.
Or the emotional tone.
Or the transformation result.
One clear change lets the player preserve the old model while learning the new condition.
The player thinks: I know this enemy, but now it behaves differently because of this one thing.
That is a powerful form of novelty.
Defeat should be readable
A good enemy should clearly communicate when the player has won.
Do not let defeat be only a hidden health subtraction.
The enemy should change state.
Squash.
Break.
Recoil.
Drop.
Transform.
Lose armor.
Open vulnerability.
Become harmless.
Become useful.
Disappear after the feedback has landed.
The player needs to understand why they won, not only that the enemy is gone.
Readable victory turns combat into learning.
The best enemies create mini-stories
A good enemy interaction often has a tiny narrative arc.
I see it.
It notices me.
It prepares.
It attacks.
I dodge.
It recovers.
I counter.
It transforms, disappears, or returns.
That story may last three seconds.
But if the states are readable, the player feels the sequence.
This is why enemies can become memorable even when they are mechanically simple. They create small moments with a beginning, middle, and end.
A practical enemy prototyping checklist
When prototyping an enemy, I would start with these questions.
Identity
What is the enemy’s dominant verb?
What is the enemy’s main threat?
What is its emotional role?
What physical feature explains what it does?
Can the player understand its silhouette quickly?
Readability
Can the player read intention before danger?
Is the direction of danger clear?
Is the timing learnable?
Is the recovery visible?
Does the player understand why they failed?\
State machine
What is the Exist state?
What is the Notice state?
What is the Prepare state?
What is the Act state?
What is the Impact or Result state?
What is the Recover state?
What is the Exit or Return state?
Toy value
What is fun to manipulate?
Can the enemy become a tool?
Can the player master it?
Does it change the player’s relationship with space?
Does it create mini-stories?
Level design
What is the safest first introduction?
What terrain makes it interesting?
What later variation refreshes it?
What other mechanic combines well with it?
What reward confirms mastery?
Prototype test
Does the enemy work with almost no explanation?
Can players describe what it does after seeing it once?
Do players blame themselves when they fail, or do they blame the enemy?
Do players want to try again?
Does the enemy create new situations when placed somewhere else?
Closing thought
Enemies are toys before they are AI.
This does not mean enemies should be stupid.
It means their intelligence should serve the interaction, not replace it.
The enemy should be readable enough to trust, expressive enough to remember, dangerous enough to matter, fair enough to master, and playful enough to manipulate.
A good enemy does not only oppose the player.
It teaches the player how to play with the world.