TIGSource Forums

The Biggest piece of a game for most modern languages is a solid entity System, whether it be 2D or 3D, The foundation of every object in the game boils down to the entity.

What do you guys think a Good entity Has? My Basics are Location, Direction, Velocity, Rotation because they can be used by any object that exists in the game world without being specific to any one object, Static or physics, NPC or Player.

Id love to hear other people's ideas.

There are plenty to be said about designing a good entity system for a game engine but my personal short take on it is (talking from a c++-perspective)

What I used to do
* For a small game without advanced tools or complicated features, go ahead and use the monolithic super BaseEntity approach where you can put all the stuff any entity needs in the base class.
* For a larger project, carefully consider if all entities really need a velocity (static entities?) or even position when you design the class hierarchy.

What I moved to the last couple of years
* Use a component based system where you build any object you need from smaller components. Faster, cleaner, better. As long as you can find a good way for the components to communicate when needed.

google "composition vs inheritance" for countless times this discussion with some really good examples on how to do it right.


the general gist these days seems t be : prefer composition, but don't stop thinking about it, sometimes inheritance structures are better/easier.

Yeah if I was doing like Ludum or Fuck this Jam I would probably go with this aproach


The concept i'm going for with Entity is that entity has to be able to apply to EVERY object including Crates or tables or Computer Consoles. these TECHNICALLY don't need a velocity unless the Player is able to collide with them and move them with some kind of Physics.

BUT in this case I would also probably have a bool or enum that determines whether the object is movable. Adding a velocity would only happen in entity if MOST of my objects were movable. otherwise Id Sub class into something that implements a moveable interface.

Exactly! I definitely have a hard time getting them to communicate, since I use interfaces to add things.


Honestly? I was taught inheritance first.... so you actually just introduced me to the concept of Composition hahahahaha

An interesting discussion with a rant on entity systems: Still hardly any games, why entity systems suck, and why 4k is good (http://www.java-gaming.org/topics/still-hardly-any-games-why-entity-systems-suck-and-why-4k-is-good/25070/view.html) (similar stuff: Peak Abstraction (http://tomhammersley.blogspot.de/2012/02/peak-abstraction.html)). Edit: Almost forgot this How to program independent games (http://the-witness.net/news/2011/06/how-to-program-independent-games/).
When creating games I think reusability is rarely relevant.

Maybe you want to look at http://gamadu.com/artemis/

Location, rotation etc. are only relevant to spatial entities.

"It is not as easy to understand as just having Some Entities In An ArrayList that all extend a base Entity class."

That is my normal solution, and I've yet to run into a major issue with it. Even mmorpg emulators that I've worked on that are well over 500k lines of code, have more or less used this same solution and it has worked fine. In the end its simple and fast to implement, even if lacking grace and often wasting some memory.

I used to go with "One base class, derive anything" for a long time now, but I kept running into composition-like problems where getting a desired effect would mean coupling multiple entities and have them work tightly together.

Now finally got over to add a component system. It's just a means to an end, not the final all-solution, but coding feels a lot more sane now. Some random points:

- Getting the components to work together can be complicated
- as can be serializing the whole stuff
- but it's just the same issues you'd run into with a inheritance-only approach
- the easiest things to move to components are pure behaviour things
- Iterating over all components in all entities can be an performance issue.
- You can mitigate this by building caches - simple arrays where you collect all entities for a given purpose, e.g. drawing, colliding
- A few of my components are:
+++ Script - attach behaviour over time to an entity
+++ KillMe - destroying the entity when some decision is met. For example: destroy a light when the tile below it was damaged
+++ SoundSource - just emitting a sound when the player is close enough to hear it
+++ ParticleFX - creating a particle effect upon construction, updating its location while alive, stopping it when being destroyed
+++ AreaEffect - change other entities in proximity every 0.x seconds

You can get this pretty far, I guess... I haven't been there, but this discussion got me thinking. For example: a monster. I used to derive a class for one type of monster, implementing its behaviour and appearance together in this class. But you could just split this up - one component just showing the graphics for the monster, one component controlling that graphics to show animations suitable for the current movement and actions of the monster, maybe one component doing the physics - plain moving and colliding - and finally one component performing the AI, controlling the movement, sending commands to the animation.

This could work, even though I can't judge if it's actually worth the work. Upto now my experience is: thinking in components makes your code shorter and more precise, at the cost of some more boilerplate like having more small classes.

[Edit] Maybe it's just me, but I found myself copying a lot of code back and forth between my projects, to the point where I moved a lot of basic framework stuff to its own repository and pulling it into every project via svn:external.

I frequently seem to, in time, to boil down to massively functional base entities with minimal storage footprint. ie. anything that could be vaguely useful for multiple classes ends up as functionality in the base class, with the actual storage in child classes, provided in calls or retrieved by virtual functions. One of the children frequently turns out to be a container type, which most of the entities end up inheriting from. Sometimes it collapses back up into the base class if all entities end up containing other entities. These are all padded out with a sprinkling of functional component classes.

Sometimes these functional base classes then start wandering around the rest of my code, sinking its fangs into other classes that strayed too far from their original intent. Soon, everything of consequence is an entity. ;)

For years now I've had little need for inheritance except in a few special cases. Interfaces and composition suffice for most purposes, and any inheritance is simple and shallow. I tend to think in terms of reducing dependencies for any particular piece of code because it needs to be readily testable by itself as a unit or with minimal coupling.

I'd recommend looking at SOLID design principles, functional programming, and test-driven design, and avoid thinking too much in terms of a grand design. And if something doesn't fit into a framework or system, think about whether it really belongs there before forcing it there or growing the framework.

I think when you have a readily available solution, such as an entity/component system, you tend to think in those terms and everything becomes an entity or component. The vast majority of my code is not part of any system, especially finer-grained objects that need special treatment to scale well. My component system is really only used for the convenience of locating dependencies, event publishing, and tool support in visualizing/editing the game. And as far as performance, beyond using separate buffers for component types, I haven't put much effort into optimizing the system because it hasn't showed up on my radar as a bottleneck.

One outstanding design issue I'd like to solve is working out a good way to manage update ordering dependencies (camera update depends on target update happening first). I'm wondering if this points to a larger design problem, or if I can continue to get away with adding new update stages as needed.

EDIT: Just want to say that I'm not suggesting that test-driven design is appropriate in game development (I'm certainly not very strict about it), but that thinking in terms of testability at least helps me reduce coupling and produce code that I can easily exercise in a test.

Sometimes people tend to get stuck on one concept like components are always better or a hierarchy is always better. I think the important thing is to realize the benefits of the various systems and use them when appropriate. There is no silver bullet.

I would agree with what gears is saying overall in his first paragraph. The majority of my entities are made up of a flat set of components brought together excluding an interface/abstract that has an update/render logic. On the other hand if I have a grunt enemy then another grunt with slightly different behavior I'll define the specialized grunt with inheritance.

If you have time on your hands then learn and experiment with various methodologies. First hand experience is always far better than reading about something and drawing a conclusion.


EDIT :PrinceCC's post about 4k etc was interesting but I would also venture to say that designing the framework is a relatively well documented and repeated task. Making a game is frequently experimental and new. It's harder to do and I think because of that people get that far then realize the game itself is much harder to complete than the framework and get discouraged.