Skip to content
Back to projects

Revisiting my first Python game to measure my progress

Revisiting one of my first Python programs to compare its initial structure with the development practices I have learned since.

Problem

This project comes from one of my first Python programs, developed before my computer science studies.

Several years after its creation, I decided to revisit the project to evaluate its structure with the knowledge I had gained since. The original version grouped most of the game logic into a structure poorly suited to evolution.

The goal of the refactor was therefore to turn this first project into a more readable, modular, and maintainable base while preserving the principle and identity of the original game.

Approach

I started by restructuring the project around an object-oriented architecture and separating the different responsibilities.

The main logic is orchestrated by the Game class, while the different features are distributed across several components:

Game
├── Snake
├── Apple
├── ScoreManager
├── SoundManager
└── AnimationManager

This refactor was accompanied by several functional improvements:

  • persistent high score saving
  • pause and resume system
  • progressive difficulty based on score
  • sound effects
  • animations on important events
  • ZQSD and arrow controls
  • executable generation with PyInstaller

Turtle remains responsible for rendering the game. Pygame is used only to play sound effects, while Pillow prepares some of the graphical assets used by Turtle.

Results

The refactor now separates game orchestration, the snake, apples, score, sound, and animations into distinct components.

A PyInstaller script generates an executable. Progressive levels, sound effects, and animations extend the original version.

Comparing the original version with the rewrite, the clearest difference is in the code's structure: separated responsibilities, an automated build, and a codebase that is simpler to evolve.

Limits

The choice of Turtle naturally limits the game's graphical possibilities and performance. However, this technology remains sufficient for the project scope and keeps the implementation simple and accessible.

The project also remains intentionally limited in features: the main goal was to work on software structure quality rather than building a complex game.

Next steps

Future improvements would focus mainly on strengthening reliability and enriching the project:

  • add automated tests on game logic, especially movement, collisions, and score management
  • document and further automate the build and distribution process
  • add new game modes or gameplay elements, such as obstacles or different difficulty levels