Game Network API
Author
I am a computer games student studying for a BSc(Hons) degree, for my dissertation I have chosen to create a network API for games.
The following is the current basic outline:
Open source.
Tcp and Udp connections.
Udp with ordered data(none reliable).
Udp with reliable data(unordered).
Data compression.
Server and client also maybe Peer 2 peer.
Runs on Windows, Linux and maybe Macintosh.
Threaded and single thread API, therefore also thread safe and non thread safe.
Grouping of relevant information to send to players, based on the API users specifications.
Further areas of consideration.
Encryption of data - player cheating.
Possibly to include voice communication.
Remote procedure calls.
Is there anything that you would like included into the API which you feel it lacks or a standard network feature which you feel is left out?
Thanks.
If you have any questions or recommendations, then please feel free.
It depends on how high-level you want to go. You could including sending an entire object, variable monitors (that watch variables on the server, and any changes are sent to the client immediately with no extra work), authentication, etc.
Variable monitors (there is probably a proper name for it) would definately be at the top of my personal list, as it allows you to focus on making the game, not keeping the clients in sync with every little change.
Variable monitors (there is probably a proper name for it) would definately be at the top of my personal list, as it allows you to focus on making the game, not keeping the clients in sync with every little change.
Sending entire object.
This is something which I have thought about, the programmer could just overload the insertion to a packet/stream for the object, if the object has pointers and such or use remote procedure calls(if included)
Variable monitors.
I think this falls into the relevant information section, this could use a design pattern like observer. One example maybe to use a sphere union(potenial visiable/audible objects) for data of interest etc.
What sort of variables are you thinking of? Do you think this would be covered by the above?
I should add this will be coded using C++.
Thanks for the comments.
This is something which I have thought about, the programmer could just overload the insertion to a packet/stream for the object, if the object has pointers and such or use remote procedure calls(if included)
Variable monitors.
I think this falls into the relevant information section, this could use a design pattern like observer. One example maybe to use a sphere union(potenial visiable/audible objects) for data of interest etc.
What sort of variables are you thinking of? Do you think this would be covered by the above?
I should add this will be coded using C++.
Thanks for the comments.
The observer pattern would work well nicely.
As for what items I was thinking of:
Player/Character names
Teams
Skins
Models
Health
Ammo
Speed
Direction
etc
Basically, anything that would need to be sent to the client. Different broadcasting types would be useful too, such as CLIENT_ALL (keeps all clients informed on the status of that variable), CLIENT_RANGE (only clients in a specified range) and CLIENT_OWNER (sends it to the client that represents the object).
CLIENT_ALL would be things like names, models and skins. CLIENT_RANGE would be speed, direction, animation, graphical effects, etc. CLIENT_OWNER would be health, ammo, shield/armour, etc.
Btw, you might get more of a responce if you ask a moderator to move it to the Multiplayer & Networking forum.
Best of luck!
As for what items I was thinking of:
Player/Character names
Teams
Skins
Models
Health
Ammo
Speed
Direction
etc
Basically, anything that would need to be sent to the client. Different broadcasting types would be useful too, such as CLIENT_ALL (keeps all clients informed on the status of that variable), CLIENT_RANGE (only clients in a specified range) and CLIENT_OWNER (sends it to the client that represents the object).
CLIENT_ALL would be things like names, models and skins. CLIENT_RANGE would be speed, direction, animation, graphical effects, etc. CLIENT_OWNER would be health, ammo, shield/armour, etc.
Btw, you might get more of a responce if you ask a moderator to move it to the Multiplayer & Networking forum.
Best of luck!
Author
I had not thought of this as a feature, but I could see that it would be useful to have something like a condition variable on another machine. As for groups of players/machines to send data this will be included.
Thanks
Thanks
you could make a session management,
opening sessions, finding sessions in a LAN,
joining sessions at a specific ip, etc.
that would be quite high-level, but no game can do without it.
opening sessions, finding sessions in a LAN,
joining sessions at a specific ip, etc.
that would be quite high-level, but no game can do without it.
I'd like to see a different kind of reliability that I don't know if anybody's added to a network stack yet. Sometimes I have small amounts (~1 packet) of data that might represent a player's keyboard state or the position of a ship. This data could easily be keyed so the network stack would know if I was sending an update of this information. I'd like this information to be reliably transmitted, however, if there's a newer update, I'd like that new information to go instead.
Example:
sendKeyedReliable( clientControlKey, clientControls );
//First packet gets sent out, but is lost on the way to the server.
//time passes, but not enough time for resend to timeout
sendKeyedReliable( clientControlKey, clientControls );
//Old packet is thrown away, new version is sent.
//On server side
result = getKeyedReliable( clientControlKey, &clientControls );
//If a new version has been received since we last asked, result is true.
It's not a big deal, but it's an idea.
Example:
sendKeyedReliable( clientControlKey, clientControls );
//First packet gets sent out, but is lost on the way to the server.
//time passes, but not enough time for resend to timeout
sendKeyedReliable( clientControlKey, clientControls );
//Old packet is thrown away, new version is sent.
//On server side
result = getKeyedReliable( clientControlKey, &clientControls );
//If a new version has been received since we last asked, result is true.
It's not a big deal, but it's an idea.
No, wait, I'm sorry, turns out Torque Network Library already does that. Object states, doncha know.
Author
Do you think having different ports for different types of communication would be a bad or good design choice?
I was thinking of having a port for normal udp communction and another for reliable udp packets, this would mean the realiable layer would only know and work with reliable packets on the designated port. Thus any packets which have been droped by the network or the timeout has elapsed would then be added to the buffer(and then tagged to the end of the packet, if it fits) of reliable messages waiting to be sent, rather than tagging the reliable message onto a non reliable message.
Handshaking on first contact could associate the correct ports in use.
Any ideas on this?
thanks.
I was thinking of having a port for normal udp communction and another for reliable udp packets, this would mean the realiable layer would only know and work with reliable packets on the designated port. Thus any packets which have been droped by the network or the timeout has elapsed would then be added to the buffer(and then tagged to the end of the packet, if it fits) of reliable messages waiting to be sent, rather than tagging the reliable message onto a non reliable message.
Handshaking on first contact could associate the correct ports in use.
Any ideas on this?
thanks.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
