Elixir for game development

The BEAM rules on servers, not clients, I would not recommend building a visual client on the BEAM.

You ‘can’, but I’d not recommend it.

@Qqwy was building an FRP in Elixir, I already built one in OCaml->Javascript. ^.^

Ooo, QtQuick is a good idea, I’ve use QML and it is indeed awesome.

If you want a web client, well Elixir makes a dang fine server for that. ^.^

Guh, I hate Electron, nothing eats more resources on my system then loading any Electron app… >.>

2 Likes

Which IMHO is very, very unfortunate. BEAM languages, especially Elixir, would be amazing to write client applications in if there was a good rich GUI facility. wxWidgets is not that (just look at the fun the last weeks on the erlang list about this!), but one can imagine such a thing existing. The lack of a good modern toolkit is one of the last things that holds the BEAM forever on headless services.

Concurrency is absolutely huge for modern GUI applications, something we’ve been working around for the last couple decades with one hack or another. Threading is a nightmare, so it is often faked with event loops and async I/O to varying degrees of success.

Good, modern UI toolkits put as much of the UI as possible in threads (QtQuick does this in several ways, as well as putting as much on the GPU as possible) leaving the application code to languish in yesterday’s development paradigms. It would be absolutely wonderful to be able to develop rich client applications with a language that gave you good concurrency out of the box. The other benefits like FP rather than OOP and all the other bits and pieces would be the icing on the cake.

4 Likes

If you like to do some functional web client I think Elm might be a nice option.

If you would like to create an installed client you could take a look at Arcadia. It is built on top of unity so for more serious projects it is nice to be able to leverage all the features off a fully fledged game engine.

Both of which could be combined with an elixir backend ofc :slight_smile:

@NobbZ: that’s really interesting!

I’m not planning writing game yet, but I heard about some topics related to it. Probably the most interesting was Vulcan API. Do you know if there is any possibility to “connect” features from Elixir world and Vulcan API?

Today’s CPUs (also in mobile devices) have lots of cores, for example 8 cores is not something new. I think that it could be awesome to have game data processing and process managing in Elixir and combine it with Vulcan API. Last time I saw a card game in beta version that does not loaded images for all cards and really fast I got idea like: Here Supervisor would be just perfect!.

And think about that ad: First game that could use full power of your CPU! It's written using Elixir and ... :smiley:

Vulkan (not Vulcan) is significantly lower level, manage your own memory and all, and very unforgiving for errors. Overall you will not get much of a speed difference if any between well written OpenGL and well written Vulkan except in a few very specific cases. Mostly Vulkan is just OpenGL cleaned up of it’s ancient cruft.

Eh I’ve already been doing so in C++ (custom engine) and Rust (amethyst, new engine). ^.^

Elixir/BEAM would not be performant for a client, at all. Maybe as a scripting layer, but not much beyond that at all…

2 Likes

Yes, I always make mistake here, because some words in Polish with k letter are translated to English equivalent word with c letter. :smiley:

Yes, but it started with excellent support. For example OpenGL drivers from AMD (at least for my old GPU) are … I heard that implementing Vulkan makes them much more fast rather than old OpenGL drivers that probably needs a good rework, but I don’t have so much time to test it. :slight_smile:

Why not? Can you say something more? I think that some groups of games could have Elixir parts without problem:

# 1. If there is something that needs as much CPU power
I know that we can’t say that … language is x times slower than … language, but we can assume some things, just for example:

