as far as i know, synthizer does not work on mack yet, but lucia should work.

@haily_merry, go read through Mason's framework thread. It's just Lucia with a few "enhancements" like a different menu. It suffers from poor encryption practices last time I checked so that is a thing to keep in mind when making your decision.
But honestly, and I'll probably get some backlash for this, don't use any of them. Seriously. Those frameworks are just wrappers for pygame and you'll have to fight with them if you want anything out of the ordinary. Most of them also make it difficult if not downright impossible to follow traditional game patterns (not that most would care for it, but still). The only one I'd even consider recommending is Earwax, though you should find its thread on here and read through posts 165-66 to see what you're in for before making a commitment. It's a lot.
I don't understand why we need a "framework" for game creation when its selling feature is simplifying stuff to key_pressed and key_down. I mean, sure, I've been in the realm of "I need this", but I cannot explain why. If you want to route events to a specific listener, you'll have to change the framework. If you want to preprocess events and filter out keys for your input, you'll have to change the framework. The only advantage I personally see is the sound wrapping bit, and even there Lucia fails because I didn't realize that you needed caching (I was new and honestly probably shouldn't have released the code), Earwax has few documentation on its sound support, and Mason's framework has a BGT-like names with some interesting decisions concerning slots and ids.

Or you can, you know, just not use a framework at all and just use a game engine that's been proven to work? I mean, there's a huge difference between, say, bevy or UE4, and the frameworks we've created here. UE4/Bevy/Unity/... actually add features that are actually useful in games. These frameworks... Don't really do that

@8, to my knowledge their accessibility hasn't changed. But write your own. At least then it ties in with what your trying to do and you don't have to dig into the frameworks guts just to get anything unusual out of it.

Perilous Marathon barely even used Lucia, actually. I think it used it for window creation and keyboard handling, and, that's about where it ended, it even used a custom menu class I believe.

Honestly? Pygame + sound_lib + accessible_output2 / tolk and you'll be just fine. You've got Americranian's sound_pool if you're new, even if it does have some issues with caching that Lucia may even have fixed by now, so you could just copy the sound pool out of there if you're really, really, really worried about that.

checking for key down events.
keys=pygame.key.get_pressed()
if keys[K_SPACE:
do something.
checking for key presses.
for event in pygame.event.get():
if event.type==KEYDOWN:
  if event.key==K_SPACE:
   do something.
You'll have to remember that keydown is key pressed, and get_pressed() is actually checking for keys that are currently being held every iteration of your loop. It's weird and confused the fuck out of me at first, but there you go. Been awhile since I've touched pygame, so this may be far from perfect, but hopefully it works.

you can even follow americranian's python guid on keyboard handling tutorial on articles room. there the article explains about how to do key presses and key downs using pygame it self. you can write a wrapper based on those info given in americranian's article

The problem with writing wrappers is that they have a serious potential to limit the way your code works. For example, writing key_pressed only offers *one* key without any KMOD stuff (Shift, Control, etc). You could include those, but what if you need to get input from the user now? You have to hook into the pygame events themselves, sort of defeating the purpose of your key_pressed. What if you want to route events to a specific listener? Wellp, you kind of can't now without writing a wrapper over a wrapper, which sort of defeats the point.
If you are confused as to why you'd even want to route events, I encourage you to look up stuff like the state pattern. That, or just browse through my post history, I provide a lot of examples of what not to do when working with states.
If you want to see state in action, I recommend looking up PyAge, written by Highjacker. I believe that he even posted a thread on here. A pity it doesn't get a lot of recognition, though that's because it doesn't offer so many bells and whistles, choosing to instead focus on flexibility rather than coding features for a specific subset of games.

here's the thing. Yes you *can* make one of these.  Unity is proof of that.  But it will itself be 20 or 30 times more complicated than any game anyone ever writes with it and it takes a full-time dev at least to keep it going.  It's technically possible but practically impossible.  I have written the first few hundred lines of my MMO thing and it's already specialized to my MMO thing even though it's just a generic compressed array thing for tilemaps (you'll hear moree about it after Synthizer 0.9 and when it gets a bit further along I plan a devblog of some sort but we'll see).  You have to write small libraries that handle one problem, be opinionated and write specifically for a specific sort of game, or have the kind of resources someone like unity has.  Every other attempt I've seen at this in audiogames land has failed, including mine.  You run into the complexity problem and then it snowballs and either you push through and end up with a giant mess or you realize that actually you can't do this so easily as it seems and stop.

Also w.r.t. Lucia, unless something changed, Amerikranian has said that the sound stuff is broken in the "every time you play the sounnd it re-reads it from disk" sense.  Which turned into literally blaming Python for being slow in at least one thread that I don't have the link to anymore.  I haven't code reviewed it.  I don't know how good or bad it is for sure.

Earwax got used in at least one game by Chris but Chris has moved onto Dart for a variety of reasons including that Dart makes accessible cross-platform mobile apps, and frankly if they get their desktop accessibility together (which they appear to be doing) I'll probably also head in that direction for the UI parts of the MMO thing (don't do as I do here: unless you're experienced multi-language projects are a nightmare).

@21
Yes, sadly, Earwax was a great idea, and I still like some if the ideas therein. Glad I got the whole decorator thing out of my system, but actually it turns out that you and others were right: Enforcing object inheritance is the right way to go for anything larger than Lucky 13.

Currently wrapping SDL in Dart. I know Rust has a wrapper already, but I'm not learning yet another language because my head's in danger of exploding, and they have a weird thing where you need .unwrap() after every call.

Anyways. I'm not sure how Dart + SDL | Flutter + Synthizer + Tolk will work out, but I have tentatively high hopes.