so, I'm trying to figure out whether I can gte some sort of plan tht can
actually be implemented a bit. unfortunately my memory and concentration are
screwed up because of my lack of veggies, and this fucking computer making me
depressed.
so... I have this parts idea. lotsa nice predefined parts that can be coded
for, and users can create more parts and add them too. they'd kinda replace
the scriptorium, I guess. thing is, they'd prolly be responsible for
conserving energy, and I want to make sure that there's an understandable way
of doing that, and testing the eficiency of parts, so that people can know
which ones break conservation, and don't do it by accident.
remember, kits will probably run *outside* the game, and just have litle hooks
into it, some standard way of getting info and doing stuff.
I was thinking of having two types of parts: organic and inorganic. organic
ones communicate through nerves or chemicals, and once the cob dies they shut
down permanently. inorganic ones run on electricity or something, and can be
turned on & off as you wish. that way the electricity can be metered to
conserve energy, but if someone gets sick of the 'conservation' they can hook
it up to an unlimited energy source or something. we're not going to make it
annoying like bioenergy, but for wolfling runs I think it'd be a good way of
preventing the world from grinding to a halt from out-of-control replication.

hmm. I wonder if there's any easy way of determining energy-consumed by the
amount of time the part spent processing stuff? if there was, it'd be a neat
way of balancing stuff - if you want complicated parts that might lag the
world, you have to have the energy required to run them. and it could be
easier than hand-calculating the appropriate energy cost.

I still haven't worked out the communication stuff, though. and what language
would the parts be scripted in? and how would the dna work? oh, and it seems
vadim's engine isnt exactly designed to understand parts. it only expects
creatures to see things, and I dunno if it supports other senses. so either I
make my own, or pwersuade his to be more flexible, but either way I have to
define the interface first.

when it comes to creating first cobs, either at world creation or from an
injector... I see them as generally having two things: dna, which codes for
parts and sprites n'stuff, and an initial blob of matter (chems) to start
from. I suppose they'd also need an initial location or something... in
general I'd like that to be based off another object (the parent or a little
reciever-thing for the injector) but some agents may not care about being
in-map or something... oh, I'm probably going to hate mvsf, I hope fuzzie
finds a good way of doing it.

hmm. I haven't thought about object interaction with push/pull/etc. I can tink
about that later. also, fuzzie says the DS engine just gives out 5 commands
per tick (inst blocks counting as one, I assume). hmm. I'd still want
something that counts everything, even in inst. depends on the language for
the parts, I guess.

okay, so where do I start? I don't really need a brain structure yet (dunno if
that'd be in a part, or something special) but I do need a few basic parts,
power sources, a framework for tracking energy... and I need to sotr out the
chemical model. I can probably make simple inorganic things like rocks and
balls without it, but no plants or anything... oh, foo, and plants are going
to want something soil-like. I woner if parts can simplify that too? in a way
it'd be another communication/transport method... chemicals in hte
environment... and you'd need a 'root' sort of part to absorb them. I expect
I'll need a few parts for excretion, too.

so... scenery objets obviously don't need chems. but what abotu gadgets? most
wouldn't want them, it drains processing time and chemicals have a tendency to
decompose, but some may want to be weird hybrids... eh.. I'll see how it goes.

hmm. objects will also need properties. I'm not sure if initial properties
should be specified in dna or derived from something else. need to think about
both the adam/eve case and children. children would generally start egg-like
with chems donated by the mother. injected cobs would need to have everything
normally taken from the mother be defined. either way, I wanted the dna to
control the appearance... not necesarily the exact sprites, 'cause animation
might not be feasible that way, but certainly the properties (size, colour,
whatever) and the sprite set (eg. norn breeds). but dna would also have to be
combined, for breeding... that'd have to be done sanely, ohdears, and it'd
generally have to be robust and not break horribly from any random mutation (a
mutation that makes a creature unable to live is fine, though).

urk. I'll have to define dna, something that interprets dna to build an object
from it, some basic parts in whatevre language, something that can run the
parts in a controlled way... 

