Ping Pong 2D

Building a 2D Ping Pong Game

Most people start with 2D game development because it's the simplest form of real-time interactive programming. The math is straightforward, the scope is small, and you can ship a working prototype in a weekend. The catch is that the things that actually matter are rarely the first things beginners focus on. Here's how I'd approach building a clean 2D ping pong game if I were starting today, along with a few things that took me longer than they should have to figure out. The game loop runs at your target frame rate, typically 60 frames per second. Each frame does three things in order: process input, update game state, render to screen. Keep that order fixed. Swapping update and input order will make your controls feel sluggish without any obvious reason why. I spent about three days debugging input lag before realizing I was reading player input after the physics update instead of before it. For the ball, you need a position vector, a velocity vector, and a radius. That's all the state the ball carries. On each frame, add velocity to position. Check bounds by comparing the ball's position against the top and bottom walls and the left and right scoring zones. Collision detection with paddles uses axis-aligned bounding box overlap, which is the cheapest collision check available. You don't need circles for the paddles unless you're doing something fancy with curved surfaces.

Velocity should not be a fixed number per frame. Use pixels per second for your velocity values, then multiply by delta time when applying movement. If you move the ball by a fixed pixel amount regardless of frame rate, your game breaks on anything other than 60fps and you won't know why until someone tests it on a 144hz monitor and complains the ball is moving at three times the intended speed.

Collision resolution that doesn't suck

When the ball hits a paddle, you want the bounce angle to depend on where it struck the paddle, not just a simple reverse of horizontal velocity. Divide the paddle into sections. Center hit returns the ball straight. Edge hits angle it toward the corners. Map the impact point from the paddle's local space to a range between minus one and one, then use that value to adjust the vertical component of the ball's velocity. There's a specific edge case that catches everyone out. When the ball moves fast enough, it can pass completely through a paddle between frames. This is tunneling, and it happens more often than you'd expect once the ball speed exceeds roughly half the paddle width per frame. The fix is continuous collision detection using raycasting or swept sphere tests. For a simple ping pong game, you can also just clamp the ball position to the paddle surface when an overlap is detected and then reflect the velocity. It's not perfect but it works for most casual implementations and saves you from implementing GJK or SAT unless you actually need that level of precision.

Implementing the actual game mechanics

Start with a single paddle controlled by keyboard input. Arrow keys or WASD for vertical movement. Clamp the paddle position so it stays within the play area boundaries. Then add a second paddle. This can be AI-controlled initially. A basic AI tracks the ball's y position with some delay and a maximum movement speed. The delay makes it feel less robotic and gives human players a fighting chance. An AI that reacts instantly with no speed limit is unbeatable and boring. For scoring, the ball passing the left edge scores for player two and passing the right edge scores for player one. After a point is scored, reset the ball to center with a velocity directed toward the player who just lost the point. Add a short delay before the serve so players aren't surprised by immediate restarts. The ball speed should increase incrementally after each paddle hit. Start at a moderate base speed and add a small percentage with each rally exchange. This creates natural tension as points go back and forth. I found that capping the maximum speed at about three times the starting speed prevents the game from becoming unplayable. Beyond that, it's just twitch reflexes with no strategy involved.

Where this approach falls apart

This method works fine for a simple two-player local game or a casual single-player experience. It does not scale to networked multiplayer without significant changes. Synchronizing ball position across a network requires either authoritative server validation or client-side prediction with reconciliation. Running this logic on the client alone leads to Cheating and desynchronization issues that are painful to debug later. If you plan to make this multiplayer, set up the networking layer from day one rather than adding it as an afterthought. Another limitation is that this collision approach assumes rectangular paddles and circular balls. If you want spin physics or curved paddle surfaces, none of the simple AABB logic applies anymore. You'd need to switch to proper circle-circle or circle-ellipse collision detection with angular velocity calculations. That's a separate project entirely and increases the complexity substantially.

Getting the code running

You can implement this in any language with a graphics library. Python with Pygame is the most accessible option for beginners. JavaScript with the HTML5 canvas element works directly in a browser. Cwith Unity gives you a full engine environment but introduces a lot of overhead for what is essentially a simple game. The logic is identical across all of them. For a downloadable starting point, GitHub has numerous open source implementations of 2D ping pong games that you can clone and modify. Search for ping pong 2D open source on GitHub and filter by most stars to find well-maintained repos. Look for repositories that include a README with setup instructions and have recent commits. Older repos may use outdated APIs that won't compile on current systems. The actual source code for a minimal working version contains roughly three hundred to five hundred lines depending on the language and whether you include comments and spacing for readability. The core loop is maybe fifty lines. Everything else is input handling, collision math, rendering calls, and score management. Don't overcomplicate the architecture upfront. Get something working first, then refactor when you know what features you actually need.

Common mistakes to avoid

Don't pre-render all your assets into textures before runtime unless you have a specific performance reason. Loading spritesheet images and letting the graphics API handle batching is simpler and usually fast enough for a 2D game of this scale. Premature optimization here wastes time without measurable benefit. Don't use random numbers for ball direction after a serve. Players expect consistency. If the ball always launches at the same angle on serve, they can develop rhythm and strategy. Random serves feel cheap and unfair even when players don't consciously realize why. Don't skip sound. Even simple square wave beeps for paddle hits and wall bounces make the game feel significantly more responsive. Audio feedback is cheap to implement and has disproportionate impact on perceived quality. A silent ping pong game feels broken even when the physics are correct.