[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Using distributed objects for games

From: Ivan Vučica
Subject: Using distributed objects for games
Date: Thu, 14 Jul 2011 00:50:35 +0200


I'm thinking about how one would go about using distributed objects in
an action game, and I'd love your input before spending what seems to
possibly be a lot of time to make this work, and then being
disappointed with the issues that arise.

Has someone successfully used distributed objects in situations that
do not require successful transmission? I'm looking at Apple's
documentation, and it appears to me that most of what I need to do is
instantiate a SOCK_DGRAM-typed NSSocketPort and use that as a
transmission medium, and then use asynchronous messages. However,
there appear to be timeout and other checks involved.

Is it possible to use distributed objects messaging over UDP? If I use
it combined with asynchronous messages, can I count on various checks
not intervening? Or would I be better off using plain, old BSD sockets

It seems to me a possibly interesting approach in context of an action
game: clients could simply issue messages such as -setPosition:,
-setDirection: and -fireBullet: to the server, and the server could
track this information and then broadcast processed information to
other client via similar -setPosition:, -setDirection: and other
messages, instead of doing the same thing the "old fashioned" way of
encoding these directives manually.

Using TCP is probably a bad idea since high-frequency messages such as
positioning and movement is usually treated as droppable in FPSes and
other action games, and is usually recoverable in the very next
received packet. I'd use a second communications channel based on TCP
solely for high-reliability messages such as firing a bullet, or
sending a chat message.

What are your thoughts? Is this approach sound and reasonable?

Ivan Vučica - address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]