Hey, I've been trying to think of ways to make an entity system. I have never made one so I'm not quite sure whats efficient or not. Honestly, I don't know how the class would look. So if someone could help me out with the base of one, thanks.

Try to find things in common between your entities. Their x and y coordinates?A draw and update method?A move method?How about getX, getY methods?Or you could also handle their sprites here. Animation...If all your entities have health, why not put it here? (I wouldn't do that, I have lots of entities that are neither drawn nor have health, so I leave that for extended classes)

If you don't have any idea what an entity system should look like, why are you looking to write one? Most libraries factor out common patterns that the creator is already familiar with. If you just want to use an entity system, grab an existing implementation like Entreri

It depends. There are no silver bullets in computer science. So it depends on what your skills are like, what you want to do, etc. etc.

Yeah, I understand that. I mean how should an efficient base look like.

Quote

Try to find things in common between your entities. Their x and y coordinates?A draw and update method?A move method?How about getX, getY methods?Or you could also handle their sprites here. Animation...If all your entities have health, why not put it here? (I wouldn't do that, I have lots of entities that are neither drawn nor have health, so I leave that for extended classes)

Ok, really I kind of figured that. I should have been more clear, I was in a hurry last night typing that.So how should I go about IDing them? I noticed some people used a HashMap array I guess, never used one before. But is that how I would id them?

Like,

1 2 3

publicintgetEntityX(intID) {returnID.x;{

Quote

If you don't have any idea what an entity system should look like, why are you looking to write one? Most libraries factor out common patterns that the creator is already familiar with. If you just want to use an entity system, grab an existing implementation like Entreri

I'm trying to write one so I can learn about them now. I don't want to use any external libraries.

So how should I go about IDing them? I noticed some people used a HashMap array I guess, never used one before. But is that how I would id them?

What matters is the interface. You should have a method that takes an Entity ID and returns an Entity. An Entity should be able to query and alter its list of Components. These are interfaces, and you should write them as interfaces first, classes after. How you implement it, whether it's with a Map or an array or a database is then up to whatever concrete class implements the interface.

Some general tips:

Int or a Long makes a decent entity ID. I'd go with Long, since it'll give you enough IDs that you'll never need to recycle an ID, and that has some benefits later.

Start simple. Using a Map<Long,Entity> to store your entities is fine to start with. Just don't expose it, make sure you can only get at it with methods defined on an interface.

Entity shouldn't do anything super interesting -- it's just a relation of components, that's all. Components do all the real work.

Where the long is the entity id and the ArrayList<Component> is the list of components that belong to that entity. This makes it easy to get all of the components for a given entity. Another possibility is:

1

HashMap<Int,ArrayList<Entity>> dataByComponent;

In this case, the Int is a Component Id. This allows you to easily get all of the entities that have a given component.

There are other (and most likely better) ways to do this as well. Like sproingie said, think about the interface. Imagine your entity system is already written and you are writing a game using it. What are the methods that your game is calling?

Typically the Monster and Player classes will inherit Entity. (In some EC systems, there are no hardcoded classes like Monster or Player just Entities but I wouldn't start that way as I do not think it is useful).

Most Entity Systems will have a centralized EntitySystem or EntityManager type class that holds the entities and components assigned to them. So you your Entity would not have a dataByComponent method. It would instead have a getComponent method which in turn gets the data from the EntitySystem. So think about creating an EntitySystem class which has the responsibility of storing Entities and components and allows you to:

* Get all Components for a given Entity* Get all Entities that have a given Component* Get a specific Entity's Component.* Returns true if an Entity has as given Component* Allows you to create, delete Entities* Allows you to associate and disassociate components with entities.

It looks like you have two potential Components, Movement and Image (or Sprite). If you want to go the EC route and are using these as an example start with creating a Movement Component that can be applied to both Monster and Player.

I am surprised you have input handling code directly in the Player class. If I were doing this, I would have the input handling code in a separate class and have it update Player's state as necessary.

In my opinion a complex entity system that relies on total separation of logic/rendering/etc, hash maps storing components, and all that jazz (like Artemis) is complete overkill for most simple 2D games. Instead, a good "entity system" might have a base class as simple as this:

Having all those operations on one base class is one thing, might serve all the practical needs of your game so who really cares if they don't contain a bunch of components, right? Putting them on a single interface however is just nonsense -- they're quite clearly different interfaces! The whole point of interfaces is that you'd split that into Updateable, Renderable, and Spatial interfaces, and then if you decide what the heck, everything has those so let's implement them on an abstract base, then great. But naming it "Entity" doesn't automatically mean you have an entity system.

The whole point of interfaces is that you'd split that into Updateable, Renderable, and Spatial interfaces, and then if you decide what the heck, everything has those so let's implement them on an abstract base, then great. But naming it "Entity" doesn't automatically mean you have an entity system.

That's my point. Most "entity systems" for simple 2D games end up being a single class/interface; everything else is overkill.

Note: Of course, my code was just an example. Some 2D games might separate Entity/CollidableEntity... others might separate Entity/MovableEntity.. or whatever. Point is: you generally don't need a huge/complex "entity system" for a simple 2D game.

Violent agreement on that point. In fact, I'd say even a complex game done by one developer can dispense with most of these complex abstractions. It would seem to be when you need to experiment with different designs without undergoing rewrites of the base system that fancy component systems come in handy, such as if you have an engine that isn't rewriteable by people who aren't source licensees.

Alright, I appreciate all the posts you've guys have made. You helped me alot as in this if my first time making an entity system. I'm sorry I guess I didn't know you guys didn't have the same definition as me, but anyways what would a good way be to this for a 2D game. I'm trying to handle movement, collision, level, stats. Every "Entity" should have them. So would I would have an Entity class that would contain all the entities, such as player, npcs/monsters and then each of them would have there own classes? How would this look?

1) Can I make a comparison and contrast of component based and prototype based, if no return no.2) Can I list at least 3 methods of design by composition, if no return no.3) Do I expect millions of active entities, if no return no.4) Am I writing in a language that support linear access to memory and caching hints, if no return pfff...hard call.

And also - If you want to learn how to make entity systems for the purposes of just learning about them, Java is not a great choice, as it makes all the most important bits of entity systems extremely difficult and fiddly to do.

Composition in Java is a joke. You can work around it by writing huge piles of boilerplate code and creating millions of superfluous objects.The memory layout in Java defeats the entire purpose of entity systems. You can work around it with arcane rituals with mapped objects and flyweight patterns.

I think you are vastly exaggerating there. Of course Java syntax is more verbose than that of a scripting languages and hash maps are less comfortable to use but that's about it. And what does memory layout have to do with an entity system? The memory layout describes what data is stored in what part of ram. In Java and also in scripting languages the memory layout is not even visible to the programmer.

The only plausible bullet point in favor a component based vs. other techniques is the ability to perform high processing rates by data segregation and linear ordering. And this is really only if you squint your eyes and don't think too much because neither of these require a component based model.

As for verbosity, I've never seen a real component based implementation in Java that wasn't horrible on the eyes. The lack of operator overloading (notable getters and setters) is a real hindrance. So IHMO if you want to play with these types of design models it seems like a good idea to do it in a language that designed for these types of abstractions rather than fighting the main design points of Java (class based + strong typing).

The only plausible bullet point in favor a component based vs. other techniques is the ability to perform high processing rates by data segregation and linear ordering.

You're only going to get this if you have control over the memory layout. If you read the T-Machine article on entity systems, the primary benefit being touted is the reference locality you get from slicing just the components you need, which is an awful nice thing if you're targeting something like the PS3 where random fetches are death to performance.

You'll also notice that it doesn't espouse doing all this low-level frippery by hand, but having a good toolchain that supports component assembly instead. Unfortunately the article is handwavey enough on the implementation details that it seems to have been taken as a generic anti-OO rant, and I confess that's how I read it the first time too.

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