I’m the author of Mob. If you haven’t checked it out, please do. https://mobframework.com/

Mob does a lot with NIFs as that’s the bridge between the BEAM and the native mobile platform.

It occurred to me that a NIF could be arbitrarily big and the BEAM could effectively just be window dressing. This opens up some interesting avenues. This isn’t restricted to game engines but game engines could definitely benefit. A naive approach to a game engine is to run a game loop. If your game is 60 fps then your game loop has ~17ms to run. If it completes before then, you sleep until 17ms is complete. If all you are doing is running a game loop then you have to check the status of everything in the context and update its state every 17ms which for some things will be overkill.

That’s where processes could come in. Only the things that are very directly associated with something happening on the screen need to be updated every 17ms, eg bullet position in FPS. Everything that is a bit slower could go by process and be dealt with asynchronously. This also goes for network requests, etc.

All of a sudden, this problem has become much more tractable as you can sort into items that need to be tied to the game loop and items that can be handled by BEAM processes.

I’m happy to hear feedback on this idea. I’ve no plans to pursue it although maybe experimentally.

You could also look at taking an existing game engine such as Godot and jamming it in as a NIF.