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)
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.)