Building a Dodgeball Game That Actually Works
I spent about three weeks building a browser-based Dodgeball Game in 2019, mostly because someone in my office pool challenged me to prove it was easy. It is not easy. It is straightforward, but there are specific problems that will eat your time if you do not account for them upfront. This is what I learned after breaking every edge case I could find. A dodgeball game loop is simpler than most people think. You have players represented as circles moving around a rectangle, three projectiles in play at any given time, and two rules: eliminate anyone a projectile hits, and when all players on one side are out, the other side wins. The trick is making it feel fair while running at 60 frames per second. I built mine in JavaScript using the Canvas API. You do not need a game engine unless you want sprites, sound, or a storefront build. A plain canvas loop with requestAnimationFrame gives you full control and keeps the file size under 40 kilobytes for everything including physics and rendering. That matters when you are trying to load something on a slow network in a school computer lab.
The movement system uses velocity vectors. Each player has a velocity on the x and y axes, and you apply friction each frame to bring them to rest. Friction value around 0.92 feels right for casual play. Higher and movement slides forever. Lower and the game feels like you are walking through mud.
Projectile Mechanics and the Edge Case Nobody Warns You About
Projectiles are the hardest part. Not because of collision detection, but because of the cooldown and ownership rules. In a proper dodgeball game, you cannot throw another ball until your current one is caught or hits a player. Tracking state properly prevents players from spamming throws and ruining the game in the first three seconds. I also ran into a specific collision detection problem that I did not see coming. When a projectile is moving fast, say at 12 pixels per frame, it can pass completely through a player's hitbox in a single frame. The collision check runs per frame, so if the projectile was at y=400 last frame and y=412 this frame, and the player is at y=405 with a radius of 8, the check would miss entirely. This is called tunneling and it is a real problem in simple 2D games. The workaround is not a complex continuous collision system. For a dodgeball game, you simply move the projectile in smaller sub-steps. Instead of one jump of 12 pixels, you break it into three sub-steps of 4 pixels each and check collision at each step. That alone fixed the issue for me without needing swept sphere tests or any advanced math.
Get the Full Details
Catch Logic and Ball Physics
When a player catches a ball, you remove that projectile and usually give the catcher a new one or award a point depending on your ruleset. I went with the standard rule: caught ball means the thrower is out and the catcher keeps their spot. Simple and clean. Bounce rules are optional but recommended. If a ball hits the wall before reaching a player, it should bounce off with the normal component of its velocity reversed. A wall bounce adds strategy because players can use walls to set up shots that would otherwise be impossible to throw directly. I found that limiting the number of allowed wall bounces per throw to two kept the game balanced. Beyond that, balls just kept bouncing around forever and nobody wanted to chase them.
Common Pitfalls When Building a Dodgeball Game
Here are the three things that will break your game if you ignore them. First, you need a reset sequence between rounds. Without it, the ball just sits in limbo after the last player is eliminated and nothing happens. A simple two-second pause followed by a full position reset and three new balls thrown from opposite sides handles this cleanly. Second, input handling for multiple players on one keyboard requires checking key states rather than key events. If you use keydown events, a player holding down W might fire three throw commands while moving. Key state polling each frame solves this. I used a simple object tracking pressed keys, then read from it in the game loop instead of listening to event listeners for movement decisions.
Third, collision detection order matters more than people admit. If you check projectile-player collisions before player-player collisions, you can get weird states where two players overlap inside each other and balls pass through the overlapping space incorrectly. Check player-player collision resolution first, then run projectile checks. This kept the hit registration consistent across all my tests.
Dodgeball Game Implementation Notes
The code structure I settled on has four main components: a player controller, a projectile manager, a collision system, and a game state handler. Keeping these separate makes debugging significantly faster. When something breaks, you know exactly which component to look at instead of searching through a thousand-line monolith. For the render side, I drew everything with basic arc and line functions. No textures needed. Player circles in different colors, projectile circles slightly smaller, a center line, and score text at the top. That is all a functional dodgeball game requires visually. Adding anything else is decoration, not necessity. If you want to deploy this anywhere, a static file host works fine. Cloudflare Pages, GitHub Pages, even an internal web server in a school network. The whole project ran on a single HTML file with embedded JavaScript and CSS at about 6,000 lines including comments and formatting. Not huge, but detailed enough that another person could pick it up and extend it.
There are tradeoffs to accepting. A canvas-based approach like this does not scale well to more than four simultaneous players on one keyboard. If you need more, you would want to move to a game framework or at minimum add gamepad input support. The collision system also does not handle rotation-based shapes, only circles, which is appropriate for dodgeball but limits future feature expansion unless you redesign the physics layer.
