akka ants without STM

[Kallin Nagelberg]

Hey everyone!

I've been reading through the akka docs, looking at some of the example projects, and am interested in how it might help me run a large scale wildlife simulation. Without elaborating too much, I'd like to simulate a massive world that potentially is scalable across machines, with all sorts of animals moving around, eating each other etc. There are a couple old Akka sample projects that show a simple simulation of Ants, all represented as actors. I was looking at them, but they're heavily tied to the now removed STM framework. I'm trying to jump in and right a new version of Ants using the latest Akka code, but am not sure how best to migrate away from all the deprecated STM code. 

The original projects are

https://github.com/pvlugter/ants

and

https://github.com/azzoti/ScalaAkkaAnts

Any guidance would be appreciated :) 

Thanks,

-Kal

[Kallin Nagelberg]

Would it be safe to say that Akka is no longer an appropriate framework for such a simulation? 

[Patrik Nordwall]

Hi Kal,

On Thu, Mar 20, 2014 at 10:00 PM, Kallin Nagelberg <kallin.n...@gmail.com> wrote:

Would it be safe to say that Akka is no longer an appropriate framework for such a simulation? 

I'm not familiar with the ant simulation. If it requires transactions across actors it is probably safe to say that actors are not appropriate. You can of course use STM with actors without using the deprecated abstractions in akka.

You want it to scale across machines, and then STM is not an option anyway.

There must be a more scalable way of designing large scale wildlife simulations, but I have no experience of that domain.

Cheers,

Patrik

 

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

[Justin du coeur]

On Mar 21, 2014 6:35 AM, "Patrik Nordwall" <patrik....@gmail.com> wrote:
> There must be a more scalable way of designing large scale wildlife simulations, but I have no experience of that domain.

(Don't know the Ants app, but did spend a while in the videogame business, which pertains to this.)

It's a fascinating problem, actually.  The issue is that a naive simulator, designed for one machine, usually assumes simultaneity - there is a constant systemwide clock that all entities respect, and interactions between entities are more or less synchronous.  Presumably the old STM version was mimicking that.  That has a hard time scaling across a large cluster, though.

Not sure what the answer is, but I would bet that the MMORPG industry has done a lot of work on the topic.  At a guess, I would observe that you mostly care about *local* synchrony rather than global.  So it seems like you might be able to build an approximate but functional simulator by dividing the space into an octtree of actors, which arbitrate the interactions of the creatures in those spaces.  Instead of committing transactions, the creature and space actors cooperate to decide what happens in each go around.  (Basically, set up an internal architecture that mimics the way that player interactions work in a typical online game.)

That's just an offhand guess, but it seems like it should work...

[Kallin Nagelberg]

Thanks for the answer Patrik :)

You're actually cluing into what I'm really interested in here; creating a highly scalable solution for a real-time massively multiplayer game.. something along the lines of a server-side dwarf fortress with massive concurrency between all of the entities in the simulation, along with the players/influencers. 

And I agree that for the most part, local sync is the only thing that really matters, at least as far as any 'hard' real-time constraints go. When I see the low per-instance limits in mmos, or hear about Eve Online having to dilate time to support many concurrent users it makes me cringe and think that there must be a better way :P

Out of curiosity, could I ask where you worked? I find myself sitting here at a cafe on Saturday aft listening to a 'best of' 16-bit console music, just having missed GDC in my own backyard, and wondering how best to make the leap from a career of enterprise software to mmo server tech :)

Cheers,

-Kal

--

>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---

You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/RvAsX4IRBC8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

[Justin du coeur]

On Sat, Mar 22, 2014 at 1:43 PM, Kallin Nagelberg <kallin.n...@gmail.com> wrote:

Thanks for the answer Patrik :)

Actually, that one was me, not Patrik.  Threads getting tangled in the email.

 

You're actually cluing into what I'm really interested in here; creating a highly scalable solution for a real-time massively multiplayer game.. something along the lines of a server-side dwarf fortress with massive concurrency between all of the entities in the simulation, along with the players/influencers. 

Yeah, I suspected -- this sort of problem tends to come up in games programming.  The crucial rule is that building a *truly* honest large-scale simulation is nearly impossible, due to these sorts of synchronization problems.  So you instead want to focus on producing an experience that feels synchronous on the player's local level, and which "plays fair" to a reasonable degree.

(I will note that even playing fair isn't always possible in a high-speed environment, if the player action time is similar to the network latency.  One of the nice things about Shock was that, since it was cooperative multiplayer, I could be arbitrarily unfair in favor of the players -- the bots weren't going to complain about the fact that my algorithms always erred in favor of the players in case of race conditions.)

 

And I agree that for the most part, local sync is the only thing that really matters, at least as far as any 'hard' real-time constraints go. When I see the low per-instance limits in mmos, or hear about Eve Online having to dilate time to support many concurrent users it makes me cringe and think that there must be a better way :P

Yep.  It's a variant of the problem that I learned the hard way, that you can't easily take a single-player game and make it multi-player.  Similarly, if your MMO's architecture isn't built for arbitrary scalability to begin with, that's eventually going to bite you on the tuchus.

 

Out of curiosity, could I ask where you worked? I find myself sitting here at a cafe on Saturday aft listening to a 'best of' 16-bit console music, just having missed GDC in my own backyard, and wondering how best to make the leap from a career of enterprise software to mmo server tech :)

Looking Glass Studios, in its latter days: I built the resource management systems for the game Thief, and most of the peer-to-peer multiplayer systems for the game System Shock II.  (And I was in the middle of building the client/server multiplayer engine for our next-gen Siege Engine when the company shut down.)  After that, I and a bunch of other refugees from Looking Glass spent several years building a highly-generalized peer-to-peer (but not game-oriented) distributed data engine at a company called Buzzpad.

I will warn that the game industry is still, far as I can tell, pretty insane -- the ego-boo from working at LG was pretty fabulous, but the work conditions were a tad abusive, and while I gather that things have improved somewhat, they are still kind of loony.  That's based on impressions from my friend who just left Irrational, having been there all the way from System Shock II through Bioshock, its spiritual sequel.  He's now striking off on his own as an indie game developer, which promises to be more fun, but building an MMO is hard to do as an indie...

[Kallin Nagelberg]

Sorry about the confusion Justin!

And congrats on helping ship one of the greatest games made! Those monkeys still give me nightmares.. 

Speaking of turning a single player game into a multiplayer one, there's a great book that came out recently, 'Stay a while and listen', which chronicles the early days of Blizzard, and they're struggles with that same problem in one anecdote.

And I think you're right, indie is the way to go right now, or perhaps a kickstarted project along the lines of Pillars of Eternity. There's so much potential in that space now, especially with new angles like Twitch play Pokemon or even VR. I appreciate the warning though! I'll definitely keep this group posted if I accomplish anything note-worthy with an akka-based simulation.

Cheers,

-Kal

--