> So, if you want to build games using raylib, why not learn learning or use Swift for that?
Never ever worked for me. Imagine, you actually learned basic Swift and Raylib, now you want "advanced" features in your game like navigation/pathfinding, model loading, ImGui, skeletal animation (those are actually vital for gamedev).
You realize that
- Navigation is only ReCast which is pure C++ library,
- ImGui has C++ API as first-class citizen,
- Decent animation with compression is only open-sourced by OzzAnimation which is pure C++ project.
For gamedev interfacing with C is never enough, half of ecosystem is built heavily on C++. Even C++ interop is not enough (see Dlang). Without all those libraries you are bound to make boring 2d platformers.
It's also industry standard to do so. I don't think I've ever seen a team outsource something like pathfinding. Maybe in the Unity/Unreal space, which I'm very unfamiliar with. Dependencies are generally speaking not viewed as a good thing. They become vanishingly rare outside of certain things like physics engines, sound engines, vegetation, etc. And usually higher quality proprietary ones are chosen over OSS (though this is changing with physics engines in particular, mostly thanks to Bullet)
NIH is a cultural pillar. Even scripting layers are relatively split on if they're in-house or not. It's not uncommon to find both an in-house fork of Lua + a few other completely custom scripting engines all serving their own purpose.
Pathfinding middleware has traditionally been a thing though, e.g. apart from the mentioned ReCast (which is the popular free solution) the commercial counterpart was PathEngine (looks like they are even still around: https://pathengine.com/overview/).
If you need to do efficient path finding on random triangle geometry (as opposed to running A* on simple quad or hex grids) it quickly gets tricky.
What has undeniably declined is the traditional "10k US-$ commercial middleware". Today the options are either free and open source (which can be extremely high quality, like Jolt: https://github.com/jrouwe/JoltPhysics) or fully featured engines like Godot, Unity or UE - but little inbetween those "extremes".
I did mention this was changing in particular with physics engines. That being said, proprietary dependencies still reign supreme in places like audio engines. Something like OpenAL isn't really a replacement for FMOD or Wwise. I know those off-the-shelf engines roll their own replacements, but then they also roll their own pathfinding and navmesh generation as far as I know.
It's not a terribly long list, it seems, even if it's non-exhaustive.
> I see the industry is of full double standards
Absolutely, and that's why it's so great. No two companies are going to look the same. The culture of the video games industry is a rather unique one that's kept its archipelago syndrome alive against all odds. It'll be a sad day if that ever changes.
I've seen people genuinely wonder how one would go about making a 2D platformer without a generalized third-party physics engine—as though every single classic 2D platformer didn't have its own simple, bespoke physics simulation!
There are entire classes (even genres) of video games that don't require substantial third-party library support, and it's frustrating to see that this seems to be more and more of a minority view as time goes on.
Dear ImGui via the C bindings is actually quite nice and not much less convenient than the C++ API (the only notable difference is that the C API has no overloads and default params).
E.g. here's a control panel UI (from the below ozz-animation sample) with the 'Dear Bindings' approach (using a custom 'ig' prefix)):
TL;DR: quite a few C++ libraries out of the game-dev world are actually quite easy to access from C or languages that can talk to C APIs, mainly because the game-dev world typically uses a very 'orthodox' subset of C++ (no or very restricted C++ stdlib usage, no rtti, no exceptions, ideally no smart pointers in the public API).
Everyone will have their different take on what Swift is, and what a proper alternative looks like. Swift started life as a C-family successor, so I'll be looking at languages with similar aims (fine-grain control, scaling to large projects.)
The first two I'd mention are D and Nim. I only wrote ~10k LoC with these languages (so they weren't really for me) but they strike me as similar to Swift. They both optionally support an automatic memory management strategy like GC, (whereas Swift as ARC) and there is great effort put into metaprogramming facilities. Both D and Nim compile much faster than Swift, and offer better error messages than the Swift compiler in the presence of complex generic expressions. In the context of the parent post (games) Nim is especially well equipped with a package ecosystem. D seems a touch less lively, but has a following.
For myself, I prefer the Odin programming language. Full disclosure, I've been donating to Odin for about a year now after happily using it for more than 5. After writing "Orthodox C++" for a while, I stumbled on Odin and feel as if it was made specifically for me. The compiler is fast, and the language has been something like a tutor or mentor for me, as it applies friction in places where I usually waste time. It would take some hand-holding as a first-language though, as some error messages relating to overloading/generics would seem obtuse to a beginner.
EDIT: I've recently been exposed to the Raku language, and it strikes me as sort of a ... dynamic version of Swift? It's jammed full of functionality, with an emphasis on being able to design syntax a-la DSL.
Also I'd add that Swift is sort of part of this new litter of "no-paradigm languages" like Kotlin and C#. I don't think Kotlin can actually dip as low-level as C# and Swift can, though. At least I think only C# and Swift have some kind of safety-wrapped user-level pointer "thing."
I might be interested on how to build the WASM build more easier with Swift tools.
I guess some tools exist to facilitate the final builds, but did not found it...
Do not hesitate to comment if someone experienced this before.
Out of curiosity, how does the size and performance of the generated WASM compare to just compiling the same Raylib example from the equivalent C code via Emscripten? In other words, how much overhead does the choice to use Swift add here or in general?
Raylib has a C API though, and this is 'easy-mode' in any language (even without integrated bindings generation like Swift or Zig have - e.g. it's fairly trivial to write a bindings generator that uses Clang's ast-dump json file format as input and translates the API declarations into another language.
A more interesting question would be how well the C++ interoperability works that was added in Swift 5.9, does it work with all C++ headers, even headers that make extensive use of template code. Also how does Swift extract information needed for lifetime tracking, e.g. C++ APIs that return smart pointers and object lifetime ends on the caller's side. Does this only work for C++ stdlib smart pointer types, or are custom types also supported.
> A more interesting question would be how well the C++ interoperability works
They’re using it in their work on FoundationDB. Looks good, but has limitations. Swift can call C++ and vice versa, Swift classes can inherit from C++ and vice versa, but not for all code, and may need work adding annotations on the C++ side. See https://github.com/apple/foundationdb/blob/main/SWIFT_GUIDE.....
> So, if you want to build games using raylib, why not learn learning or use Swift for that?
Never ever worked for me. Imagine, you actually learned basic Swift and Raylib, now you want "advanced" features in your game like navigation/pathfinding, model loading, ImGui, skeletal animation (those are actually vital for gamedev). You realize that
- Navigation is only ReCast which is pure C++ library,
- ImGui has C++ API as first-class citizen,
- Decent animation with compression is only open-sourced by OzzAnimation which is pure C++ project.
For gamedev interfacing with C is never enough, half of ecosystem is built heavily on C++. Even C++ interop is not enough (see Dlang). Without all those libraries you are bound to make boring 2d platformers.
Same for Zig, Odin, C3 etc.
> Without all those libraries you are bound to make boring 2d platformers.
Perhaps if you're completely devoid of imagination.
It is in fact possible to make video games without deferring to open-source libraries for every single aspect of it.
It's also industry standard to do so. I don't think I've ever seen a team outsource something like pathfinding. Maybe in the Unity/Unreal space, which I'm very unfamiliar with. Dependencies are generally speaking not viewed as a good thing. They become vanishingly rare outside of certain things like physics engines, sound engines, vegetation, etc. And usually higher quality proprietary ones are chosen over OSS (though this is changing with physics engines in particular, mostly thanks to Bullet)
NIH is a cultural pillar. Even scripting layers are relatively split on if they're in-house or not. It's not uncommon to find both an in-house fork of Lua + a few other completely custom scripting engines all serving their own purpose.
Pathfinding middleware has traditionally been a thing though, e.g. apart from the mentioned ReCast (which is the popular free solution) the commercial counterpart was PathEngine (looks like they are even still around: https://pathengine.com/overview/).
If you need to do efficient path finding on random triangle geometry (as opposed to running A* on simple quad or hex grids) it quickly gets tricky.
What has undeniably declined is the traditional "10k US-$ commercial middleware". Today the options are either free and open source (which can be extremely high quality, like Jolt: https://github.com/jrouwe/JoltPhysics) or fully featured engines like Godot, Unity or UE - but little inbetween those "extremes".
> Today the options are either free and open source (which can be extremely high quality, like Jolt: https://github.com/jrouwe/JoltPhysics)
I did mention this was changing in particular with physics engines. That being said, proprietary dependencies still reign supreme in places like audio engines. Something like OpenAL isn't really a replacement for FMOD or Wwise. I know those off-the-shelf engines roll their own replacements, but then they also roll their own pathfinding and navmesh generation as far as I know.
From https://recastnav.com :
> Industry Standard - Recast powers AI navigation features in Unity, Unreal, Godot, O3DE and countless AAA and indie games and engines
I see the industry is of full double standards :)
https://www.mobygames.com/group/9867/middleware-recast/
It's not a terribly long list, it seems, even if it's non-exhaustive.
> I see the industry is of full double standards
Absolutely, and that's why it's so great. No two companies are going to look the same. The culture of the video games industry is a rather unique one that's kept its archipelago syndrome alive against all odds. It'll be a sad day if that ever changes.
I've seen people genuinely wonder how one would go about making a 2D platformer without a generalized third-party physics engine—as though every single classic 2D platformer didn't have its own simple, bespoke physics simulation!
There are entire classes (even genres) of video games that don't require substantial third-party library support, and it's frustrating to see that this seems to be more and more of a minority view as time goes on.
> ImGui has C++ API as first-class citizen
Dear ImGui via the C bindings is actually quite nice and not much less convenient than the C++ API (the only notable difference is that the C API has no overloads and default params).
E.g. here's a control panel UI (from the below ozz-animation sample) with the 'Dear Bindings' approach (using a custom 'ig' prefix)):
https://github.com/floooh/sokol-samples/blob/d8429d701eb7a8c...
Dear ImGui is a bit of an outlier for C++ libraries though, since it is essentially a C API wrapped in a namespace.
OzzAnimation is also fairly trivial to wrap in an (abstracted) C API, for instance I use this in some of the sokol-samples:
https://github.com/floooh/sokol-samples/blob/master/libs/ozz...
Implementation: https://github.com/floooh/sokol-samples/blob/master/libs/ozz...
...used in this sample:
https://github.com/floooh/sokol-samples/blob/master/sapp/shd...
...WASM live version:
https://floooh.github.io/sokol-html5/shdfeatures-sapp.html
TL;DR: quite a few C++ libraries out of the game-dev world are actually quite easy to access from C or languages that can talk to C APIs, mainly because the game-dev world typically uses a very 'orthodox' subset of C++ (no or very restricted C++ stdlib usage, no rtti, no exceptions, ideally no smart pointers in the public API).
> So, if you want to build games using raylib, why not learn learning or use Swift for that?
Because Apple won't fix Swift's abysmal compile times, and there are languages with similar or better ergonomics without that flaw.
What are the languages with similar or better ergonomics?
Everyone will have their different take on what Swift is, and what a proper alternative looks like. Swift started life as a C-family successor, so I'll be looking at languages with similar aims (fine-grain control, scaling to large projects.)
The first two I'd mention are D and Nim. I only wrote ~10k LoC with these languages (so they weren't really for me) but they strike me as similar to Swift. They both optionally support an automatic memory management strategy like GC, (whereas Swift as ARC) and there is great effort put into metaprogramming facilities. Both D and Nim compile much faster than Swift, and offer better error messages than the Swift compiler in the presence of complex generic expressions. In the context of the parent post (games) Nim is especially well equipped with a package ecosystem. D seems a touch less lively, but has a following.
For myself, I prefer the Odin programming language. Full disclosure, I've been donating to Odin for about a year now after happily using it for more than 5. After writing "Orthodox C++" for a while, I stumbled on Odin and feel as if it was made specifically for me. The compiler is fast, and the language has been something like a tutor or mentor for me, as it applies friction in places where I usually waste time. It would take some hand-holding as a first-language though, as some error messages relating to overloading/generics would seem obtuse to a beginner.
EDIT: I've recently been exposed to the Raku language, and it strikes me as sort of a ... dynamic version of Swift? It's jammed full of functionality, with an emphasis on being able to design syntax a-la DSL.
Also I'd add that Swift is sort of part of this new litter of "no-paradigm languages" like Kotlin and C#. I don't think Kotlin can actually dip as low-level as C# and Swift can, though. At least I think only C# and Swift have some kind of safety-wrapped user-level pointer "thing."
Thanks for sharing it!
I might be interested on how to build the WASM build more easier with Swift tools. I guess some tools exist to facilitate the final builds, but did not found it...
Do not hesitate to comment if someone experienced this before.
Out of curiosity, how does the size and performance of the generated WASM compare to just compiling the same Raylib example from the equivalent C code via Emscripten? In other words, how much overhead does the choice to use Swift add here or in general?
Raylib has a C API though, and this is 'easy-mode' in any language (even without integrated bindings generation like Swift or Zig have - e.g. it's fairly trivial to write a bindings generator that uses Clang's ast-dump json file format as input and translates the API declarations into another language.
A more interesting question would be how well the C++ interoperability works that was added in Swift 5.9, does it work with all C++ headers, even headers that make extensive use of template code. Also how does Swift extract information needed for lifetime tracking, e.g. C++ APIs that return smart pointers and object lifetime ends on the caller's side. Does this only work for C++ stdlib smart pointer types, or are custom types also supported.
> A more interesting question would be how well the C++ interoperability works
They’re using it in their work on FoundationDB. Looks good, but has limitations. Swift can call C++ and vice versa, Swift classes can inherit from C++ and vice versa, but not for all code, and may need work adding annotations on the C++ side. See https://github.com/apple/foundationdb/blob/main/SWIFT_GUIDE.....
There’s a good video on that work from a few years ago that was discussed on HN in https://news.ycombinator.com/item?id=38444876.
For sure — that's where it gets difficult.
Show me a real C++ interop example. Does function, constructor and operator overloading resolve correctly? How about C++26 reflection?