Pong

A Modular Pong Application Built on a Reusable C++ Engine

Pong is a complete C++ game application built using Engine Interface and the SFML Engine Backend. Rather than implementing rendering, input, audio and resource management directly within the game, it consumes these systems through the reusable engine architecture.

Developed as the application layer of the wider project, Pong demonstrates how modular gameplay systems, artificial intelligence, collision handling and state-driven application flow can be composed above a backend-agnostic engine foundation.

---

The Engineering Problem

Although Pong is mechanically simple, a tightly coupled implementation can quickly combine gameplay rules, rendering, input, collision handling, scoring and application flow within the same classes.

The challenge was to create a complete game while preserving clear boundaries between reusable engine functionality and Pong-specific behaviour, ensuring that the application remained modular, maintainable and capable of supporting additional game modes and features.

My Role

I designed and implemented the complete Pong application, developing the gameplay objects, application states, scenes, collision behaviour, match systems and artificial intelligence that operate above the Engine Interface and SFML Engine Backend projects.

The project demonstrates the practical use of a layered engine architecture, with an emphasis on gameplay system design, separation of concerns, state-driven flow and reusable application components.

Gameplay Demonstration

Architecture Overview

Pong forms the application layer of the wider architecture, using the services provided by the SFML Engine Backend through contracts defined by Engine Interface.

Each subsystem focuses on a specific gameplay responsibility. Application states manage the overall flow, scenes organise active game environments, and focused gameplay systems control physics, scoring, artificial intelligence and collision responses.

Core Gameplay Systems

The application is organised into three focused areas that combine reusable engine services with Pong-specific behaviour. Each area maintains clear ownership of its responsibilities while contributing to the complete gameplay experience.

Together, these systems create a complete game application while preserving the architectural separation between gameplay logic, reusable engine services and backend implementation.

Engineering Principles

Principles	Application
Separation of Concerns	Application flow, gameplay rules, artificial intelligence, physics, collisions and rendering integration are divided into focused systems with distinct responsibilities.
Single Responsibility	Classes such as MatchCtrl, BallPhysics, PongCollisionManager and GameStateEvaluator each manage a specific area of game behaviour.
Dependency Inversion	Pong depends on reusable engine contracts rather than directly controlling SFML systems, reducing coupling between gameplay code and backend implementation.
Composition Over Monolithic Design	Gameplay behaviour is assembled from states, scenes, objects, controllers and utility systems instead of being concentrated within one central game class.
State-Driven Architecture	Title, loading, menu, gameplay, pause and debug behaviour are represented by independent application states with controlled transitions.
Reusable Behaviour	Human and automated players share common paddle behaviour, while reusable physics and match systems support multiple game modes.
Data-Driven Configuration	Difficulty settings and gameplay modes centralise behavioural values, allowing game balance to change without restructuring core systems.
Extensibility	The architecture supports additional courts, game modes, AI behaviours and gameplay features without requiring major changes to existing engine layers.
Clear Ownership	Each system owns the data and behaviour associated with its role, making interactions easier to understand, test and maintain.
Layered Architecture	Pong operates as the application layer above the SFML Engine Backend and Engine Interface, preserving clear boundaries between gameplay, engine services and backend technology.

Key Design Decisions

Application-Level Separation

Pong-specific behaviour remains within the application project, while rendering, input, audio, resources and shared framework systems remain within the reusable engine layers.

State-Driven Application Flow

Title screens, loading, menus, gameplay, pausing and debugging are implemented as independent states, preventing unrelated application behaviour from accumulating inside a single game loop.

Focused Gameplay Components

Ball physics, match control, scoring, collision handling and artificial intelligence are implemented as dedicated systems with clearly defined responsibilities.

Shared Player Behaviour

Human-controlled and automated paddles build on the same player implementation, allowing both to participate consistently in movement, collision and ball-interaction systems.

Technologies

Engineering Outcome

Pong demonstrates how a complete game can be developed above a reusable and backend-agnostic C++ engine architecture. By keeping gameplay rules separate from framework and backend systems, the project supports clean application flow, focused gameplay components and future extension while validating the Engine Interface and SFML Engine Backend through a practical application.

Application Gallery

Repository

Explore the source code to see how the architectural principles are implemented throughout the framework.

Engineering Review

Read the accompanying architecture review for a detailed discussion of the design decisions, implementation strategy and engineering trade-offs behind the project.