Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (117)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Scattered storage model?  (Read 8627 times)
0 Members and 1 Guest are viewing this topic.
Offline Ragosch

Junior Member




Java games rock!


« Posted 2006-05-28 03:32:46 »

As I currently see it the only storage I can access safely from a GLO is the ObjectStore, because the execution of GLOs is farmed out on the cluster (i.e. no reliable "local" server) and to open a socket and read/write data from/to a remote server will take too long and the GLO execution might be aborted before it is able to complete.

So all the data needs to be stored in the ObjectStore in order to be accessible from an executing GLO. Unfortunately a GLO loads in whole all the time to in order to be instantiated again. To get a more efficent data model which is able to act like an indexed file where I can access records only instead of loading the whole file every time, we would need to implement "file"-GLOs which hold references to "records" stored in "record" GLOs. This is not a very efficient way to do that, but without any normal way to use the underlying database (lets say via SQL or such) I see no way around this - all data needs to be stored in GLOs to be accessible from GLOs as it is currently implemented. Or am I missing a point here?

Ragosch
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #1 - Posted 2006-05-28 10:08:17 »

Hi

Yup, everything is a GLO. I'm not sure why you are after index file style access, replacing those was the point of DB's, GLOs are named objects, that can contain references to other GLOs. I'm curious as to what data it is that you want to load as indexed files?, we may be able to think of a nicer solution.

Cheers

Endolf

Offline Ragosch

Junior Member




Java games rock!


« Reply #2 - Posted 2006-05-28 10:37:48 »

It is not really that I want to access an indexed file - it is just that I dont want to read the whole "file" if I just want a few "records" out of it. There is a database underneath SGS - a SQL database - and therefore I wonder why we dont get SQL access to it to be able to store other data there, instead of splitting them into hundreds of thousands or millions of GLOs. A SQL query can deliver a rather sophisticated result set but with just naked GLOs we cant do such queries even the database to do so is there - that's my problem, because we need to store, organize and manage a massive amount of economical data for our game where access to database services would be fine - now we need to hold redundant copies of part of the data on the client machines, what causes additional synchronisation which would not be needed if we could access the underlying database system via SQL directly from a GLO.

This could be done asynchron in a way - a "query" GLO constructs a query and creates a new "result interpreter" GLO implementing an interface in order to be "called and executed" by the "result set ready" event. Then the "query" GLO requests the query from the task providing the GLOReference to the "result interpreter" GLO. Later when the result set is ready, the task loads and executes the "result interpreter" GLO passing the result set to it (much in a way an event loads and executes a GLO in the current implementation). That would be an elegant way to handle SQL queries while sticking to the "tasks are short-lived" rule.

I mean that is a real problem. Every sophisticated game will need some kind of database services which needs to be used from inside the game logic on the server-cluster and there is no safe way to establish a connection to a database from a GLO due to "a task is short-lived" rule. Like it is implemented now we would be force to use just a form of indexed file access or less without any possibility to use high-level database queries even the database is there. Hope it is more understandable now what I am after.

Any suggestion on that?

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

Senior Member


Medals: 1


shiny.


« Reply #3 - Posted 2006-05-28 12:24:19 »

Lazy loading?

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Ragosch

Junior Member




Java games rock!


« Reply #4 - Posted 2006-05-28 12:42:54 »

The problem here is not a loading method, but the need for a sophisticated database system if you have a game a bit more complex than this tank demo game. Our game has a real economy ingame (even it is a MMORPG) and users need to analyse economic situations, alter price lists, handle trade-routes, wagon loads and so on and so on. This is done best using a database system, but unfortunately with SGS I do not have a database system available which I can acess directly from a GLO (in the easiest case from the "player" GLO). All those fine things like SQL queries would not be available using just naked GLOs as the only storage available. All we have with this ObjectStore is a kind of transactional-safe "hashtable" - but no database system, even one is there underneath, and that is sad .... we would just need a method to access and alter it using SQL. Without any abiltiy to use a database system from the game logic, SGS is just a nice idea but pretty worthless for sophisticated games which are not just hack and slash style.

Ragosch
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #5 - Posted 2006-05-28 13:07:11 »

Hi

I agree, when there is a simple mapping and you want just a named object here and there, then it works well, but when you want to query the datastore and return a few results based on other related info, then yeah, I guess we have an issue.

