Question

I’m part of a team designing the server for a client/server model naval warfare video game (University course). We have a fairly concrete (well, I think) system design, but there is one aspect that bothers me.

The basic layout of the system is:

Server [thread] (handles incoming connections)
|
Game [thread] (deals with game events in it's work queue and sending messages to clients)
|--Environment (holds environment variables, deals with collision)
|--Client(s) [thread] (handles incoming messages from client sockets and adds events to the Game's work queue)
    |--Ship (holds game data, eg: hit points, fire power, etc)
    |--Parser (parses client messages and creates game event objects)
|--GameEvent (event objects held in a queue that can preform appropriate work and send appropriate responses to clients)

Now, my issue is that both Client and GameEvent (and probably Environment, once we get to it) need a reference to the Game object that they belong to.

Clients need to add GameEvent’s to the Game’s work queue.

GameEvent’s need to access other game data (other Client’s Ships, Environment).

Is there a better/more conventional method instead of having these objects store a local reference to their Game? What about declaring all of Game’s methods as static? We only need to handle one game at a time, so there wouldn’t ever be more than one instance of Game…

I’m sure there is a convention for a system with one central object that has many helper objects that need to reference it.

Answer 1

Did you consider using a Dependency Injection framework like Guice? There you have config classes called “modules”, where you bind your interface Game to an implementation (you can decide if you want a singleton or new instances). A Client class would look like

public class Client {
   private final Game game;

   @Inject
   public Client(Game game) {
      this.game = game; 
   }   

   ... 
}

You can construct this class as usual, providing a Game instance (e.g. for testing, using a mock Game class). But if you let Guice create this instance for you (which doesn’t need to be directly, it works as well if another class injects Client), you get automatically the instance specified in your Guice module.

I know it takes some time to wrap your head around that concept, but I can confirm that this leads to cleaner, more flexible code.