RTS Game Server - must private client socketServer connections be used?
Hi
it seems another expert suggested I stay in my comfort zone and go back to Java. Thanks for all the Python help. I learned a lot.
In my Java, RTS server, if I have my clients joining in TCP to begin handshaking working, must I create a private serversocket between that, each client and the server for game-play (game state authority) messaging in addition to UDP rapid game-play messaging? Must that be a serverSocket on the client?
I keep getting errors that seem to involve collisions, if I use the same ServerSocket on the server for everything, client joining, and then in game player movements, it explodes, and it seems to be socket entanglements at DataInputstream.read() lines and such, while read, writing may be occurring elsewhere from other clients.
If I have a system so that the server doesn't use one server socket for everything, collisions shouldn't be as hectic.
Of course, one socket can't handle the whole game from 4+ clients!
How is it done? What sockets must the clients and server have?
Do I send the user directives (e.g. mouse clicks to direct unit movements) via UDP or TCP? TCP guarantees attacks won't fail to occur, but then, must the server expect a message per cycle from each client? - even if NO_ACTIVITY message?
Thanks
it seems another expert suggested I stay in my comfort zone and go back to Java. Thanks for all the Python help. I learned a lot.
In my Java, RTS server, if I have my clients joining in TCP to begin handshaking working, must I create a private serversocket between that, each client and the server for game-play (game state authority) messaging in addition to UDP rapid game-play messaging? Must that be a serverSocket on the client?
I keep getting errors that seem to involve collisions, if I use the same ServerSocket on the server for everything, client joining, and then in game player movements, it explodes, and it seems to be socket entanglements at DataInputstream.read() lines and such, while read, writing may be occurring elsewhere from other clients.
If I have a system so that the server doesn't use one server socket for everything, collisions shouldn't be as hectic.
Of course, one socket can't handle the whole game from 4+ clients!
How is it done? What sockets must the clients and server have?
Do I send the user directives (e.g. mouse clicks to direct unit movements) via UDP or TCP? TCP guarantees attacks won't fail to occur, but then, must the server expect a message per cycle from each client? - even if NO_ACTIVITY message?
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
;)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
How is it done?[etc . . .]
UDP is meant for ultra-fast comms, as it's connectionless, meaning there is no guarantee that any (single) packet will be delivered. Those are the up- and downsides.
For rapid exchange of data such as the mouse clicks you mention, you would I suspect want UDP as it would be crucial in a fast-moving game that all players are apprised of the actions of the rest of the group as soon as possible. If there is a lot of clicking going on, then losing one or two here and there isn't probably going to make much difference. What would make a difference is if all those packets had to be re-routed by the server, back to the peer group rump. In which case, it would be better to consider a one-to-one relationship between the clients for UDP. As Doug is a games programmer, he'd maybe want to comment on this, but afaiac, in addition to what CEHJ said about TCP, I'd see this as your model, since VoIP, for example, over single-port UDP in Java would be pedestrian. IOW, you are looking at P2P networking; the server, just a muster point.
I imagine it would be key to put as much gui work as possible on the clients' shoulders, since you won't want to be adding that overhead to everything else that's going on.
ASKER
perfect.
The code is writing itself ;)
The code is writing itself ;)
perfect.
The code is writing itself ;)
Don't forget to share that secret from your yacht with us one day when you have a moment.
Doug