A *really* simple example might be returning the top 10 priced objects in the market. In SQL, you just write a stored proc or a simple query, and let the DB do it's job, they have spent years and years developing fast quries like that, add an Index to that table, and it's nice and quick. In SGS we would have to load up every object in the market, sort them in memory by price, and then return the top 10.

I think Jeff is on vacation atm, so I dunno when he'll be able to get back to us, but one alternative might be to run the complex stuff like the market externally to SGS, have the client connect to a market server when needed. I hope Jeff has a better solution though.

Endolf

Offline abies

Senior Member





« Reply #6 - Posted 2006-05-28 14:28:50 »

I think that serialization is generally not a best idea for long term persistent storage. It becomes a LOT of pain after year or two, when half of code inside your objects is written to handle all the possible combinations of old data.

In one project I have worked for where we have used serialization for most data, we had string query field in addition to blob with serialized data in every row (in addition to timestamp, modified_by and version fields). It is overly complicated design done just to have same structure of table for every object out there, but something similar could be used here - in addition to object id and serialized blob, there can be any number of extra columns duplicating some of the data from object. You could then decide what aspects of given object you want to use for sql queries, with all the rest, less important data being hidden inside blob.

In market example, stuff like location, price, object type, quantity, owner, expiration date could be exposed, with detailed description, object itself, vendor percentages etc being hidden inside serialized data only. If at some point more data is required, it would be one time offline extension of database by a column and going through all serialized objects, rewriting them to database.

Anyway, I think that at some point, for most serious projects you will end up with using just normal sql storage, with explicit store/load code (maybe using some mapping tools) and dropping serialization completly, except maybe some intra-server communication if needed. SGS does not support it at the moment, but I don't think it should be too hard.

Another possibility would be to use some kind of fully object-oriented database and creating some kind of EJBQL... I mean SGSQL... but I'm afraid this would be outside of scope of this project.

Artur Biesiadowski
Offline emerald

Senior Newbie





« Reply #7 - Posted 2006-05-28 18:31:15 »

abit side track: does anyone knows how large(capacity) is the storage of the ObjectStore?  Huh

feelin rusty
Offline Ragosch

Junior Member




Java games rock!


« Reply #8 - Posted 2006-05-28 23:42:07 »

abit side track: does anyone knows how large(capacity) is the storage of the ObjectStore?  Huh

Currently the derby java DB is underneath - there are practically no limits beside those given by the OS. But Jeff mentioned HADB for their "big" solution. They wont choose a limited db, I guess, but you cant count on a specific db with SGS.

Ragosch
Offline Ragosch

Junior Member




Java games rock!


L
« Reply #9 - Posted 2006-05-29 00:11:54 »

Hi

I agree, when there is a simple mapping and you want just a named object here and there, then it works well, but when you want to query the datastore and return a few results based on other related info, then yeah, I guess we have an issue.

A *really* simple example might be returning the top 10 priced objects in the market. In SQL, you just write a stored proc or a simple query, and let the DB do it's job, they have spent years and years developing fast quries like that, add an Index to that table, and it's nice and quick. In SGS we would have to load up every object in the market, sort them in memory by price, and then return the top 10.

I think Jeff is on vacation atm, so I dunno when he'll be able to get back to us, but one alternative might be to run the complex stuff like the market externally to SGS, have the client connect to a market server when needed. I hope Jeff has a better solution though.

Endolf

I basically have pointed out how it could be integrated without breaking the current system. There need to be an interface for an "result set ready" event. This interface needs to be implemented by a GLO which is intented to work on the result set as soon as it is available. This GLO would be loaded and executed via this interface much in the way GLOs are loaded and executed by SGS events now. There needs to be a method in the task object which takes a SQL query and the GLOReference to that GLO which implements this "result set ready" interface. The task can now query the underlying database and prepare the callback when the result set will be available. When the result set is available the SGS should load and execute the GLO listening to this event. An asynchron elegant way to integrate this into the current model without exposing the underlying database too much.

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

Junior Member




Java games rock!


« Reply #10 - Posted 2006-05-29 00:32:47 »

@abies:

