I like Odin because it values the low-friction of C, unlike just about every other "better C" I've tried. It adds friction where you're likely to cut yourself, and reduces friction where it matters; in places like:
- having semantic modules instead of textual inclusion
- having a nice build-system built in
- smart bounds-checking/integer-wrapping semantics (customizable, too!)
- predefined mathematical operators for things like vectors and matrices
- an actually useful core library
There's no particular feature of Odin that really stands out, but where Odin outclasses every language available is that every single feature has been very thoughtfully considered and designed to have the least amount of issues. Once you work with it for a few months, it becomes obvious very quickly its vision is remarkably consistent, leading to a smooth and outright delightful development experience.
I will caution, if you are the type of developer who likes to pull in lots of packages and dependencies to start a project, it's not for you. There's no package manager, and rightly so[1]. You'll have to build most high-level systems yourself. But when you realise that most frameworks and dependencies are trivial to implement by hand, this won't be a bother.
If you're the kind of developer who loves building systems and doing everything yourself, you'll feel right at home.
[1] https://www.gingerbill.org/article/2025/09/08/package-manage...
I am _not_ talking about ease of use or interface.
For a long time Godot has not been ready for medium-large 3D releases, that is changing, but for the most part both it and Raylib are very reliable and will be perfectly good to release a 2D game with.
I'm not actually sure whether a 3D game with skinned meshes will ever be in-scope for Raylib. Wouldn't seem like it.
I interpret this to mean something like “as my game gets more involved” which is not unrelated to a venture into 3D. Why are you policing my comment which is trying to be helpful?
Nothing against the MIPI-DSI displays, but sometimes they require you to write pin definitions for like, 40 pins, it gets a little ridiculous.
ESP32-S3-BOX-3 (320x240 ILI9341, SPI) - Working
M5Stack Core S3 (320x240 ILI9342C, SPI) - Working
ESP32-P4 Function EV Board (1024x600 EK79007, MIPI-DSI) - Working
Easy to add: Any board with ESP-BSP noglib support. Just add to board_init.c.
About a year ago I was curious about building an ECS-based game engine with world simulations like in dwarf fortress, but obviously at much smaller scale while playing Starfield. Something cool started to materialise after tinkering so I thought why not turn it into a space-sim roguelike with a simulated living world.
I use swift because it gives me fantastic devex with all its great type inference and macros + raylib gives me cross platform input handling / rendering and window management.
C-interop setup is basically instant - you point compiler to c headers and the API becomes immediately visible on swift side
As for swift ergonomics, I particularly love that I can now write very readable code, like:
> world.addRelation(attacker, Attacks.self, target) > world.addRelation(player, Owns.self, sword)
or
> for (entity, position) in world.query(Position.self).with(Health.self, Velocity.self).without(Enemy.self) {}
Raylib helps you draw stuff, play sound, and do the basics. But you're gonna be writing your own lighting/raytrace/pathfind/etc functions and it's ultimately going to take longer. The upside is if you need to do something very unique, all of the power to mske it reality is in your hands because Raylib isn't opinionated on how your game logic works and how it's packaged up. It's just the delivery guy to give the result to the user.
> if yes what are the things that raylib is missing that these engines have?
Asset management and import pipelines, rendering pipeline, loads of ready-to-go features like environments, baked lighting and global illumination, AO, reflections, particle systems, input mapping and event propagation, scripting, audio systems, GUI systems, and lots more.
Raylib is a library that you could use to build all that stuff, but otherwise it's a useful library, not a fully-featured game engine.
If you don't want a game engine and know exactly what you features you need and want to build only that, then Raylib is a great option.
If you don't want to write a global illumination system or asset management pipeline but would rather focus on creating gameplay, then a game engine is a good choice.
Unity and Unreal do anything most games will ever need and have massive ecosystems.
For example , Unity has built in physics , navigation, asset management, input handling, build systems, audio processing, etc.
Unreal has that and arguably more.
Godot is getting there, but still has growing pains. In larger projects things get weird.
