Sign in to follow this  

Game Network API

This topic is 4071 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Do you think having different ports for different types of communication would be a bad or good design choice?


I think that's a bad idea, for two reasons:

1) You want to make it as easy as possible for people behind firewalls to host serevrs. Forwarding more than one port is annoying.

2) There is per-packet overhead of the IP and UDP headers (28 bytes), as well as your own framing, and the low-level framing. You really want to pack as much data as you can into each packet, and schedule packets at a regular rate of X times per second. Combining all data into a single packet, you can put a single packet sequence number in the packet header, and use this for both timing and reliable determination.

Share this post


Link to post
Share on other sites
That's funny, to me, #1 is absolutely goddamn critical, and #2? Bleh, doesn't everyone have reasonably fast connections these days? Of course, no one wants unneccesary overhead, but I could certainly live with this.

Also, another really handy feature:
NAT punch-through

[smile]

Share this post


Link to post
Share on other sites

This topic is 4071 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this