Author Topic: A new project ( and possible thoughts for DB3)  (Read 3330 times)

Offline Hastur

  • Bot Neophyte
  • *
  • Posts: 1
    • View Profile
A new project ( and possible thoughts for DB3)
« on: March 30, 2009, 05:21:23 PM »
Hello all -

I've been playing with DB2 quite a bit, and lurking on the forums for a while.  I have also been reading over the DB3 progress and technical specifications, and have decided to start my own project.  I'm using this post to describe what I'm doing, maybe get some feedback, and perhaps spark some discussions about features in DB3 at the same time.

It is not my intention to draw anyone away from DB3.  I will definitely play with it when it comes out.  I am starting with DB2 as my baseline of functionality.  The ideas are all good, but my aims are a bit different than where DB3 is going.  

** Simulation differences **
What really excites me is the idea of emergent behavior.   I want to see bots change in significant and unexpected ways over time.  I'm not very interested in a "C-Robots or Core Wars with food" kind of thing.  While those are certainly fun in their own right, I want to see things evolve.  So I plan on making the mutation system as close to "real world" as can be done in the context of a sim.  

This leads to multi-cellular creatures.  I want to have a slightly more robust mechanism for inter-cell communication.  Perhaps model some kind of chemical secretions, which causes every other cell within a certain distance to have receptors triggered.  Or a touch based system that is faster, but requires contact, like neurons.  Mutations have to be able to support the emergence of multi-celled critters as well.

I would like to see the DNA "instructions" operate at a somewhat lower level than they do now in places.  Reproducing in one instruction doesn't really do justice to what is happening.  Of course, writing 50 instructions to divide a cell isn't fun either (more on that in the technical section).  So some of the current sysvars need to be broken up into more atomic steps.

** Technical differences **

Because of the things I would like to see on the simulation side, I need to diverge a bit on the technical side as well.

I would like to see a more client-server form of module separation.  If you are running a simulation off in the corner for a hundred hours, it doesn't make sense to waste a lot of computer cycles drawing things on the screen.  So I would like to see a separation between the simulation itself (the server) and any tool that can be used to view the simulation (the clients).  The simulation server would be a minimally interactive application, run from the command line, that is designed to run the simulation as fast as possible.  Clients could connect to it to see the state of the simulation, modify conditions, add new bots, etc.

Multi-core is a must.  Cores are actually getting slower as time goes by, but they are making up for it in quantity.  Dual core machines are standard consumer products now, and quad core is just around the corner.  Three years from now 8+ cores will available.  I'm currently eyeing a new desktop machine that has two quad-core processors.  Any simulation that doesn't support threading at a fairly low level is going to get left behind.  

My initial thoughts on thoughts are that running the DNA programs can be easily parallelized.  Since the DNA only affects the owning cells state, that can be threaded with no problems.  

When the simulation runs, cells on one side of the field can't affect cells on the other.  They can be simulated in parallel.  My thought is divide the simulation space into "zones", based on the number of active cores.  Cells within each zone will interact with each other within the context of a single thread.  Cells on the border of a zone could potentially affect cells in another zone, so in the those cases the threads would have to coordinate their activities.

Don't get me wrong; multi-threaded programming is hard to do correctly.  I'm a big fan of the messaging passing concurrency style that Erlang uses.  But Erlang is fairly slow when it comes to raw processing speed.  It would be a net loss on a single core machine.  On the other hand, Erlang easily scales up to multiple cores, or even multiple machines, so with sufficient hardware, it becomes a real contender.  I wrote a small multi-threaded sim in Erlang on my machine.  It got up to 400 active threads.  I was then able to hand off a number of those threads to other machines on my home network.  By the end, I had 800 threads running on four different machines, with no deadlocks or problems.  It's pretty darn impressive.

But, since raw, pedal-to-the-metal speed is the issue, I want to do the simulation piece in C.  It needs to be portable between at least Windows, Mac and Linux.  The GUI pieces don't need to be as fast, so can be written in a much higher level language, like Ruby or Python.  Graphics needs to be in OpenGL for portability.

Since the simulation is being run as a server, it should be fairly easy to have simulations that are always on.  Rather than starting and stopping the simulation all the time, I can just keep it running, then connect to it when I want to see what's going on, or make changes.  Likewise, anyone else (with permission, of course) could connect to it and possibly manipulate it at some level.  It might be fun to have a community "primordial soup" where people can log in, dump their newest creation, and see how it fares in a chaotic, free-for-all environment.  Kind of like the league play now, but in a more natural fashion.

