Mobile games, built in Python.
A structured lecture series that takes you from Python basics to a deployable Android game — covering Kivy, touch input, sprite logic, and packaging. Content is delivered online so you work on your own schedule without travel.
See the full programWhat the field actually looks like right now
Python's role in mobile game development has shifted significantly since Kivy matured. The toolchain that once required substantial platform-specific bridging now handles Android packaging through Buildozer with far less friction. The lectures reflect this — examples use current library versions, not tutorials written for Python 2 environments.
Each module references tools and patterns that appear in real production projects: event-driven input handling, texture atlases for sprite performance, and audio management that doesn't stall the main thread. These are not theoretical exercises.
What the program involves
Six lecture modules delivered asynchronously, with exercises after each one. The workload is honest — roughly seven to nine hours per week if you engage with the projects rather than just watching. A full breakdown of the curriculum, pacing, and access details lives on the program page.
- Python for game logic
- Kivy framework core
- Sprites and animation
- Touch and event input
- Audio and performance
- Android deployment
Lectures are pre-recorded. You watch and work at your own pace, with no fixed session times.
Designed to be completed in eight weeks at the suggested pace, though access extends beyond that.
The final project produces a packaged Android application built entirely during the course.
Three things most people wonder before enrolling
The people behind the lectures
Théodore has shipped four mobile titles using Python and Kivy, two of which reached over 30,000 downloads on Google Play. He spent several years in a small games studio before moving to independent work and teaching. His lectures focus on the decisions that actually affect whether a game runs well on a phone — not just whether the code is correct.
- Kivy architecture
- Performance profiling
- Android packaging
- Game loop design
Solène teaches the Python fundamentals module and the audio and asset management sessions. She has a background in scientific computing and transitioned into game development after contributing to open-source Kivy tooling. Her approach to explaining event-driven programming has been consistently noted by students as the clearest part of the curriculum.
- Python fundamentals
- Event handling
- Audio management
- Asset pipelines
Getting unstuck is part of the process
Every student hits a point where something stops working and the reason is not obvious. That is not a sign that the program is too hard — it is usually where the most durable learning happens. The support structure here is designed to help you work through those moments, not to hand you the answer immediately.
Instructors review submitted exercises and leave written feedback. A peer forum is available for discussion between students. For direct questions, email response typically comes within two working days.
How this is put together differently
One tool, done properly
The program covers Kivy specifically — not a survey of every Python game library. That focus means the lectures can go into the parts that matter for mobile: touch event propagation, texture memory, and the Buildozer packaging process. Breadth is traded for depth where it counts.
Built to accumulate, not just inform
Each module builds directly on the previous one. The sprite system introduced in module three is the same one used in the audio and performance sessions later. Students are not starting over with each topic — they are extending a single project through the entire program.
The hard parts are named
Android packaging is genuinely difficult. Kivy's documentation has gaps. These are acknowledged in the lectures rather than glossed over. When something is known to cause problems — Buildozer environment setup on Windows, for instance — the session addresses it directly with the current working approach.
Asynchronous by design, not by default
The lectures were written for asynchronous delivery from the start, not recorded versions of live sessions. That changes how explanations are structured — demonstrations are shorter, references to earlier material are explicit, and exercises are designed to work without a live instructor present.