This … game part is from 5 up to 10 times faster in C++ than in Elixir. So let’s say that Elixir have 1 point and C++ have 10 points. But all of that happen in only one thread, so if we have 8-core CPU then C++ still have 10 points, but Elixir have more: 1 * 2 * 8 => 16 i.e. 1 point per each thread.`

Of course it’s not so simple to say, but something like it. :slight_smile:

# 2. Network things - imagine that our game allows multiplayer mode, so it could be client as same as server. Each Elixir process per connection with player should work well.

# 3. Supervising processes
If something goes wrong when drawing then we could restart drawing process (Vulkan port) and initialize it again that redraws specific area.

# 4. Simple website editor for creating new cards :smiley:

I said something about card game. I don’t believe than C++ will have much more FPS that Elixir also in 1 thread for this case - not even talking about 8-core CPU here …
What we could have there?

  1. Options + files (load & save settings)
  2. Network things (client + server code)
  3. Process for each player and card for storing stats and do simple math (damage, health etc.) + listener for events - i.e. simple game engine (not draw engine)
  4. Supervisor for managing drawing process + communication to Vulkan - i.e. change health => call draw another integer in card
  5. 3rd-party libraries for example for OS notifications and similar also really small things

All hardest things here are rendering and animations.

I can understand that in some cases there is need to use pointers to memory and other low level things, but I don’t think that it’s so bad for some types of games or maybe I missed something?

What do you think?

There is a word Vulcan in English, just in this case the spec is named Vulkan, yes it is weird. ^.^;

They’ve gotten significantly better in recent years actually. :slight_smile:

The utter and sheer amount of data that has to be sent to the GPU I could not see being done efficiently via BEAM’s message passing. Perhaps updating a rendered scene state in a native code world via the BEAM would work, but the act of rendering itself and all the synchronization points (‘Flushes’ in GPU parlance) that have to be serialized would never allow it to perform anywhere within a factor as well as native code.

Maaaaybe if you make NIF’s and program them very carefully would it work somewhat decent. But even then keeping the rendered ‘state’ and just sending over changes to native code would be significantly more efficient.

This is one of those cases that is very CPU/Memory bound, which the BEAM is not suited for. :slight_smile:

I honestly think that even 5 to 10 times faster in native code is being kind, I’d really honestly believe that except in very simple demo’s that it will be multiple orders of magnitude type difference, which is the difference between a smooth 60 fps and getting 2 fps.

Network would be awesome on the BEAM, that is what it is practically designed for after all. ^.^
However using those network packets to do things like, oh, handle Physics processing or so forth, that would fall flat again.

If your GPU code is crashing then depending on the quality of the drivers you will crash the entire OS or just have a significant speed hit as the rendering pipeline has to be flushed and cleared (I’ve seen stalls of this routinely cost well over 1 second per frame, which drops you to <1fps instantly). GPU coding has to be done right or it is not a ‘crashing’ issue but rather you become unplayable just because the hardware has to reset its state.

This is generally done once, so it does not matter where it is done.

This itself is fine on the BEAM, but what is done ‘with’ those packets may not be.

It’s not just the player but the entire world that you have to simulate, this is hugely CPU bound and will not be done well in the BEAM except for absolutely trivial scenes.

This will not be done well on the BEAM. A draw call to the GPU can be batched up in command buffers and so forth, but they have to be flushed at times and at certain points and these are absolutely timing critical (micro-second kind of critical to the hardware).

Eh, notifications and such are pretty trivial.

Some ‘types’ sure, like a card game would not matter for sure. Potentially even something as complex as a 2d shooter becomes infeasible unless the object count is kept extremely low.

2 Likes

I don’t know if I understand you correctly. You are talking about bigger games where there is a number of things that could change small detail and therefore make huge affect on computations, right?
Originally I think about 3 steps:

  1. Elixir as a master process - like website backend that simply manages data. I don’t want to integrate Elixir with JavaScript, HTML and CSS - just use multi thread ability and if there is really big performance problem then optionally:
    1.5 make a NIF’s for lower-level language, but I don’t see that is really needed (of course it depends on how much data we need to process and how fast). Anyway it could be possible to manages NIFs to run computation on all cores/threads instead of one - like in normal games, right?
    Btw. one time I have a network problem and I was need to save data (that I normally fetches from sites) and I saved them to file using :erlang.term_to_binary and was surprised how fast it reads really big files back to Elixirs types and I’m working on really old laptop that is not recommend for games from release date. :slight_smile: So here I believe that Elixir could make lots of awesome things also for at least some games …
  2. A library/framework or something like graphic engine that connects Vulkan with Elixir by NIF instead of try to use Vulkan API directly in Elixir (I don’t need to be expert to know that it’s bad idea) and therefore don’t force Elixir to make any graphic work - just manages and process information data that will be directly used in framework as argument to draw specific things.
  3. Finally Vulkan API that makes as much as possible work on GPU.

If we are still in topic … vs … then if so it’s 30x bigger fps, so we only need 15 (60 / 2 threads / 2 fps) core CPU to have similar results in both cases - of course it’s not a gaming CPU, but it’s really not a problem for today’s technology. :smiley:

Hmm, you are talking about sending rendered image? I don’t think that sending informations about changes on map is a really big problem especially on better PC setups with fast SSD. :smiley:

# receive opponent moved, shoot and destroyed one item in map
# process required information
Framework.send_data_to_render(data)

Oh, that’s what I don’t expected. I know about drivers, but not whole GPU code, wow. +1000 respect for all people that works on GPUs. :smiley:

I can understand that working on GPU form Elixir to create game like GTA V could be a little (:slight_smile:) problem, but I think about something really other.

I believe that for all 2D games Elixir + NIF with Framework + Vulkan/OpenGL should work really well and here Elixir should not be close to use whole CPU power. We probably are talking about different solutions. I believe that there is not much data in really big number of games (also 3D).
Problem begins when we need to have calculate position of every body on map (not just simple movement with jumping, but also move by explosions and more) and in second case where we have a really big number of data to manage like in games with open world.

I don’t think to make a clone of Unreal Anthology in Elixir, but what Elixir offers should be too much for simpler cases like clone of M.U.G.E.N., 2D mob games or card games.

More cores rendering will not increase FPS like that. You can only use multiple cores to build up multiple CommandQueues, but even then executing those is serial and that tends to be the slowest part, not the building of the CommandQueues (except for some very exotic work that almost no game does at all). Extra cores can improve rendering by loading, say, multiple textures at the same time to the GPU, but the actual rendering will not be helped by more cores at all.

2 Likes

Yeah, I forgot about serial - here was my mistake. Now I see what you are trying to say.
So with Elixir we can optimise some parts of every game, but not rendering part. From what I heard developers already achieve what they should (I mean here about OpenGL/Vaulkan), because rest heavy depends on hardware + drivers + of course whole code quality.
Thanks for explanations!

Sorry for my terse messages today, just crazy busy at work, I can be more detailed later if wanted. ^.^;

2 Likes

It is outdated. Last update 2014.

Here is another solution, with full Qt support: https://github.com/luc-tielen/Cure/issues/5#issuecomment-318596547

1 Like

Uh, not really? That is just a port mapping library (which you can already do in straight OTP/BEAM without libraries) to an external app that you have to build? ^.^;

So, ErlangVM already supports that by nature? So I guess this project was started before?
Anyway, do you think it will work? Here is a more expanded view on this:

So all whats left seems to be a generic QML library:

https://filcuc.github.io/DOtherSide/

And the README of libqmlbind mentions special API code for dynamical languages, while itself seems to be unmaintained for one year, so it might make sense to port those parts of the API into DOtherside? Again, of course, if anybody is interested at all.

I am not too sure about this, but there was a post on this forum which said that Elixir and Unity 3D was combined.
I had to learn unity because it was a prerequisite for a job that I was going to get.
As far as I can tell the unity game engine is pretty comprehensive about everything and all-in-all a well built engine.
Combining it with elixir is an added advantage that’s all

I think Scenic it’s the giant step forward we needed to talk about GameDev in Elixir

I wrote about it here

3 Likes

You might be referring to the game InVected we (me and a couple of other guys, some from our company, some from the university) built for the last Global Game Jam, using Unity for the front-end, and Elixir+Phoenix for the back-end, which synchronized a very simple browser application on the user’s phone with the large Unity screen, allowing them to use their phones as ‘joysticks’. It was a lot of fun, and supports 14+ players (that’s as much as we’ve tested it with at the end of the 48h game jam).

4 Likes

That’s so cool. I love these type of games. Jackbox Party pack and Eon Altar are the ones I know that do it and those are SO MUCH fun with friends. I’ll check out the game and code!

In general, I think elixir is great for the server side as long as no heavy physics calculations/number crunching is involved.

I’m still very skeptical with Elixir for more involved graphics but am very happy to be proven wrong.

1 Like

So I could create an Elixir server to manage data distribution and syncronizing objects through clients and make clients with a GameDev specialised tool that simply authenticates to the server…
If Elixir is intended for servers, then use it to create servers :wink:

1 Like