For a solo developer, art production is often the largest constraint. I wanted to add a stone-giant boss to the game and initially tried generating it directly with a general image model similar to Midjourney. The result did not survive contact with the game. This note records the full route from that failure to a usable production process.
1. Recognizing the limit: general image generators do not produce game-ready pixel enemies
The first stone giant came from a general image model. In isolation it looked acceptable, but placed beside the game’s hand-drawn pixel enemies, the mismatch was immediate. The generated image used high resolution, fine detail, and soft edges; the game uses low resolution, block shapes, and hard pixel boundaries. Their pixel densities belonged to different visual systems.
This was not a prompt-writing problem but a limitation of the medium. The practical conclusion was direct: general image models are useful for concept and promotional images, not for the in-game pixel asset itself. A game-ready pixel enemy requires either an existing pixel asset or a pixel-specific tool. I chose PixelLab because it supports both pixel generation and animation.
2. Image generation: anchoring the result to the game
The decisive step was to provide an existing in-game enemy as the style reference. I used a purchased rock-spirit asset as the anchor. PixelLab could then follow its block density, palette, and outline treatment when producing the new giant, which made the result belong to the same visual family.
One counterintuitive lesson was to match density rather than dimensions. The game’s enemies are physically small assets—roughly sixty pixels of occupied content—then enlarged during rendering. Requesting the largest possible output therefore creates finer pixels and returns to the original high-resolution mismatch. A medium output size was more appropriate.
Failure modes during generation
- A reference pose can reproduce its defects: I asked the model to follow the concept image’s stance, but one leg was obscured behind rock in the reference. The generated version therefore omitted a leg. The correction was to use the reference for shape and design language, not for an exact pose.
- Color can leak through the shadow reference: I wanted black basalt and disabled palette copying, yet the result remained green because the copied shadow treatment carried the reference color with it. The correction was to state the material and color explicitly—
dark basalt / black rock—so the text constraint overruled the reference tint.
3. Animation: where most of the work begins
Producing one convincing frame was relatively simple. Converting it into coherent animation was not. The main failures were these:
- The wrong tool version imposed a frame limit: two similarly named versions were available. The “Pro” version was locked to four frames per generation, which was insufficient for a slow, heavy boss; the “NEW” version exposed a frame-count control that could reach sixteen. Tool selection determined whether the motion was feasible.
- Raised hands left the canvas: an overhead strike moved the hands beyond the image boundary and cut them off. The solution was to place the character lower on the canvas and reserve enough space above the head before generation.
- The largest failure was the model’s tendency to return to the starting pose. Text-to-animation models often assume a seamless loop. The first strike therefore became: raise the arms, pause for too long, then return to idle—without ever hitting the ground. An attack is not a loop; it should end in the impact pose. I rewrote the instruction around three explicit conditions: strike the ground in front of the body, finish crouched with both fists on the ground, and remain in that final pose without standing back up. Only then did the motion carry weight.
Several smaller constraints also mattered:
- Loop seams: symmetrical motions such as breathing can use a ping-pong order,
0→N→0. Directional walking cannot simply play backward; it must be regenerated as a complete step that returns to the starting state, or reduced to a smaller loopable interval. - Avoid body rotation in a 2D side view: wording such as “twist the waist and turn” may be interpreted as a full 3D rotation, destroying the side silhouette. Horizontal sweeps are especially difficult; vertical or forward attacks are more reliable.
- Automatic prompt enhancement can weaken attack instructions: it often reintroduces “turn around” and “return to the original pose,” both of which must be removed.
- A heavy enemy should not recoil too far: a stone giant should react to a hit with a compact, grounded contraction rather than a large backward movement.
4. Result: a giant that strikes, roars, and breaks apart
After these revisions, the set contained seven actions: idle, walk, overhead strike, charged spin, roar, hit reaction, and disintegration death. All seven remained block-based, dark, and consistent with the rest of the game’s pixel treatment.
I did not generate a new flame effect for the spinning area attack. An older purchased asset pack already contained a suitable dark flame ring. Recoloring it toward orange-red and layering the frames around the giant produced the required effect. Existing assets are part of the production system and should be reused when they already solve the problem.
5. Conclusion
AI-assisted pixel-boss production is workable under three conditions: use a tool designed for pixel assets rather than general image generation, anchor the output to the game’s own visual material, and expect substantial human-directed iteration. This giant went through nearly twenty revisions, each requiring a person to decide whether the result still belonged to the game.
The model supplies production capacity; the developer remains responsible for judgment. That division is the most accurate description of this solo-development workflow.