← Back to devlog

Art

From polygon to slime

For months Ascension's first enemy was a green hexagon with a red wedge. That is how its brain got built before its body, and how the body arrived afterwards: nine animations in eight directions.

On the left the green hexagon with its attack wedge and health bar; on the right the finished slime, at the same in-game scale
On the left the green hexagon with its attack wedge and health bar; on the right the finished slime, at the same in-game scale

This is the first enemy in the game: on the left as it was for months, on the right as it is now. Both at the same size:

On the left the green hexagon with its red attack wedge and health bar; on the right the finished slime, at the same scale

A green hexagon twenty-one pixels tall, a red wedge that appeared when it attacked, and a health bar of twenty-four by three. That was the slime. And it was not for lack of time to draw it: it was on purpose.

The brain first

An enemy’s job is not to look good. It is to be read: that you understand it has seen you, that you know a hit is coming before it lands, and that if it connects you can point at the moment you slipped.

None of that depends on the drawing. It depends on durations, distances and states. So the slime began as a state machine shaped like a polygon: it chases, winds up, attacks, recovers, gets stunned and takes hits. It spots the player at a hundred and eighteen pixels and its allies at a hundred and thirty-eight, which is how they warn each other.

With the hexagon on screen you can tune things that a nice drawing on top makes harder to see: whether the tell before the hit lasts long enough, whether the push on taking damage reads, whether two slimes get in each other’s way while circling you.

June · The concept

In parallel, the design. This is the base slime, drawn in mid-June:

Slime concept: translucent green body with internal bubbles, a highlight on top and a simple face of two eyes and a smile

A translucent body with bubbles inside, a highlight on top that gives it volume, and a face of two dots and a curve. Little, and enough: an enemy you are going to see hundreds of times cannot demand attention every time.

The full commission

From there came the order, and here is the difference between drawing a monster and producing one. It is not an image: it is nine animations in eight directions, nine frames each. Six hundred and forty-eight drawings for a single creature.

The nine: spawn, idle, walk, alert, attack, cast, take a hit, recover and die.

The walk, in all eight directions:

Review sheet of the walk cycle: eight rows, one per direction, with nine frames each

And those same seventy-two drawings, in motion:

The slime walking in all eight directions at once, animated

The attack is a body slam: it compresses, throws itself and lands.

The slime attacking in all eight directions at once, animated: it squashes, leaps forward and lands

What got thrown out

Three of the nine had to be redone.

Idle v01 came back with sparkles. An enemy that glitters while it waits looks like it is doing something; idle has to be the opposite of a tell.

Spawn v01 came out weak, with no weight. It was replaced by one built here, by hand, rather than ordering it again.

And cast v01 pushed the energy outside the body. Redone so the charge stays inside: if the effect leaves the outline, the player stops watching the enemy and watches the effect, and then never sees the hit coming.

And the death, the hardest one to order — the eight directions had to be commissioned separately and stitched together here — deflates into a puddle:

The slime dying, animated: it deflates until it is a low puddle

What producing it taught

Three rules that go in writing for the ones that follow:

  • One animation per batch. Asking for the eight directions of one movement at once works; asking for several movements at once does not.
  • Death cannot be ordered whole. Interpolating between the first and last frame only holds for one direction at a time, so the eight had to be ordered separately and stitched together here.
  • Ban detached effects in the order, and check anyway: if specks are left outside the body, keep only the largest blob and throw away the rest.

The body goes on top, without touching anything

The set was approved on 28 July. And what I like most about how it was mounted is that the hexagon was not deleted.

The code loads the animations if the file exists; if it does not, the polygon keeps working exactly as before. The collision, the hurtbox, the health and the knockback never find out: only the skin changes. Each state of the machine has its animation — winding up lights the alert, attacking lights the slam, recovering lights the recovery — and that is where the relationship between the two layers ends.

Which means that if tomorrow the slime needs a different body, you change the body. And that if something breaks in the art, the game is still playable with a coloured shape.

What I take from it

Separating the brain from the skin is not programmer elegance: it is what lets you have a playable enemy months before you have a good-looking one, and change either without breaking the other.

And there is a second reason for going this deep on this particular creature. The base slime is not an enemy: it is the template. The list of nine animations, the frames per direction and the mistakes already made carry over to the seventeen variants behind it — ice, fire, metal, winged — and to the other families in the bestiary.

The first monster costs triple. That is exactly why the next ones cost a third.

← Back to devlog