Entity system design

Interesting topic.

I don't have much to say about it, it seems to me that you have a good grip of some options and should probably use one that gets the game done, if that's what you want to :). My game that i'm working on has been almost finished two times already with completely different designs, the first one where everytthing was in one 250 kb cpp file. The second time it was a lot better, but still not very modular. Now i'm in the beginning of the third reworking with a MVC approach that will probably use a component design when i finally decide how the design should be. But the goal for me is not to make a working game, at least not now. I'm in it to learn new stuff as an recreational activity.

Don't know if i added something of interest, i just felt it was a shame that no one hade answered yet. At least this will bump the thread a bit :)

/Martin

Hi Martin, thanks for your reply!:)

The component-based design sounds like a good choice, from what I've seen it scales very well with both smaller and larger projects. The 250kb code you had there sounds a lot like my functional design, hehe :)

The main advantage I've seen with the NFA-design is that it is slightly "more" reusable, while the same methods may be reused for several entities. The design also stresses that everything in the game exists as an entity, including the game itself. This enables some weird options, such as being able to run multiple instances of the game(s) simultaneously within the same application, or being able to play the game from within itself(!).
I did find a few annoying things about the NFA-design: For one, it seemed really hard to debug. If the game logic crashes/fails somewhere, it's hard to isolate the error due to the entity methods being dynamic. Also, a NFA gets very complex very fast, and then it becomes hard to maintain. For example, if you change one method used by several entities, you will no longer be able to guarantee correct function of the entities using the method.

I think I will stick with the component design for my engine. Maybe I've missed some key point about the NFA-design, but it's just taken so much time to experiment with.. I would probably have a functioning engine by now if I'd just skipped it :p

This subject gets the majority of my brain time for my current project. I have no amazing insights to add, but thank you for those two articles you linked, and this thread.

I am on the third iteration of my engine and just got done doing some major refactoring to the whole organizational scheme of things in terms of the overall "engine." I was previously running into a lot of dependency issues but I finally came up with a new architecture that basically eliminates all of my dependency problems, and simplifies things such that I don't have to worry about the order of including header files at all.



The core libraries are things like matrix, quaternion, math, etc, and some very basic game node classes. By making these things independent and all put into a precompiled header, its very simple to add new functionality to my game engine as modules...each module is independent, and usually only takes 1 header -- the precompiled header. Compiling my project now takes about 1 second and I never have dependency issues.

The second major insight I had was to separate input/output from the game engine. My game requires a lot of mode switches in terms of view, such as switching between first person, third person, cutscenes, menus, etc...in each mode I want the IO devices to behave completely differently. Also, the way that I want the viewing matrices to change is completely dependent on this. What I came up with, which I am very happy with, is an "IO_Manager" class that has some very basic virtual functions like "Init", "GetInput," "UpdateView". Now when I want to switch between first person and third person, its as simple as swapping the pointer between these IO Managers and initializing the new one. In my game loop I just call GetInput when I want to check for input, and UpdateView before I render so that matrices are applied properly. Moreover, what this means is that my scene has no concept of a Camera object...which is good because its a pain when the camera is so closely related to your input device mechanism, and also the location of your player character.

Now I am trying to rethink the problem of an object hierarchy. One thing that I know FOR SURE is that a purely inheritance based organization is a baaaad thing. I am not sure that a purely aggregation based method is such agood thing either. I think there is probably an optimal mix between the two. Now I have a ShapeNode which basically describes a set of meshes and effects that represent one logical shape object. Above this I have a RenderNode which can contain any number of ShapeNodes and has virtual methods like ForceUpdate, FrameUpdate, Render. It contains information about object position. Then at the top level I have a more traditional class hierarchy of logical game objects, and each one contains a RenderNode. I am still playing around with concepts here to find the optimal mix. One thing I noticed was that to avoid having to do dynamic casting, I should make my base RenderNode class have an Update function and then split it into a Static and Dynamic version, where the static one calls an empty method. One thing that bothers me a lot though is that certain objects need very specific information in order to render. For example, I have a cloud of particles that follows the player that needs to be updated with information about the camera FOV And player position.

Hey, that's a cool article (that I have seen before :)).

