BEAM Based Game Engine - feedback/thoughts?

Chat & Discussions Chat / Discussions
,
1

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.

5 Likes
2

image
image1125×796 40.8 KB

This is literally the top of the forum posts right now…

3

Cool but this is the conventional way to use the BEAM as the server. I’m talking about hosting the whole game or if multiplayer, one node of the game on the player’s device in the BEAM.

1 Like
4

One thing I’d be interested in seeing is where you draw the line between “game state” and “engine state”.

A lot of BEAM game discussions seem to end up in one of two extremes:

  • Everything is a process.

  • Everything performance-sensitive gets pushed into a NIF.

The first tends to fight the hardware, and the second starts looking suspiciously like a traditional engine with Elixir as a scripting layer.

My intuition is that the sweet spot is letting BEAM own the coordination, gameplay logic, networking, and fault tolerance, while a native layer owns the frame-critical systems.

Have you identified any specific workloads that actually perform better because they’re running as BEAM processes rather than simply being easier to develop and maintain there? I think the answer to that question would help clarify where this architecture really shines.

5

Before my engineering path, I’ve played with several game engines like Unreal, Cry Engine, Unity etc even did some level-design. Today I have no patience for design work (decision fatigue hits real hard and everything becomes a never ending project). I’d be interested in a framework where I can build a game mostly using code and dont worry too much about design/3d etc