Devlog #18 - Weekly Roundup 11-05-2024

• Started a turnbased test game with mouse picking & bird’s-eye camera controls adapted from my V2 engine (the last Synthnostate: Crusaders demo)
• Code cleanup, factoring, moving globals into a Game struct…
• Stress testing:
  • max 700 NPCs non-animated, all same model - at 60 fps
  • max 25 NPCs with separately loaded models & animations running at 60 fps
  • on my mid gaming PC with no attempt at optimization
  • acceptable
• Scripting tests and decisions…

Scripting

I was considering Cyberscript but that’s only because I heard about it from a friend whose opinion I respect, the same guy who convinced me to look at Odin and Zig. However, it’s too new and many planned features are incomplete including multithreading which I consider essential for heavily scripted games (i.e. small C/C++ core with all the high-level game code written in a more flexible script language) which would be nice in theory but only if the script language is solid and stable.

So I went down a rabbit hole, from one language to another, ultimately considering a dozen script languages…

• Mature/obsolete ones from the 90s single-core era, mostly dynamically typed and single-threaded:
  • Lua
  • Squirrel (Lua with C syntax)
  • AngelScript (very C/C++ like)
  • Javascript (QuickJS, Duktape, MuJS implementations in particular)
  • Haxe
  • Python (honorable mention)
• Newer ones from the multicore era, with concurrency support, optional static types, type inference, etc:
  • Cyberscript
  • Daslang/Dascript
  • GDScript (if someone spins it off from Godot…)
  • Wren
  • Janet, Io, Gravity, etc

Most of these are either dead, dying, or too new. Python is very much alive and I know it well, but it’s totally unsuitable for game scripting. Javascript is better but it will never be great because it’s the web’s language. AS3 was great but alas it’s dead. AngelScript and Daslang are written in C++ and aren’t exactly C-friendly. Wren is written in C but looks abandoned already. Squirrel is interesting - it’s written in C++ but deliberately has a C API only (which annoys C++ devs and reduces its popularity) but in any case it’s not suitable for heavy scripting and I can deal with Lua’s warts for light scripting.

So it’s back to Lua where I was 3 years ago before JS and Godot. But instead of a heavily scripted game with a tiny C core, this time I’m taking a more conservative approach, coding mostly in C with only light scripting (config, startup, dialogue conditions/actions). In particular I’m gonna write GUIs in C. Assuming immediate-mode RayGUI is fast enough (I’ll stress-test it this week) it’ll save me some effort.

What next

• Adapting my old C code to Raylib
• Turnbased gunplay
• Moving NPCs around (turnbased & realtime)
• Turn controller & animation sequencer
• TTS for the lulz (yup, that’s in my pre-godot Synthnostate 2042 prototype code - because in the future communist utopia computers have regressed to 80’s tech. It’s literally an open-source TTS library made by a communist… who didn’t really make it, only ported it from another port of an ancient 80’s TTS. Fucking kek.)
• Windows build

I’ll probably upload Raylib Test 2 before Thanksgiving, or whenever I have a basic turnbased demo running on Windows+Linux. Then I’ll just add various scenarios with the eventual goal of tying it together as an RPG.

My focus remains the vampire sim, Synthnostate: Sanguinity/Salem. I’m thinking we gotta start with solid combat mechanics, like Bloodrayne and Bloodlines with less jank, less emphasis on special moves/abilities, more RPG than Bloodrayne, but not a linear narrative RPG like Bloodlines. Furthermore, in outlining the mechanics on paper, I believe we can do it with Raylib’s basic collision functions, no third party physics engine necessary, just an octree partitioning optimization for larger scenes, eventually. If that works and it’s fun, I think we’ll roll with it. That might even make it into Test 2.