The current model of SGS is pretty good as far as you need to work with data synchronized to its handling methods (i.e. objects). The use of GLOs is perfect for breaking down program execution into slices which can then be farmed out on the server-cluster using a central persistent and transactional-safe storage. So far so good. But all those mass data with sophisticated query needs cannot be integrated into this model nice and easily - the nature of data retrieval here is asynchron and not synchron. It could be broken down into 2 steps,  a GLO starting the query and another one which is started when the correspondenting result set is ready to work on. But SGS would need to offer some kind of SQL support through the task object (the SGS context for GLOs).

Ragosch
Offline Ragosch

Junior Member




Java games rock!


« Reply #11 - Posted 2006-05-29 03:09:56 »

I think Jeff is on vacation atm, so I dunno when he'll be able to get back to us, but one alternative might be to run the complex stuff like the market externally to SGS, have the client connect to a market server when needed. I hope Jeff has a better solution though.

The problem here is that market data are basically effected and produced by actions inside the game. And there is no real good way to access any other storage than the ObjectStore from GLOs. You could use a special client as a server to be able to access a database elsewhere, but this would be a horrible hack, and I really hate hacks. There is no way currently to access another storage than the ObjectStore from GLOs, and that is the place where market data manipulation happens. So there is no real good way to use an extern market server like you suggested.

Ragosch
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #12 - Posted 2006-05-29 07:53:23 »

Hi

I was meaning that the game client runs 2 connections, 1 to SGS when in game, and 1 when needed to the market server. Use SGS for what it seems to be good at, ie, the movement control and game object management, and an interface to a DB for what they are good for, fast queries over larger data sets.

SQL can't be called on SGS object store as the whole GLO is stored via serialisation (if memory serves), so there is no way to query any of it's members.

Endolf

Offline Ragosch

Junior Member




Java games rock!


« Reply #13 - Posted 2006-05-29 09:15:04 »

As I pointed out the alteration of market situation happens inside the game logic (in the GLO pool). Now how do you expect these data to be transferred to an extern database?- That is the problem here, because you cant access anything outside the SGS beside connections to the clients. So you need either do a hack with a fake client which is actually just a way to transfer SQL commands to an extern database or you need to make a design enhancement to the SGS providing some basic SQL access via the SimTask object to the internally used SGS DB. How this services could be integrated into the current implementation of the SGS I have suggested twice in this topic ... if there are any questions please ask because I dont know how to explain it any better yet. But this is a really vital problem for all games which are not just "very basic demos".

Ragosch
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #14 - Posted 2006-05-29 09:20:47 »

I would looking into embedding the sgs client into the market app/server using the sgs as a layer between

player
-------
SGS
-------
market

and in this setup using the SGS as an kind of cach at the same time. security wise it should be easier complexity wise it should be simple since the client only needs one connection then a market is usually represented by a few npc's anyways. (call it a hacked client if you must I gues.) I'm sure there are other perhaps more elegant solutions but I don't have time to look at it.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Ragosch

Junior Member




Java games rock!


« Reply #15 - Posted 2006-05-29 09:24:40 »

SQL can't be called on SGS object store as the whole GLO is stored via serialisation (if memory serves), so there is no way to query any of it's members.

That is not what I trying to achieve. I want to use database features of the underlying SGS database via SQL (by enhancement of the current SimTask-services). This way mass data would not be stored in the ObjectStore via GLOs but in a normal way using the underlying database. GLOs would be just those world objects and some special GLOs use to communicate with the SQL-database over a process similar to that I have suggested (asynchron query/result processing). I dont want database services to objects in the ObjectStore, just a bypass access to the underlying database using SQL in oder to use this database in the normal way including creation of new tables, sophisticated queries and such.

Ragosch
Offline Ragosch

Junior Member




Java games rock!


« Reply #16 - Posted 2006-05-29 09:32:12 »

Tell me how I can transfer data from the SGS to an extern database without using a bridge fake client which is just there to do transfer to and from extern database to the SGS - this is a horrible hack and will not perform very well. The other solution of just using the database underneath the SGS which is already there and could provide all those services easily would be much better and is also really easy to implement (but it needs to be provided by the SimTask object and the callback needs to be done with a special "result set ready" interface implemented by the 2nd GLO which will process the data requested later - the later would just work in the same way GLOs are loaded and execute by events in the current implementation of the SGS).

Ragosch
Offline Ragosch

Junior Member




Java games rock!


« Reply #17 - Posted 2006-05-29 09:44:40 »

