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 On Fri, Mar 21, 2014 at 7:30 PM, Justin du coeur <[email protected]> wrote: > > On Mar 21, 2014 6:35 AM, "Patrik Nordwall" <[email protected]> > 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... > > -- > >>>>>>>>>> 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 > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
