Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (552)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  source layout..  (Read 1494 times)
0 Members and 1 Guest are viewing this topic.
Offline MickeyB

Senior Member




my game will work, my game will work!


« Posted 2003-12-15 11:30:51 »

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?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline tom
« Reply #1 - Posted 2003-12-15 12:17:17 »

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.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2003-12-15 13:05:21 »

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.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 158
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2003-12-15 14:37:51 »

*** Moved to Networking ***

Seems more appropriate here.

Kev

Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #4 - Posted 2003-12-15 15:56:44 »

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".


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...

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline crystalsquid

Junior Member




... Boing ...


« Reply #5 - Posted 2003-12-15 20:39:15 »

Quote

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...


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
Offline Jeff

JGO Coder




Got any cats?


« Reply #6 - Posted 2003-12-16 01:51:44 »

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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2003-12-16 06:42:04 »

Quote


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.


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 Smiley 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!).

malloc will be first against the wall when the revolution comes...
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #8 - Posted 2003-12-16 11:04:17 »

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.

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (23 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (41 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!