You are right: IMVU is light on "game rules." (Except for a few of the games layered on top -- if you download it today, there's a pretty popular minigame called "Walk Off" that also works as a social match-maker.)

Specifically for enforcing game rules, the main challenge is getting the right users to talk to the right in-memory game rule engine. For slow, turn-based games (backyard monsters, etc) you can inflate the game state, apply one player's action, and then save back to persistent storage. However, for real-time games, you need to keep state in RAM, and get messages to/from that RAM, on a suitable deadline. Perhaps this is the subset of MMO that you're really interested in? (As opposed to, say, subscription billing systems, which are at least as complex :-)

I wouldn't store such content into RAM, the server wouldn't support it, better to use Redis for instance for such purpose. Just faster in I/O operations than RAM, assuming you don't need to keep any history of the messages themselves. But you're right about the design.

• http://redis.io/

I wouldn't store such content into RAM, the server wouldn't support it, better to use Redis for instance for such purpose.

That doesn't work for real-time games rules. Games that use physical simulation, or significant game state (like, say, D&D) would spend all their time marshaling game state over the network just to serve a single request. It's much more efficient to keep the game state in a specific server, and checkpoint back to persistent storage once in a while.

Compare full-blown fist person shooters like Battlefield or whatever -- they certainly won't keep the data in Redis. Many of the reasons for why they don't do that, also hold true for other real-time games, even if they are more RPG-ish.

I guess it really depends on the kind of game you're building. But for a browser-based game I would prefer Redis, RAM makes more sense for something like Battlefield indeed. Redis is something to use on the server side, not the client. Sessions, temporary data and this kind of stuff should rather be stored there than in RAM.

I'm doing a thesis about MMO, but I'm also building one (well, trying to, at the very least), a browser MMORPG and it makes sense in this case to store the world map data, user sessions and more. I of course use persistent storage (mongoDB) to ensure data integrity. But I didn't talk about it sooner because I don't want to base my thesis on my own experience, since I am far too yound and inexperimented to have a clean overview. That's why I count on experienced developper's feedbacks to help me out.

use persistent storage (mongoDB) to ensure data integrity

Friends don't let friends use mongoDB in production. Redis supports persistency with about the same level of guarantee as Mongo, but is better about replication. Cassandra supports stronger consistency than Mongo, with a similar set of schemaless database support. And Postgres, MySQL, and friends support robust, serializable consistency and schema management, with high performance if you use them right. Granted, these are my opinions, and you'll find other people with different opinions, but I feel these opinions are based on pretty solid test and benchmarking over the years.

That being said, it seems I didn't make myself clear in how much the RAM-vs-datastore distinction matters: If your game supports real-time interactions, you will not get sufficient performance out of a Redis-based system, or any system that needs to inflate state for each game tick or each user command. If your game is turn-based, that might work, although the quicker the turns become, the more you'll start to pay for the inflation/deflation and networking. Note that even the best 10Gbit networking can only do about a gigabyte per second of throughput (and costs about $500 per port for switching + server NIC above 1 Gbit); modern servers do 50 GByte/s or more through main RAM. For real-time work, a factor 50 in efficiency matters!