As mentioned earlier, things like repro are too high level.  I want to support the idea of "libraries" of genetic information, that can be included into a cell's programming.  You would be free to use the stock repro function, which then includes all of the steps needed to do reproduction, or write your own if you want to tweak the process.  

My reasoning here is simple.  The longer that a DNA strand is, the more mutations can affect it in unexpected ways.  The current system has repro as a single step, so unless a mutation hits that step directly, reproduction will never be affected.  And, if it is affected, it might make reproduction impossible (for instance if an instruction is deleted).  By having a long strand of birthing instructions, a mutation somewhere in the middle will change it without necessarily destroying it.  

On the other hand, being able to work effectively with multi-cellular organisms requires thinking at a somewhat higher level.  If I am making a 200 cell Darwinzilla, I need to be able to abstract the genetic instructions for each piece.  Libraries of functions are a perfect way to do this.

I also like the idea of being able to break your project up into multiple files.  Maybe each file is analogous to a chromosome.  A complete DNA "strand" would include specific chromosomes, which would contain any number of genes.

The current RPN Assembly language is truly horrific.  I love the stack based idea, and how the DNA controls the state, rather than simulation, but that language is just awful.  So that needs an overhaul.      

Whew!  That was more than I intended typing.  Feedback is welcome.  If any of this can be useful in DB3, have at it.  Maybe I'm over-complicating?  I don't know, we'll see.  

Offline Endy

  • Bot Overlord
  • ****
  • Posts: 852
    • View Profile
A new project ( and possible thoughts for DB3)
« Reply #1 on: March 30, 2009, 06:12:44 PM »
I was thinking a language with percent based actions and that modified all memlocs/memvals to be within a standard range would work best.

For multibots, you'd need a semi-global memloc system accessible by all bots in an MB. Then they can directly communicate and co-ordinate movement. I rigged up a version using *.totalmyspecies and it did well to have them all going the same direction.

I was hoping for something that could interact with the user too; see the cursor, sense a key press. You can rig something up in DB that works like that and program the bots to react. It's weird, but cool to see them reacting directly to something you do.
« Last Edit: March 30, 2009, 06:14:21 PM by Endy »

Offline Prsn828

  • Bot Destroyer
  • ***
  • Posts: 139
    • View Profile
A new project ( and possible thoughts for DB3)
« Reply #2 on: March 30, 2009, 06:39:41 PM »
By all means, give it your best.

Honestly, I have no idea what lies in store with DB3, but I do want to caution you, it is a huge task to build something this big, especially by yourself (Although it would not be unlike me to try it  ).

I am glad to see so much activity in the forums right now, as I joined when it seemed kind of dead...
Keep us updated as to how things are working out.  This sounds like a very interesting approach.
So, what will it be? Will you submit to my will, or must I bend reality to suit my needs?
Better answer before I do BOTH!

Offline bacillus

  • Bot Overlord
  • ****
  • Posts: 907
    • View Profile
A new project ( and possible thoughts for DB3)
« Reply #3 on: April 01, 2009, 12:22:24 AM »
I tried making a simulation once that tried evolving life forms from a primordial sludge of 'elements'; while it didn't work as well as I wanted it to, it can scavenge some key ideas from it:
-Minerals have different properties, which change the cell. Yellow, for example, might be very unreactive and takes plenty of energy to bond, which means that it offers good protection. Other elements may be conductive, which allows the transfer of heat. This could be translated to digestion rates.
-Energy can be internal eg. through chemical bonds, or external eg. spots of high temperature, which could either speed up certain reactions, or break up the 'organism'. Something like this is something I always thought would be cool to implement, but relied on too much of a physical model of the cell itself.
-Certain elements could form a temporary physical bond, which helped anchor the organism and prevent the current from sweeping it away.

On a different attempt, I tried out the concept of a 'cell wall', which simply held the bot intact and would kill the bot if it disappeared eg. release all its energy and minerals. The wall has to be sustained, and can be damaged through heat of enzymes released by other cells.

Hope you found something mildly inspiring in there  
"They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown."
- Carl Sagan

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
A new project ( and possible thoughts for DB3)
« Reply #4 on: April 01, 2009, 06:40:57 AM »
I'd be interested in any ideas for something not RPN based.  It is truly awful to try and read.  Writing it is actually pretty easy (and there are times I wish I could code using RPN when I'm working with equations) but reading it is next to impossible.  You have to keep a sort of stack going in your head and, well, yech.  But it is very forgiving about order.  If the commands are "words" then any sequence of commands forms a grammatically valid "sentence".  Which is invaluable where mutations are concerned.  That's not true of something like C or BASIC, which means mutations have to have some grammar knowledge built in, which potentially introduces biases.  Makes the mutations less "pure".