a market is usually represented by a few npc's anyways.
We dont have this kind of fake economy. We use a real economy based on supply and demand, desire, reputation, social status and a complex hierarchy of markets of up to 750,000 characters in game. We have 2 economists in our team in order to create a real working economy in our game, not just a fake like in nearly all other games. Maybe now you can imagine that we really need database services for this, not just a few named GLOs accessed in a hashtable like manner.

Ragosch
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #18 - Posted 2006-05-29 10:40:17 »

how does a player interact with the market then? action wise and performace wise. how real time is real time?    yocto seconds? how are these markets connected economi wise? knowlage is power how fast can market knowlage posibli be gattered, are you modeling the the economi in abstract sence do you actually the requirements you set if you do then could you outline it? I say this because Invoice's should have a human like time span that they are valid. (I mean ppl actually need to be able to read an invoce before that they can decide if they agree or not,.) where do invoces come from? a person? a computer? undoubtly the player needs some way of interfacing with the market. an npc can exsist in many forms. there can be many of these and If they need a common mind set you can tie those togetter.

a database is non redudant per default this means that anything that can be calculated shouldn't reside in it. however you are gonna need the computed values some where in your game I sugjested storing those computed values as GLOs where as the actual database is.

it won't perform badly if implented right the main objection will always be that it's achitechtually ugly and will introduce failover-issues.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Ragosch

Junior Member




Java games rock!


« Reply #19 - Posted 2006-05-29 12:15:30 »

Unfortunately it seems that I didnt have explained it good enough, sigh.

The problem is that I cannot access any other storage then the ObjectStore from GLOs in an elegant and safe way. I personally hate the idea of using a special client as gateway to an external database - simply because it is a client which would need to act like a communication server between SGS and an external database - what a hell of a hack, I hate it - that really turns me off and lets me think of implementing the whole thing myself basing it on JXTA and drop SGS totally. It is kind of ridiculous that there will be no elegant access to a sophisticated database if one is already there but not accessible currently. And it will be not just me who demands database access from the game logic ... this is a central need for any game more than just a tech demo or cellphone game.

Ragosch
Offline Ragosch

Junior Member




Java games rock!


« Reply #20 - Posted 2006-05-29 12:33:17 »

See EVEs economy for example - there are local, regional and global markets, quite complex, realtime and like ours totally player-driven. Can you imagine such a system like EVEs market-system performed on a set of GLOs?- Not really, or are you able to?

Ragosch
Offline Mr_Light

Senior Member


Medals: 1


shiny.


« Reply #21 - Posted 2006-05-29 15:49:43 »

realtime is a relative concept around here, I'm not sure if I'm asking my questions wrong or I'm simply not getting responses. to keep from matters getting grim, I'm just gonna qoute jeff,  these where in response to something else but the problem is somewhat  the same.

You are correct that the design was somehwat inspired by Javaspaces and similar tuple space systems.

BUT none of the ones out there have the kinds of performance we need so the SGS rolls its own.  In the process we also simplified the model as we have no need to search based on anything other then ID or a name-table that maps names to IDs (Primary Keys in all cases.)

The SDK ObejctStore is a custom in-memory transactional store backing itself up to BLOBs in Derby.

The full back-end is currently using HADB, which is a technology that Sun bought (actually we bought the whole company.)  It is a destributed in-memory database that scales "near-lineraly" according to the developers.

Shawn Kendall at full sail/IMI and I have been talking about this specific problem some.  To *really* take advanatge of the architecture you would want to develop a physics model which can handle parallel computation.  this would allow you to properly spread your load across the SGS back-end.  We provide the key primitive for such aprallel problems== which is the ATTEMPT form of GET.  You can see how this is used to paralelize the processing of timer events in the PDTimer source code.

Actually developing the destributed processing algorithym though I have a feeling is an un-done research project.  Anyone looking for a good thesis subject?  Cool

Short term, you can punt and do what you woudl have done anyway-- build a seperate physics server process around your favorite physics library.  You can then talk to it from the rest of your logic through the Raw Socket Manager in the SGS.


It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Ragosch

Junior Member




Java games rock!


« Reply #22 - Posted 2006-05-29 16:15:50 »

