can organic/chemical parts be 'damaged' like organs? obviously if they don't
get their energy they eventually die and can't be fixed... but perhaps
'damage' would be a sensible method of doing that. have them become damaged a
little each time they don't get enough energy - then there's a small amount of
time in which the object can be revived, but pretty soon it'll be too late.
one of my problems here seems to be that 'parts' are doing the job of both
scripts *and* organs. it's hard to make them easily scriptable and still find
a meaningful way for stuff to evolve. I do want some form of evolution, right?

on hibernation - maybe some organs would reduce their functioning & energy
needs in hte presence/absence of a certain chem? then they'd only need a small
trickle of energy to keep them undamaged. perhaps you could do a similar thing
for sleep too, and hibernation is just like a really really deep sleep? I
suppose part of the definition of sleep is that you're not moving
around much or doing much that would burn energy anyways...

how is it that parts of dna are only activated later in life? like puberty and
menopause - what is it that triggers them and how? what about how a plant
decides when to grow flowers? and when the flowers turn into fruit? and how a
tree loses its leaves? (that one has something to do with stopping chlorophyll
production iirc)

hmm. can a part be disowned? say, a tree disowns a leaf and suddenly it's its
own agent and falls to the ground? kinda like reproduction, but not - it's
taking off an existing part, not interpreting any dna. heck, even reproduction
could start as an egg- or seed-part... that would separate out the
find-safe-place thing (parts can have their own body, that's how you get
compound objects) n'stuff... the seed/egg part would probably have the logic for
growing (possibly including dna reading) once it's cut off (either directly
getting an event, testing a var, or indirectly via chems). 

hey, excretion could be handled with the disown thing too. just create a
garbage part, have some way of getting your unwanted chems into it (would that
be a kidney or liver part maybe?) and then dump it. :) although there might be
a more efficient way of getting rid of unwanted chems... I dunno.

each part, and also the root object, will probably want a var list. an easy
way to implement this would be linked lists, but that wouldn't be efficient at
all. maybe a hash table or something? either way, that's a detail that can be
improved later. hide it behind get and set functions - I'm thinking of
something similar to name vars, except... maybe a bit more type-specific. for
now they'd all be ints but there's also a need for floats and strings.

should body vars be hardcoded or should it be possible to add more? obviously
every body would want a size, location, sprite, colour, etc - but if new
senses are added in hte future, might they want new attributes to sense?
should it just be done like name vars? or should there still be a limited,
predefined set of vars in the body? I'm not sure... a body is really just a
chunk of data and an indication that something has a presence in the world,
and probably an indication that it can send/receive physical events... it's
not a part, because parts can have a body, and no part can have more than one.
...heck, should the root object even have a body? or should it have to define
a part and give that a body? for simple objects like rocks it might be
annoying to define a part, but if you don't define a part then how can you
receive events? I guess you can't... which is fine for rocks and other dead
things, really. or should be. if you wanted a rock that can break like in the
ettin desert, then you would want parts. up to the designer really :)

hmm. should all parts have a copy of the dna? I guess it depends on how the
dna is implemented and whether it can mutate during life. certainly when the
object disowns a part, it should get dna - hey look, forensics. bet I could
make a dna "fingerprint" somehow by interpreting the dna graphically. that'd
be a neat way for the user to compare stuff.

on saving worlds - it'd be nice to do it sanely, not however CL did it... you
have to save not only the state of every object, but also where it was in
scripts, and engine state... and you'd need to make an attempt to let clients
clean up - data for transient client-interface objects (if such things will
exist) would not be stored.
perhaps this would be a valid use of xml.

and then I'd need the ability to load a world back in from xml. oh what fun.
:P
but it'd allow people to extract data from existing world files, and they
might
find that useful. heck, even a world switcher would find it useful - you could
display a bit of info about the world, maybe even save a screenshot of it...
well, no, for a server/client that wouldn't really be feasible unless the
client
telling it to close also sent a screeny... but still. neat stuff like that
would
be much easier.

as for internal structure... hmm. probably start with a body struct, and an
object struct... object may have a body, and may have 0-* parts. each part may
also have a body. both object and parts need some kind of var storage, and
parts also need a way to handle events of some sort. I'm not sure if I'll have
a lot of 2^n limits like CL did... depends how the code turns out.
oh, and as for timer events - more than one would be nice. or you could even
have timer objects that simply send out a blip every so often on whatevr
channel... or timer parts perhaps? heck, with parts you could do both... and
an object sending out a timing signal need not be a simple one, it could be
configurable and so on. certainly for gadgets it'd be a needed part. as for
organic objects... hmm. not sure.

but, um, how would the part itself do the timer? well, that gets into the
internals of how parts work... but I figure each part could be allowed one
timer, like c3... perhaps they could have some weird method of registering with the
engine as being interested in timer events, with the period and starting
point... I don't like the potential for lots and lots of timer parts existing
then though, I wonder how c3 does it...

ahwell. start with some basic body/parts structures, then add some admin
language for manipulating them, then think about dna or interactions or
something.