Axiom + Amethyst

(Khionu Sybiern) #1

For over a month, I’ve been doing an async refactor of an Actor Model in Rust called Axiom. It’s approaching a point where it needs a minimal example that proves it to work in a practical project. The lead maintainer wanted to create a game server, and I suggested we work with Amethyst. The benefit is mutually drawing attention to our projects, as members of the Rust ecosystem.

What is the Actor Model, and what about Actix?

The Actor Model consists of many Actors that own their own state and communicate exclusively via messages. Each Actor can be thought of as a micro-service. A proper Actor Model implementation removes all concurrency concerns and enables taking advantage of all CPU cores.

The Actor Model is used widely in large-scale services, including Discord, and is the basis of Erlang and Elixir, as BEAM VM languages. Axiom, as a Rust Actor Model, would be potentially ideal to serve as a base for any future Amethyst hosted services.

Actix is more of a “pseudo” Actor Model. It cannot make all of the guarantees that you’d find in Akka, Erlang, or Elixir, and it was made, first and foremost, to drive Actix’s HTTP APIs (which is apparent from trying to read the docs on Actix for usage sans HTTP).

What kind of example?

It doesn’t need to be anything larger than what we have in our Showcase Family already. In fact, some of those games might already be perfect.

So… what’s to be discussed?

Mainly, the Showcase Team should weigh on whether they would like to collaborate with us, and after that, it’s a matter of picking/making the game, and then implementation specifics. For this thread, I’d like to get an idea of how everyone feels about this arrangement, before worrying too much about specifics.

(Erlend Sogge Heggen) #2

Evoli is currently in hiatus, and my basic understanding is that the actor model tends to work very well for simulation games. I’d be totally on board with an experimental branch of Evoli that attempts to employ the actor model.

I’ve no say over our other showcase games, but as they are all being actively developed I can’t imagine any of them would benefit from an architectural shift at this time.

I tried to find simple examples of games using the actor model without much luck. Perhaps the best example around, while certainly not basic, is Citybound and its actor framework Kay.

1 Like
(Khionu Sybiern) #3

Unless they already have networking, I would hope that using an Actor Model for the server wouldn’t require a shift?

The benefits of an Actor Model in simulations are notable, yes. A “hosted” Evoli instance could be done in Axiom while local play is all in Amethyst.

(Erlend Sogge Heggen) #4

Ah that’s true. In that case doing a multiplayer branch for Space Menace would also be a viable option.

(Kel) #5

Would this server use Laminar as UDP transport?

(Erlend Sogge Heggen) #6

That was probably the plan for @jstnlef? but I don’t expect the experimental vs-edition branch of Space Menace to advance any further now that we’ve got a showcase game with multiplayer as a design goal in Grumpy Visitors.

Multiplayer isn’t a priority for Space Menace, so whoever wants to give it a go is free to approach it as they see fit.

(Justin LeFebvre) #7

Most of the work I’ve put in recently has been on the integration of the new Networking library into Grumpy Visitors (which is done at this point). I’d love to hear/see more on the integration of an actor system into Amethyst. Presumably you would want to have it’s scheduler be Amethyst’s scheduler. Does Axiom allow you to specify a separate scheduler or manually run the actors yourself?

1 Like

About Kai, I saw this video (is 2 years old) but if I understand correctly the multiplayer part his library already manage that, you can see his talk it’s very interesting.

I was away from amethyst discord for a while but saw on the road map about this actor model, and now this thread, what will happen to specs or legion if this got implemented, is just an option or is a replacement? The whole amethyst experice will shift with this approach?

(Khionu Sybiern) #9

It could! Would just need to create some glue between it and Axiom. Axiom is not bound to any networking protocols. I’m actually planning on making a QUIC extension for my own stuff.

Umm, I don’t think this is feasible. Amethyst is too tied to ECS, and they’re intrinsically different concurrency models (if ECS, in itself, can be considered a concurrency model? either way).

Axiom has a custom Executor-Reactor setup for async actors. It wouldn’t be possible for actors to be ran outside of this setup. This is why I was suggesting that the “hosted” Evoli be Axiom, it wouldn’t have to worry about being integrated with the rest of Amethyst.

I’m not familiar with what part of the roadmap you’re talking about, but Axiom specifically was never in the planning of Amethyst. This proposal is not a continuation of any other thoughts, save the generic having multiplayer examples.

The sole scope of this proposal is using Axiom to power multiplayer servers for one or more Amethyst Showcase games.


I read that in the amethyst roadmap (way at the bottom in the ECS part) that’s why my question before. So then if I understand correctly this is exclusively (at least for now) for amethyst servers? If so still interesting.


(Khionu Sybiern) #11

It’s possible that Axiom could be used as that Actor Model… but I wouldn’t presume to know the thoughts behind that. Axiom is meant to be the most basic foundation of a proper Actor Model infrastructure. The lead maintainer has said they’re willing to open up to user scheduling, but I wouldn’t count on that in the foreseeable future. We have a lot on our plate trying to ensure that a few critical, but non-core components are fully functional (ie Clusters and basic TCP support).

So, maybe, I won’t discount it as a possibility, but that’s not in the scope of this proposal