source layout..

Networking & Multiplayer
#1

Wasn’t sure where to post this. I am working on the classes for my game. In the past, when I have done a multiplayer game, I have written the client side that could be played without a server, then gone back and written a server with all new code/package. i.e Player.java in the client is slightly to very different form Player.java in the server package. One effort I did soley multiplayer and again duplicated source class names in the client and server but they had different code and functionality and in a different package. Is this norm or a matter of personal pref?

I see some source form others where they write one Player.java class and use it both from the server and client(obviously one goal of OO dev), with everything in one package.

Comments?

#2

I think it makes sense to separate the server and client into different packages. They may contain the same class Names. But thats ok as long as they don’t share any code. Shared code should go in separate packages.

#3

In the minds of embittered pro games devs (taken from a GDC roundtable, and heartily agreed with by all present)

“Always - without exception - put the client and server [send and receive] code as near to each other as possible…this means in the same class, preferably in the same method, and if at all possible each taking no more than 0.5 screens to display so you can see both simultaneously whilst developing, debugging, maintaining and extending”.

The overriding emphasis was on two things - always trying to do this and the fact that in reality it isn’t always practical nor sensible.

In almost all cases IME of implementing protocols, you can actually more easily code both sides (client and server) in a single class (or both halves of each part of the protocol in single classes).

IME development is also MUCH easier wherever you make just a single (set of) method(s) which are called by both server and client, just with different arguments. This is true even for non-symmetrical protocols - sometimes you end up with lots of “case-switching” code, which is generally bad in OO development, BUT this makes mistakes in design and implementation actually much easier to spot and fix. In total, your dev time is reduced because tracking down such mistakes accounts for a very large amount of dev time.

IME you sometimes also find that trying to implement a non-symmetric protocol in a single (set of) method(s) actually helps you to spot non-obvious symmetricality, and end up with really neat and clever and EASY TO MODIFY code - better than you would have had implementing them entirely separately.

Finally, the major counter-example is the OO paradigm of looking at how classes are LIKELY to change in the future. If your server is likely to fundamentally change frequently, for instance, independent of client changes, you theoretically should separate the classes and methods…however, because client/server methods are nearly always bound strongly to the underlying protocols which MUST change simultaneously on client and server, this usually is not an issue worth considering.

EDIT: despite the references I made to protocol implementation, I was indeed talking more generally about the actual server- and client-specific code as a whole. You obviously need to draw a line somewhere, with “protocol low-level specific stuff” being naturally better in shared classes, and “incidental high-level stuff - like the number of threads the server spawns on startup” being naturally better in separate packages.

#4

*** Moved to Networking ***

Seems more appropriate here.

Kev

#5

[quote]In the minds of embittered pro games devs (taken from a GDC roundtable, and heartily agreed with by all present)

“Always - without exception - put the client and server [send and receive] code as near to each other as possible…this means in the same class, preferably in the same method, and if at all possible each taking no more than 0.5 screens to display so you can see both simultaneously whilst developing, debugging, maintaining and extending”.
[/quote]
uhmm, ok, oh god, uhmm, well, ok…hmmmm

ok, here is why I asked the question. I have created the following classes:
Sprite
ImageSprite
SpaceObject
StarShip
SpaceStation
Planet
Moon
ShipComponent
ShipWeapon
ShipEngine
ShipHold
ShipCore
ShipShield
Player
GT6 (main app with fullscreen rendering)
Sector (Collection of SpaceObjects for display if within screen space)
GameConstants

ok, now…
GT6 takes player movement and adjust the offsets for all SpaceObjects in the Sector(excpet the players StarShip) then renders them thru sector.render().

For testing purposes, GT6 creates a Player, the player creates a StarShip and GT6 calls
player.render() which paints the players StarShip in the center of the screen. It is this StarShip that can have the ShipComponents. I was going to have 2-3 StartShip creation methods, one for the player and one for the other players taht will be in the Sector collection which will only have location data, ship image data, and player name/id. (Logical?)

I think I understand your comments on having the send and receive code all in one place. (though doesn’t this require taht you send your server and client out to clients, or jar it leaving out the server folder?)

Before I even get to the communication classes, I couldn’t decide whether to have a StarShip class in the server area that was slightly different from the StarShip class in the client area. Or use one with 2-3 different creation methods depending on whether its a server object, client object or other player in this clients sector.

doh!

I guess what I am trying to get at is should I have classes for the client that only really need painting capabilities. i.e location x and y, what image, id, and handle key activity for interaction, then the server side version that will be data driven, calcs, results, etc…

#6

There is no easy answer to this.
The more dependant the client is on a frame by frame update, the more susceptable the game will be to network lag.
Having the client able to perform most logic (particularly with respect to movement, changing local properties like routing more power to the shields, away from the engines etc.) then the less often you have to tell the server. This applies more if you can be floating around your own quiet area of space. You should also be interpolating between updates so the game looks smoother to the player. For a non-movement example, if a player arms his torpedoes, there may be a 2 second animation as they pop out of his ship into position. It is far better for the server to just tell the players that ship ‘x’ has started arming, than having to change the ship ‘x’ frame for every client on every update. By transmitting the ‘action’, the client fills in the details, saving you much bandwidth & server processing.

On the flip side, the more you allow (or require) the client to do, the more carefully you have to ensure client-server synchronisation. A simple way is generate a simple ‘checksum’ for each ship on the server every 10 seconds, and any clients that find their checksums do not match request a full update for that ship.

At the end of the day you have to decide what the game needs in terms of response times & smoothness, and what type of network you will be using (LAN or Modem Internet)

Hope this helps,

  • Dom
#7

So if you look at a game like NWN you can infer that the client and server are very different beasts. The client is a visualization system. The server is a rules and script processor.

I think when you start talking about WAN games in general this sort of separation of functionality starts making a great deal of sense because of the issues of latency and bandwidth.

Although I do know of commercial games that try to run “frame-rate” based simulations on the back end, frankly FWIS those games have REAL lag and performance issues.

#8

Actually, I think there is an easy answer. The OP’s suggestion is the best way, in general, to do things - at this high a level your client and server classes are doing completely different roles and will evolve independently (just think about how much of the server code you intend to change when you update your graphics rendering…). This might sound contradictory to what I said earlier :slight_smile: but AFAICS the context is now more clearly of ultra-high-level concepts?

In practice, this means they should be as separate as possible; they may temporarily duplicate logic, but sooner or later you’re likely to end up moving / removing the duplication.

If you’re worried about lag etc, the better solution is to have a three-layer architecture: Remote server (somewhere on net), Local server (on local PC), and Local client (drawing the pictures). Communication time between the local items will be near instantaneous, and you can put interpolation, dead-reckoning, and other fancy tricks inside the local server, so that the local client merely needs to render whatever it’s seeing on the local server.

One of the myriad advantages of this is that you can write the remote server and local client first, get your game running etc, and then at the last moment do the optimization - write the local server - without having to change ANY code anywhere in your existing classes (…almost!).

#9

thanks a ton! After reading all of this, I have moved to the thought process that seems to have come out of this…local client that does drawing, with server doing work. Then optimize if needed.
One key thing that I think will limit my lag concerns is that combat is not true real-time(no point and shoot with collision detection based on real-time location). My combat will be: pick a target, choose weapons array to fire, which actually fires that weapon. The server will check your weapon/combat skill for hit or miss, then compare weapon type to shileds and hull of target and decide appropriate damage, then send results to those that need it. As for the graphics, on firing, the server will notify of “action type” and then clients within range will see the graphical display of the weapon type firing in the general direction of the target.
Thanks again…you guys are great.