then I'll need a chemical model for parts that deal in chems... some sort of
outside-chem model for parts that want to interact with other objects
indirectly...  oh, and parts need a 'broken' flag, organic ones have it set
when they're unable to draw energy, gadgets might have some other way f
setting it but lack of electricity doesn't permanently break them... hmmm,
what about hibernation?

anyways. I'll also need an injector kit right from the beginning, and some
sort of caos-like interface for directly mucking with the world... then I'll
need a general kit-interface, perhaps built on top of a generic client
interface... but that would mean it'd definitely be a server. other way would
be to write kits as clients to AC, and make sure AC has the flexibility
necessary to let my kits do what they need...

I suppose I'll also want to be able to see the world in some form, won't I?
well, that means either making it a client to AC and usign an AC client to
view it, or setting up some basic thingy myself.

either way, I *will* want a direct command-line interface built in, in case it
goes nuts or something.

oh, and I was thinking maybe have body-related properties separated out a
little more. maybe even a 'body' part that stores location, size, stuff like
that. hrmm, which makes me wonder how dna can store sprite names and still be
flexible, but anyways. figure that out later. objects also need a common set
of vars, for communication n'stuff. chems could be quite useful for
signalling, but more specific stuff would require something more like name
vars. like setv name "sense_light" 1 or something, to indicate that the object
is interested in anything shining light. then the lamp part of another object
would check for that property before sending out some light... I dunno... it
could just shower every visible object with light, but it depends which is
more efficient. also depends on whether the engine (us or AC) can preselect a
list based on having a certain property.

aaanyways. where do we *begin*? with a game loop that does nothing. whee.
then, it needs hte ability to load in parts. either load em all at startup, or
load when needed, but it'd be nice to load new ones without a restart. sounds
like you want a general load_part() function. mm, we should be able to
gracefully handle requests for nonexistant ones too. and keep track of who's
loaded.
parts'll need a uid; will that be number or string or what? reserving caos
species #s was annoying; it'd be nice for each author to be allowed their own
namespace or something. basically, there has to be more than enough room for
development, and some reasonable way to avoid accidental duplication. and a
sane way to overwrite with new versions might also be nice.

so, say we have a magic load_part() function that gets the part for us, and
can be called whenever the dna asks for a part not loaded.

mmf. let's start with non-flexible dna for gadgets, where we don't have to
worry about mutation or anything.

now, this totally blank world... at least it doesn't need a gui. that'll be
the client's responsibility, but it will need to provide data required for
that gui.

what do we want to do first? assuming all resources can be loaded on demand. I
want to create... a block. just a dumb block of stuff. I dunno yet whether I
should be required to define *what* stuff, so let's skip that... but... first,
I need a new object. give it a mass of, say, 5. I'm The Hand, I can create
matter from nothing. :P then, it needs a body. body has a size (1), sprite
(?), location (?), and whatever other properties the sense parts end up wanting.

did I forget anything? can't think of it. a block doesn't do anything, doesn't
decompose, and I don't want to deal with stuff being eaten yet.

oh, and about plants and no incentive to make fruit: there is, however, an
incentive to make nectar - pollination could be possible, at worst it'd be
like the stickyweed thing.

oh. and once I'd created a few blocks, I might want to destroy one.
first I'd need a basic list of all objects in the world. kinda like ps. list
uid, location, a few other things about them... just simple stuff. then
deleting by uid should be easy.

I wonder if I could get a nice tab-complete command-line thingy? eh, prolly
just as a client, the builtin one would be quite basic.

back to the block... the object and its mass would be something created in
part-language, like an injector. but the body and its properties- I wanted
those read from something dna-like. for now let's not think about the ability
to mutate: just get something basic. heck, you could do it in lua: all you're
really specifying is one part and its initial properties. then to create the
block, I'd specify a mass and a string of dna - perhaps loaded from a file,
perhaps some other way - say, from an existing object. mm, later it'd be good
to have a command for dumping an object's dna to file. still not quite sure
how a world itself would be saved.