A running theme of this project is that 2D game development is like programming in Easy Mode. Everything takes less code, requires fewer steps, uses less CPU / memory, and has a larger margin for error. It’s amazing to be able to just make something without constantly getting snagged on annoying tech issues, performance trade-offs, and gameplay compromises.
Take collision detection, for example.
Early in the project I used rectangle-based collision. If I shot at a bad robot, the game would check for a collision between the bullet and the square region where it was drawing the enemy.
![]() |
| Okay, pixels don’t suffer zooming nearly as gracefully as polygons. Then again, you can fix this by just not letting the player zoom in too far. Good luck keeping the player from looking at the walls too closely in your FPS. |
But this is a crappy solution. Basically every enemy is shaped like a box for the purposes of collision. That’s good enough when shots hit center-mass, but it’s really unsatisfying to have bullets score a hit when they pass through the (usually empty) corners of the rectangle. Unless I’m going to make all the foes square, this isn’t a viable technique.
So I change it to check using distance calculations:
Continue reading 〉〉 “Project Good Robot 11: When Stuff Collides”
T w e n t y S i d e d


