Here’s a stronger way to explain it:
The issue is not that the community is “rejecting” AI artwork on principle. Nobody is saying you need permission to use it in your own project. You can use whatever workflow you want.
The warning is practical.
Generative image tools are very good at producing a picture that looks impressive at first glance. They are usually
bad at producing actual usable beat ’em up sprite assets.
OpenBOR sprites are not just random images. They need to obey a lot of technical rules:
- consistent character proportions from frame to frame
- stable costume details
- matching lighting and shading
- clean transparent backgrounds
- correct facing direction
- readable silhouettes
- predictable limb positions
- frames that animate smoothly
- correct sprite scale relative to enemies, stages, and hitboxes
- no melted hands, broken weapons, drifting faces, or changing designs
- clean separation between idle, walk, attack, pain, fall, rise, jump, and special animations
AI tools often fail at exactly those things.
A single generated image may look nice. A full sprite sheet needs
dozens or hundreds of frames that all look like the same character moving in a controlled way. That is where generative tools usually fall apart.
For example, frame 1 may have a red glove, frame 2 may have a black glove, frame 3 may have an extra belt, frame 4 may change the face, frame 5 may alter the boots, and frame 6 may shift the body size. The result may look acceptable as isolated artwork, but it becomes a nightmare once you try to animate it, align offsets, create attacks, place hitboxes, and make it feel good in-game.
That is why people are warning you.
The community is not saying “AI art is forbidden.” The concern is that you are building your game on assets that may become impossible to maintain once the prototype grows. You may get the first few screens running, but later you will need consistency, corrections, new poses, alternate attacks, damage frames, grabbed frames, weapon frames, palettes, enemy variations, and fixes. At that point, AI-generated sprites can create much more work than they save.
Same with using none.
Yes, the game may run right now. That does not mean the setup is correct. none is not a general-purpose solution. It is a specific command used for specific cases. Using it to bypass problems early can hide mistakes instead of solving them. Later, when you start adding real stages, enemies, attacks, animations, and transitions, those hidden mistakes can become much harder to debug.
So the advice is not:
“Do not use AI because we do not accept it.”
The advice is:
“Be careful, because AI can give you something that looks like progress while quietly creating technical debt.”
A prototype running is good. That means you are learning. Just do not mistake “it runs” for “the foundation is solid.” OpenBOR development gets much stricter once you move from a test build to a real playable game.
A safer approach would be:
Use AI only for rough concept art, mood boards, portraits, backgrounds, or inspiration. For actual gameplay sprites, either draw/edit them manually, use properly prepared sprite bases, commission sprite work, or learn a controlled workflow where you can guarantee consistency across every frame.
Generative tools can help, but they cannot replace the boring technical discipline that sprite-based games require. That discipline is what keeps the project from collapsing later.
