To better understand how games were historically built, I set myself a challenge: recreate titles from different eras, as far as my patience and curiosity allow. Naturally, I began with Pong (1972)—the game that helped ignite the videogame industry and reshape how we viewed television technology. As highlighted in Discovery Channel’s “The History of Video Games,” the idea of a console generating its own signal, independent of broadcasting stations, was revolutionary.
Pong is mechanically simple: two paddles, one ball, and a scoring system triggered when the ball crosses a boundary. Later versions introduced CPU players and difficulty levels, but the essence remains a stripped-down sports abstraction.
Building Pong with LibGDX—using a language and framework I barely knew—was surprisingly painless. The Breakout tutorial provided a solid foundation, and mechanically both games are similar enough that a shared base system would be straightforward.
One thing that genuinely impressed me was how much a mature framework improves the development experience. LibGDX handled almost everything elegantly.
Creating a CPU opponent turned out to be more troublesome than expected. Either it was absurdly precise (ruining the challenge), or it jittered uncontrollably like it had a motor malfunction. The cause was simple: adding random noise every frame resulted in contradictory adjustments—+N on one tick, –M on the next—producing erratic movement. A proper fix would involve sampling noise at fixed intervals (every S seconds) instead of per frame, simulating realistic human error. Due to my inexperience, I didn’t fully implement this.
Since the CPU wasn’t viable, I shifted difficulty to shared mechanics: ball size and ball speed. I also added new modes:
Normal (1 ball)
Double (2 balls)
Crazy (3–8 randomized balls)
I couldn’t finish full input configuration in time, so controls default to WASD and Arrow Keys. It unintentionally resembles the old Flash multiplayer days. At least both players can’t trigger the same inputs simultaneously, which prevents some bugs.
A major self-inflicted issue was choosing ApplicationAdapter instead of Game. This created immediate friction when adding screens and broke physics normalization due to the absence of delta time. Movement became hardware-dependent: slow machines made the game easier; heavy multitasking created exploitable slow motion. Switching to Game fixed this and forced better structure, even if it exposed how much I still don’t know.
Migrating to a screen system introduced yet another restructuring step:
Main now loads MainScreen,
which calls GameScreen,
which finally uses the Pong class.
I also created a Settings class to centralize game modes and parameters. Defining and organizing these settings was one of the hardest parts, and I still feel there’s room for improvement.
Despite the hurdles—many caused by inexperience, some by Java/LibGDX design quirks—building Pong was genuinely satisfying. It taught me a lot about game structure, state management, input systems, physics normalization, and the pitfalls of poor architectural choices. I’m looking forward to tackling more complex games next.