Code center > Darwinbots3

possible new project


Good Morning DarwinBots.

It's been a long time but over the last couple of years I've been finding myself missing DarwinBots more and more and almost starting a completely new project along the same lines but not identical.
My thought are to start making a pure C++ evolvable or programable bot system using openGL with a nice tidy wrapper ( SFML is currently my favorite option ) using a multi threaded timer interrupt system and an object oriented environment grid (that constantly tracks local bots) to get around the age old limitations of nasty slow calculations.

I see that it's kind of dead around here but i thought I would just post a quick message here to see if anybody is the least bit interested in starting a complete new generation of DarwinBots.

One of the biggest issues I've come up against with C++ coding is that I will have to move completely away from the forms approach used in the VB6 version.
I took a look at the C++ code that is posted up here but I noticed that it's very old and very incomplete.
TBH I plan to throw away everything and start over with a complete new system with whole new sensory systems. The bots that I envision will literally be more like actual robots in the way they work. They will still have the ability to mutate but my plan to separate the "DNA" into two distinct parts. The first part will designate the form while the second part will be purely behavioral.
My "Bots" will be more like little nanites with different possible configurations that can be used for different things such as power generators, manipulators, weapons.
They may still end up looking like standard darwinbots (at least at first ) but that is where the likeness ends.

If anybody is interested in what I'm planning just let me know and I will keep posting updates here.



Hey PY!  It's been a long time!

I'd chuck the old C++ version, except maybe to see how I approached some things.  For better or worse it inherits a lot of the sins of the VB6 version and I was a fairly green engineer at the time.  There's a lot I'd do differently.

For an environment grid I'd ditch object oriented entirely and do a functional style.  Essentially several flat 2D arrays of scalars with some kernels to apply to them.  I feel that's more likely to be both testable and performant.  This talk is python-centric but about doing Conway's game of life in an object oriented way and why that might not be the best way to do it.  Might give you some food for thought.

It probably just makes sense to host code on github (assuming you want to open source it) but you're welcome to any server resources you'd like.  The server is just running linux where we have (essentially) root access.

When I find free time I still try to work on DB3 but I'm happy to put together a few CLs for your project if there's anything well defined you'd like to farm out.

My object oriented env grid concept is really more designed to make it far easier and faster to scan the botlist for details.
Each section of the grid would act as a completely independent map segment that would own all bots and other objects that are present within it.
When an object moves across a border from one segment of the grid to the next, the segments would pass ownership from one to the other.
In this way, during a sensor scan the bots only need to concern themselves with any segments that are within their sensor range. Makes the botlist WAY smaller so takes massively less processing power.

Ah, you're basically describing a broad phase, specifically a uniform grid.  (See this lecture, for instance).  There are a couple other methods, each with pros and cons.  Personally I like sort and sweep (also called sweep and prune) just for the simplicity of implementation.  You basically project all your convex boundaries on to an arbitrary axis, sort everything, and find potential collisions by walking forward or backward from a given point.  Spatial hash could also work.  Basically a uniform grid but instead of having every cell be unique you take the x,y coordinates of non-empty cells and use it to construct a hash function in to a hash table.  Then you're only really storing cells that have stuff in them.  Worst case two cells map to the same hash cell but you still have to do a narrow phase check so it's just a few extra narrow phase checks in practice and not a big deal.

Posting to designate interest.


[0] Message Index

Go to full version