Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
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  
  Data Structures  (Read 6197 times)
0 Members and 1 Guest are viewing this topic.
Offline Dreamcatchermatt

Junior Member





« Posted 2010-04-12 05:02:10 »

Hi All,

I have been trying to think of a better way to hold all of the objects (planets, ships, etc) that make up my game in memory.

I have come across the TreeSet in one of my (i'll admit old) JAVA text books, and from the way it was breifly described, it seems a great way to organise all my objects, as they will all be uniuque and all have parent and child nodes.

is the TreeSet the way to go? Are there any obvious dissadvantages in using this data structure?

I have been serching on google for some tutorials as to how to use the TreeSet, but there seems to be little aditional information out there than the few paragraphs in the textbook. This has lead me to beleive that it may be depreceated, or no-longer supported.

If anyone has any hints it would be great Smiley

Thanks,
Matt
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #1 - Posted 2010-04-12 08:02:12 »

TreeSet is probably not what you want. Just use one of the lists - ArrayList or LinkedList. They have different performance characteristics depending on how you use them, but I doubt it's going to be an issue for you. I'd recommend ArrayList.
Offline pjt33
« Reply #2 - Posted 2010-04-12 08:15:23 »

TreeSet doesn't give you access to the nodes or to the parent-child relationship. It's a self-balancing tree, which means it rearranges itself to give good performance. If you want a collection in which no element is repeated (a set) and which remains sorted according to some sorting criterion then TreeSet is the class you're looking for. Otherwise it isn't. If you want a general tree structure you'll have to write it yourself or find some third party library.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Dreamcatchermatt

Junior Member





« Reply #3 - Posted 2010-04-12 13:58:16 »

Ok, I think I missunderstood exactly how the TreeSet works.

I am probably going to store space-ships in one structure and things like projectiles and sprites in another. Eventualy I would want to be able to handle upto 5000+ ships at any one time and 10,000+ projectiles (this project is for a space RTS).

Obviously this would put a huge importance on performance, expecialy for projectiles, particles, etc.

pjt33: whould this be an example of when the Set structures should be used?

I already have a self-coded tree structure that I am using for my environmental objects (stars, planets, moons, etc) and could look at making this more general.
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #4 - Posted 2010-04-12 16:02:17 »

Start out simple to get it working.  ArrayList should be fine.  But when you get up to the full online RTS example you may want to look at using Entity systems.

Offline Dreamcatchermatt

Junior Member





« Reply #5 - Posted 2010-04-13 14:41:29 »

In the Java contect, what is an Entity system?

I've heard them called 'like an agent based sytem but...', bit I'm not really sure what makes them different, and to be honist I think that the person explaining them hadent much of an idea either Smiley

I'm currently at university reading Ageht Oriented Systems Engineering, so if this is the case, that could be a fun little project to play with.

My only reason for shying away from an agent based aproach in this particular case is that generaly agents run within their own thread, and I'm not even sure if it is possible to run 5000+ threads on a 'normal' desktop pc or laptop.

Then again, I havent tried... looks like it could an interesting experiment.
Does anyone know if there is a thread limit of the top of their head?
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #6 - Posted 2010-04-13 19:18:33 »

As far as I understand, the two are completely unrelated. An agent-based system is usually used in AI-type situations, no? An Entity-based system is just a way of organizing everything in a game that is commonly used. It's also very simple.

Basically, everything that exists in your game is an Entity. Depending on how you want to design it, an Entity has different attributes. Usually this will be something as simple as position and size. Then it probably has an act() function and a draw() function. Maybe is has calls to allow it to contain animations or sprites. Then its subclasses define more specific data, like perhaps a CombatEntity has damage, hit points, and the like, while BackgroundEntity has parallax variables.

Here is an example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
Entity
    CombatEntity
        EnemyEntity
            DragonEntity
            ZombieEntity
            etc.
        PlayerEntity
    ConversationEntity
        AllyEntity
            RogueEntity
            MotherEntity
        QuestEntity
            TimedQuestEntity
            StoryQuestEntity


Some people wouldn't have different subclasses for every single type of thing, but it's mostly down to taste. The game I'm working on right now has something like 40 different Entity types (one for a cloud, one for a sun, one for a skeleton, etc.), but I've done games where there are only 5 types or so and you just pass different things into the constructors to control different behavior. It all depends on your project.

See my work:
OTC Software
Offline Dreamcatchermatt

Junior Member





« Reply #7 - Posted 2010-04-14 07:50:25 »

ahh, I see. actually that's pretty muchwhat I have already.

1  
2  
3  
4  
5  
6  
7  
8  
9  
class physicsPoint
//holds positioning, velocity, accelleration, etc

class ship extends physicsPoint impliments MouseListener
// holds all the methods and events to draw a ship on the screen, and will also have
// methods to load/save ship data to to a file/database server

class etc extends physicsPoint
// you get the idea


is this what you mean?

chears!

please forgive typos, tiny phone keyboard :/
Offline appel

JGO Wizard


Medals: 51
Projects: 4


I always win!


« Reply #8 - Posted 2010-04-14 13:01:12 »

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #9 - Posted 2010-04-14 14:08:34 »

This is a good article. I'd personally argue to not typically use a component system as an indie programmer because your classes will rarely be that complicated, so "blob" classes won't become too bad.

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Dreamcatchermatt

Junior Member





« Reply #10 - Posted 2010-04-14 18:19:08 »

Thanks appel, that looks almost exactly what I need, and also highlighted a few problems with my current aproach that i hadnt properly considdered!

Actualy, that seems like a very usefull way to go. I am mainly designing this as a re-useable game library for a number of other projects I have in my sketch-book, and the idea of haveing data-driven object creation as part of the engine sounds like a fantastic time-saver in the long run.

I am mostly interested in developing online casual games, probably using the facebook api for user interaction, etc. (Actualy, the space RTS is a bit of an odd project for me, and something I have been playing with for years as a sandbox for trying out new code).

I'm really glad you linked me this. One project I have on my 'near future' list requires prosedural item generation (also alowing users to combine and invent new items). Using a component-based object sustem as described in the article seems a great way to do this.
Offline Dreamcatchermatt

Junior Member





« Reply #11 - Posted 2010-04-19 13:35:44 »

I've taken a few moments over lunch to sketch out how I think the component based Entity would work.
Taking a cue from the article, I have created a class called ComponentManager that instanceates and hold all the components:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
public class ComponentManager {
    Inventory myInventory;
    Physics myPhysics;
    Render myRender;
    StateAI myStateAI;
   
    public ComponentManager(String[] args)
    {
        for(String s : args)
        {
            if(s.equals("Inventory"))
            {
                this.myInventory = new Inventory();
            }
            if(s.equals("Physics"))
            {
                this.myPhysics = new Physics();
            }
            if(s.equals("Render"))
            {
                this.myRender = new Render();
            }
            if(s.equals("StateAI"))
            {
                this.myStateAI = new StateAI();
            }
        }      
    }
   
    public Inventory getInventory()
    {
        return this.myInventory;
    }
   
    // etc...
}


then, each component class would have its owen methods/variables that it would make available to the class owning the ComponentManager.

One thing that’s puzzling me though; when I declare my variables
1  
2  
3  
4  
5  
 
    Inventory myInventory;
    Physics myPhysics;
    Render myRender;
    StateAI myStateAI;

do they start taking up memory THEN, or when they are instanceated?

1  
 this.myStateAI = new StateAI();


If they take up no resources, then this structure would be fine. However, if resources are allocated as the variables are declaired, then this method would have no advantage.

Any thoughts?

Chears
Matt
Offline rouncer

Junior Member





« Reply #12 - Posted 2010-04-19 13:49:36 »

I like your plugged in ai, sweet.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 793
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #13 - Posted 2010-04-19 18:59:55 »

One thing that’s puzzling me though; when I declare my variables
1  
2  
3  
4  
5  
 
    Inventory myInventory;
    Physics myPhysics;
    Render myRender;
    StateAI myStateAI;

do they start taking up memory THEN, or when they are instanceated?

when they are instantiated

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #14 - Posted 2010-04-19 22:18:56 »

when they are instantiated
Although when you declare the variable the pointer is created, no? Obviously not much memory, but something. Please correct me if I'm wrong here, Riven. Smiley

See my work:
OTC Software
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 793
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #15 - Posted 2010-04-19 22:57:18 »

Although when you declare the variable the pointer is created, no? Obviously not much memory, but something. Please correct me if I'm wrong here, Riven. Smiley

No. It's an entry in the local variables of the method. Before you think 'ah! so it taking RAM right there!'... well no, all local variables share it, and they can even share the same index, just not at the same time.

local-variable-space = max-concurrently-used-variables (which has nothing to do with multithreading...)



Example: (this takes 1 local)

Object a;
String b;

a = new Object();
System.out.println(a); // 1 local reserved
b= "6";
System.out.println(b); // still 1 local reserved

// this line would make the whole method reserve 2 locals
int hashy = a.hashCode()+b.hashCode();

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #16 - Posted 2010-04-20 00:04:05 »

Huh, that's interesting. Very good to know. I always figured that dangling pointers were using up bits of memory, I had no idea the amount being used was based upon how many you were using concurrently. Smart design.

See my work:
OTC Software
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 793
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #17 - Posted 2010-04-20 00:13:03 »

Huh, that's interesting. Very good to know. I always figured that dangling pointers were using up bits of memory, I had no idea the amount being used was based upon how many you were using concurrently. Smart design.

Actually, there are no danging pointers in Java.

The GC checks the local variables for references too (naturally, or every Java app would crash). The JVM is actually quite smart about when local variables go out of scope in bytecode (even if they still are in scope in java sourcecode)

Anyway, just read up on bytecode. That's what tells the JVM what to do, and that's where you'll find stacks/locals, and recently debug data too, even telling you where each variable goes in to / out of scope (counting by instruction).

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #18 - Posted 2010-04-20 00:28:18 »

Actually, there are no danging pointers in Java.

The GC checks the local variables for references too (naturally, or every Java app would crash). The JVM is actually quite smart about when local variables go out of scope in bytecode (even if they still are in scope in java sourcecode)

Anyway, just read up on bytecode. That's what tells the JVM what to do, and that's where you'll find stacks/locals, and recently debug data too, even telling you where each variable goes in to / out of scope (counting by instruction).
Yes, by dangling pointer I more meant a pointer that doesn't go anywhere. Obviously if it's not taking up any memory then it doesn't actually exist as far the compiler is concerned. So it makes sense to act as you described above in the byte code. I should read up on byte code, but once I start reading and stop doing I inevitably get bored and fall asleep. Tongue

See my work:
OTC Software
Offline JL235

JGO Coder


Medals: 10



« Reply #19 - Posted 2010-04-20 03:53:15 »

I organise my game objects into two data structures. First I store the actors according to their painting order which is a tree mapping an integer to a set of game objects. The integer describes how the game object will be drawn in relation to other game objects stored in the collection, lower values being drawn first and higher ones drawn later. All game objects begin with a default draw value of 0. It's essentially a: Tree< Integer, Set<GameObject> >. This can also be used for cheaply iterating over all game objects.

For collisions I use a CollisionsGrid that stores objects according to their location. First they are seperated based on the class of the game object stored, so all Tanks and Infantry are stored seperately within a map. For each class the space is split into essentially a big 2D array where each element represents a section of the display (usually approximately 80x80 pixels on the screen). All game objects that overlap that section of the grid are stored in that element, which is implemented as a HashSet. A game object may also be overlapping several 2D array elements, and so will be stored in multiple elements. When checking for colliding game objects the object being tested against will be used to work out how many array elements it overlaps, and only the actors within those elements are checked for more precise (and expensive) object-to-object intersections. The array itself also expands dynamically, so it only ever stores for areas of space that game objects move to. Overall it's essentially a: Map< Class<? extends GameObject>, Set<? extends GameObject>[][] >.

The map can also pull out not only the objects of a given class, but also all objects of a sub-class too. So if I ask for instances of 'Tank' then I will receive all instances of Tank any sub-classed such as 'FlameTank' and 'SuperTank'. Unfortinatly checking if classes are a sub-class of each other has always been very slow for me, so internally it indexes the class hierarchies that it has stores and updates this whenever it meets a class it doesn't know.

For the final implementation I use custom data structures for most of the above; custom trees, sets, lists and even a custom 2D array.

Offline Dreamcatchermatt

Junior Member





« Reply #20 - Posted 2010-04-21 13:00:42 »

Wow, that sounds very well thought-out, nice one. Smiley

I am literaly counting down the days till i'm finished with uni coursework and can get some serious work done.

Thanks everyone for your continued help and advice, I'm really glad I came accross this forum!

Offline Galaxy613

Senior Newbie





« Reply #21 - Posted 2010-04-22 03:34:22 »


I'll like to go back to this article for a second. It was a good read and I think I understand it, but what happens if one component needs data from another component? Will the component manager somehow know that some data needs to be sent to a particular component, if so... how? Say the Render component needs the variables of the Position component to do it's work, how will it get access to that data?

Programming since 2001 (Technically Tongue )
Uses: BlitzMax, Java, C++
Computers: W7 Desktop and a Triple Booting Netbook.
Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #22 - Posted 2010-04-22 07:08:12 »

I'll like to go back to this article for a second. It was a good read and I think I understand it, but what happens if one component needs data from another component? Will the component manager somehow know that some data needs to be sent to a particular component, if so... how? Say the Render component needs the variables of the Position component to do it's work, how will it get access to that data?

It takes a while to really get, and even after I've found implementing entity systems to be extremely tedious. An entity doesn't "need" anything. It just holds values. The "system" that manages some portion of the app (eg, rendering) is what needs data, and it knows how to get it from the entities.

This is an interesting ES article series:
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

Offline tom
« Reply #23 - Posted 2010-04-22 12:08:06 »

There are different ways of implementing component systems so how you get hold of other components may vary. It also depends on how you implemented you game object model. That is where the objects are stored and how to get hold of them.

I've implemented GameObject as an actual java class that contains a list of components. My components may also have methods. As an example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
class RenderComponent extends Component {
...
   // called every frame
  public void update() {
      // owner is the GameObject that this component is part of
     PositionComponent posComp = getOwner().getComponent(PositionComponent.class);
      if (posComp != null) {
         renderAt(posComp.x, posComp.y, posComp.z);
      }
   }
}


My GameObjects are store in a world that I can get hold of from the component. So if the player component wants to get hold of the positions of all the powerups I could write:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
class Player extends Component {
...
   // called every frame
  public void update() {
      // a reference to the world is given to the component when it was added to the world
     for (Powerup powerup : getWorld().getComponents(Powerup.class)) {
         PositionComponent posComp = powerup.getOwner().getComponent(PositionComponent.class);
         if (posComp != null) {
             // do something with the powerup
        }          
      }
   }
}


You should also read the Game Object Component System thread.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #24 - Posted 2010-04-22 13:58:16 »

You can also give each component a parent object, and then try to access a specific type of component from that parent object.

See my work:
OTC Software
Offline JL235

JGO Coder


Medals: 10



« Reply #25 - Posted 2010-04-22 14:07:08 »

There are different ways of implementing component systems so how you get hold of other components may vary. It also depends on how you implemented you game object model. That is where the objects are stored and how to get hold of them.

I've implemented GameObject as an actual java class that contains a list of components. My components may also have methods. As an example:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
class RenderComponent extends Component {
...
   // called every frame
  public void update() {
      // owner is the GameObject that this component is part of
     PositionComponent posComp = getOwner().getComponent(PositionComponent.class);
      if (posComp != null) {
         renderAt(posComp.x, posComp.y, posComp.z);
      }
   }
}


My GameObjects are store in a world that I can get hold of from the component. So if the player component wants to get hold of the positions of all the powerups I could write:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
class Player extends Component {
...
   // called every frame
  public void update() {
      // a reference to the world is given to the component when it was added to the world
     for (Powerup powerup : getWorld().getComponents(Powerup.class)) {
         PositionComponent posComp = powerup.getOwner().getComponent(PositionComponent.class);
         if (posComp != null) {
             // do something with the powerup
        }          
      }
   }
}


You should also read the Game Object Component System thread.
I'd much rather write...
1  
2  
3  
for ( Powerup powerup : getWorld().getComponents(Powerup.class) ) {
    powerup.setPosition( x, y );
}

then
1  
2  
3  
4  
5  
6  
7  
8  
for ( Powerup powerup : getWorld().getComponents(Powerup.class) ) {
    PositionComponent posComp = powerup.getOwner().getComponent(PositionComponent.class);
    if (posComp != null) {
         posComp.setPosition( x, y );
    } else {
        throw new IllegalStateException("Was expecting position component for Powerup.");
    }
}

I fully agree that it doesn't solve all problems, but inheritence solves most game structural issues in a neater and more expressive way then components.

For the places where you get into a mess with multiple inheritence (which is mainly what component oriented structures aim to solve) then you should reach for components and use a mixed structure. For example I think it's perfectly reasonable to presume that all game objects will have a location (and where a location is not needed it just won't be used). Then you have the best of both; neatness for the majority of code and improved code-reuse for those tricky areas.

