Live data from Hacker News

Show HN: Lyceum – An MMO game built with Zig and Erlang

github.com

41–50 of 72 posts

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#41
post #38

The BEAM is made with fault tolerance, scalability, and concurrency in mind at the cost of performance due to immutability and message passing approach among other things, which sounds like a terrible choice for a multiplayer video game that's anything more than a walking simulator. Erlang sounds like a good choice for auxiliary video game services, such as chat/social, guild management, auction house and so on, not…

Given the current state of the game (the one we keep passing around between client and server), I don't think Erlang is a bottleneck in performance for us, and it won't be in the near future. Keep in mind this state is not that huge and it is yet not distributed, so it is totally possible that at some point Erlang will slow us down. I will keep your comment in mind, thank you!

Edit: currently with the game running at 60fps, there is no bottleneck from the server side. And we call it every 16ms! I should also mention that Erlang's choice has a learning purpose; we want to try to use the game as a way to learn more about OTP and the BEAM.

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#42
post #29
post #18

Earlier quoted context omitted.

I see now, you are sending messages directly to Erlang server so you don't have to worry about network sockets. In my experience the issues with Erlang come with working with data structures, records are not flexible and there is not much one can do to abstract the boilerplate.

Having a potentially untrusted client connect to the erlang node as a c_node (which seems to be what zerl does) is not a good idea generally, as connecting that way essentially allows the client to execute arbitrary code on the server.

Please correct me if I say anything wrong.

As far as I can tell, this is not possible at all; the serialization layer (Zerl) cannot send arbitrary code to another node. Now, assuming we implement this, I also think this is not possible due to how the server is designed; based on supervisors and child processes for user sessions.

We recently became aware that you can indeed send tuples that have fixed effects when using the supervisor behavior, so it may be totally possible and probable that one could exploit this vulnerability to some degree in our server. We plan to investigate more about it as we continue to learn more about OTP and the BEAM.

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#43
post #3

> the client written in Zig (superchanged with raylib and Zerl). What does "supercharged" mean here? I'd guess raylib simply does all the rendering and input handling, what is it "supercharging" here?

It just means they like raylib and Zerl and used them.

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#44
post #38

The BEAM is made with fault tolerance, scalability, and concurrency in mind at the cost of performance due to immutability and message passing approach among other things, which sounds like a terrible choice for a multiplayer video game that's anything more than a walking simulator. Erlang sounds like a good choice for auxiliary video game services, such as chat/social, guild management, auction house and so on, not…

If it comes down to immutability and copies being a bottleneck, a solution is probably to move more of the core game state into native code (like with Zig), but fault tolerance, scalability, and concurrency seem like important things for a MMO.

Hot loading is pretty nice too.

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#45
post #42
post #29

Earlier quoted context omitted.

Having a potentially untrusted client connect to the erlang node as a c_node (which seems to be what zerl does) is not a good idea generally, as connecting that way essentially allows the client to execute arbitrary code on the server.

Please correct me if I say anything wrong. As far as I can tell, this is not possible at all; the serialization layer (Zerl) cannot send arbitrary code to another node. Now, assuming we implement this, I also think this is not possible due to how the server is designed; based on supervisors and child processes for user sessions. We recently became aware that you can indeed send tuples that have fixed effects when usi…

If you're using zerl on the client and plain dist on the server; the question isn't what Zerl can serialize, but what the server will process.

With stock OTP dist, there is no barrier between nodes. Stock OTP runs an rpc server that you can use to send function calls to run, which can include BEAM code to load (or file I/O to do); and even if that's disabled, you can spawn a process to run a function with arguments on a remote node without needing an rpc server at all.

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#46
Do you think that you could use that Erlang feature where you can link up several server program instances running on separate physical servers?

Maybe you could simulate different parts of the game world on different physical servers.

I think this is something like what the Very Large MMOs do, but with Erlang it might be easier.

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#47
post #46

Do you think that you could use that Erlang feature where you can link up several server program instances running on separate physical servers? Maybe you could simulate different parts of the game world on different physical servers. I think this is something like what the Very Large MMOs do, but with Erlang it might be easier.

Sounds like an awesome idea for when we introduce the Server Browser! Thank you!

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#48
post #45
post #42

Earlier quoted context omitted.

Please correct me if I say anything wrong. As far as I can tell, this is not possible at all; the serialization layer (Zerl) cannot send arbitrary code to another node. Now, assuming we implement this, I also think this is not possible due to how the server is designed; based on supervisors and child processes for user sessions. We recently became aware that you can indeed send tuples that have fixed effects when usi…

If you're using zerl on the client and plain dist on the server; the question isn't what Zerl can serialize, but what the server will process. With stock OTP dist, there is no barrier between nodes. Stock OTP runs an rpc server that you can use to send function calls to run, which can include BEAM code to load (or file I/O to do); and even if that's disabled, you can spawn a process to run a function with arguments o…

How can one protect the server then? Do we need some special behavior and/or library?

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#49
post #38

The BEAM is made with fault tolerance, scalability, and concurrency in mind at the cost of performance due to immutability and message passing approach among other things, which sounds like a terrible choice for a multiplayer video game that's anything more than a walking simulator. Erlang sounds like a good choice for auxiliary video game services, such as chat/social, guild management, auction house and so on, not…

it really depends on the game. people have been writing large-scale multiplayer games for over 25 years now, with MMOs sporting 2,000 player+ shards on significantly more primitive hardware. There is always this assertion that high-level languages of various flavors are too slow for games, but I suspect that today's hardware more than makes up for it for the right kind of game.

Re: Show HN: Lyceum – An MMO game built with Zig and Erlang

#50
post #7

Pretty amazing effort, this looks like a great labour of love! I can't give feedback on the code/technology, but on the writing on the lore section, I would try to simplify the writing. For instance the following: > The reverberations of the trumpet stirred the knights from their deep repose, igniting a tumultuous awakening. With swords unsheathed and hearts ablaze, they clashed in a thunderous symphony of war, each…

It's a style thing. Fantasy writing often does this deliberately. I've thought about this before when I revisited fantasy after years of being in the CS domain which helped me abhor ornate writing. I definitely think there is such thing as TOO ornate but dead-simple language also feels bad. It feels wrong to just say its an exception with fantasy - simplicity is good because it conveys the same thing more clearly and…

True high fantasy would not reference swords and trumpets, first spending a chapter or two defining a world with its own musical instruments and bladed weapons, their names of course also being in a language, sorry, tongue, for which the author must also first labour to invent a common version spoken by everyone, an ancient/high version only remembered by a few, and at least one alphabet.

In addition, each one must be described in detail, including a potted life story of the blacksmith that created it; when, why, and for whom; metallurgical observations; history of actual use; any supernatural blessings whether apocryphal or actual; the litany of families that have retained it as an heirloom & their subsequent social or political fates; details of any inscription or filigree; and a nickname. This remains true for both the swords and the trumpet. Additional remarks concerning a scabbard or case are optional but highly regarded.

Post reply on HN