It's fine if they don't use the Spine Runtimes to playback animations, i.e. via sprite sheets. Most will want to use the Spine Runtimes though, which requires them to have a Spine license.
We actually come from a strong FOSS background (Kryo, libGDX, and more).
For Spine, FOSS didn't make sense to us, as you either end up with open-core, which over time will shift incentives to work on the proprietary parts, or a donation based funding model, which is stressful and unpredictable.
It's being used by a lot of companies with WebGL tech stacks mostly deployed on low-powered slot machines. Quite a few web games in the Asian market also use it. However, three.js likely won't add anything for a 2D game. You'd be better served with Phaser or PixiJS (which is the industry standard in slot games it seems).
The skinning could be done GPU side but with caveats: the number of bones that can influence a vertex would be limited and matrix palettes might have to be split up, inducing multiple draw calls. There actually was a GPU skinner at some point iirc, and the load for common example skeletons was pretty much the same sadly.
The Enterprise license doesn't claim any revenue share. It's a subscription model that triggers above a revenue threshold. It cross-finances the non-enterprise, pay once lifetime licenses for individuals, which get updates forever.
No, that's exactly what I meant. The author says they want to write a plugin which uses spine-cpp to render Spine skeletons.
A user of that plugin needs a Spine Editor license. The author of the plugin does not. Users of the engine not using the plugin do not need a license either. That's how integrations with e.g. GameMaker, Defold, etc. have worked for years.
The express app is really only used during local dev. In prod, only the bot part is relevant.
The site is served statically via Nginx, with a log_format that doesn't use any PII in it. That's part of my Docker setup, which is not in the repo, so I guess people have to "trust" me (which is not ideal of course).
The whole thing runs on a Hetzner server, so while I do not log any PII, Hetzner logs at least the IP and keeps that info for a while. So I guess I lied :(
Oh, thanks for the info. The client embeds external media, e.g. from YouTube. I'd assume that is the culprit. The server only serves 3 static files and doesn't do anything else.
It's actually pretty close in speed, and quite a bit faster to compile larger code bases. The key benefit is being able to debug while the program is running in VESA modes, something you couldn't do in Turbo C or similar environments.
