Seems that the build works fine but the link in /snap/bin/snowball fails to execute, the generated binary in /snap/snowball/89/snowball does execute however, but this is not an endpoint obvious to the end user.
I have no idea what is causing this problem.
Your bundled package list (stage-packages) is looking slim, as in it looks as if it contains the bits relevant to your game but not the bits you’d usually not think about, such as graphic drivers, X11 libraries, audio libraries, etc, since these are usually assumed to be on the host system already. In snap, you have to bundle these dependencies too.
There’s some things known as extensions that exist to make this easier, collections of packages and some wrapper scripts to ease integration into the system. You should try one, the Gnome ones are usually preferred for either GTK applications or applications with no other strong preferences (e.g, there’s a QT extension, but you’re an SDL app so Gnome works fine).
You’d enable it like so:
apps:
snowball:
extensions: [gnome-3-34]
command: snowball
It’s worth mentioning I’d never recommend to your users to run /snap/snowball/current/snowball directly, it won’t be sandboxed or otherwise exist in the snap sandbox. It does often appear to work, but it’s completely broken beyond trivial cases. Hopefully, the Gnome extension will fix the proper snap/bin/snowball route 
Thank you so much that’s done the trick, see I assumed it was something to do with the plugs as I noticed these /snap/bin files seemed to be sand-boxers when viewing them in a hex editor. I suppose there where a few under-sights in my decisions there - I assume when using SDL if I am not using audio or other components SDL offers I probably need to give access to all the plugs SDL makes use of even if I don’t explicitly use them? I guess I undershot the plugs thinking “well I only use SDL for OpenGL and X11”.
The answers is basically “it depends”. SDL is a mature library and I’d imagine could do fine without the audio-playback interface if you weren’t actually using any audio (I’m under the impression you have to actually initialise an audio subsystem in SDL manually anyway, and in theory a good application would react appropriately if SDL returned an error initialising sound). However, most libraries might have some environment variables that could help out in these scenarios, or some other configuration that could give you leeway. For example, SDL would likely have something similar to just sending the audio output to /dev/null rather than any actual sound device/socket, so this might help for example if you had a misbehaving application that absolutely demanded some audio output but didn’t actually make use of it.
Other libraries might not be as mature or lenient, and so yeah, they could potentially just break if certain permissions weren’t granted even if they weren’t used, but it’s entirely a case by case evaluation and so there’s no general answer.
FWIW, the plugs are still slightly relevant, I’ve noticed you’ve removed the plugs definition in your git repository, the extensions usually set some sane defaults for their purposes, and if you were to run snapcraft expand-extensions in the CLI you’d notice that actually there is some plugs being used anyway, applied just before your snap is built. I think you might have found the desktop one in particular important for example, since it sets up some basics like being able to access the users fonts!