Wow, thank you!! Most of the code (state machine, popups, juicy buttons, basic dialogue system) is assembled from bits I already had from other games and prototypes. I used AI for most of the procedural graphics and parts of the dialogue, so I can't take all the credit. But the fact that bare code is so easy to reuse and combine compared to game engine scripts is actually why I prefer not using an engine. I have a very soft spot for python too though, and was overjoyed that pygame suddenly was a viable jam option when I discovered pygbag for web exports!
Viewing post in Hire me (or not!!) jam comments
It's all about how you separate logic into small classes, you can look up "composition design pattern for game development", or "composition vs inheritance", there are a ton of great articles and videos out there. The core design I use for my game elements (a button, an enemy, a lamp on the desk, etc.. ), is they all have the following methods: Initialize, Draw, Update, Destroy.
For the state machine, I have a small game template project with a splash, title screen, and gameplay state (screen). Each state has a reference to the Game object, which contains all the settings and game data that is shared between states (basically the data that is saved, like hero stats, last position, etc). I'm not sure if this is the cleanest, but it works for my needs.
Hope that helps a bit!