In-memory Ruby objects and HTTP stacks

[Manuel González Noriega]

Hi, 

I'm toying with a "virtual pet" concept in which several of those creatures would "live" in memory and passing messages back and forth between the human owner (like "bark" or "go there") and the creature ("I'm hungry", "I want to play", etc) would happen via web or mobile interfaces.

The reason for wanting the creatures to be persisted in memory and not respawned with each HTTP request is having them be proactive and able to do stuff "on their own" like "Request food if you've gone 3 hours without eating", or eventually even interacting among themselves without the need for any human intervention whatsoever. So the scenario is akin to a lightweight MMORPG-like persisted world with web or mobile bindings. While I'm very confortable with the architecturing and development of traditional RESTful stacks, I'm out of my depth with the "persisted" requirements.

My best guess so far is using DCell for spawning the creatures from inside the request/response HTTP cycle, keep them "alive" in memory, and communicating with them later on.

Could someone kindly confirm this is a viable option and that I'm not completely misreading the nature and use cases of the Celluloid/Dcell paradigm? 

Any kind of tips, pointers or suggested reading (in so far they don't drive the discussion too off topic) are of course welcome!

[Josh Adams]

You can start with just celluloid. See https://github.com/isotope11/simcity and search under isotope11 on github for simcity for a few other pieces. Once you like it you could move simulation objects to other nodes on the network using dcell.

I wouldn't start there though.

--
You received this message because you are subscribed to the Google Groups "Celluloid" group.
To unsubscribe from this group and stop receiving emails from it, send an email to celluloid-rub...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Manuel González Noriega]

Thanks a bunch, Josh. I will study your code carefully.

[Jeremy Voorhis]

The structure of Josh's simcity code follows a common pattern for simulations. Josh, please correct me where I'm wrong, but the Board implements the root of the game state, and progress is made by calling its #tick method. This allows the board to update, and then propagate the #tick call to any objects in its tree. In between ticks, you can safely sample the new game state and render the results to your users.

This is somewhat analogous to how you would implement a traditional video game, where the game's main loop updates the simulation and draws the results on screen. You may need to modify this to fit a web environment, i.e. a request handler could obtain a read-only snapshot of the game state for rendering while the simulation continues to make progress.

Cheers,

--

Jeremy Voorhis

[Manuel González Noriega]

So, if I got it right, I would only keep a singleton World class
running in memory, and it, using a Celluloid timer, would invoke its
own 'tick' method after X seconds that would in turn call (better if
asynchronously) the "tick" method on other objects such as instances
of the Pet class.

Yeah, I can see how that's probably the best way to proceed. Thanks a
lot to you and Josh.

[Manuel González Noriega]

The "reading" part of the world state is less of a problem, as the
user interface feeds mainly from Redis-based pubsub nodes and
timelines (i.e. the "pet" publishes events such "I have barked" to
Redis and the "Fido has barked" activity is stored on a timestamped
sorted set), so I reckon that abstraction layer is well covered.

Thanks again.

On 21 February 2013 23:00, Manuel González Noriega