Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
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  
  GLO advice + ~bug found in SwordWorld demo  (Read 2051 times)
0 Members and 1 Guest are viewing this topic.
Offline c4scroller

Senior Newbie





« Posted 2006-07-01 01:53:48 »

Hello,

(1) I would like some advice regarding the design of GLOs, in particular the sort of scale that one GLO should occupy (in terms of object size/responsibilities). i.e.:

If I want to represent AI players in, say a local world of 50 players (Human and AI), should I just have one GLO to represent all the AI players, or an individual GLO for each one? Should I avoid using GLOs at all for AI players?

 I am aware that this all depends on the type of application/load/users/world size etc., but just some ideas or tips more than anything would be useful.

(2) I believe I have found a 'bug' in the SwordWorld java code, though it might be deliberate or already have been fixed in newer versions: For ages I could not figure out why my simple server program (which is very similar to SwordWorld.java) was never 'remembering' players (by this I mean it never seemed to find existing GLOs for players logging on repeated time). Looking at SwordWorldBoot.java, the problem (if it is considered one) lies in the fact that when a GLO is _not_ found (the initial lookup gives == null), the ensuing operation to create it does not include the player name just used:

i.e. the line: 
            playerRef = simTask.createGLO(playerTemplate);

should be

             playerRef = simTask.createGLO(playerTemplate, playerName)

Without that, the GLO created in the absence of a searched-for GLO is 'nameless', 'never' to be found again.  Grin

Best wishes
Greg

Offline bahuman

Junior Member





« Reply #1 - Posted 2006-07-01 03:10:26 »

I'm no expert on PD/SGS, but since GLO's have some resemblance of beans, I think you should consider the following:

doing a GET for a GLO is probably expensive. So the less GLO's you need to get, the better. This would encourage you to make a few, large GLO's.

however, the bigger your GLO, the higher chances are that two tasks will want to GET the same GLO. This encourages you to split your GLO's in the smallest units possible.

In your question: suppose player A wants to talk to bot#1, and player B wants to talk to bot#2. If both bots are taken care of by the same GLO, player B will have to wait until player A is ready talking to bot#1. This will cause a performance hit. On the other hand, if there's a GLO called "bot1" and a GLO called "bot2", player A can GET "bot1" and talk to it, while at the same time player B will get "bot2", and talk to it. Your server will be able to handle more clients at the same time.

Conclusion: I think you should split it up as much as possible.
Offline abies

Senior Member





« Reply #2 - Posted 2006-07-01 18:13:21 »

Hello,

(1) I would like some advice regarding the design of GLOs, in particular the sort of scale that one GLO should occupy (in terms of object size/responsibilities). i.e.:

If I want to represent AI players in, say a local world of 50 players (Human and AI), should I just have one GLO to represent all the AI players, or an individual GLO for each one? Should I avoid using GLOs at all for AI players?

Think about having to serialize/deserialize all of the every time you want to access even one property on single of them...

I think that you should have certainly at least one GLO per NPC. Depending on how your game is structured, I would even consider splitting inventory/dropped items/shop data/whatever in separate GLOs.

I would start with having everybody and their dogs as separate GLOs and merge them only if it proves to be a performance problem at some point because of mutliple gets (or/and if you will observe patterns that some GLOs are always accessed/modified together with another ones).

Artur Biesiadowski
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #3 - Posted 2006-07-02 23:08:18 »

These gusy have about summed it up.

Locking a GLO is an expence.. but so is deserializing a huge one.

In general today the DB costs outweigh the serialization costs HOWEVER
the more you put ina single GLO the less paralelization you are likely to be able to get.

(The degenerate case is a GLO that *every* event needs to lock.  At that point you have a prgoram that will only ever run on one core  in the back end.)

If this is timer drive stuff keep in mind that the PDTimer uilitty tries to destribute the timer events across the entire back end.

Finally, keep in mind that PEEK is cheraper the GET *and* does not block.  Therefor if all you are doing is inspecting a value,
consider using PEEK rather then GET.

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 DanK

Junior Member




Javver games rock yawel!


« Reply #4 - Posted 2006-07-03 05:42:59 »

Speaing of the swordworld demo it also has a player object that keeps a reference to the channelid object, it doesn't seem like this should be good since the channelid is only valid until the SGS restarts, or am I misunderstanding something?

Offline Jeff

JGO Coder




Got any cats?


« Reply #5 - Posted 2006-07-04 23:15:05 »

This is currently true but I believe if you walk throuh the code you will find it gets reset everytime boot() is called.

In the future we actually have on the drawing board to extend the life of channelIDs.

Edit: I looked at it and your right,  it needs to be updated on all players on boot, on each player on userJoined (probably easiest and simplest),  or not cache in the player object at all.  This *will* change, but its true today.

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

CogWheelz (14 views)
2014-08-01 22:53:16

CogWheelz (14 views)
2014-08-01 22:51:43

CopyableCougar4 (15 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (35 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

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

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

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

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

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22
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!