PPong: Learning to Finish a Game

Starting Small on Purpose

I have a lot of game ideas.

The problem is that I have very little to no experience in game development, and no artistic skills. I can code, but I can’t draw, animate, or build the kind of large-scale projects I imagine yet.

At first, that felt limiting. Then I started thinking about the origins of video games.

The first games were not made by teams of artists and designers. They were often built by engineers and programmers experimenting with simple mechanics and technical limitations. If I wanted to eventually build more ambitious projects, I first needed to understand the fundamentals and, more importantly, learn how to finish something.

So I decided to deliberately start small.

That’s how PPong was born.

Why Pong?

A classic Pong is functional, but not very interesting today.

It’s one of the most recognizable games ever made, but also one of the most explored. Recreating it exactly would mostly teach me how to reproduce an existing system. It would be another Pong clone in the wild.

I wanted to add a twist, a mechanic that stayed simple while adding some strategic depth.

The first idea was adding a second ball. But even that felt more chaotic than interesting. The real idea came after:

• each player owns a ball
• only one ball is active at a time
• players can switch which ball is active

When a ball becomes inactive, it stays frozen in place. When the other one is activated, it inherits the speed and direction of the previous ball.

That single mechanic completely changed the game.

Players could now:

• prepare attacks in advance
• switch as a last resort defense
• leave a ball sleeping near the opponent’s goal
• create pressure by controlling timing instead of only reacting

The game was still understandable in seconds, but it introduced a layer of prediction and positioning that did not exist in traditional Pong.

Side note, the game originally was called PPoonngg, but it was too annoying to write so I kept PPong.

Designing Around the Switch Mechanic

The switch mechanic also introduced something I did not expect: it changed the pacing of the game.

In normal Pong, players only focus on the active ball. The main challenge comes from the speed of the ball that increases, and at some point it moves faster that the paddles, so a goal is unavoidable.

Here, both balls matter at all times:

• the active one can score, so an immediate threat
• the sleeping one represents a future threat

This forced players to think ahead.

I added the customization feature to put an emphasis on the ownership of one of the balls.

One interesting consequence was the cooldown system. After switching, players temporarily lose control of the switch mechanic until the opponent gives it back. Without that limitation, players could spam switches constantly and the game would become unreadable.

The cooldown turned the mechanic into a commitment instead of a reflex.

Simple systems often become more interesting when players cannot use them freely all the time.

Rebuilding the AI

The AI was one of the first real technical problems I encountered.

In classic Pong, the AI logic is extremely simple:

• follow the ball vertically
• adjust movement speed for difficulty

But PPong broke that logic completely.

The AI now needed to:

• understand which ball was dangerous
• decide when to switch
• choose between attacking and defending

I approached this incrementally instead of trying to build a “smart” AI immediately.

Tutorial Difficulty

• follows the active ball
• only switches defensively
• switches immediately when the ball enters a danger zone
• focuses on teaching the mechanic

Normal Difficulty

The normal AI introduces basic strategy:

• balanced between attack and defense
• switches defensively when needed, not instantly
• can switch offensively when an opportunity appears
• uses simple position checks to avoid unnecessary switches

Instead of instantly reacting to every threat, it evaluates alignment and ball positions before switching.

Hard Difficulty

The hard AI pushes this further:

• more aggressive timing
• faster paddle speed
• better anticipation
• opportunistic switching when the sleeping ball creates pressure

The important lesson here was that game AI does not need to be “realistic” or “intelligent.” It only needs to create interesting situations for the player.

Most of the work was not technical complexity, but tuning behavior until it felt fun to play. I am pretty sure that there are other strategies that other players could think about. I had to try to imagine what they would be, but I had to make a choice. Should I try to add new features, or should I take time to improve the AI ?

I chose to add features.

The Online Multiplayer Detour

I decided to experiment with online multiplayer.

The local multiplayer mode worked well, and playing against someone remotely sounded like the natural next step.

I used Mirror, a networking library for Unity, and started building a networked version of the game.

This taught me a lot:

• the difference between server and client logic
• synchronization issues
• authoritative game states
• Linux server builds
• how multiple versions of the same game effectively run simultaneously

I even managed to play a classic version of Pong remotely against my brother.

For a while, it felt like success.

But as the project grew, so did the problems.

Every fix introduced another issue:

• synchronization inconsistencies
• strange warnings
• duplicated logic
• edge cases I no longer fully understood

Eventually I realized something important: I was no longer building the game intentionally. I was patching quick fixes on top of previous quick fixes.

The project was escaping its original scope.

My father once gave me an analogy that perfectly describes this situation:

If you take a bicycle and add more wheels, a motor, and seats, you do not create a car. You create an uncomfortable bicycle.

That is exactly what PPong’s online mode was becoming, and so I stopped.

Not because online multiplayer was impossible, but because continuing would have transformed the project into something much larger than originally intended.

Learning to Define Scope

This was probably the most important lesson of the entire project.

I tend to have large ideas and ambitious systems in mind. But ambition without limits quickly turns into unfinished work.

PPong taught me that defining scope is not about limiting creativity. It is about protecting the project from uncontrolled growth.

At some point, you need to ask:

• what is the actual goal of this project?
• what am I trying to learn?
• what features genuinely improve the experience?

Online multiplayer stopped answering those questions.

Finishing the project became more valuable than endlessly expanding it.

That was a difficult decision, but probably the correct one.

Also, this project was a way to learn how to use tools like Unity. I have other projects, and spending too much time perfecting a Pong variation felt like a bad idea.

Mobile Accessibility

The last major addition to the project came from a very practical problem.

Whenever I wanted to show the game to friends, almost nobody had a computer available.

However everyone had a smartphone.

So I adapted PPong for mobile:

• touch controls to move the paddle
• mobile UI
• simplified input handling

I also made the decision to disable local multiplayer on mobile devices. Technically it was possible, but on a small screen it simply did not create a good experience.

This was another example of scope management:

• not every feature needs to exist on every platform
• accessibility sometimes matters more than feature completeness

The mobile version was not part of the original plan, but it made the game easier to share and easier to test with other people.

Finishing the Project

PPong is not a revolutionary game.

It is a small project, but a complete one, built to learn:

• game design
• AI behavior
• basic networking concepts
• scope management
• cross-platform adaptation

What matters most is not the features it contains, but the fact that it is finished.