It's been a while since I last posted here, but I came back just for a moment to tell you about my library. Ever since I started my work on the µGame console, I had my game library working both in MicroPython and CircuitPython, but since CircuitPython was better for beginners, I went with that — the library is merged in the CircuitPython repository and ships by default on Adafruit's PyGamer and PyBadge boards (there is a learn guide, if you are interested, at https://learn.adafruit.com/circuitpytho ... cing-balls). But if you wanted to use it with MicroPython, you would have to go to my fork of it, find the right branch, rebase it against master and compile by yourself. That is a lot of work, and no wonder that only a few people have ever attempted it, and even fewer succeeded.
However, recently MicroPython has introduced a crude way of "packaging" third party extensions (http://docs.micropython.org/en/latest/d ... dules.html), so I took some time to change my library and make it compatible with that. You can find it at https://github.com/python-ugame/micropython-stage together with the support files for an ESP8266 board with a buttons shield and ST7735 display, and an M5Stack board with a game "face" add-on. Those files can be used as a starting point for adding support for your own boards.
A few words about what the library does. It's split in three parts: a small module called "_stage" written C that does the time-sensitive task of rendering and sending the pixels to the screen, a "stage" python module that has all the classes and functions for creating and controlling sprites and tile maps, and a "ugame" python module that handles initialization of the display, buttons, sound etc. Normally, the "ugame" module is specific to the board you are using (it's called "ugame", because it was originally written for my home-brew game console µGame), and the other two parts stay the same. The library itself provides you with "banks", which are sets of 16 images 16x16 each, with a 16-color palette and 1-bit transparency, which you can then use on "grids" of tiles or as free-moving "sprites". In typical use, you would have one or more layers of grids representing the world of your game, and several sprites representing the player character, enemies, NPCs, missiles, explosions, etc. The grids can also represent elements of the user interface, and there is a special kind of grid that displays text. It's designed that way so that all the pixels can be computed on the fly while rendering, without having to keep them all in memory (which is very limited on microcontrollers), and to be able to only update the parts of the screen that actually changed.
Below you can see one of my games, Vacuum Invaders, played on an M5Stack:
![Image](https://cdn.hackaday.io/images/original/8989641564692013055.gif)
More information about the library: https://hackaday.io/project/80626-stage ... ite-engine