My interest was piqued by the topic of this post.
I am not a gamer so all of this is new to me.
Some findings (in no particular order):
--currently, there only a few multiplayer iPhone games.
--most multiplayer iPhone games are limited to a local WiFi (BonJour) net
--There are only a few multiplayer iPhone games for the Internet
--Neither of the above work particularly well in my limited experience (lost connection & what's going on-- did it die or is is just really slow).
--Multiplayer Role Playing games (adventure games, etc.) likely just synch with all the other players to get their status
--Multiplayer Role Playing Games have a relatively low refresh/interaction requirement, and, likely, can tolerate the overhead (connections, handshaking, message ordering, guaranteed message delivery, retransmission, etc.) of a standard HTTP/TCP connection
--Multiplayer Role Playing Games could be implemented on the server as a specialized form of a chat application.
--There are other types of multiplayer games that usually involve high-speed graphics on the clients (think a multiplayer auto/horse racing game).
--The heavy lifting for these High Speed Graphics multiplayer games is done on the client (the iPhone).
--The High Speed Graphics multiplayer games need information on the status of other users: x/y/z location, direction, speed, etc. as well as other less dynamic info.
--In order to sustain a reasonable frame rate, the High Speed Graphics multiplayer games need more frequent data exchange (synching) with other players (through a server).
-- The overhead of HTTP/TCP is, likely, too great to support more than a few players in a High Speed Graphics multiplayer game.
--Servers for High Speed Graphics multiplayer games are typically specialty programs written in C++ and use UDP protocol rather than HTTP.
--UDP is a connectionless protocol where a message is composed and sent. There is no handshaking (you don't even know if the recipient is there), no message ordering (message 1 arrives before message 2), no guaranteed delivery, error detection, retransmission. We're gaining performance and sacrificing reliability. The theory being: "If we drop some messages, so what?. Another one is coming right behind it. We can finesse the dropped messages in the client app or just experience a momentary lag.
Some conclusions?
-- If the data exchange (synch) rate is low (say 300-500ms) and the app supports say, under 30, active players in, say 15 rooms) you could build the multiplayer server as a specialized Chat Server using HTTP.
-- ColdFusionwould be a good choice for writing the app as it automatically compiles to Java ByteCode (rather than being interpreted as are PHP, ASP).
-- There should be free, open-source chat apps available for most languages-- ColdFusion has some, I assume the others do, as well.
--You may be able to find free, open-source UDP examples to allow you to support more interaction, more players, better frame rates, etc.
-- Bandwidth does not appear to be a limiting factor, rather the overhead of the protocol (HTTP or UDP).
-- Given the above, you should be able to prototype a multiplayer game server on a local machine, with little (or no) expense for software and limited amount of time to write the code (just modify existing, working, examples).
-- For initial production, you could, likely, use a co-hosting service in the $19-$99/mo range.
-- As needs dictate, you could upgraded to [limited-shared] hosting, dedicated, hosting, etc. to support a larger audience.
Anyway, let's see some great multiplayer iPhone games!
HTH
Dick
|