This stuff is creeping up regularly on these boards, and I think that underlying actor / entity / component system is a really underrated problem. Especially in our days of multicore, scripting, wild mutithreading and crazy networking.

Combining these into one unified system sounds great, as the underlying core of your engine, but it's hard to achieve. I consider it kind of one of the holy grail of game programming. Once it's sussed, then your laughing all the way to retirement!

So, no real insight apart from what has been posted previously, but I'm all ears.

Quote:

Original post by oliii Hey, that's a cool article (that I have seen before :)). This stuff is creeping up regularly on these boards, and I think that underlying actor / entity / component system is a really underrated problem. Especially in our days of multicore, scripting, wild mutithreading and crazy networking. Combining these into one unified system sounds great, as the underlying core of your engine, but it's hard to achieve. I consider it kind of one of the holy grail of game programming. Once it's sussed, then your laughing all the way to retirement! So, no real insight apart from what has been posted previously, but I'm all ears.

That's just it; I don't think there really is any "holy grail" or one solution that will solve every problem. Don't sweat on making it absolutely perfect, or else you're just wasting the majority of your time. Find something that works for you, and works well, and understand the consequences of your architecture design.

Quote:

Original post by fd9_ Quote: Original post by oliii Hey, that's a cool article (that I have seen before :)). This stuff is creeping up regularly on these boards, and I think that underlying actor / entity / component system is a really underrated problem. Especially in our days of multicore, scripting, wild mutithreading and crazy networking. Combining these into one unified system sounds great, as the underlying core of your engine, but it's hard to achieve. I consider it kind of one of the holy grail of game programming. Once it's sussed, then your laughing all the way to retirement! So, no real insight apart from what has been posted previously, but I'm all ears. That's just it; I don't think there really is any "holy grail" or one solution that will solve every problem. Don't sweat on making it absolutely perfect, or else you're just wasting the majority of your time. Find something that works for you, and works well, and understand the consequences of your architecture design.

Interesting that you write 'holy grail', that's exactly how I used to describe the NFA-design when I first read the article by Britt.L.Hannah. ;) I haven't read a lot on generic game design theory, but if I had to choose one 'the most' generic game design, at the moment I would place my vote on the non-deterministic finite state machine.

Still, I no longer believe in the holy grail for the same reasons fd9_ wrote. I'm sure we'll see more clever designs in the future, but there always seems to be a trade-off between the less generic and the more generic. If you go more generic you'll get 'reusable', 'easy to extend', etc., but you have to pay for it with something. Usually you pay for it with 'time to implement', 'debugging possibilities', 'simplicity', but also sometimes with 'execution speed' (see overhead for OOP virtual function table lookups for example), etc.

Quote:

Original post by fd9_ Quote: Original post by oliii Hey, that's a cool article (that I have seen before :)). This stuff is creeping up regularly on these boards, and I think that underlying actor / entity / component system is a really underrated problem. Especially in our days of multicore, scripting, wild mutithreading and crazy networking. Combining these into one unified system sounds great, as the underlying core of your engine, but it's hard to achieve. I consider it kind of one of the holy grail of game programming. Once it's sussed, then your laughing all the way to retirement! So, no real insight apart from what has been posted previously, but I'm all ears. That's just it, I don't think there really is any "holy grail" or one solution that will solve every problem. Don't sweat on making it absolutely perfect, or else you're just wasting the majority of your time. Find something that works for you, and works well, and understand the consequences of your architecture design.

Of course there isn't ONE solution, but on most games I've worked on, even thinking of an architecture would be a step up. And they all would share the same design patterns quite happily. I seriously hope that stuff gets mentioned on our 'next iteration', and that we start moving away from the deep hierarchies and 5,000 lines-of-code files. With 15+ coders, that's just asking for trouble. It's a self-perpetuating chaos.

I prefer a component based system. Break everything down into the simplest objects so they can be brought together in a large entity to create anything. Since my two revisions on mine I've gotten to a fairly nice system of dynamic game entities. However, the base entities have to be very encapsulated which can be a good or bad thing I guess. Code bloat ftl. My game entities were highly tied into my event system so they didn't have any real code, just FSM managers and such to process requests.

I'd be interested to hear how everyone else does game entities.

There was an interesting discussion recently about this, here.