Jinx VS seer

Check out jinx https://jamesboer.github.io/Jinx/

Don't get me wrong, I'm a big fan of automated tests where it makes sense. I wrote a scripting language that I use for my personal game projects, and I never would have been able to do it if it weren't for the battery of tests for every feature, error, and corner case I could think of. But games are rarely like other software, with hard rules about what is "correct" or "incorrect". And it would be a nightmare to try to keep up with designers, constantly tweaking and tuning, so what's "correct" is literally a day to day, constantly moving target.

A second trial for you might be Jinx. Depending on your definition of procedural, Jinx is 100% only procedural. https://jamesboer.github.io/Jinx/

Jinx (embeddable scripting language) works as following:

Feel free to look at my own interpreter, written in modern C++. You're welcome to ask me if you have any questions.

I use my own scripting language more like content, especially for things like one-off events and behaviors. Example: scripting special behaviors for a boss fight, or a room with a unique trap in it, or any other sort of one-off behavior that would be overkill for C++, but too complex for most other types of data-driven content. These days, visual scripting also helps to fill in these gaps between content and procedure.

You're welcome to look at my scripting language Jinx, written in modern C++. Just let me know if you have specific questions. Data flow is JxLexer.cpp -> JxParser.cpp -> JxScript.cpp. Most everything else is implementation details. Also, note the parer is pretty complex, mostly because Jinx has a crazily flexible syntax for functions.

Feel free to look at Jinx if you want an example of what I consider a fairly easy-to-use and integrate scripting system. Obviously, I'm a bit biased since I wrote it.

If you're working in UTF-8 internally, you could just write your own UTF-16 to UTF-8 conversion functions to convert strings at API boundaries. I did this in my scripting language because I didn't want to bring in dependencies.

CLion uses lldb.

I wrote https://github.com/daym/idea-native2-debugger as a stop-gap. It uses gdb and works in IntelliJ IDEA Community edition. Setting it up the first time is kinda weird since you need to add a new run/debug configuration "Native2Debugger". I could not figure out how to hook this directly into the existing run configuration that you use to run your program to begin with. Otherwise, I like how it turned out.

If you want a standalone frontend, https://github.com/epasveer/seer is extremely good.

And emacs has gdb integration. By now I tried it, and... I guess it's better than nothing.

(Shameless plug for my frontend to gdb --> https://github.com/epasveer/seer )