There it is - thank you very much - I have totally overlooked the ability to open a socket and get callbacks to a special GLO - you saved my day, thank you once more. Nevertheless it would be a good solution to use just the underlying database directly from the SimTask; anyway it can be done using these raw sockets and that is what's important ... cant believe I didnt see that, I have looked it over and over but didnt see those sockets ... strange sometimes.

Ragosch
Offline abies

Senior Member





« Reply #23 - Posted 2006-05-29 19:53:55 »

So, more or less, you are suggesting using GLOs for some of game objects, while leaving market to be totally outside of space managed by SGS ? How do you plan to do transactions then, like:

Get market offer
Get player GLO
Check money and deduct from player if needed
Put item into player inventory
Remove market offer

Imagine that after doing a commit on market database, SGS decides that your task is running too long and kills it, not committing transaction on player GLO. I don't think that you are allowed to do any kind of operation modifying any kind of state inside jvm or outside of it from inside a SGS task and still be safe from reexecution perspective.

All this starts to smell very EJB to me, two phase commits, container managing transactions for all the data sources, etc, etc. And we all know where EJB is as far as performance is concerned...

Artur Biesiadowski
Offline Ragosch

Junior Member




Java games rock!


« Reply #24 - Posted 2006-05-30 02:56:57 »

I think of updating the extern database asynchronously, not synchron with the running SimTask.

First the economic transaction is made inside the SGS and a GLO is constructed listening to Raw Socket Events ready to report the transaction to the database if the socket connection will be available. The last action on the SimTask is opening the socket connection registering the listening GLO; then the task ends.

As soon as the socket connection will be available, the GLO containing the transaction will be "started" by SGS and sends the economic transaction as an SQL command through the socket to the database, closes the socket and thats it so far - should be pretty fast, so no problem with timeout here. Hm, maybe I should use an XML document instead of a SQL command here in order to be able to transfer some meta data with it at the same time.

The only problem is how to get rid of this GLO again. It was started by an event, therefore it was accessed by GET and I cant kill it from inside the GLO because it would be written again when the task ends. Any ideas how to get rid of it safely after execution?-

Hm, maybe I should not kill those GLOs, because I could use them in the case I need to synchronize the external database again during a sheduled downtime for maintainance purposes. If they are still there, I could use them to redo all transactions from the last safe point of the database to the current state of the SGS and create a new safe point this way ... much better, just need to name those GLOs properly.

Thank you for your question, abies, it spend me a new idea on this  Smiley

To answer your question. I dont think of separating the market from the SGS. I just wanted an instrument to analyse the market in a sophisticated way outside of the GLO pool. The external economic data in the database is 100% redundant, just for supplying sophisticated fast answers to complex questions without the need to investigate thousands of GLOs. The database is not just covering market information, but also logistics and other important economic informations.

Ragosch

Btw: the clients would contact the extern database directly, just querying it to get sophisticated answers. There is just a reporting connection planned from the game logic to the database, actually just updating it, never requesting data from there.
Offline emerald

Senior Newbie





« Reply #25 - Posted 2006-05-30 08:02:27 »

abit side track: does anyone knows how large(capacity) is the storage of the ObjectStore?  Huh

Currently the derby java DB is underneath - there are practically no limits beside those given by the OS. But Jeff mentioned HADB for their "big" solution. They wont choose a limited db, I guess, but you cant count on a specific db with SGS.

Ragosch

Ragosch: thanks so much. i understands that currently each host contains onli 1 slice which is capable of handling 200-500 users, depending on the game and hardware. but i wonder if 2 hosts can access the same ObjectStore? If yes, how can i do that?

feelin rusty
Offline Ragosch

Junior Member




Java games rock!


« Reply #26 - Posted 2006-05-30 09:09:33 »

Ragosch: thanks so much. i understands that currently each host contains onli 1 slice which is capable of handling 200-500 users, depending on the game and hardware. but i wonder if 2 hosts can access the same ObjectStore? If yes, how can i do that?
The context to access the ObjectStore from any other GLO in the system is the SimTask object which you can get by a call to the static method SimTask.getCurrent() for example with the line

1  
SimTask task =SimTask.getCurrent();


Once you have this task you need a GLOReference to another GLO. Lets say you want to find and work on a GLO named "myTestGLO". First you get the GLOReference by

1  
GLOReference ref = task.findGLO("myTestGLO");


