远程共享对象：一个数组 SO 和多个对象 SO 哪个更好？
我正在构建一个多人游戏，客户端使用 Flash/Flex，服务器端使用 FluorineFX（就像 FCS/FMS，只不过它是用 .NET 编写的）。我的问题是关于 RTMP 协议上共享对象的使用和性能。
本质上，我计划同时在屏幕上显示相当多的对象，每个对象都有自己的坐标、行为、视觉效果等。连接到同一房间的所有用户都将能够看到这些对象并与之交互。
使用包含游戏世界中所有对象的单个数组共享对象将使在所有客户端之间快速同步所有对象变得非常容易，但似乎它可能会降低性能，并且当它出现时我会失去灵活性涉及每个单独对象的安全性。
或者，在游戏世界中为每个对象使用不同的共享对象将为我提供很大的灵活性，让我可以根据位置来决定谁获得哪些对象（以最小化网络性能），但我担心大量具有唯一性的共享对象我最终会得到的名称，并且必须让客户端在不同的共享对象移动时不断连接/断开连接。
我不是 RTMP 方面的专家，但我了解处理此问题的每种方法的优点/缺点，并且我意识到我可以根据情况在技术上混合使用这两个概念，但我我真的在寻找具有使用远程共享对象经验的个人，我可以从中收集一些知识。
有人愿意分享他们在该主题上的经验吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们使用 Flex-WebORB-MSMQ 和 RTMP 来实现悲观并发，因此问题并不完全相同，因为我们没有不断地连接/断开连接。这是我的问题，使用不同的共享对象时是否有必要连接/断开连接？对于不同的对象使用消息传递和不同的渠道怎么样？直觉上我会选择第二种方式，其中每个对象都有一个共享对象，但如果你真的需要每次连接/断开连接，那么我担心事情将不再顺利进行（我想你必须测试一下） 。另一方面，如果对象不是太复杂，使用一个远程对象似乎并不是太大的问题......当然，如果用户没有权限查看其中一个对象，则存储它们在一个共享对象中是一种危险，因为用户可以拦截网络流量......
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...
我只有有限的远程共享对象经验，到目前为止，我还没有使用远程对象实现任何“大”的东西，但是重新思考 Cardoen 先生的上述评论，想象一下有一个有 1000 个房间和每个房间 100 个游戏对象的游戏。作为一名玩家，你一次只能呆在一个房间里。如果游戏的设计使得所有游戏对象都在一个大的 SO 中，那么很明显这不是一个好的解决方案。
如果游戏真的被设计成“玩家只能看到他所在房间里的东西”，那么每个房间都可以有一个 SO。但我想这可以归结为游戏设计。
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.
我们在游戏中使用 Flash 和 FluorineFx，但共享对象对于我们的目的来说似乎有点“啰嗦”，因此我们选择将消息推送到连接的客户端。这使我们能够完全控制要发送的消息、消息优先级和频率。
共享对象是快速启动和运行的好方法，但您可能会发现稍后会遇到性能问题。
诚然，我们的游戏是一款儿童 MMO，因此我们不会太在意如何完美同步所有客户端，而且我们的多人迷你游戏也都是回合制的。
许多此类决策取决于您正在构建的游戏类型：
为了一场比赛？
客户端与服务器？
有一本好书，名为 ActionScript for Multiplayer Games and Virtual Worlds，其中讨论了这些问题。
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:
for a game?
the client vs. the server?
There is a good book called ActionScript for Multiplayer Games and Virtual Worlds that talks about these issues.