GLO advice + ~bug found in SwordWorld demo

[c4scroller]

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. 

Best wishes
Greg

[bahuman]

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.

[abies]

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

Games published by our own members! Check 'em out!

[Jeff]

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.

[DanK]

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?

[Jeff]

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.