Remote Shared Objects: Which is better, one array SO or multiple object SOs?

Question

I'm building a multiplayer game using Flash/Flex for the client and FluorineFX (just like FCS/FMS except it is written in .NET) on the server-side. My questions are regarding the use and performance of shared objects over RTMP protocol.

Essentially, I'm planning on having quite a few objects on screen simultaneously, each with their own coordinates, behaviors, visuals, etc. All users that are connected to the same room will be able to see and interact with these objects.

Using a single array shared object that holds all of the objects in the game world would make it extremely easy to sync all of the objects across all clients very quickly, but it seems that it could be performance heavy and that I would lose flexibility when it comes to security for each individual object.

Alternatively, using a different shared object per each object in the game world would give me a lot of flexibility in who gets what objects based on location (to minimize network performance), but I'm worried about the massive amount of shared objects with unique names that I would end up with, and having to get the client to constantly connect/disconnect to different shared objects as they move around.

I am not an expert when it comes to RTMP, but I have an idea of the advantages/disadvantages to each method of handling this problem, and I realize that I could technically use a mixture of the two concepts based on the situation, but I'm really looking for individuals that have experience using Remote Shared Objects from which I could glean some knowledge.

Anyone care to share their experiences on the topic?

Answer 1

We are using Flex-WebORB-MSMQ and RTMP to implement Pessimistic Concurrency, so the problem isn't exactly the same as we do not have constantly connect/disconnect. That's kind off my question, is it necessary to connect/disconnect when using different shared objects? What about using messaging and different channels for different objects? Intuitively I would chose for the second way where each object has a shared object, but if you really need to connect/disconnect each time, then I'm afraid things won't work smoothly anymore (I guess you would have to test that). On the other hand, if the objects are not too complex, using one Remote Object doesn't seem too much of a problem... Of course, if a user hasn't got permission to see one of the objects, then storing them in one shared object is kind off dangerous as the user could intercept the network traffic...

Answer 2

We are using Flash and FluorineFx for our game but shared objects seemed a bit "chatty" for our purposes so we opted for pushing messages down to the connected clients. This gave us full control over what messages to send, message priority, and the frequency.

Shared objects are good way to get up and running fast but you might find you run into performance issues later on.

Admittedly our game is a kids MMO so we aren't to fussed with synchronizing all clients perfectly and our multi-player mini-games are all turn based for this reason as well.

A lot of these types of decisions depend on what type of game you are building:

• Is it turn based or real-time?
• What is the maximum number of players for a game?
• How much logic is being handled on the client vs. the server?

There is a good book called ActionScript for Multiplayer Games and Virtual Worlds that talks about these issues.

Answer 3

I only have limited Remoted Shared Object experience and I haven't implemented anything "big" using remote objects so far, but rethinking the above comment by mr Cardoen, imagine having a game with 1000 rooms and 100 game objects in each room. As a player, you can only be in one room at once. If the game was designed so that all game objects were in one big SO, it becomes obvious that is not a good solution.

If the game really is designed like "the player can only see things in the room he's in", then you could have one SO for each room. But I guess it boils down to the game design.