Well my entity system is much simpler. Most stuff is scripted, and most simple entities just use a base entity class (some stuff like NPCs and the player character have their own classes so heavy lifting can be done in C++).

An event for me is just an integer ID describing the event - some examples might be EVENT_CREATE (when the entity is first created, constructor stuff), EVENT_UPDATE (per frame tick update), EVENT_SHOT (fairly self explanatory :P) EVENT_TOUCHED (touched by another entity), etc.

Other than that there are a fixed amount of arguments (I use 2 at the moment, haven't needed any more than that but if I do it's simply a matter of adding an extra argument to the struct). They are Variants (that is, a structure containing basic types like an integer, boolean, float value or even a string, and a field saying what type it is).

In the C++ class there's a HandleEvent function which listens for a handful of events (just a simple switch statement), then passes the event off to the script's HandleEvent function. There's not really any validation done on the events, it's assumed if you are sending event X then it will have argument Y of type Z etc.

Once you have the system in place suddenly you start thinking in terms of messages and events and everything starts coming to you pretty clearly. For instance, I wanted a locked door that only unlocked if the player had a certain key/item (duh). So when you touch the door, the door's EVENT_TOUCHED handler sends an event back to the entity which touched it called EVENT_REQUIREITEM with the item type as an argument. If the entity has a handler for that event (which of course the player does), and it has that particular item in its inventory, it can send back an event EVENT_HAVEITEM. As soon as the door gets that, then it opens. Hopefully that makes sense!

Pretty simple system but it's worked well for me so far.

PS: when i say "event handler", I mean it has "if( EventType == EVENT_blah )", I don't do anything fancy ;)

Your entity system looks cleaner than mine, I have a lot more functions in my SceneManager class... but also it's because most of my functions in my entity are in the context of rendering things, and not making them interactive. With that said you may be able to separate the drawing function from the entities into its own Scene Renderer like I have. For me this makes more sense for batching and ordering entities to be drawn when it passes through the API's rendering loop. The SceneRenderer will not expose these API rendering functions to the entities. Instead the entities pass the info to the SceneRenderer.

As far as managing the interactive logic for the entities, you seem to be on a good path on enclosing message info as objects, but I can't advise much there. My game logic is still coded in C++ but for me it still works since I just wanted to encapsulate all the rendering stuff and focus on the actual game.

I am not sure if I would want to load each entity as their own files. Maybe it's because I'm used to loading entire scenes and maps in one file... however in the case where you want to limit memory usage and only load entities as you need them on the fly. However, putting each entity in its own file may be less cumbersome if you use another language besides XML which leads to...

Quote:Original post by mightypigeon
Actually I'd advocate the use of a message parsing/event based system. I have it set up so entities really only expose a HandleEvent function, and can respond to events as they please. It's not that difficult to get going.

The good thing I'd say about XML, is that it is easy to understand. But if you want the fastest performance you'd want a format the requires minimal parsing (or a binary format). There's nothing stopping you from converting XML into another format, though.

That said, that's probably the least of your worries for now.

YAML or JSON are simpler to parse and the text is less verbose. If you want something that is faster to read by the program and still easy to understand and edit by hand and not worry about planning your own binary format, I would go with either one. I may go as far to say as they can be even easier to read than XML once you understand the syntax.