Data Structures

Newbie & Debugging Questions
#21

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

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!

#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?

#23

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/

#24

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:


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:


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.

#25

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

#26

I’d much rather write…


for ( Powerup powerup : getWorld().getComponents(Powerup.class) ) {
    powerup.setPosition( x, y );
}

then


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

#27

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


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

#28

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.

#29

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

#30

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.

#31

Seconded; performance is overrated. I personally put code maintainability and personal productivity above performance.

#32

My comment is not intended to say that such systems are either good or bad, but to simply point out the fact that it is an important design desision. Increasing the memory footprint increases the number of cache & page missing that will occur. Is this important? Maybe yes, maybe no. It depends on a number of factors, such as access patterns and the number of active entities.

Performance is overrated, unless it’s an issue. :wink: There are tons of possible systems, of which “faking” cross-cutting concerns in an OO language is simply one solution. To toss out another, a simple data-driven model can handle the majority of the concerns addressed by cross-cuts…and it’s simpler to write and maintain. It is superior? Well, like all game related questions…it depends.

When should I use a flavor of hash-table or a binary tree? Which is “better”? They have similar usages, but the best choice, well, depends.

#33

I would say that IMO making cross component access will be requiered in a lot of case (as pointed above by Demonpants code), like if you got three components : sensor, visibility & position in the system that manage visibility you will want to read the position and in the system that manage sensor you will also want to read position. In my case I have found interresting to have an entity class that is accessible from any of its components, this way a component know its entity and can give access to others components owned by this entity ( I told about its implementation here http://www.java-gaming.org/index.php/topic,22011.0.html), It is now implemented and working , it give excellent performance and it is very easy to use or build system.

EDIT : typos…

#34

Thanks for all the replies to my post. I’m still trying to soak it in. It definitely gives me another option than the traditional inheriting hierarchy to think about. :slight_smile:

#35

Indeed, thanks for all the replies.

I’m playing with my code now. I’m having trouble getting cross-communication between components working.

I have the ArrayList + Parent setup as above.

What i want to do is get child A to get a property from child B. In this instance, I want my sprite drawing code to access the position of the entity from the physics component.

I’m doing this by saying

(PhysicsComponent)(this.Parent().GetComponentType(PhysicsComponent.class)).GetPosition();

however, this causes a squiggly underline error on NetBeans, even though i think it should work.

Any ideas?

#36

It doesn’t compile.

#37

Just a hunch, but it might be casting the return of getPosition rather then getComponentType. Try:

( (PhysicsComponent) (this.Parent().GetComponentType(PhysicsComponent.class)) ).GetPosition();

However it’s also possible to remove the cast entirely using generics.


public <A> A getComponentType(Class<A> klass)
{
    Component component = components.get( klass );
    
    return (A) component;
}
#38

great, thanks JL323, that looks like a better way of doing this.

I personaly have never programed with generics in java before, and only used code that uses them from 3rd party and .NET librarys in C#

I’ll hit the books and let you know how it goes.

#39

FYI Java generics really aren’t worth much else than saving you a bit of typing. Just ask Kev to go on a Java generics rant - he doesn’t use them at all. So don’t be in a hurry to learn them.

#40

But they not only save lots of typing, make your code clearer and catch many potential run-time bugs at compile time (like potential class cast exceptions).

I fully agree they have limitations, and I’d like to see them go further, but IMHO there are no negatives in using generics. They are even backwards compatible with pre-generics JVMs.