Once you have this reference you access the associated GLO via this reference using the task again as context like this (lets say this GLO would be of the class MyTestGLO):

1  
MyTestGLO glo = ref.get(task);  /* requesting a write-lock on the GLO */


You see you  never need to worry about where the ObjectStore actually is. If you have a GLOReference you can access the assiociated GLO at any time through the SimTask object.

Ragosch

Offline emerald

Senior Newbie





« Reply #27 - Posted 2006-05-30 15:11:55 »

You see you  never need to worry about where the ObjectStore actually is. If you have a GLOReference you can access the assiociated GLO at any time through the SimTask object.

Ragosch

hmm... ya, i kinda get wat u means by this. ie. 2 GLOs within the ObjectStore.

From what i understand, if 2 SGS, each lies on a separate work station or server, SGS1 talks to ObjectStore1 and SGS2 talks to ObjectStore2. there is no comm from SGS1 to ObjectStore2 and SGS2 to ObjectStore1 right?

is there a possible way for these 2 seperate work stations(different IP) to access a common objectstore?

feelin rusty
Offline Ragosch

Junior Member




Java games rock!


« Reply #28 - Posted 2006-05-30 15:31:52 »

No, you missed the concepts here. There is only 1 ObjectStore for 1 game. Even it might be processed on a huge server-cluster. All slices access the same ObjectStore. And because you never know on which slice a GLO is actually executed you access this unique ObjectStore through the SimTask object using GLOReferences.

You dont need to synchronize anything here, because there is only 1 ObjectStore which is accessed from all slices. SGS takes care of the transactions you do within 1 task. All changes you do are transferred to the ObjectStore on an all-or-nothing base. If execution of a task takes too long it might be aborted and requeued. Nothing has changed in the ObjectStore then; it is guaranteed that all changes will take place at the same time - that is meant by transactional-safe database manipulation.

If several games are installed on the same SGS each game has a separate ObjectStore even all installed games are executed on the same server-cluster. There is no way to access the ObjectStore of another game directly. Your connection to the ObjectStore of your game is the SimTask object. It provides all methods needed to access it. But it is important that you do not store a reference to the SimTask object and reuse it in another task; you need to request the current SimTask newly in every task using SimTask.getCurrent().

Ragosch
Offline emerald

Senior Newbie





« Reply #29 - Posted 2006-05-31 05:05:03 »

No, you missed the concepts here. There is only 1 ObjectStore for 1 game. Even it might be processed on a huge server-cluster. All slices access the same ObjectStore. And because you never know on which slice a GLO is actually executed you access this unique ObjectStore through the SimTask object using GLOReferences.

If several games are installed on the same SGS each game has a separate ObjectStore even all installed games are executed on the same server-cluster. There is no way to access the ObjectStore of another game directly. Your connection to the ObjectStore of your game is the SimTask object. It provides all methods needed to access it. But it is important that you do not store a reference to the SimTask object and reuse it in another task; you need to request the current SimTask newly in every task using SimTask.getCurrent().

thanks. i understands this concept  Grin

what i actually referring to is...

workstation 1(eg. of fake IP: 155.69.111.111) -> SGS installed -> Shooting Game
workstation 2 (eg. of fake IP: 155.69.22.22) -> SGS installed -> Shooting Game

so you can see that the SAME Shooting Game has been installed in each of the SGS on IP:155.69.111.111 and IP:155.69.22.22.
now my question: currently within SGS, there is no way for players logon to IP:155.69.111.111 to see players logon to IP:155.69.22.22 right?

feelin rusty
Pages: [1] 2
  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.

Grunnt (5 views)
2014-09-23 05:38:19

radar3301 (13 views)
2014-09-21 14:33:17

BurntPizza (31 views)
2014-09-20 17:42:18

BurntPizza (22 views)
2014-09-20 16:30:30

moogie (20 views)
2014-09-20 15:26:15

UprightPath (29 views)
2014-09-20 11:14:06

BurntPizza (33 views)
2014-09-18 18:14:18

Dwinin (48 views)
2014-09-12 00:08:26

Norakomi (75 views)
2014-09-10 04:57:51

TehJavaDev (104 views)
2014-09-09 21:39:09
List of Learning Resources
by Longor1996
2014-08-16 01:40:00

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

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

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

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

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

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

HotSpot Options
by dleskov
2014-07-07 16: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!