Is it possible to use a shebang to force a certain Python 3 version (e.g. python3.12 instead of python3)?

You're mostly asking about best practices to distribute games written in Python. Usually people rely on more than just shebangs here; I'm gonna talk about what solutions look like for the different problems you mentioned.

I recently came back to a game I have been making, but I came back to a bunch of library errors and the like. pygame.mixer didn't seem to work with the most recent version of Python (3.14) so I ended up installing Python 3.12 which pygame does seem to work with.

One problem is: how do you keep the same python version/dependencies when developing your game? I think you're good here, but if you want to be able to pin a version of python or version of pygame, you should look at uv, conda(mentioned above) or pyenv/poetry , or other Python project management tools. Modern ones have you edit a pyproject.toml that also specifies the version of Python you support and your dependencies. Under the hood they manage a virtual Python environment for you that is separate from your system Python.

(Note: Python packaging has changed a lot over the years and is notoriously hard. I would try out a popular tool like uv and stick to its documentation to start. There's also official information about the standards the modern tools use at https://packaging.python.org/en/latest/. If you want to learn more about the complicated history of all this stuff, the most complete explanation I know is at https://carpentries-incubator.github.io/pythonpackaging/instructor/04-history-of-packaging.html. It's really easy to find tutorials for ten-year-old ways of doing Python packaging.)

I end up compiling my game through pyinstaller, into a Mac application or a .exe, and I haven't played around with how that works either. If I install it with Python 3.12, will the application be run with Python 3.12 even without a shebang line?

Pyinstaller is special. Pyinstaller actually bundles Python into the installer. So, users running your game bundled with Pyinstaller will always run the Python version built into the installer, and your shebangs aren't relevant to it. See the Pyinstaller docs for more.

For a game you're putting on Steam or itch.io or sending to friends, you probably want to distribute a Pyinstaller-built version of a game so that people can run it without installing Python/Pygame separately.

To answer the specific question about shebangs:

I couldn't seem to find much information online about using shebangs for versions on python3 vs differentiating between python2/3, I'm mostly just curious if this is something that a shebang can be used for.

As mentioned in the comments, #!/usr/bin/env python3.12 does just work. But it will only work if someone has Python 3.12 installed and their distro installs a python3.12 command. This is why people use Pyinstaller for things like games that they want to run anywhere with the same version of Python no matter what the user has installed already.

Using a shebang line you can in principle only choose an executable as interpreter of a script (Python or any other language, e.g. bash) that exists on your system.

However, if you have a tool that is able to create a managed environment with a specific Python version on the fly, you can use it as interpreter.

For example, with uv the following is possible:

#!/usr/bin/env -S uv run --python 3.12

This means that in order to run the script, the uv run command will be executed with the --python 3.12 argument instructing it to use an environment where Python 3.12 is installed.

If the script is named with a .py file ending, this invocation of uv run will automatically execute the script using the Python interpreter in that environment.

Otherwise, either python or --script must be appended to the shebang line to explicitly tell uv run to invoke Python.

Remarks:

Strictly speaking you are using /usr/bin/env as interpreter, which finds and calls the uv executable. This avoids hardcoding the path to uv in the script.

Regarding -S, see shebang under linux does not split arguments.