Re: Heatbug thoughts...

[Sven N. Thommesen]

At 04:46 PM 8/18/97 -0400, you wrote:
>All (who are interested),
>
>I have started thinking of a radically different way of doing the
>heatbugs birth/death/lifespan...
>
>At the simulation start, create the maximum number of bugs allowed in
>this population, (in the default world, 80 by 80 -> 6400 bugs), but you
>might set it lower than that.  

You definitely *want* to set it lower than that, if you want your bugs to
be able to move at all!

>Then have status flags, (ie. limbo, baby,
>mature, dead), where that is the order that the lifespan follows.  You
>could even had different behaviour for the various life stages, (ie.
>baby bugs move randomly, mature bugs follow "normal" movement rules,
>dead bugs absorb heat, instead of create heat, bugs in limbo don't do
>anything.)
>

Sure; a complex if-statement in the -step method will do it.

>You could implement a Age variable, or just make changes in its
>happiness level control the stage it's in.
>

Epstein and Axtell's book on Sugarscape has lots of different behavioral
rules that you might find interesting.

>The only problems this presents, is that after the initial creation,
>would each bug have static aspects, ie. output heat, comfort level.  

No reason why a bug can't change its own parameters as its life progresses?

>And
>if they did, how could aspects be passed down from generation to
>generation...  

Again, the Sugarscape book describes different modes of offspring
inheriting attributes from their parents. You could have two neighboring
bugs 'have sex' and produce a new bug (new bugs don't *have* to be created
by the owning swarm) -- you just need to give the owning swarm a method to
pass it a pointer to the new bug so it can be added to the buglist;
otherwise the new bug would not be called on to 'step' and to display
itself every period.

>I have figured out how to create my own pixmaps, I
>re-created the mature heatbug pixmap, and also a baby pixmap and a dead
>pixmap 

Here, Brad, I'd like to hear what you found out: the second line of the ant
pixmap says "8 8 3 1". I surmise "8 8" is height and width, and "3" the
number of colors employed. But what is the "1" ?

>(with the bug on its back, could pixmaps be controled by a flag
>or once a heatbug's pixmap is set, would it be set in stone?  Would I
>have to re-create a bug to re-set its pixmap?
>

Nope. Just have the model swarm define id babyBugPixmap, youngBugPixMap, etc.
Set each of them with a PixMap using the different files you've created.
Have the model swarm pass all the pixmap pointers to each bug. Then, when a
bug changes status in life, it can just say [self setPixMap: maturePixMap]
or somesuch. The new pixmap should show up the next time the bug is asked
to draw itself.

>I fear that many of these changes would require heatbugs to be
>re-written greatly, not just minor changes and tweaks.
>

Well, for one thing Heatbugs has a problem with multiple bugs on the same
square: warnings are turned off, so it is possible to have more than one
bug think they are located on the same square. As far as the periodic
updating logic is concerned, this works (since it accesses the bugs via the
bugList in the model swarm), but of course the world raster can only
display one bug per square (here, the last one to get there). If you want
to play with multiple occupancy, there's the spaces I posted recently --
which Glen may get to putting up when he gets back from vacation ... [But
no, I haven't solved the problem of displaying multiple bugs on one spot.]

>What do you think?
>
>Brad.


Cheers,
Sven


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================