Game Development Community

A little help with networking

by Lyle Stanton · in Torque Game Builder · 01/06/2006 (12:30 pm) · 1 replies

Hello, Im having a little trouble understanding how the networking of T2D works. and was wondering if anyone could give me a few suggestions or tips to help get me started. I have hit a brick wall in the development of my card game.

I am making a card game that i want 2 people to be able to play over the internet.
this is how the networking part works.

1. The user clicks "Play Online"
2. This connects them to the server and puts them in a queue of people playing online.
3. As soon as 2 people are in the queue the server starts the game.
--- Pretty much like microsoft internet checkers. I dont want them to go through an Online LAN lobby.

Now do I have to make a seperate application for the Server, or would i just use the same application as the game?

Heres what im thinking. Please tell me if this is sounds like a good way of going about things or if im a total moron and have everything screwed up.

I have a CardGame Class that is derived from the GameConnection Class.
the CardGame Class will act as the main communication between the Player and the server.

I then would create another application that has a CardGameManager Class and put it on another computer that would be the server. The CardGameManager would have a linked list of all the current games being played.

Everytime a player moves his card or sets one down, the CardGame Class would then tell the CardGameManager on the server and it would update the players opponent with the appropriate position.

I probably have a million other questions, but does this sound like a good way to get started?

Thank you very much for your time.

#1
01/06/2006 (2:14 pm)
I'd suggest separating the player matching/queuing mechanism from the actual gameplay managing. Then you could have a master server that does nothing but pair players together automatically as you describe and you can then focus on how the gameplay communication happens as a totally separate issue.

Whether or not this same application also has classes that handle in-game communication or not is really a design decision. Are you going to have tons of people playing at once where server scaling might become an issue? If so, you might want to implement the actual gameplay-manager server into its own application so you can farm it out across multiple machines to handle the load. Otherwise you could keep it as one big application where after the queueing happens, another class in the app takes over game state communication.

You could also choose to directly connect the players to each-other once the queue/matching server has done its work, having one player's machine automatically act as the server/listener and the other as the client/connector with the queue/matching server sending each client the details like IP and such.