What’s the value added in this over RayLib? Is it just building GLFW from source to dodge the dependency issues? Granted, that’s a lot bigger deal than I’m making it seem.
raylib is awesome and a great source of inspiration for me. It's definitely way more complete & comprehensive today than Mach is, too.
Longer term, I think you'll find raylib to be better for simpler applications, and Mach looking a little more like an Unreal/Unity/Godot & geared towards more complex applications. All speculation, though, they're both improving rather quickly!
The other obvious difference would be language it's written in (C vs. Zig)
> Mach looking a little more like an Unreal/Unity/Godot
Right now, Mach is probably something more like Bevy, Magnum.Graphics or BGFX. ie: a _framework_.
But your post alludes that that is not the goal. That Mach seeks to build asset importing, animation tools, navigation system, etc? ie: A FULL GAME ENGINE!?
I'm kind of new to game dev and I'm a little confused about the terminology you're using. You called Bevy a framework to differentiate it from an engine, but on the Bevy website they call themselves an engine. What would you say is differentiation between a framework and an engine?
While I've never seen it defined this way, I think the distinction comes down to this:
An engine deals with assets in depth, and exposes runtime abstractions to them.
A framework does what is necessary to expose I/O and load the assets, but aims to be minimally opinionated about how they integrate into the application.
For example, in an engine you might have abstractions for applying collision, physics, and rendering techniques onto an image asset, so that you can achieve a useful result just by configuring the data correctly. A framework would give you a way to load the image and display it, but leave it to you to add more detailed behaviors by writing new code.
In effect, engines are never totally done until you have a feature-complete application. Often it works out that you need a scripting layer to define a certain kind of asset(e.g. dialogue tree logic), and then what you have is an engine extension; if the asset is defined independently of the scripting system, it can be made portable to another engine.
I think the key difference in most people's eyes is: am I interacting with this mostly through code (framework), or is there a substantial amount of graphical tooling that aids me (engine)?
I'd say Bevy today is more akin to a framework, but they intend to add tooling etc. to become closer to an engine later on from what I understand.
