[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Great!



On Mon, 22 Nov 1999, Tim Brown wrote:
> Well, I just got back to coding my game.  I have also
> upgraded to ozone-0.3.2.  It works well.  Thanks for fixing
> the proxy bugs.  I actaully got paid to write a game in Java
> for work:)  So, it has kept me busy for the last month or
> so.  I just about have that done so back to the space game.
> 
> I have been able to have multiple RemoteDatabase connections
> with no problems.  The reason I have multiple connections is
> so the game client can send and receive both objects and
> text.  I use text for simple commands and objects where more
> information must be transferred.  I also developed something
> like OIG which generates non-ozone objects from OzoneObjects
> for faster transfer to my game client.

I've added your last patch of OIG. Thanks!

> e the game client
> connect to Ozone is that the game server (ozone client) can
> make many database requests and updates faster since it is
> local to the Ozone server.  If I make the game client a
> client of ozone it will require that I put more of the game
> logic in the client which will increase net activity.    The
> current design has the game client sending a request of some
> kind which is acted upon by the game server.  The game
> server may query Ozone repeatedly but will usually send only
> one answer back to the game client.

You can have as much of the game logic in the server as you like, even if game
clients connect directly to the ozone server (which is the game server as
well). In fact, this is the way to program efficient ozone applications of
any kind, not just games. If I got you right, you want to avoid net traffic by
having the (game) server interface on the highest abstraction level as
possible. Great! But why then grouping results of several database requests and
transforming to another format before sending to the client? Just put this
grouping/(transforming) logic in one method of your game server (which runs
inside the database) and call it via ozone RMI!

With your current architecture you avoid net traffic. Good. But the more
important performance bottleneck is every kind of external call - remote _and_
local! Even calls on a LocalDatabase are transactions! (copy arguments, start
new thread, check user permissions, commit/abort, write to disk, copy
results...) So the real task in order to make efficient ozone applications is
to avoid external RMI calls and making the interface between server and client
as small and efficient as possible. 

> I just thew that overview in in case someone has ideas that
> may help make my design better and also because Gerd and
> others have suggested I make the game client a client of
> Ozone.

Should we add your space game to the list of "ozonies" at ozone-db.org? It
seems to be a pretty complex example of an ozone application. I would like to
see it there.


Falko
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de