The primary milestone of this development cycle was transforming a loose, functional prototype into a structured, scalable application using Object-Oriented Programming (OOP). By encapsulating all game states—such as scores, velocities, and tracking arrays—inside a master FlappyBirdGame class, the architecture became self-contained, eliminating the risk of global variable pollution. A critical part of this refactoring involved dismantling the splintered, independent. after () loops that separately ran gravity, pipe movement, and scoring. These were consolidated into a single unified game_loop running at approximately 60 frames per second (~16ms). This master clock synchronizes all physics updates and collision checks simultaneously, removing the erratic micro-stutters from the previous version and delivering a noticeably smoother gameplay experience. In addition to structural overhaul, several game-breaking bugs and interface oversights were resolved. The disruptive terminal-based color input was entirely removed, replaced by an integrated canvas menu featuring clickable native tk.Frame buttons for interactive background selection. To fix an instant-death bug where the bird would plunge into the ground the millisecond the game started, an initial upward velocity pulse (FLAP_STRENGTH) was injected straight into the start sequence, giving the player immediate buoyancy and reaction time. Critical syntax errors were also squashed, including a casing typo that turned tk.Frame into an invalid lowercase property, and a keybind mismatch that wrongly mapped the “P” key to a non-existent method instead of the intended toggle_pause function.Finally, core mechanics were tuned to match genuine arcade standards. The superficial timer-based score keeper was abandoned; instead, pipes are now generated with unique geometric tags so that points are only awarded when the bird’s trailing horizontal boundary completely clears the obstacle. A ceiling boundary collision check (b_y1 <= 0) was added to close a loophole where players could fly off-screen to bypass pipes entirely. To keep the gameplay loop engaging, a difficulty scaling mechanic was implemented to speed up the incoming pipes by 1.5 pixels every 3 points, while a session-wide high score counter was added to track and display the player’s best run. The iteration concludes with a polished game loop, stable crash boundaries, and a foundation ready for external asset implementation.