You can also give each component a parent object, and then try to access a specific type of component from that parent object.
You are wrapping a component oriented system into an inheritance hierarchy. Might as well just use inheritance to start with; less code, simpler code, less overhead and does the same.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #26 - Posted 2010-04-22 14:12:43 »

That's true, JL, but if you keep it simple then you can get the best of both worlds:

1  
2  
3  
4  
5  
public class Component
{
    private ArrayList<Component> components;
    private Component parent;
}


That's all you would do. So any component can have a parent (that it can access if it needs to), and/or it can have a lot of child components. So you can get a nice tree structure in there in terms of how things are formatted which can work very well with renderers, etc. if you make it work nicely enough (great for boned animations and the like).

See my work:
OTC Software
Offline JL235

JGO Coder


Medals: 10



« Reply #27 - Posted 2010-04-22 14:32:47 »

That's true, JL, but if you keep it simple then you can get the best of both worlds:

1  
2  
3  
4  
5  
public class Component
{
    private ArrayList<Component> components;
    private Component parent;
}


That's all you would do. So any component can have a parent (that it can access if it needs to), and/or it can have a lot of child components. So you can get a nice tree structure in there in terms of how things are formatted which can work very well with renderers, etc. if you make it work nicely enough (great for boned animations and the like).
That's a very useful property, but that is not how I understand component oriented programming. Organising the game into a tree structure for rendering, updating or any other task can be implemented using both components and inheritence (I do this myself for my games and I do not use a component oriented structure in my game libraries).

