Code center > Darwinbots3
Darwinbots 3 Progress
Moonfisher:
Ehm, I'm a litle confused, you mention having water and air as particles, but then you also mention breaking particles off of polygons in order to use them.
If the entire environment is particles then it would no longer be cheap to process since you need to go over every pixel, and from looking at the sand games the method doesn't seem well suited for simulating large masses of particles blending together. I'm sure a lot could be done to improve performance and make the particles switch place if one is heavier than the other and stuff like that... but I think it would be a lot cheaper to have air and watter as a field and only simulate sand and minerals as particles.
I also think the way the sand physics works would have to be improved a lot in order for it to be realy usefull, or it'll just end up at the bottom as a rock hard wall.
But if you're planning to break the sand off of polygons to use them, then do we actualy need the particles ?
Also in case you haven't already done this, you can also find the radius for an entire body, this way you only need to check polygons within the radius against the polygons in the body.
Btw do you have t a link to some reference material you're using for collision?
Numsgil:
Leaving aside computational costs for the moment, combing the sand games with alife would be cool. Bringing back computational costs, well, ugh. It is highly parallelizable, which is nice. But it's just too much overhead for the present.
That said, I really don't know how the break off bits of polygons to allow for tunneling and mining. It's not something other games do usually. Dig Dug is still pretty much state-of-the-art. So I'll need to figure out some options when I get that far. The only two options I know of at the moment involve using a grid of particles or using unions of shapes and negative space.
Prsn828:
--- Quote from: Numsgil ---Leaving aside computational costs for the moment, combing the sand games with alife would be cool. Bringing back computational costs, well, ugh. It is highly parallelizable, which is nice. But it's just too much overhead for the present.
That said, I really don't know how the break off bits of polygons to allow for tunneling and mining. It's not something other games do usually. Dig Dug is still pretty much state-of-the-art. So I'll need to figure out some options when I get that far. The only two options I know of at the moment involve using a grid of particles or using unions of shapes and negative space.
--- End quote ---
You don't have to know of a technique, just create one.
Most of the shapes are polygons, so break off a triangular section, turn the original into two valid polygons (since it probably just became part concave), and viola, you have your origonal, plus a loose chunk. The math for it is extremely simple, basic algebra at the most; and you could specify, say, the area, or the mass, of the chunk you break off, to be a certain mass/size.
As far as dig-dug, me thinks they use a boolean grid for the dirt
Not that complicated, especially when compared to a falling-sand game.
And, now that you mention it, combining a falling-sand game with something like DB3 is something I have always wanted to do/see done. Perhaps we will in another release (but DEFINITELY NOT in M1!!!)
Prsn828:
Sorry about the double post, but an edit on the last one would have been unnoticeable.
There is a link HERE at the top of the page that will take you to the chat Nums and I use to collaborate. If you want a real-time chat about DB3, that is the place to go.
Arzgarb:
--- Quote from: Prsn828 ---Oh, and DNA will be much more robust this time around.
--- End quote ---
One thing that currently reduces DNA evolvability is the mod:ing of values. For example, if a mutation changes a number to a logic operator, its value gets mod:ed to the number of values in the "logic operators" class. Since the amount of commands in other classes than number and *number is quite low (under 20 in all, I think), evolved DNA seldom contains large numbers. This could be fixed by not mod:ing the value of the base pairs and maybe storing the mod:ed value somewhere for faster use. What I mean is that while a bp now looks like (type, value), it should be changed to (type, value, modvalue), where modvalue only needs to be recalculated when a mutation occurs.
--- Quote from: Prsn828 ---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.
--- End quote ---
If particles can be broken off of shapes and then consumed by bots, you'll also want to allow them to be released again (maybe when the bot dies?) and to get packed together and transformed to a shape again. Otherwise you'll eventually end up with all material being chopped to particles and eaten up.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version