RPG Maker Worst Practices: Pixel Collisions.

Every now and then, someone asks about "pixel movement" and "pixel collisions." It's been happening ever since RPG Maker XP, and it just keeps happening, two decades later.

In fact, some of you old timers may remember this:

The reasoning goes that if the player is allowed to move pixel by pixel, then collisions should also account for every pixel. It has a seductive but destructive charm to it: paint your collisions pixel by pixel, and let the engine magically handle the rest.

Some even propose automating the process, and getting something like this to act as the collision body:

Ignoring for a moment the fact that something like that doesn't even make sense in the top-down perspective, surely you can see how that's wildly inefficient?

You're going to:

• Take the character's sprite sheet
• Take the tileset
• Compare every non-transparent pixel of the character against every non-transparent pixel of every tile in the vicinity
• Repeat the above every frame

All of that in one of the least optimized game engines in the history of videogames, because you don't want the player to walk through a virtual tree that was drawn one pixel too wide?

In that case, don't limit yourself to the player's collision. Apply pixel-perfect detection to everything. Doors? Why should a door open just because the player is vaguely near it? Make them line up their nose with the doorknob pixel. Chests? They should require the player's hand pixel to exactly overlap the lid pixel. NPC dialogue? They shouldn't just talk to you because you're in the same zip code. Make your players find the exact pixel where the NPC turns their head.

Because if the goal is to have a movement system that feels good, and a rewarding gameplay, it would be better to look at what the games with the cool movement systems and rewarding gameplays do.

There is such a thing as taking a bad idea too far.