Game Networking Design Critique

Define the interfaces first, Gun/Gernade/Bullet, Wall/Floor/Street are detailed concrete classes. They may be useful examples to thnk through to figure out the interfaces, but they do not belong on this class diagram.

Start with the flow of time and how you are going to handle that. Once you figure that out, you can figure out how acquiring input, simulating the world, drawing graphics, & playing sound will work. (e.g. its quite different for a turn-based game compared to a RTS or a FPS, even the RTS and FPS can be radically different in how they handle time.)

Once you understand time, you can start to understand your simulation, then you can understand how the networking must work to support that model.

Another problem is that you have mixed two different object models into one diagram. Some of the classes are engine infrastructure (Lobby, Renderer, Actor) whereas others represent the game domain objects (Item, Tiles, Territories).
(If the goal is an iso-metric engine, then maybe Tile belongs in the infrastructure.)

Quote:

Original post by Shannon Barber Define the interfaces first, Gun/Gernade/Bullet, Wall/Floor/Street are detailed concrete classes. They may be useful examples to thnk through to figure out the interfaces, but they do not belong on this class diagram. Start with the flow of time and how you are going to handle that. Once you figure that out, you can figure out how acquiring input, simulating the world, drawing graphics, & playing sound will work. (e.g. its quite different for a turn-based game compared to a RTS or a FPS, even the RTS and FPS can be radically different in how they handle time.) Once you understand time, you can start to understand your simulation, then you can understand how the networking must work to support that model. Another problem is that you have mixed two different object models into one diagram. Some of the classes are engine infrastructure (Lobby, Renderer, Actor) whereas others represent the game domain objects (Item, Tiles, Territories). (If the goal is an iso-metric engine, then maybe Tile belongs in the infrastructure.)

Very true the concrete classes do not need to be included in a preliminary design document since the interface describes their functionality. However the Bullet class is still relevent because one of my problems is whether to keep the Bullet(s) on the server side or to have them stored on each client and updated based on time. Like I said I am still not sure how to implement the Bullets being drawn throughout their lifecycle.

Should the Actor draw the item and then the Gun draw it's Bullets?
Should they be queued?

The Renderer will be a timed frame rendering algorithm that contains a Canvas to draw to using the standard buffer strategy. Each visible Tile, Actor, etc will draw themselves.

You are right that I have not separated the Game Architecture from the Client/Server Archiecture. In my current implementation though I have a Game package, Server package, and a Client package. The Game package consists of the Actor, Item(And SubClasses), Map, Territory, Tile(and subclasses), and Game. The server package consists of Server, GameLobby, and ClientProxy. The Client package consists of the Client, Renderer, ProxyActor, Member, Group.

However I am considering leaving out Member and Group till other issues are resolved. I've just started working on this so I am still in the process of updating the design and didn't make the package separations to the UML yet.

One tip...

Its fairly difficult to identify problems with a given class diagram. Creating sequence diagrams for the important use cases will help you spot a lot of problems. I don't recommend spending lots of time doing this (especially at the class level where you classes will likely change quite ofen), but some quick sequences can show you if you are on the right track.

Lets take your current diagram, and figure out how the logic of "Rendering bullets from multiple clients" might play out. (And bear with me if I make mistakes, I don't know what each of your classes actually do and I making some assumptions... That will likely be wrong ;) )

Client 1 Player Fires Weapon:
1. Actor recieves ui command to fire (don't see classes to do this, because messages are tied to the proxy actor, and this is an actor firing).
2. Gun spawns a bullet object (Gun has a Bullet, presumably can call fire cmd)
3. Gun or bullet notify Game of the bullet's existance (Don't see how this is done).
4. Something sends the message that a bullet has been created to the server (I don't understand a lot of the client stuff you have. Client is both an actor and a client-proxy?

And so on...


Anyways building quick sequence diagrams is a very useful tool to help validate your static constructs.

Quote:

Original post by shaft One tip... Its fairly difficult to identify problems with a given class diagram. Creating sequence diagrams for the important use cases will help you spot a lot of problems. I don't recommend spending lots of time doing this (especially at the class level where you classes will likely change quite ofen), but some quick sequences can show you if you are on the right track. Lets take your current diagram, and figure out how the logic of "Rendering bullets from multiple clients" might play out. (And bear with me if I make mistakes, I don't know what each of your classes actually do and I making some assumptions... That will likely be wrong ;) ) Client 1 Player Fires Weapon: 1. Actor recieves ui command to fire (don't see classes to do this, because messages are tied to the proxy actor, and this is an actor firing). 2. Gun spawns a bullet object (Gun has a Bullet, presumably can call fire cmd) 3. Gun or bullet notify Game of the bullet's existance (Don't see how this is done). 4. Something sends the message that a bullet has been created to the server (I don't understand a lot of the client stuff you have. Client is both an actor and a client-proxy? And so on... Anyways building quick sequence diagrams is a very useful tool to help validate your static constructs.

Very good points... It would be a good idea to do the sequence diagrams.

Steps 3 and 4 are the most important which I missed in the design. The UI command to fire is contained within the Client and the client will call the ProxyActors fire method in turn invoking the Actors fire method using the Message sent over the network.

The client is also an Actor so that ClientProxy can be added seemlessly to the Game on the Server side without any passing or storing of separate objects. Thus there is only one object for all the Client data.

Instead of the Client having an Actor and having a Member and having to then create a new ClientProxy on the server and get the Actor from the Client and adding it to the Game.

All you have to do is create a new ClientProxy and give that object directly to the game thus eliminating a few extra calls.