Component based game objects

Game Mechanics
#41

The only stitching I will have to do is for the AI. Basically going through a priority list of things that can be done and matching things with the available behaviors (= components). It’ll only be an if(getComponent(x) != null) thing for a like 5 different things, so it should be fine. Everything else should be very easy to get done and be clear and nice…

EDIT: So I lightly started working on it, but had to start with actually creating units. I have to keep a prototype or a factory for each unit type, and a prototype or factory for each component. Keeping a whole prototype seemed kind of weird as my Stat class has some empty ArrayLists for modifiers, also a list of parents that would be invalid for a copy, cached values, e.t.c. so I think a component factory interface would be the most appropriate solution to creating components for objects. Creating an object would simply be creating an entity and calling each component factory to create their respective components. Does this seem like a good idea? I think it’s much simpler than what I had before in my earlier projects.

#42

:o

#43

Well, it is, isn’t it? It saves all that boilerplate crap.

Cas :slight_smile:

#44

I guess game programming != neat programming ;D

#45

I feel ignored… ._. What are you doing? I’m the OP, you know!

#46

Inasmuch as it’s possible to create a game using it, sure. From what I’ve seen of java entity systems, I personally think they’re ovengineered in all the wrong places and underengineered where they need it. I’m not sure there even can be a particularly elegant solution as composition-based solutions go in Java, but building an untyped relational database into the runtime doesn’t strike me as the way to go about it.

#47

Awww blocked in the US :frowning:

I just felt like jumping in the conversation since I’ve been watching this for a while now:
Why would you want to use a 3rd party component-based system and get restricted by it? You could just build your own personalized one and live happily ever after. :slight_smile:

#48

I’ve tried. Projects were killed. :emo: If I can use Artemis to get a better view of the problem, even if it doesn’t work out I’ve tried something new and hopefully learned from it. In the end I aim at being able to make a good system myself, either for this game or my next. xd We’ll see how it goes…

#49

Artemis and Apollo aren’t exactly big enough that they’re going to put a straitjacket on your design. You could hack them them into completely different shapes in a day or two. They’re a template for a design, not a framework.

I wouldn’t mind seeing Google Guice used as a component system. It seems to be powerful enough to use in a lot of different ways, but lightweight enough (in both footprint and lack of global policy) to be acceptable for games.

#50

Well, I haven’t really stopped using it :slight_smile: I’ve just been rather busy to actually do something proper with it, and it seems people in general like it.
I was/am working on another entity framework which was more traditional, called Apollo. I’m already working on a few games using it and so far it’s pretty productive. It’s nothing releasable yet, as It’s more oriented towards a specific game library currently, and 2D. Artemis and Apollo don’t really compete with each other, they are different frameworks for different reasons and goals. You can do all the things you want in either, but differently.
Artemis was fun to make, is a fun design, and I will definitely do something more with it later.

Measuring performance of Artemis by running million entities in a loop isn’t really an accurate test. You have to consider what are the main performance hits in games (in the context of this discussion). When you have a lot going on in your game, hundreds and perhaps thousands of entities being created and destroyed every second, that’s when you’ll start go crazy over performance bottlenecks in your design.
That’s where Artemis is GREAT. So, instead of just iterating over million elements in an array, try adding, removing, all while having the entities (and components) organized in such a way it makes sense and is super fast to actually use them.
In Artemis you can look up a component of any entity with virtually no performance hit, anytime and anywhere.

Artemis isn’t just a data storage for your entities. ArrayList would have been enough if that was the case.

Overkill or not. Well… I think the most important thing here is if it helps you get your game going. I think having a consistent framework, from one game project to the next, is pretty good. You can easily resuse code from your previous projects. At least it will give you a fresh perspective.

#51

I really like the concept of separating data and logic in Artemis. For me it’s much easier to handle it, but I guess that for someone reading my code, it would be a little bit harder as they’d have to jump between components and systems to be able understand the flow and logic of it all.
I just finished the basics of my unit factory, which is basically just a list of ComponentCreators (probably a bad name >_>) which can create a component each. I can then create multiple units of the same unit type with just a single line of code. I will in the actual game set up unit factories from some kind of external script or config file for each unit type. Everything is very straightforward, and every component is a clear distinct part without any dependencies, which is a goddamn miracle compared to my old attempts. Tying together things with EntitySystems in the end is just plain FUN. I can’t remember programming being this fun for quite some time! I don’t know, maybe I’m digging my own grave here, but I’m having fun doing it at least! xD

#52

Sorry for the double post, but I just wanted to say “AWESOME!” again. I replaced my temporary Unit class with Artemis entities which supported stats and movement and got the exact same or (very marginally) HIGHER performance with the Artemis version. I like. :wink:

#53

@theagentd & others…

I’m very close to releasing a comprehensive component architecture framework as part of a platform for Java/Android called TyphonRT. There is an entity system (ES) extension as well. I’ve put a considerable amount of time into the component architecture and ES making it efficient and fast. While yes I’m indeed going to be charging for aspects of the larger platform the core component architecture and ES will be released under a slightly modified GPL classpath license allowing usage in any project.

I’ve spent a considerable amount of time on performance matters. Like Artemis and B^3’s articles / reference implementation there is the component as data / system as logic separation. One performance aspect I’ll mention though is the ability to recycle containers (an entity), components, & systems. Essentially this is a generic object pool such that when an entity goes away it is ripped apart and the container, components, and systems are recycled and when entities are composed they can pull them from the recycler. If the game is generally well tuned regarding entity lifecycle the recycler footprint can be kept low leading to none to minimal GC in runtime.

While yes there is a general performance concern when one is querying a container to receive a component (essentially a HashMap retrieval) even with the majority of code flow utilizing this method the bottleneck remains with fill rate for instance which isn’t related to the ES / component architecture.

I’ll be giving an all day workshop at AnDevCon II on Nov 6th and a large part of the discussion will be about entity systems and performance concerns. My main test case is a Quake3 class engine example, so it’s reasonably comprehensive. I’ll be doing to initial early access release at that time and am hoping to get to full public release by March. I’ve been working on TyphonRT for years, so it is well formed.

Like Cas mentions if you want to ship a game that is of low to moderate complexity with static unit types without being concerned too much about reuse for future games just go at it and don’t worry about an ES. He’s been successful with this approach for sure!

If you are an architecture wonk like me you spend years fine tuning and improving ones application of the larger craft; [edit] err games forthcoming! ::slight_smile: I happened to end up fully in the component architecture / composition camp after years of minimizing ties to OOP as core architecture. My ES went through the pain of OOP and eventually buckled. As things go a lot of the Java component oriented based ES popping up are not necessarily refined and serve more as a reference implementation for the general idea.

theagentd, or others interested in checking things out in Nov drop me an email at the contact email from the TyphonRT site or send me a PM here. The basic splash page up now while not inaccurate doesn’t give away all the details of what TyphonRT has become as a platform which will be revealed on public launch. Anyway, I’d be glad to spend a reasonable amount of time to personally work with you regarding ES matters and TyphonRT in Nov as it should particularly serve well for RTS games.