Archived

This topic is now archived and is closed to further replies.

Kanzure

Client -> Server -- how do I manage players (and other noobie questions)

Recommended Posts

Kanzure    126
http://www.allegro.cc/forums/view_thread.php?_id=299458&request=1062640103& If you look there, those are my questions. I have no professional or any answers at all that are helpful. I would like number one to be answered mostly, buttttt...plz help? Thnx.

Share this post


Link to post
Share on other sites
Megahertz    286
1) You can either use a linked list of TCPSocket objects or use a static array, possibly a static array of pointers. That way if you wanted to resize the array its leaves a little flexibility in doing so. This may complicate things further down the line and if youre doing multiple threads, you'll definitely run into some issues to make access to the list threadsafe.

2) Personally, and im not too sure this matters really, I like to recieve the data first, then do any processing based on the data recieved, then send out the results. It really depends on how your server is deisgned, if the Send/Recieve/Process stuff is all in different threads, then its prolly not going to make difference. If however all 3 are in the same thread, id opt for the way i described above. This way you dont have to wait for another iteration through the list of clients to be serviced to get the data in the mail. Seems like it would make things feel more responsive on the client side, but im not sure anybody would really notice the difference seeing as how the cycle through the list ideally goes pretty fast.

3) Yes its generally a good idea to send some sort of header information along with the packet. One of first things you should put in the header is a typeid for the packet and its length. What I do is have a generic packet structure something like this:


struct RawPacket {

int typeid;
int size;
int *data;

}


When ever data arrives on the socket it gets copied to a buffer. The first 4 bytes are the typeid and the second 4 bytes is the size of the packet. I keep appending data to this buffer until i have > 8 bytes in it. Once I do that I know how big the packet is and can create a RawPacket object, stuff what data I have into it and then finish filling it out with more reads to recv (obviously in the case of UDP you get the entire packet with one call to recvfrom so this setup isnt needed and you can stuff all of it in there at once). Once the packet is totally filled out I can push the packet onto the incomming queue for the client and the other thread will pop it off the queue and process it.

In the process thread I look at the typeid of the RawPacket and based off of the id I create the apprpriate packet object (i.e. PlayerPosUpdate), memcopy the data member of CRawPacket to the PlayerPosUpdate object, thereby filling out the final packet. I can then act on the packet based off the information contained in the PlayerPosUpdate struct and queue up an outgoing packet if i need to. To save yourself from a memcopy you could also just typecast RawPackets data member to the PlayerPosUpdate struct and access it that way.

There's a little more work involved than that but thats basically how it goes. I have a TCPConnection and a UDPConnection class and they behave differently to handle the differnt types of sockets (either SOCK_STREAM or SOCK_DGRAM) and what can happen if packets arrive out of order and all that in the case of UDP. Both can be derived from a base class so that you can have a common interface between them which really boils down to 2 common methods, pushpacket and poppacket. All the sending and recieving is taken care of behind the scenes.



4) Peer to peer, IMO, is a death trap best avoided. One of the challenges in making an online game is to have the game cheat free. Theres certainly cheating in Client/Server games, but because the server is the authenticator for all actions and because its out of the clients/players contol its somewhat easier to contain the cheats and prevent them.

Also given youve asked some of the above questions I'm assuming you have little experience with online game programming. In which case I'd start out going for a purely Client/Server model and addressing those issues first, once you have that down, then id start looking at peer to peer. Of course on the flip side you can shoot for the moon and try and tackle the issues with peer to peer, but its usually good to get the basics down and then gradually work up from there.

Hope this helps get you going in the right direction. This certainly probably isnt the best way to handle things, but it's whats currently working for me, so YMMV.

-=[ Megahertz ]=-


[edited by - Megahertz on September 5, 2003 2:14:05 AM]

Share this post


Link to post
Share on other sites