I believe that if LÖVE weren't inextricably tied to Lua and were instead exposed as a C library that 2D game development would become a lot easier in someone's language of choice. You don't have to muck around with low-level details like initializing SDL or using raw calls to OpenGL, but you don't have to be constrained by the complexity of larger frameworks like Unity. It's like the one proper wrapper API for all the individual hard-to-use libraries.
I don't like LÖVE because of Lua, I like LÖVE because the framework itself is so well-designed and easy to use. Other people seem to agree to the point of reimplementing LÖVE's API in Rust, as ggez.
Love can actually be used directly as a C++ library. It's a bit of work to get the build system going but then you can use the Love API like: https://github.com/castle-xyz/castle-client/blob/7bfffa10e84... -- we used to use the Lua Love and have since worked on porting our engine to C++. It even runs in the web with the same code through Wasm. No Lua VM ever gets initialized. I may create a minimal starter template repo showing an example of this at some point...
Though, for a 'simple C library for 2d (and actually 3d) game development' -- I would highly recommend https://www.raylib.com/. I really, really dig the API design there. One of the main 'downsides' I guess is it doesn't out of the box build natively for iOS -- but the Wasm support makes it run there pretty fine out of the box and raylib-fork can be used to get a native iOS build going with some work. It's got a lot of stuff out of the box including a GLTF loader and skeletal animation.
I was hoping for a C API specifically to use LOVE with a statically typed language, but because C++'s ABI is unstable writing a C wrapper is about the only way for the engine to be bound to other programming languages besides Lua. Also everything needed to quickly make a game is already included in LOVE provided the correct libraries are available in the system, so it's quite convenient.
But raylib sounds pretty simple to use if you want a library-driven approach, and the WASM support is interesting. There was at one point a project that ported LOVE to asm.js but it's since went unmaintained. I was actually able to run one of my >100MB projects on it, but it was pretty unstable and I soon ran into asset size limitations.
Love does work through wasm in the pure C++ approach, have been using it on a project for a bit now. It's definitely better that way vs. also using Lua since you can't use LuaJIT and vanilla Lua running in wasm esp. with a GC isn't geat perf-wise.
Agreed re: C API -- would definitely need a wrapper there. The C++ API is also a bit less ergonomic in some ways than the Lua one (particularly how images are initialized) but also more in others (type checking and autocomplete is great). Lovr (topic of this post) uses LuaJIT's C FFI actually with a C API internally so it's more in that direction, FWIW.
What does "library-driven approach" mean in raylib's case and how is it different from Love's approach? In both cases I just have a CMake project that builds my application to either a native executable (including mobile in Love) or web, with all dependencies vendored, calling functions and using types from either API.
I do think raylib's C API fits this well and with the least impedance mismatch, having used all of them -- Love in Lua, Love in C++ and raylib in C -- extensively. eg. you can directly manage and render vertex buffers in raylib and go down to the 'rlgl' level, in constrast I found Love's default image rendering to have perf issues in web (it uses buffer orphaning) and I had to do something more manual with Love's meshes.
A question: would it be too much work to port Love2D to a different embedding language? (I'm currently having looks at Squirrel (http://www.squirrel-lang.org/) I always thought Lua was tightly coupled with the framework, but what you've mentioned seems to imply that's not the case.
Having attempted this myself, the answer is "a lot of work." Even with the classes and bindings separated, there is still a lot of C++ code used in the binding layer, and some of the C++ code is tightly coupled to Lua data structures. If a transition to a C API were to be made, that C++ code has to be put behind a corresponding C wrapper, so basically opaque pointer types to all those classes and functions/methods have to be wrapped to fully support using LOVE as a standalone library.
I still think that a C API would be a better option than trying to fork the project to replace Lua with Squirrel or some other language, so that at least others can have a chance to write bindings for their favorite languages without having to do all the porting work again.
I don't think it's "too much work" if you really need it or are really interested in doing so and the approach results in incremental benefit vs. one big blob of benefit at the end. It would be quite a bit of work and not super automatic, probably. You have to implement all the files named 'wrap_*' in the Love codebase, kind of. It's definitely possible to start working on a game project to test with and do it incrementally, which is probably strategically the best path and also fun, which can make it worth it. Something like:
- Get direct Love C++ project working without Lua
- Make some level of test cases with it to get a sense of C++ API usage
- Embed squirrel interpreter into test
- Start binding API to squirrel and testing more and more of API incrementally from squirrel
- Port more and more test cases till it's all covered (or prioritize based on need of game(s))
The nature of the thing you are increasingly covering in Squirrel could be a particular game or a set of demos (maybe both).
Check out OpenFrameworks: https://openframeworks.cc/about/ It's a C++ library that uses all the same kinds of libraries as love (and a lot more) but wraps them up into a uniform C++ object model and scene graph. I've used it for some simple 3d scenes + opencv processing and found it very enjoyable and easy to use.
I don't like LÖVE because of Lua, I like LÖVE because the framework itself is so well-designed and easy to use. Other people seem to agree to the point of reimplementing LÖVE's API in Rust, as ggez.