🖙Python Game Development: A New Hope
Recently-ish, I've encountered not one but two Python game development libraries/tools/frameworks that have caught my interest. This is noteworthy because historically I haven't been too impressed by the available tools for making games in Python, despite me liking the language. 1
The first is LiSE. It was on my radar for some time, but I had mistakenly thought of it as being mostly for life simulations, taken literally in the sense of games like SimEarth. It is for that, but it's also for a variety of other detailed simulations. It's rule-based, which is a paradigm for developing game logic I've liked to try for a while. It also has a time travel feature, allowing you to see the steps that led up to the current state. This seems hugely useful for debugging and exploring the consequences of different design decisions, particularly the intersection of different design decisions. The time travel feature also apparently handles save files for you, which would frankly be a nice thing to not have to worry about in a game with that much state.
It isn't a game engine, though, so there's not that much in the way of a graphics or sound API as far as I can tell. The README says "ELiDE is meant to support repurposing its widgets to build a rudimentary graphical interface for a game." That's a smart choice designwise2, although if you don't want to use that interface3 it means you have to pick from one of the frankly underwhelming options for Python. Still, it's a really cool idea so maybe I'll brave one of them.
LiSE can also act as a server, so in theory a game could be written in whatever framework or engine and then spawn the server that handles the logic. I don't think it's a bad idea to split logic from the other elements of a game, but having those two parts have to communicate over HTTP(S) might be a bit awkward. I think you'd also have to be careful about how much state is passed and how serialization is done to avoid blowing past the 16.667 ms deadline for a 60 FPS game. Also, I could see the server-spawning part being kinda annoying, but once I got it working reliably it would probably be fine?
The other is Pyxel. I just did a game jam in TIC-80, and I had a lot of fun. The limits really help during a game jam, and it was fun to play with pixel art for the first time. Pyxel is designed similarly, being inspired by TIC-80 and PICO-8. As much as I like Fennel (and I want to like Lua), some of Lua's weirdness and limits leak through, so I could see myself enjoying Pyxel even more. My impression is that it is not as oriented around a single "cartridge" file and has slightly larger limits for graphics but similar limits on audio. I could see these differences going either way, although I don't think they'll be make or break. The cartridges sometimes feel a little gimmicky and come at the expense of being able to organize your project into multiple files, but they're a fun kind of gimmicky and are a viable distribution method. Similarly, having more space to play with graphics could be fun or could take away some of the useful limitations.
I should clarify I have yet to either try these in practice, so this is mostly gleaned from reading the documentation and taking a (very shallow) look at some examles. I'm also writing from a hobbyist perspective, so I'm under no illusion that either of these mean Python will take the big budget or even indie game dev world by storm. (Although I guess renPy has kinda done that for another niche, so perhaps these could take a niche by storm.) It would be neat to see it succeed alongside Lua and JavaScript for hobbyist game dev, though.
I had a reasonably positive impression of renPy for what it is, but I haven't been that interested in making a visual novel.↩
the README lists Crusader Kings, Democracy, Dwarf Fortress, and The Sims as games in its definition of "life simulation." I think you'd be hard-pressed to design an engine that serves all of those well.↩
I added this based on a correction/clarification from Clayote. Thanks for the correction, Clayote! (And thanks for LiSE!)↩