My understanding is that it is about adding new class properties as objects rather then through subclassing (i.e. using 'addComponent' instead of 'extends').

Using components can be damn useful in some places, like weapon systems. It can be much simpler to have each weapon defined as it's own object that could be added to an Enemy game object then to sub-class the Enemy multiple times for each weapon. However most game objects don't have weapons. That's my point above; use inheritence for the bulk of the code and components for those fiddly corner-cases.

Offline Roquen
« Reply #28 - Posted 2010-04-22 14:59:06 »

A consideration for systems such as this is that your taking a pointer intensive language and exploding the number of pointers. 
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #29 - Posted 2010-04-22 16:23:02 »

That's a very useful property, but that is not how I understand component oriented programming. Organising the game into a tree structure for rendering, updating or any other task can be implemented using both components and inheritence (I do this myself for my games and I do not use a component oriented structure in my game libraries).

My understanding is that it is about adding new class properties as objects rather then through subclassing (i.e. using 'addComponent' instead of 'extends').

Using components can be damn useful in some places, like weapon systems. It can be much simpler to have each weapon defined as it's own object that could be added to an Enemy game object then to sub-class the Enemy multiple times for each weapon. However most game objects don't have weapons. That's my point above; use inheritence for the bulk of the code and components for those fiddly corner-cases.
Yeah that's totally true. I've actually never done it like the above, it was just an idea that occurred to me.

@Roquen Unless you're going crazy with this component system, I really don't think the number of pointers is going to make a big difference.

See my work:
OTC Software
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.

Dwinin (19 views)
2014-09-12 09:08:26

Norakomi (54 views)
2014-09-10 13:57:51

TehJavaDev (63 views)
2014-09-10 06:39:09

Tekkerue (31 views)
2014-09-09 02:24:56

mitcheeb (53 views)
2014-09-08 06:06:29

BurntPizza (37 views)
2014-09-07 01:13:42

Longarmx (23 views)
2014-09-07 01:12:14

Longarmx (27 views)
2014-09-07 01:11:22

Longarmx (27 views)
2014-09-07 01:10:19

mitcheeb (35 views)
2014-09-04 23:08:59
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!