Sign in to follow this  

Matchmaking

This topic is 3670 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

Hi, I have a few questions in regards to matchmaking. Firstly I was searching the forum for threads to do with match-making and came across http://www.gamedev.net/community/forums/topic.asp?topic_id=432973 where it was said that xbox live re-implemented TCP on top of UDP to get better NAT punch-through compatibility. Obviously the matchmaking needs to be done completely reliably, and my initial instinct was to go with TCP as it would have been well suited to something like this. However as my game is using UDP (and is essentially peer-to-peer with one of the clients chosen to run a listen server and the others connecting to that client) that would have resulted in some strange mix of using TCP and UDP (for the NAT punch-through) for the server which I don't think is a good idea. I already have a reliable message protocol implemented on top of UDP based on an article in GPG5 that is used in the game client occasionally however, thats more for mixing reliable/unreliable messages and I don't think it's quite suited to this - really TCP is suited to this but I need UDP. I have a pretty good understanding of workings TCP and don't think I'll have too many problems implementing ontop of UDP however I just wanted to check if this is a sane thing to do before progressing :) Secondly what would be the best way to structure the server in regards to threading? As it's a matchmaking server I can't imagine the performance or bandwidth requirements will be very high (I'd still like it to be able to support a fair few thousand players, and hopefully even be able to scale the server if the game ever takes off) ideally I'd like to get the design right from the start so I don't have to redo it too much later. Oh the server will be implemented in Java using Asynchronous I/O. Previously before I decided on delegating the game server to the client I had a dedicated game server implementation in which I was playing around with handling a large number of clients, the server supported multiple games being hosted. I had a single thread blocking on select() waiting for incoming datagrams, upon receiving a datagram the thread would stick it in a BlockingQueue (and go back to waiting for datagrams) that was serviced a thread pool. A thread from this pool would parse the datagram into some kind of message and then queue this message to be processed and executed on the next iteration of the gameloop (which had its own thread). Essentially I avoided synchronization issues at the expense of concurrency by using message passing between the threads. Would a similar design be any good for the matchmaking server? Heck is this even a good design? I'm pretty competent with threading however I have very little experience with any kind of scalable server design so any input would be awesome! Anyway sorry for the longish post, and thanks for your time if you read it :)

Share this post


Link to post
Share on other sites
Matchmaking consists of mainly a few operations:

1) Register a host with certain game parameters
2) Search for games matching certain parameters
3) Add players to a given hosted game roster
4) Start a hosted game roster (which un-lists it from the matchmaking)
5) Time out players or hosts that drop

These can all easily be built on top of whatever reliable mechanism you already have. If you already have reliable transmission on top of UDP, then that's what I would use.

Regarding threading: I wouldn't worry about it for now.

Share this post


Link to post
Share on other sites
Quote:
Regarding threading: I wouldn't worry about it for now.


So just stick with a single threaded approach? Also what would be the best method of determining who to delegate the server to? Currently I just calculate the round trip time using a ping packet and pick the user with the lowest RTT...

[Edited by - dbotha on December 1, 2007 7:52:11 PM]

Share this post


Link to post
Share on other sites
You can use any of three ways:

1) Pick whomever is hosting the game/level as the server. Not guaranteed to be the best RTT, but gives users control.

2) Pick whomever has the lowest RTT from some given machine (such as the matchmaker). This is what you're doing, and will likely screen out anyone with a truly poor connection.

3) Let each machine ping each other machine, send the data to the matchmaker, and run some numbercrunching on the matchmaker to figure out who would give the lowest overall ping, or fairest balance, or whatever else you want to optimize. More work, could improve the average game somewhat over the other two.

Personally, I don't think 1) is bad, because users are in control. Users are, overall, pretty smart.

Share this post


Link to post
Share on other sites

This topic is 3670 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