Thanks for the questions.
Short/quick answers follow:
On 19/12/2007, Joshua Hughes <jhughes@solidtechnology.com> wrote:
> Adam Martin wrote:
> > So ... I thought it would be a good idea to bring it to MUD DEV and
> > try to iterate an explanation and understand better why some people
> > completely disagree.
> >
> Hi Adam,
>
> I read through your Entity Systems post on MUD-Dev awhile back, and just
> wanted you to know that I personally found it very interesting. I
> suspect the lack of response on the MUD-Dev list is mainly from other
> people like myself who are confused about it, rather than a lack of
> interest in the subject. :) Ergo, consider this email an attempt to
> encourage you to finish the following chapters. :-)
> * Entity - I am a bit shaky on this. This is obviously a generic common
> object? It has a list of components, and/or local variables that
> override 'inherited' defaults?
- the entity is, in fact, nothing more or less than a GUID,
i.e. a globally-unique integer. You can dress it up, (give it a unique
string name if you like - but that's just a fancy kind of number) but
at the mathematical level that's all it is. Soemwhere, you have a
mapping from GUID to "all the components that are attached to that
GUID". The entity is a convenient handle to an individual instance
that is easier to persist than a pointer ;)
> Where is the state information for each entity stored? In the entity
> itself? Is it stored in the system instead? I.E. does the Poison_system
> just keep a referenced list of everybody who is poisoned, and the
> Health_system just keep a list of all hitpoints?
- data could live in different places. Your pseudocode gives one
possible implementation. I was trying not to mandate it, BUT imho the
best way in the long run is for the components to contain the
variables. No variables in the entity, ONLY in its components.
- you MIX the concept of "possessing a variable" and
"constructing/initializing/etc a variable" and, possibly (looks
implicit from your code, but you didnt come out and say it) "modifying
a variable". Ideally, I would have possession of variable in the
component, and the initializing take place in a completely different
place. Where? Good question; in my experience at least, that needs to be in
some kind of special system whose job is to "load/create/delete
entities". I should talk about this in the next post; I thought there
was something important I'd forgotten, but couldn't work out what :).
IIRC Scott Bilas / Dungeon Siege did it the same way.
Briefly ... the entity system is great for giving you lots of runtime
behaviour but it DOES
NOT HAVE a concept of construction/initialization built-in. You need
to add that functionality somehow as an external feature. I've been
toying around for a while with ideas of how to do that within the
entity system itself (OOP uses a "special magical method" to perform
construction, which is possibly really just cheating outrageously, but
it "kind of" makes sense, and we all pretend it's normal so it's OK) -
but that's not how I've actually done it before with ES's (it's clearer to
implement that stuff as an external system (not in the
system-within-the-entity-system meaning, but in the
a-system-that-is-not-the-entity-sytem meaning)).
> Sorry for the questions, and thanks in advance for the answers.
Thanks for the prodding. I'll try and do a follow up post in the coming weeks.
Adam