Gremlin looks very relevant! If it could, as much as possible, abstract-out the actual carrier (direct TCP, a Websocket, UDP) this would be ideal indeed; the message-based mode of operation of Protobuf relates well (GPB being a very solid technological choice) and leads naturally to RPC… and having a client-side automatically prepared in Godot for that would be certainly a huge advantage, especially if it is generated from Erlang.
I do not know enough Godot and Unity to have a clear opinion on the best choice for the context at hand (free software vs more services/higher quality rendering/plenty of assets readily available). Should no killer rendering feature exist in Unity but not in Godot, and should, even for high-end content, an actual asset conversion be doable to target the latter (materials, prefabs and advanced animation-related features may be a problem?), many (like me) could prefer Godot; the perspective that it would then neatly integrate to an Erlang server-side thanks to Gremlin would be awesome!
The other direction, for server-side (Erlang-powered) scripting in a GDScript dialect, is interesting as well, and surely another technical feat! Yet on the server I would still probably prefer remaining in pure Erlang as much as possible and having the slimmest dependency onto the client-side software (seen mostly as a dumb view and a basic controller, in MVC parlance), thinking that the libraries and languages there might be less interesting in their own right / more prone to change.
As the functional services seem to me relatively close, Gremlin could end up as an Erlang-based Mirror-like library for Godot, isn’t it? Have you considered taking inspiration from Mirror (or the other technologies Kartheek mentioned), or even sought some level of compliance with it, at least on an API level? Switching more easily solutions on the client and/or server side would offer much welcome flexibility.
Overall, there are so many needs besides rendering and middleware (persistence, world simulation, resource management, live upgrade, etc. - and of course the game logic itself) that, especially for hobbyists, it is clearly overwhelming. Please share pointers here to your code when you are ready to open-source it! IMHO, the biggest threat to such ambitious game-related projects is not a premature sharing of unpolished work-in-progress, but the exhaustion of motivation because the task is too big for a solo developer, or even for a few of them; this is why I started this thread at the first place
A parallel topic could consist in exploring the actual game that each Erlanger interested by this thread would like to create (the great absentee in these discussions), as this may explain many of the design decisions. Moreover the second biggest threat to these projects is starting the creation of a game and finishing by devising some library instead; another enjoyable, yet different, goal…