Friday, July 25, 2008
Entity System (Part 3)
Well, the compiler looks almost done; a ntl file in, a .net assembly out. I'm sure there will be a few bugs to iron out, but it conforts me to just think I'm not too far from its release.
The next step will be releasing an editor for the language; for now, I think I'm going to use Roger Alsing's Syntaxbox and some other stuff found in the net.
Another aspect worth discussing is that the Entity System will work on its own thread, and it will communicate with the main thread via the so-called "action gateway". Every action sent to the ES is queued and executed serially; the inverse is alike, however the main thread has to take care of serializing the actions the ES has sent and execute them after whatever comes first (usually rendering and physics update).
Now, in my mind this looks like a good plan, but I know it's bound to change somehow. I can't wait to have some working results to show.
Good weekend, Raine out (nerdish goodbye).
Part 4 is here.
The next step will be releasing an editor for the language; for now, I think I'm going to use Roger Alsing's Syntaxbox and some other stuff found in the net.
Another aspect worth discussing is that the Entity System will work on its own thread, and it will communicate with the main thread via the so-called "action gateway". Every action sent to the ES is queued and executed serially; the inverse is alike, however the main thread has to take care of serializing the actions the ES has sent and execute them after whatever comes first (usually rendering and physics update).
Now, in my mind this looks like a good plan, but I know it's bound to change somehow. I can't wait to have some working results to show.
Good weekend, Raine out (nerdish goodbye).
Part 4 is here.
Tuesday, July 22, 2008
Tree awesomeness
When you have an artist doing stuff like this...
Awesomeness rating: 100%
Well, check out our website if you're interested in how the tools are coming along. :)
Awesomeness rating: 100%
Well, check out our website if you're interested in how the tools are coming along. :)
Sunday, July 20, 2008
Async Resource Loader
A few months ago I had the map loading stuff done, and wanted to try some landscape paging. I thought a worker thread would save my day but, as it turned out, loading stuff from HD was still blocking the rendering. I took a look around and found out that synchronous calls (even in a different thread) wouldn't act any better than if they were in the main (rendering) thread.
Real life then set in, and I couldn't get much done. Some weeks ago I rewrote the async loader, and this time it'd include asynchronous calls. So, a worker thread + asynchronous calls (Begin... / End... methods). I soon realized a bad design mistake and I wiped the folder (lesson learned: don't code anything until you've filled at least a page of a good old paper notebook).
I'm going to write it again before implementing anything else since I want all loads to be performed without rendering hiccups (or at least, as few as possible, since the OS has the final say on everything). So, since it's to be rewritten, I'll take more time to design it carefully.
The ARL (async resource loader, blah blah blah) allows you to use custom loaders (since all it does, on its own, is to load a stream of bytes asynchronously from somewhere). Once you have added at least a loader, you start the "service" and call the Load(ResourceInfo) method wherever you like (provided it's in the main thread). Once it's ready, you get a Resource object back (from a callback, I guess). That's about it.
There are details to consider, however; load requests have to be queued, can be aborted, the object which does the final loading (that is, converting the stream of bytes into an useable resource) must be locked (both inside the custom loader and outside), and last but not least, it really has to be threadsafe and performing, otherwise it's useless.
That's all for the moment, ran out of inspiration....
Real life then set in, and I couldn't get much done. Some weeks ago I rewrote the async loader, and this time it'd include asynchronous calls. So, a worker thread + asynchronous calls (Begin... / End... methods). I soon realized a bad design mistake and I wiped the folder (lesson learned: don't code anything until you've filled at least a page of a good old paper notebook).
I'm going to write it again before implementing anything else since I want all loads to be performed without rendering hiccups (or at least, as few as possible, since the OS has the final say on everything). So, since it's to be rewritten, I'll take more time to design it carefully.
The ARL (async resource loader, blah blah blah) allows you to use custom loaders (since all it does, on its own, is to load a stream of bytes asynchronously from somewhere). Once you have added at least a loader, you start the "service" and call the Load(ResourceInfo) method wherever you like (provided it's in the main thread). Once it's ready, you get a Resource object back (from a callback, I guess). That's about it.
There are details to consider, however; load requests have to be queued, can be aborted, the object which does the final loading (that is, converting the stream of bytes into an useable resource) must be locked (both inside the custom loader and outside), and last but not least, it really has to be threadsafe and performing, otherwise it's useless.
That's all for the moment, ran out of inspiration....
Friday, July 18, 2008
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):
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.
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.
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.
Thursday, July 17, 2008
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.
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.
Subscribe to:
Posts (Atom)