Code center > Darwinbots3
Darwinbots 3 Progress
Prsn828:
Actually, I have a few zero-bot sims where the bots used venom quite quickly. Also, have you ever heard of the 'Falling Sand Game'? It uses clever tricks to quickly simulate thousands of particles of different elements, as well as their interactions, and does it extremely fast. I have actually made a version of it my-self, so I know it is actually quite simple. Further note that most are run in Java, the slowest of the High-level languages. A C++ version I know of can run 10,000 particles at 1,000 frames per second on a grid of 8,000 by 10,000 pixels (values are approximated).
You just have to think outside the box.
Oh, and DNA will be much more robust this time around.
Numsgil:
Don't they work by having a huge matrix (*gasp*) of particles, and then defining a kernel (*gasp*) which acts on that grid?
I thought about doing something like that for the environment grid. Or more precisely that was the environment grid. But it's a huge amount of data usually. And while the kernel operation is O(nm) for the dimensions of the matrix (n rows m cols, or whatever), O(8000 * 10000) is still a huge number. Even if a clever algorithm can take advantage of the sparseness and get you down to O(n) for n particles, you still need a lot of particles.
So I dunno. There might be some clever answers. Will need to spend some time thinking about it. An ideal solution would scale more or less linearly with the number of bots, regardless of sim size, just by clever coincidence.
Prsn828:
--- Quote from: Numsgil ---Don't they work by having a huge matrix (*gasp*) of particles, and then defining a kernel (*gasp*) which acts on that grid?
I thought about doing something like that for the environment grid. Or more precisely that was the environment grid. But it's a huge amount of data usually. And while the kernel operation is O(nm) for the dimensions of the matrix (n rows m cols, or whatever), O(8000 * 10000) is still a huge number. Even if a clever algorithm can take advantage of the sparseness and get you down to O(n) for n particles, you still need a lot of particles.
So I dunno. There might be some clever answers. Will need to spend some time thinking about it. An ideal solution would scale more or less linearly with the number of bots, regardless of sim size, just by clever coincidence.
--- End quote ---
You use a giant int[][] where each int represents an element, and you go through the array performing local operations on small sections. You get to skip any empty/blank sections, so that greatly speeds up the process. You can usually just use a dictionary to apply results, and results only occur within certain random probabilities, which further shrinks the task. Often you must lock positions that have been edited, again decreasing the number of things left to iterate. All in all, it is a game of getting away with doing as little as possible, and ordering if statements as strategically as possible.
If we want to implement this in DB3, we will need to modify how it works, but it is doable, and it wouldn't really have an impact on the simulation speed since I doubt much would be moving around without gravity to influence things.
Moonfisher:
Took a look at those falling sand games, pretty cool demo's. Couldn't find the source though, but had a look at the forums.
Am I correct to understand that these particles will only interact with eachother, and that bots wouldn't collide or see them?
Or are you planning to change the way collision works for bots aswell? And if so... is there another clever way to avoid heavy costs in this area aswell?
Also on a sidenote if the bots can see the particles then they'll probably have a hard time navigating (Maybe instead of actualy seeing the particle the eye could see past them but still register the presence of a particle in the eye, or something like that)
Prsn828:
--- Quote from: Moonfisher ---Took a look at those falling sand games, pretty cool demo's. Couldn't find the source though, but had a look at the forums.
Am I correct to understand that these particles will only interact with eachother, and that bots wouldn't collide or see them?
Or are you planning to change the way collision works for bots aswell? And if so... is there another clever way to avoid heavy costs in this area aswell?
Also on a sidenote if the bots can see the particles then they'll probably have a hard time navigating (Maybe instead of actualy seeing the particle the eye could see past them but still register the presence of a particle in the eye, or something like that)
--- End quote ---
The reason for using these particles, I believe, is to allow them to act as environmental factors, such as sand, salt, water, etc. that bots could eat or absorb and use for various biological (or maybe it should be 'botological') processes, such as making shell, venom, etc.
Bots would be able to interact with the particles, and I believe they would likely need to break these particles off of solid, polygonal chunks of material in order to use them.
In this way, only the broken-off pieces would really interact with anything on a particle level, and the remaining polygon chunks will still be treated as a single object.
Speaking of polygonal chunks, I am proud to announce that I have had the pleasure of seeing just what a bot will look like (OK, maybe it isn't even close yet, but it IS the outline of the outer shell of the bot). In the past twenty-four hours, I have completed what is the majority of graphics commands that are necessary for the visual end of DB3 (The part you guys will be seeing the most of).
Now, I will explain how interactions will be handled:
Every physical thing in the simulation will be a type of SHAPE, which is to say, a thing with defined form(shape), but without a position and/or orientation.
A BODY is a collection of SHAPEs, and also defines the position and orientation of each of it's shapes relative to itself, as well as its own position and orientation relative to the simulation space.
Every SHAPE is able to give a BoundingCircle, which is centered at the center of mass of the shape, and within which the entire shape resides.
Since a circle can only overlap another circle if the SUM of their RADII is LESS than the distance between their CENTERS, it is fast and easy to tell if any two shapes MIGHT be colliding.
If it is found that two shapes might be colliding, then a vector that is said to be projected to the normal relative to each shape, as seen from the opposite shape this vector is coming from, is found, and can be used to determine how the collision is occurring, if it occurs at all. Don't quote me on this, I probably jumbled some of the descriptions in a bad order :/
Not only are these special vectors easy (for the computer) to compute, but the ones that are most commonly used are stored in a cache for near instant access, such that the value need only be computed once, and can be retrieved at any time afterwards.
Because of all of these methods (and some more that are a little confusing to myself, even though I may have been the one to program them in), it is expected that DB3 will be quite fast, despite the seemingly large amount of work it has to process. Trust us when we say that we are going for speed, because even things like Area and Circumference are stored in memory to prevent recalculating them.
So far we don't yet have any sysvars, or any definitive format for the DNA, but I plan to work on that some more today.
Also, sorry if my capitalization earlier sounded a little harsh, I was just pushing some subliminal messages into your heads to help you understand easier
As always, any questions or comments are welcome, this thing is (hopefully) many years from being completed (meaning it will be maintained and improved for a very long time after its initial release as a usable program.)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version