Entity System (Part 2)

It's Friday, I guess I'm going to keep rambling a bit.

I came up with a simple declarative language, which happens to be very similar to IL (I like the leading full stops) to ease the editing of entities, components and system messages (simply messages from now on):

// build options
.assembly entities.dll;
.namespace EntitySystem;
.debug true;

// declarations
.component HealthComponent
{
// .flags
.field System.Int32 Health;

.handler DamageReceived
{
.priority normal;
.state impl;

// .extern scripts/ondamagereceived.lua;
.body
{
--lua code here
}
}

}

.message DamageReceived
{
.field System.Int32 Damage;
}

.entity Player
{
.components
{
HealthComponent
}
}

The good news is that the parser works; the bad news is that the first version of the compiler refused to work properly (for some unknown reasons CreateType complained some methods didn't have any implementation).

How does it work? Basically, you can define some predefined entities by listing their components. Components have fields and handlers (message listeners) and messages have fields in order to contain the data they carry (what else? :) ).
Handlers have two special members: the .priority and .state declarators. These things specify in which order the handler is installed into the Entity. You cannot specify an index, rather the Entity System inserts these handlers in a stack fashion in the right place.

.priority allows values such as "SystemHighPriority", "SuperHighPriority", "HighPriority", "NormalPriority" etc, whereas .state allows only "pre", "impl", "post". I have to thank the good Mr John Brewer for this idea, which is basically the core of how the message dispatching works.
You can send messages from one entity to another, or from one entity to a family of entities (which is defined by the flags field, which is made to containthe numerical value behind OR'ed enum values).

I'll be releasing the compiler (and probably the source code) as soon as it's completed. This will be plugged into newborn's StoryED in order to allow further customization. You compile the NTL (eNTity definition Language), you reference the produced assembly and the ES assembly into your application and you're done. End.

I like this stuff. What do you think?

Part three is here.

Entity System (Part 1)

Long blog post incoming. And it's, like, my third one.

Entity
1596, from M.L. entitatem (nom. entitas), from L. ens (gen. entis), proposed by Caesar as prp. of esse "be" (see is), to render Gk. philosophical term to on "that which is."

System
1619, "the whole creation, the universe," from L.L. systema "an arrangement, system," from Gk. systema "organized whole, body," from syn- "together" + root of histanai "cause to stand" from PIE base *sta- "to stand" (see stet). Meaning "set of correlated principles, facts, ideas, etc." first recorded 1638. Meaning "animal body as an organized whole, sum of the vital processes in an organism" is recorded from 1683; hence fig. phrase to get (something) out of one's system (1900). Computer sense of "group of related programs" is recorded from 1963. All systems go (1962) is from U.S. space program.

http://www.etymonline.com/

There are posts around the net about entity systems. Not sure there's a particular implementation to follow. I've been reading some related threads over at gamedev.net, but none of them particularly stirred my interest either.

Entity systems are made to favour aggregation over inheritance. There are reasons to use the former, and reasons to use the latter. I'm not going to say one is better than the other. The right tool for the right blah blah blah.

I'll go the Entity System route with Darkmana, mostly because - provided my implementation will work as intended - it'll allow me to define custom behaviours with little effort.

Imagine for a moment your main character is standing near a bonfire, ready with his composite bow. The wannabe game designer in me thinks: wouldn't it be cool to put the arrow on fire by standing close to the bonfire? This means the next shot will also do some fire damage. Cool stuff, yes.

Now, what am I going to do to implement is? What's the way? Many a way. Logically speaking, my arrow is a simple arrow at first (it has some default properties), and then I add some other attributes; that is, it is on fire. From a code standpoint, I have my Arrow object, probably derived from a Missile : GameObject class. Now, it's a FieryArrow object, derived from the Arrow class. So basically, create the new one (probably with a constructor accepting the old Arrow object?) and use it.

I could go on forever (in fact I was about to, I just deleted a good bunch of lines worth of examples), but the problem still remains. Whatever you do, it's hardcoded AND stuck into a specific object hierarchy, which you can't free yourself from.

Scripting comes in rather handy. Well, you still have the fixed hierarchy issue. Why is it an issue? From Cowboy Programming:

"The result of implementing functionality near the root of the hierarchy is an overburdening of the leaf objects with unneeded functionality. However, the opposite method of implementing the functionality in the leaf nodes can also have unfortunate consequence. Functionality now becomes compartmentalized, so that only the objects specifically programmed for that particular functionality can use it. Programmers often duplicate code to mirror functionality already implemented in a different object. Eventually messy re-factoring is required by re-structuring the class hierarchy to move and combine functionality." (http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/)

Let's get rid of it, shall we? How am I going to define my game objects now? Here's my approach.

The rationale behind removing hierarchies is that entities are made of components, pretty much like a body is made of organs performing different stuff. An entity in itself isn't much; it's the way it reacts to the surrounding system rules that matters; and the way it reacts depend on what composes it.

So, now I'm going to have an object which allows me to add other objects, and these objects will take care of defining the way the owner reacts to some system messages.

I mentioned system rules. They are indipendent from the entities. Entities act into a system with a predefined set of rules, rules which they cannot change (we're talking about virtual environments and not politics) - basically the boundaries set by the game designers.

I'm going to post some more later. I need a cigarette and the lunch break's almost over. Let me know what you think.

Part two is here.

Darkmana

Almost one year ago I sent an email to newborn (Vincent, aka the Captain) asking him if I could join the team as the UI programmer. And here I am, now, trying to figure out the best way to program the whole game. Oooh I like the challenge.

It's not like I have done too much during this year, to be honest. Vincent's been in the spotlight all along, and rightfully so, because of his superdupertastic job with the tools he developed.

But I've been lurking... and researching. I've spent the time mostly designing and trying out many interesting things.

I've recently started to rewrite my own libraries, which ideally should ease the making of the game. I'll be posting about the Entity System and the Async Resource Loader design in the next days, since I think they are interesting topics.

First post

Sooo hi 2 u all. I think I'll use this blog to write and ramble about the development of Darkmana.

See you later, I'm at work now.

PS: Who's "you"? Nobody knows about this blog. oO