Code center > Darwinbots3
One year plan
Numsgil:
I've been saying off and on that I'd like to aim for a summer 2015 release for an early version of DB3. I think I'm in a good place to hit that, if you're willing to call mid to later September 2015 summer :). The timeline is maybe a little aggressive, but I'd give 2:1 odds that I can get something together in the next year that will be actually interesting to play with. Most of the pieces are there, so it's just a matter of gluing everything together and working out the issues that come along with that.
First, the scope of what this first release is going to be:
What it will definitely have:
* A GUI and graphics. Superficially similar to DB2 in many ways.
* Basic robots that can swim around, reproduce, and run DNA.
* A simple fluid model. So when I say swim around, I mean swim around. Bots and debris near each a moving bot will be moved by its wake. Bots can move the fluid in such a way to produce a "sucking" force to pull in food, that sort of thing.
* An editor to make writing DNA easier (thanks Panda)
What it will almost certainly have:
* Robots that can change their shape - There's going to be some limitations, but the current thought is that bots will basically have a body made up of uniformly sized "panels", that together form the outer hull of a simple polygon. They can't change the length of these panels, but they can change the angle between them.
* A combat system. - To gain energy from another bot, bots can either completely engulf another, digest the other externally (by secreting digestive enzymes) and "drink" the enzymes in, or attach themselves and siphon energy out. Engulfing will probably be the primary means of digesting matter. You'll probably want to be sure it's dead first, though. Defenses to the above I'll need to think through, but it will probably be somewhat similar to DB2 in the end.
* Chloroplasts - Something related to the surface area of the bot (to model respiration) and the amount of exposed area in contact with direct light (using a simple ray tracer to detect occlusion). I don't have a good idea about the exact details yet.
50/50
* Shapes/substances - That is, inorganic "things" in the world that bots can carve chunks out of. The stuff the shapes are made out of will probably be necessary for photosynthesis and/or to synthesize some of the things that bots need to grow. Inorganic remains from dead bots can "fuse" together to form new shapes.
What it probably won't have (but might)
* Physics - Specifically, bots bouncing off of and not penetrating each other. I have some really clever ideas for how to make the physics behave robustly enough to build large towering multibot structures, but fleshing that all out is going to take a good bit of work.
* Multibots - No physics also means no multibots.
* Multithreading - Everything's set up to be multithreaded, but making it actually work is a different matter.
* SIMD support - For those that don't know, all modern processors have an instruction set that can operate on 2, 4, or more floating point numbers at a time. C# doesn't really support this, but Microsoft is currently working on changing that. There's also a library called Yeppp! that provides SIMD primitives that map pretty closely to how a lot of my code is currently set up. But either case takes time that I might not have to spend.
What it definitely won't have
* Internet mode - I want to try and be more clever about how IM works in DB3 than what happens in DB2 right now. At the very least, I'd like to revisit the way that teleporters work and see if there's a better way. But that will require a better idea of how physics and multibots in DB3 work, which requires physics to be working. Plus, there's a lot of infrastructure that needs to be built on the server to make this work, which is out of scope for what I can really done in the next 12 months.
* Speed - The core algorithm at the heart of everything is going to be fast for what it is, but it's going to scale poorly. You might only be able to run ~100 bots at any reasonable speed. A different algorithm is entirely possible, and I sort of kind of know how to do it, but it's realistically several months of work.
Once an initial version is released, I'll try to polish it and generally make it work as a simple version of Darwinbots. Then, to that, I'll start adding back in pieces I haven't finished yet, while trying to get feedback from the community about how things work and what sort of priorities different things should have.
In order to build anticipation, I'm going to try and keep a dev blog of sorts in this thread. Post screenshots when I have something worth showing, that sort of thing.
Numsgil:
So, for the first dev blog type post, I'm going to share what I've been working on for the last few months:
Implementing lsqlin in C#, in a way that's efficient.
It doesn't sound very exciting, but it's really important for fluid and bots changing shape. It's also what the Physics will use to solve constraints and contact points. Most importantly, it's what will let all three systems (fluid, physics, bot shape) work together consistently, without producing any problems.
The solver I'm working on uses a Complete Orthogonal Decomposition and needs to update a QR decomposition, so I've been working on those over the summer. I've finished with them, and run them through a rather aggressive suite of tests, and things look good. Importantly they are very memory and cache efficient, so I should be able to get performance out of the solver that's better than Octave (an opensource Matlab clone).
I'm going to put them together in to the final lsqlin algorithm, and then I'll be done with this part (hopefully). I expect that to take me another month maybe to code up and test.
Once that's done, my plan is to combine it, my graphics engine, and the code for DNA to produce a simple app to try out changing and controlling robot shape. My obstacles there will be ensuring that the robot roughly maintains its total area and doesn't self intersect itself, and how best to actually control the shape of a robot from DNA.
spork22:
So there could be bots that utilize jet propulsion for movement in a similar fashion to squids or jellyfish?
Botsareus:
Thanks for the problems link Numsgil. I was loling for a good minute.
How far did you get with Box2D?
Numsgil:
--- Quote from: spork22 on September 01, 2014, 03:39:16 AM ---So there could be bots that utilize jet propulsion for movement in a similar fashion to squids or jellyfish?
--- End quote ---
Yep, that's my hope. Tricky bit will be whether that form of locomotion requires certain fluid properties or not. I'm trying to get away with only simulating certain aspects of fluid, for performance. (Specifically, I'm hoping I can get away just using the Biot Savart law, and don't need to add in any other terms (viscosity, vorticity) to get interesting fluid-like effects).
--- Quote from: Botsareus on September 01, 2014, 11:06:42 AM ---How far did you get with Box2D?
--- End quote ---
All existing physics engines I'm aware of don't do what I want them to do, Box2D included.
Navigation
[0] Message Index
[#] Next page
Go to full version