unity-actions VS Jinx

> https://game.ci

I don't recommend it.

Game CI has been in development for a long time. It only really supports GitHub Actions. It can't correctly build il2cpp Unity projects. The licenses needed to run it are more expensive than Unity Build Automation / Unity Cloud Build. If you want to automate Unity builds and you don't want to learn the Windows Containers ecosystem, Jenkins and/or Tekton, you should use Unity's service.

CI/CD is a bad choice for most developers, on most platforms, for most clients. That said, it makes sense to do for your backends.

> or (as has happened to us with different game web service/API/middleware providers) they may choose to abruptly deprecate the service upon which you built.

Which service was that? GameSparks? That sucks.

> with inappropriate cloud dev tooling

Well everyone takes their own journey to discover how shitty Lambda, Cognito, CloudFormation and related are.

> with basically any datastore other than Redis you will run in to issues matchmaking

Matchmakers do not have to be complicated.

I've been struggling with getting the docker images provided by https://game.ci/ to build his project at all, let alone automating it in a pipeline.

https://game.ci/ has fantastic GitHub actions to automate all of this on each PR or push to main etc and then just upload the result of the build as an artifact and job done - takes minutes to setup and you can use your own machine as a self hosted runner to get the same build speed as local builds

These guys did a wonderful job at providing a docker-based build environment for Unity, btw: https://game.ci/

(Someone's built something similar for Unity, but it wasn't as one click when I last looked -- especially since Unity may require licenses.)

My repositories are on github, so I'm using Github Actions for build automation - I found it really easy to setup compared to other platforms. + There's basically a ready-made action for building with unity - game.ci (although I wrote my own solution for iOS).

Game CI seems to be pretty good, given the fact that it is open source and you can fix it if needed

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.