I'm currently building a distributed mmo emulator using elixir, and it's going well (performance/bug/effort wise). Distributed via horde/libcluster libraries, ranch as acceptor pool, using livebooks for debugging and performance testing.<p>I couldn't really ask for anything better, as solo dev in less than 100h basic distribution solved(one process per map, one per player. Maps are spread around the erlang cluster using horde, if a map crashes players seeemlesly reconnect in less than a second, and the map may actually be on a whole different system, especially when the node becomes non viable)
Basic monster ai, fighting logic. Respawn/monster drops, extensive ddbuggability using observer (gui tool included in erlang, allows me to send messages to processes/see their status/ what they do, maybe kill them in the whole erlang cluster )
Can just use livebooks to do more extensive programming (just connect to cluster, execute a mark down files code blocks, see results live ingame and in the livebook)<p>It's a very great and easy language for this. I may consider moving couple of things to rust using rustler tho for the fun of learning about nifs
I can't overstate how good Elixir + LiveView is, especially for prototyping. I have been experimenting with it ever since it first came out, mostly games, and I have to say that building even simple multiplayer games is a lot of fun.<p>An example:<p><a href="https://dev.voppe.it/chess" rel="nofollow">https://dev.voppe.it/chess</a><p>(FYI there is no actual game here, just pick emojis, place them in the arena and watch them fight to the death via a poorly designed combat system. Yes, those placing emojis other than you are other players.)<p>This was a prototype that I built to see if real-time multiplayer games were feasible. Apparently LiveView manages high tickrates decently enough to be a valid solution for (quasi) real-time games. This game for example runs at a whopping 8 ticks/s! It can handle more, as I've tried developing with faster tickrates, I think as high as 24 t/s, but I want to avoid server strain. With enough HTML/CSS/SVG wizardry you can get away with quite a lot. But the most amazing thing was the fact that there was no need to fiddle around with state syncing. Everything just works! I have nothing but praise for it.<p>Try LiveView if you have the chance!
I'm curious about how race conditions would be handled when multiple users, on different regional LiveView servers, take conflicting actions.<p>In the "Let's walk it through" section, it seems like the Player-to-LiveView connection will process user input (e.g. a Tic-Tac-Toe move) and update the UI to acknowledge this, at which point the user can be assured that the LiveView server accepted their input. But it seems like this happens before the GameServer has also accepted the input. What if Player 2 made a conflicting play and their change was accepted by the GameServer before Player 1's change reached the GameServer?<p>Given, in Tic-Tac-Toe, the game is simple enough that this is neatly avoided: each regional LiveView server has enough information to only allow the current player to make a play. But in more complex applications, how might you (anyone; curious for discussion) handle this?<p>One answer is something like: The LiveView server is effectively producing optimistic updates, and the GameServer would need to produce an authoritative ordering of events and tell the various LiveServers which of the optimistic updates lost a race and should be backed out.
Great article. I'm currently building a turn-based multiplayer improv piano game for the web using Elixir/Phoenix.<p>In a nutshell, you compete with other players on creating freestyle piano solos over backing tracks using a MIDI keyboard. Players and audience members then listen through the solos and vote for their favorite.<p>The Elixir/Phoenix stack has been an absolute superpower for building my game backend. Some examples:<p><pre><code> - Phoenix channels as a wonderful abstraction over
managing WS connections. Implementing basic chat took ~3
minutes on the backend.
- The ability to model game logic with a finite state
machine in a GenServer. The lifecycle of a game round is
progressed forward by receiving incoming client events.
- The ability to have many game servers
running simultaneously as a dynamic pool under a
DynamicSupervisor. Games can end and new games can be
created, all isolated and under watchdog-like
supervision.
- ETS as an out-of-the-box memory cache for session data.
Persisting user data between pages and sessions without
needing to deal with an actual persistence layer.
</code></pre>
For the curious, the project is called Midi Matches and is currently in public alpha:<p>Game (desktop chromium only): <a href="http://midimatches.com/" rel="nofollow">http://midimatches.com/</a><p>Gameplay Video: <a href="https://www.youtube.com/watch?v=UVD2wOCB_jE&t=41s" rel="nofollow">https://www.youtube.com/watch?v=UVD2wOCB_jE&t=41s</a><p>Repo: <a href="https://github.com/henrysdev/midimatches" rel="nofollow">https://github.com/henrysdev/midimatches</a>
I always think it's amazing how much simpler your architecture can get if you don't move any and all state to some other service in the name of keeping your app stateless. Of course there are good reasons why the industry has moved towards stateless business logic services but with all the BEAM goodness (resiliency, hot code reload) it might be feasible to write apps that actually hold state again.
This post is essentially an ad on Fly's blog, but maybe some others with experience can weigh in on its tradeoffs vs the other popular providers with first class Elixir support.<p>I haven't used it yet and am curious about new offerings.<p>That said, the guide linked from this post requires more config than the competing options.<p>For example, Render also handles clustered deployment with libcluster setup, and it's very, very simple to set up. <a href="http://render.com" rel="nofollow">http://render.com</a>
This is cool. I was thinking of using Elixir/Phoenix for a browser game. A different concept, though.<p>My first choice was node but the more I use Javascript the more I hate it.
I’ve been thinking of trying out elixir for exactly this kind of thing. Having done similar projects in Nodejs (experience was fine tbh) and used Xstate or Redux for game state management on the server side. What would people recommend for that role in Elixir (or is it a case of roll yr own)
After clinging to my favorite stack for five years (elixir+ember js) my next project will ditch ember.<p>LiveView is the nail in that coffin. It doesn’t help that Ember, though I STILL love the technology and framework, is deader than dead community-wise except for a few silos. It’s very tough to find talent. And the benefits just aren’t there anymore compared to using LiveView. I still use ember on about 8 projects but no more.<p>Have others with this stack reached similar conclusions?
Ever since I heard about Fly I was really keen to try out something using Elixir. I've been severely lacking in ideas that I can complete within two weeks though (my maximum attention span)!<p>This was well-timed for me - nice to have a reference working config to play around with, especially for clustering. How do you find the BEAM handles a distributed cluster across multiple regions? Are there any oddities that crop up due to inter-site latency?
How would you handle animations and more interactive page elements? Is it possible to reach the same kind of UI as something built with Svelte/Vue/React or are there certain limitations?
See also for more discussion on LiveView: Phoenix LiveDashboard (April 16, 2020) <a href="https://news.ycombinator.com/item?id=22892401" rel="nofollow">https://news.ycombinator.com/item?id=22892401</a>
I understood all the components but given I don’t do a lot of complex distributed programming , I kind of got lost about what Horde and libcluster do. My world view is very simple: backend app server and front end code.<p>Can anyone ELI5?