I’ve been on Godot 4.2 for a few months I feel confident that I can complete this game using this engine if I have to. However, there’s a lot I just don’t like about it and I don’t have much faith that it’ll improve or even maintain its current quality, such as it is. I’m not a Godot-hater; I’ve run into a few of them spewing spurious accusations on forums and actually gained respect for the Godot team as a result. Godot is good for game jams and prototyping and real games up to a point, but RPGs not so much.

A possible contender has emerged: Raylib, Odin and Jolt/PhysX.

It’s not quite an engine, it’s a code library built on several good small independent libraries, many of which I used in my last custom engine, and more… and I’ll need Jolt/PhysX/Bullet/whatever for physics. Odin is a new C-like language that’s very well oriented toward game/graphics programming that’s taken that world by storm in just the last year or two… unlike Jai. I haven’t tried it yet, it might not work out, but I kinda know it will. With this software stack I can slap together a ‘custom’ engine without too much work - less than it took to bend Godot to my will, I’m betting.

Sometime I’ll prototype this for my next game but I’ll stick with Godot for Sanguinity unless this new thing absolutely blows Godot out of the water (which I hope and believe it will.)

For now I’m just outlining what I’ll need to do and why:

• Pros/Benefits:
  • Tighter more manageable code footprint
  • Drop Godot’s editor and GUI
  • Do most editing in Blender, or in-game when necessary (as in our custom Engine V2)
  • Raylib+Odin = everything we used in V2 but more, better, non-custom
  • Small, independent, replaceable components
  • Unencumbered by Big Engine scope creep, design flaws, baggage, overcommercialization, mismanagement, politics, etc
  • More modder-friendly
• Cons/Risks:
  • Must build+test engine runtime for any target platforms
  • Odin is new language - may lack performance, reliability, longevity
  • May lack ‘critical mass’
  • Higher bar for collaboration than Godot (minor issue)
• Dependency assessment:
  • Compile all dependencies for Windows & Linux
  • Runtime tests on both platforms
  • Is anything glitchy/unreliable?
  • Are any tools/libs unmaintainted or too ‘fringe’?
• Proof-of-concept implementation
  • 3D hello world
  • Try the immediate-mode GUIs favored by Raylib+Odin
  • Use a drop-in debug/tweak UI
  • GLTF scene/model loading
  • PBR Render Pipeline
  • Skeletal Animation
  • Navmesh Pathfinding
  • 3rd-party physics engine (Jolt, PhysX, etc)
  • 3D/physics/GUI stress tests
  • Port game object data system, gameplay code & GUIs from Godot
  • In-game editing of game objects, dialogue/quests, 3D materials & lights
  • Godot .tres material loader (or another format exported by Material Maker)
• Scripting language
  • Single-threaded (HaXe, JS, Lua) is acceptable if limited to config, startup, dialogue/quest control, etc (NOT for the game object data system or GUI as in our Engine V2)
  • Concurrent/multithreaded (Cyber, GDScript, etc) is preferable if available under a nonrestrictive license with minimal build dependencies (i.e. Odin or C implementation)
  • No, a simple homebrew scripting is NOT acceptable (this was a major flaw of our Engine V1)
• Blender tools for level editing etc
  • Auto-create shader nodes for game-style materials
  • Insert game objects (from the game’s database file) in Blender scene

I should not have to say this, but any criticisms expressed or implied in this post are just my opinion.

Follow-up Report

• This is all very promising but needs more time to cook, both on my end and the new languages etc.
• Raylib is great. It’s a collection of all the little C libraries I used in my Crusaders engine (v2) and several more.
• I’m happy with RayGUI and I’d probably be fine with any of the popular immediate-mode GUIs.
• However, PBR and skeletal animation did not “just work” at all.
• I may need to code my own navmesh system, behavior trees, projection decals, LOD, jigglebones.
• Haxe is out; it has abandoned its C/C++ and VM compilation backends to focus almost exclusively on web languages (JS, PHP, etc), and it’s a more cumbersome language than I remember.
• Cyber is a promising script language. I haven’t actually coded anything in it, but it checks all the boxes for speed, concurrency, and language design/features. It’s written in Zig and compiles to a standard C ABI static library which is easy to integrate with other languages.
• Odin is a promising super-C with nice clean syntax for most things. On the downside, it’s written in C++, requires Clang/LLVM to compile, isn’t fully cooked yet, and I can’t for the life of me figure out how to integrate C++ libraries with it.
• Unfortunately the major 3D physics libraries (PhysX, Bullet, Jolt) are all written in C++.
• I despise C++ now more than ever.
• C++ AND ITS CONSEQUENCES HAVE BEEN A DISASTER FOR THE HUMAN RACE.
• Zig is another super-C contender. I tried it briefly but threw up my hands in confusion. There are some things I just don’t like about it, and my engineer friend who told me about it feels the same way. HOWEVER, I will definitely be adding it to my toolbox, because it has many nice features in common with Odin and many more all its own, and one huge killer feature: it also compiles C and C++.
• I don’t want to build a whole game engine with Odin, Zig, or Cyber until they’re more mature.
• C is an option. Raylib is pure C, Cyber works fine with C, and I got Jolt to work with C as well. If I take the C+Cyber route, I’ll lean more heavily on scripting like I did with C+JS in Crusaders.
• I could definitely rebuild my Crusaders engine with C+Cyber+Raylib+RayGUI and halve my custom-code footprint, bug count, and maintenance burden. I’m not doing it now, but I might START it as a test.
• I think we can say that unless Godot somehow improves greatly within the next year or two, I will be implementing this contingency plan for Sanguinity.