python will be more than ok to handle this, And also, Switching from bgt to python is easy, At the least, Compaired to other languages like the c languages, And you also have lucia which has too many concepts taken from bgt, Although it's maybe a bit of broken, But it works, And about the compiled size, You can avoid this by just using a virtual invirement, Sorry broken spelling, But you get the meaning, And that way, You install all your stuff via pip and when you compile to exe theprogram will just use what you installed in the virtual invirement, And avoid stuff you installed for other projects for example.

do not use python if you can help it, you need a lot of work to get the game fast enough to play, doesn't mean python is slow but  to make it fast enough to be playable you need a lot of work

many peapol  online advice to not use threading or   processing  for some reason though

@Meatbag please stop going around telling new programmers that python is slow. python is plenty fast for a project like this. I'm not even a huge fan of python for application development, but I know for a fact that it can handle 90% of audio games out there, including this idea.

others have tried to point out to you that python isn't the problem, but rather the algorithms and data structures used. if you don't use them well, then your program will be slow even if you programmed it with raw assembly, let alone C/C++.

I don't want this to sound mean. I think you are probably very young, so it isn't your fault you don't know much about reasoning about space and time complexity in programs. however, you don't understand that the language/runtime isn't the problem when developing an audiogame like this, it is that you don't know how to write performant code. going around posting don't use python because it is slow, when others have pointed out to you multiple times that it is not the isssue is really unhelpful to other new programmers

I really thought the collision tutorial from a while back proved the point.  Apparently not.  Sigh.

Threads are bad because if you use threads and you're even remotely new to programming, you've just taken your one problem, namely it being slow, and added a second one, namely being buggy.  It took me something like 2 or 3 years to be competent at using threads and, at work, we've got a bunch of threading experts and the code reviews for threading stuff are always the most painful regardless of who wrote it. Just don't.  Learn how to not write slow algorithms first.

@12
Google deadlocks for an example of what happens if you get it wrong.  Getting them right is very situation specific.

The easiest way to use threads is when they don't share any state.  So for example if you're fetching a bunch of web pages you might do one thread per web page.  And in fact you can even find libraries that will make it easy, for example the Python multiprocessing module, which lets you do something alongb the lines of this:

def process_webpage(url):
    # ... stuff
    return result

processed = multiprocessing_pool.map(process_webpage, url_list_here)

That's not exact because these days I primarily do C and Rust, but it's along the lines of how things go.

The problem is that there's a ton of overhead to starting up something like that, enough that if the work you're doing isn't like 10-20 ms per work unit then you're wasting time.  But more to the point the safe/easy approaches like that don't work for games because every thread is going to want to touch the whole game all at once.  It requires a good bit of originality to rearrange your algorithms to be friendly to threads.

But then you run into the fact that on a 2 core laptop running the OS and NVDA you don't get more than one core anyway, which means even if you use threads they're not running in parallel, they're just taking turns.  So even if you do get it working, the people who benefit from it are the people who don't need it because they've got a powerful computer, and if you rely on it instead of making fast algorithms then no one with a cheap laptop can play it and you've just defeated yourself.

Where threads show up more is e.g. a web server, which will do one thread per request (Django does this for example, but it's hidden from you).  Or databases like Postgresql which will use divide and conquer approaches to run parts of the query in parallel.  I deal with them a lot at work because part of work is a custom database and another part of work is an analysis engine that has to process millions of giant files a minute sometimes.

If you were doing an online game you might do one thread per area.  Getting objects between threads and making sure that areas don't have to read other areas that other threads own is a thing that's not so easy, but it's a good divide and conquer approach and an environment where one core won't do it (you've got physics, all your pplayers go to a different map, now you're running the equivalent of 20 games. One core isn't going to do it).  But if your game is complex enough to justify that you'd probably not use Python first, and I don't think we currently have multithreaded online games save perhaps for doing the networking in the background, so the scale at which it matters is larger than you'd expect.