Question

This is a school project, please do not provide any code, I am only looking for hints to guide me in the right direction.

Write and test a game server that clients subscribe to. Once subscribed, the client receives
a list of games (the same game, just different ‘instances’ of it) currently in play. The client may then elect to join a game or start a new
one. A game must have at least two players before actually starting. The system must support multiple clients all playing one game, or multiple clients playing multiple games.

The objective of this project is to gain experience in Java, TCP, and threading.

My current design and implementation has 2 files: server.java and client.java

1. The server file has 3 classes: Server, Lobby and Game
2. The client file has 1 class: Client.

The implementation of the “game” is trivial, I am fine with that.

Currently, the server class establishes the TCP connection with the client class.
Each time a client is instantiated, the socket is accepted in the server class, and the program continues.

Continuing on, the server class creates the lobby class.

The lobby class is where I am having trouble with. By default, I am creating 1 “game” object, and passing in the clientSocket:

game g = new game(clientSocket, playerID);                 
g.start();

The game class extends thread, which I think is the correct way of doing it. Each “game” will be a separate thread, so to speak, so players A and B can share 1 thread, and players C and D can start a new game with another thread.

I am new to threads, but this is the best implementation I could think of. I ruled out having multiple threads for lobby’s, since that doesn’t really make sense, and multiple threads for clients is pointless too, so I think multi-threading the games class is ideal.

Right now, when I create 2 instances of the client, they are both joining the same ‘thread’ (they are both in the same game and can talk to each other).

How am I supposed to do it so that, a new player can type “new” or whatever in the lobby and create a new “game”, where it’s a new thread.

I’m sure I mis-understood certain parts about threading or whatnot, but I appreciate any help.

Answer 1

Firstly, I would suggest you read on multiplayer game development and networking in Java (UDP/TCP). I am no game-developer but simply happenned to take a Java networking course in college and had a similar project (a networked game).

Secondly, dealing with multiple threads is proportional to complexity. You want to minimize complexity. I would suggest to abandon an “I have to find a place to use threads” mentality. (Don’t force a square peg in a round hole ;))

Continuing, following through the requirements:

Write and test a game server that clients subscribe to.

IIRC, this is fairly straightforward (and you’re probably past this part).

Once subscribed, the client receives a list of games (the same game, just different ‘instances’ of it) currently in play

This should be fairly straightforward as well since a TCP connection between the server and client have been established already.

However, there are a couple of things to understand at this point. The most important, perhaps, is that there will be a single central server that will hold information on all connected clients and existing games. This consequently means that it has to be the one to deal with the state of the system (e.g. tracking currently existing gamerooms), client requests (to create/join gamerooms), as well as updating clients with relevant info on the system’s state (e.g. created/closed gamerooms).

Another consideration at this point is the scope of client’s functionality in the system. A typical implementation would probably be a fat-server, thin-client architecture. Basically, this means that a client does no real processing of data (from user input) and instead relies on the server. Most of the time, then, the client is only waiting for input from user or a response from the server. On the otherhand, the server deals with the processing of data from clients, updating the system state (including individual game states), and notifying concerned client of relevant changes in the system/game state.

The client may then elect to join a game or start a new one

What actually happens here is a client sending data “I elect to join a game” or “I elect to create a game” to the server. The server acts on this and notifies concerned clients (I say concerned and not all since some clients could possibly be playing and do not need to know whether new games have spawned).

A game must have at least two players before actually starting.

–

The system must support multiple clients all playing one game, or multiple clients playing multiple games.

Again depending on the client-server architecture, either the server will be doing all the processing (fat-server, thin-client) or the clients (thin-server, fat-client) do the processing while the server mainly serves as a relay point to other clients. I have no definite (or even confident) suggestion on this, however, as I am simply overwhelmed by the sheer number of possible implementations and their consequences. Thus, I can’t really encourage enough to read more on networking and game development. Individually, those 2 topics are incredibly vast, much more when combined.

Lastly, with regards to the use of threads. IIRC, dispatching separate threads for opened sockets are useful in preventing the application from getting blocked waiting for input. I don’t really agree with your idea of “hosting” a game in a thread but since you’re in school I can only admire your trying things out.

This may help you further: Lesson: All About Sockets. And you might perhaps also be interested in UDP.