Writing an MMO with Web Actors

http://blog.paralleluniverse.co/2014/02/13/web-spaceships/

by pron • 12 years ago

47 23 12 years ago

blog.paralleluniverse.co

danso• 12 years ago

Ha! I clicked on this expecting it to be how to make a story-driven MMO game in which the actors are all non-union/guild actors making a living off of webepisodes. Considering that even guild actors get paid beans for what they are used to in commercial/tv/film work, I was interested in what cost-savings might have been actually attained. But the actual material of the OP is even more interesting :)

angersock• 12 years ago

I...did not even consider that as a possible interpretation. That said, your explanation makes complete sense.

Volscio• 12 years ago

I was thinking about the Primer from "The Diamond Age". :(

http://en.wikipedia.org/wiki/The_Diamond_Age

MWil• 12 years ago

ha! I had the same thought. I really want interactions with the "villains" through MST3K type videos (the villains being the mad scientist and the lady with the monkey sidekick) of them explaining their diabolical plan to raid my base or pat themselves on the back for having done so

ChuckMcM• 12 years ago

I had a similar thought, my guess is that the "next generation" of MMOs has humans playing the 'Boss' in dungeon scenarios. This makes re-playing the content interesting (the talent of the boss can change) and off sets a fairly large technical burden (scripted encounters). Of course it adds issues with potential collusion, balancing difficulty, and continuity (you need someone online as the 'boss' for the encounter to happen).

I sketched out an update for WoW that would allow RBC's (remote Boss characters) to be statues in game, until someone logged in and "inhabited them" where upon there would be an in-game effect (like 20 - 30 seconds of a glowing around the statue) and then 'wham' the boss comes alive. Until either dead, or they log off and the return to being a statue.

Its a complex mechanic but it has the potential of providing a lot of quality game play for the subscribers. I'd need an economist though to get through the models of expected subscriber return value vs cost.

stcredzero7• 12 years ago

I'm currently writing an MMO.

http://www.reddit.com/r/roguelikes/comments/1xa9rj/i_have_be...

http://www.reddit.com/r/Clojure/comments/1x4ycd/i_have_been_...

I am intrigued by actor models, but I can't get my head around what that would mean in terms of architecture. A game loop is easy to understand, especially for functional programming. You just make the world at tick n+1 a function of the world at tick n.

For one thing, this makes server load easy to evaluate. It's just a percentage of simulation tick duration spent in calculation. How would I evaluate that in the actor model?

pron6• 12 years ago

Well, with (concurrent) actors there are no ticks – just like in the real world, and every actor has its own loop.

This game also computes an FPS rate. Whenever an actor completes an update, it atomically increments a counter. Every N increments, with N being the number of actors, we say a frame is done. But this is unnecessary.

The best way to estimate load is by looking at Quasar's internal execution queues. Also, every actor in this game has a loop of 30ms, i.e. it immediately responds to messages it receives, but if there are none, it updates every 30ms. If you miss that deadline, namely your current run is over 30ms from the previous one, you know the server is overloaded.

Of course, the main advantage of working like that is that you get really good parallelism. In a previous blog post where I discussed the standalone simulation[1], I mentioned that you can run it still using actors and still in parallel, but in lockstep using a Phaser. After each cycle, every actor waits for all the others to complete. This gives you "classic" predictability, but you're not making the most out of your hardware as all cores basically become idle after each step, and then you have to start them up again. When the actors run asynchronously, all cores are busy all the time.

[1] http://blog.paralleluniverse.co/2013/10/16/spaceships2/

stcredzero7• 12 years ago

The best way to estimate load is by looking at Quasar's internal execution queues.

Yes, but then how do I break things down in specific terms? With the game loop, it's easy for me to just take milliseconds timestamps before and after each subroutine. For example, I can just time how long it takes for me to run (prepopulate-monsters).

Also, every actor in this game has a loop of 30ms, i.e. it immediately responds to messages it receives, but if there are none, it updates every 30ms. If you miss that deadline, namely your current run is over 30ms from the previous one, you know the server is overloaded.

So then, I have to aggregate the loop running-times for every entity, or take a census of entities overrunning?

Of course, the main advantage of working like that is that you get really good parallelism.

I've always understood this part. However, consistent game ticks are useful for various aspects of simulation and game AI.

but you're not making the most out of your hardware as all cores basically become idle after each step

A laudable goal, but what if one is prioritizing "never lag" over efficiency? My game is to have some of the same "a-life simulation with a game attached" quality that Dwarf Fortress has. To ensure that such calculation never interferes with player responsiveness, I was planning to put such background processing on an entirely different instance, then import the resulting evolved monster species into player instances. How would this be architected differently using actors?

Kiro• 12 years ago

How can I follow the progress?

stcredzero7• 12 years ago

I will post to HN when I get to the point of having a login and only slightly embarrassing game.

peregrine• 12 years ago

The demo barely works at all, with sub 100 players, hits won't register, flying is jerky.

I get thats is only a demo but its not a very convincing one :/

pron6• 12 years ago

Flying is jerky because we do no client-side processing. A real MMO will use dead-reckoning etc.

At the top left of the screen you can see your network latency. Obviously, it depends on where you are. The server is a single US-EAST EC2 instance. So this is entirely a network issue. I can tell you that the server isn't starting to feel the load yet, and is currently running at 32.5Hz (pretty much the maximum rate). This is a much higher rate than most MMOs that run at 4-10Hz.

banachtarski• 12 years ago

The server load won't say much about latency. And it's java.

RyanZAG• 12 years ago

You're probably correct, but it really isn't very convincing...

stcredzero7• 12 years ago

I have to concur with Ryan, but for slightly different reasons. For me, the biggest scaling concerns are not with efficient use of hardware, but with guaranteeing user experience. I can see how the actor model can ensure efficient use of hardware. I can also see how it could be leveraged to give responses to user input almost as fast as network latency will allow. I'm not yet sure that it will make performance monitoring or understanding performance bottlenecks any easier or that it won't make such activities more complicated.

tmarthal• 12 years ago

This looks super interesting, a great example of functional programming and an implementation of websockets.

However, whenever something like this comes up, I always wonder about the new Java implementation of Web Sockets / actors. Do you have a comment on the difference between using Akka for your web interface instead of comsat WebActors?

I guess if this is a proof of concept for the comsat classes, it works quite well.

pron6• 12 years ago

I think the main difference is that Comsat (which runs on top of Quasar) has true lightweight threads, just like Erlang and Go. This means that actor code can block, you can have simple selective receive, and all-in-all the code is simpler and easier to follow.

Also, web sockets are not directly related to actors. Comsat's Web Actors simply let you write HTTP and WebSocket using the actor model.

Writing an MMO with Web Actors

Related Stories