Darwinbots Forum
Code center => Darwinbots3 => Topic started by: Prsn828 on March 24, 2009, 10:09:48 AM
-
Since we are likely less than a year from the first Darwinbots 3 milestone I figured it would be good to bring it some more attention. I get the feeling that most people that use this forum are pretty much in the dark about what is going on with its development, so I want to give everyone an open invitation to ask questions about how things are going and what to expect. Don't be afraid to ask questions or make suggestions, I am open to anything, and some feedback would be healthy for the project.
Now it's your turn, ask away!
-
Is DNA going to be any easier to use? I mean we still have to keep the ability to use DB2 bots, as it seems as if there are very few new bots being created, but I feel that I would be better able to write a bot with an easier syntax. A subtype of BASIC would be prefferable, as I have loads of experiance programming Ti-84's in TI-BASIC.
-
There aren't any real plans for easier syntax, although there are a few changes, like combining stores with calculations. I do understand where you are coming from. Actually, it might be worth my time to create a separate program specifically for coding a bot. I will take this into consideration and think about what would be involved. Now don't let that get your hopes up, I am only going to think about it, I have a feeling it would take a lot of work to actually do, but it would be very helpful.
Honestly, I just started writing my first bot today, so I want to get used to that before worrying about simplifying the process.
Although not quite what you are looking for, I do know that Nums has a shell of the DNA system lying around the forum or the wiki somewhere, so if you want an idea of how the DNA will work when it executes then that is something worth digging up.
-
Same basic syntax, and most of the same commands (though some work a little differently). DB2 bots won't work in DB3 because of slightly different syntax, but a transliteration shouldn't be too hard.
Planned features include a command line DNA parser, so you don't have to create a whole new bot and load it into a simulation to experiment with the DNA. Also included will be a DNA debugger, so you can step through your DNA code one bp at a time and look at the values in the stack and in memory. And a "compiler" which checks syntax and can detect common errors like misspellings. Maybe even an ability to code-and-continue, so you could pause the simulation, tweak the DNA in real time, and then let the simulation continue with the bot having new DNA.
Also planned is the ability for users to create new DNA modules in C#, so you could write a BASIC DNA version if you wanted.
Most of that is a bit further along down the road, of course, so nothing forthcoming right now.
-
I've seen a few different ideas floating around; have you decided what's going to happen with ties/physics/bot shape?
-
I've seen a few different ideas floating around; have you decided what's going to happen with ties/physics/bot shape?
I believe Nums has made a decision on how the ties will work, and the physics is the same; Nums tends to make the majority of the major decisions, but it is his project, and he is more experienced.
I can give a definite answer on the shape of bots. Here goes:
-Bots will be Iscoceleze Trapezoids.
-One side will be the "head", and the other will be the "tail".
-Both the head and the tail will be able to change width, but this might not happen until after M1.
-The height will also be able to change, but again, this will not likely be present in M1.
Some things to note:
-Theoretically, when they can finally change size they could turn themselves into Triangles, which could be interesting.
About ties:
-It is my understanding that ties are going to work more like hinges, where two bots (or a bot and a wall/shape) form a connection at a point on their perimeter which, according to Nums, does not necessarily have to be at one of their vertices.
-Ties are not going to be connected at the center of a bot.
-The plan right now is to partially ignore collisions between bots(or shapes) that are directly tied to one-another.
As for the Physics:
-Right now we are working on this.
-So far we are concentrating on the collision detection.
-Proximity will be judged based on bounding circles, so that if two bounding circles overlap a collision might be occurring. This lowers the amount of calculations done by the physics engine.
-The physics will almost certainly be from scratch, as there are no suitable physics engines for a program like this.
Again, don't expect too much from M1; Personally, I would be glad to even have a blank window pop up at this point, but by that time there will be plenty more that has already been coded.
Keep the questions coming; this is how we can best find holes in the design
-
Will DB3 be multi-core aware, or be able to use processor power on graphics cards?
-
Will DB3 be multi-core aware, or be able to use processor power on graphics cards?
There is a good chance that these will both be available to some extent. The Vectors we are currently using are likely able to take advantage of graphics card capabilities behind the scenes, but I can't promise anything at this point as far as multiple cores and graphics card processing go. At the moment there is nothing this could be used for anyway, but it is definitely a possibility.
It should be faster than DB2, even without these kinds of features.
-
I've seen a few different ideas floating around; have you decided what's going to happen with ties/physics/bot shape?
Each bot gets a single tie. Ties are not meant to be used to form multibots, but are more like mosquito suckers. Their use is primarily to drain nrg from the target over cycles, and to keep that other bot close. They might be springy, or they might be extremely rigid. It depends on how unstable a spring would be.
Bots are trapezoids. Basically the capsule shape we were talking about before but without the circular end caps. We might add circular end caps in the future, depending. Prsn's done a pretty good job of explaining how they'll work, so I don't really have anything to add.
Multibots are formed with "hinges", where basically two points on either bot's perimeter have to stay within 0 distance of each other. They can freely rotate around this point. Hinged bots are partially able to rotate into a collding state to allow for a larger degree of rotational freedom. The exact mechanics of forming a hinge I haven't decided yet. It'll either be done with something like a tie pulling the two bots together, or maybe a bot becomes "sticky" and collisions end up creating hinges, or maybe bots form a hinge during reproduction between child and parent.
Will DB3 be multi-core aware, or be able to use processor power on graphics cards?
To a limited degree it'll be multi core aware. What I mean by that is that each bot's DNA could potentially be executed on a different core. And physics to a limited degree can be passed out to different cores. But for something like this there are computationally expensive areas that can't really be passed out to different cores ("serial" operations), so it'll never be able to utilize 100% of all cores. Expect maybe 70-80% utilization of multiple cores. Which is probably a good thing since that still leaves you quite a bit of processing power to actually use your computer.
It'll utilize graphics cards for graphics, but it's infeasible (though not impossible) to push more to the card because the data has to be retrieved back from the card to the CPU at some point, and that bottleneck tends to be really slow. But things which don't need to be known on the CPU side, like the fireworks effect when a bot dies, can be offloaded entirely to the graphics cards.
-
Have you thought how sexual reproduction will be handled? I think it should be made somewhat easier than in DB2. I don't know if anyone's really tried, but it's really hard to get going in evolution sims and after that to preserve it.
-
My thought at the moment is to mimic sexual reproduction of fungii. Have it so bots are normally haploid, but they can "fuse" to form one diploid bot, with the parent's DNA sort of fighting for control. Then that diploid bot can split again later in to two haploid bots. With stranger mixes on that theme possible too.
-
Actually, I don't think we are too worried about that at the moment.
To be honest, I feel like a sort of collision-time method, where a male builds up sperm, and has it transferred while in contact with a female, would be quite effective. Some measure of fertility, and a sort of timer, could be used to determine when the female (or male, if we do this like seahorses) gives birth, and to whom's child.
Actually, I think this will depend mostly on how the DNA is handled in some of the post M1 versions. For instance, in the real world there are several hybrid animal species, the liger and tigon being prime examples. The reason this can happen is due to the minimal difference in chromosome numbers, but since the hybrid usually ends up with an odd number of chromosomes, it is generally infertile. A system like the one in real life, using chromosomes, would probably help with multibots and with sexual reproduction.
Assuming bots could purposely divide with only certain parts of the DNA being copied, certain cells could have unique functions.
Realistically, we are quite a way away from implementing something like this, but I do think it is something to strive for.
-
So what substances are being used ATM? I thought the idea of digesting chunks of soil for minerals that can be regurgitated was fun, as it could be used to build 'nests' and physical shells.
-
Nothing atm. For Milestone 1 bots will have maybe nrg, chloro (or leaves) for photosynthesis, muscles for moving and feeding, and fat for energy reserves, and that's it. No shell or slime or anything else yet. Just wanted to make things as simple as possible for a first version.
I'll expand that later to allow bots to build shell, etc. And to dig into shapes ("soil") to form nests. And maybe connect the two so shell is built from what is excavated from shapes.
-
What would help to create a more complex environment is by allowing different shapes in a sim to have different physical properties. We could make a beach: two triangles (one water one land) and one rectangle (air), all having their own parameters for physics (like drag, viscosity, buoancy). This is all feasable by making the physics part of the shape and not the sim.
-
That's planned. Not in the immediate future, but I'm planning around that idea.
-
That would save a lot of work. If the first version of DB3 would be programmed as a sim having one shape (consisting of the entire space in the sim) with certain physical properties the basics would be in place at the right level.
-
Yep that's how it's going to work. The first version will essentially have a large rectangular shape which the physics understands that bots are supposed to stay inside of, and the physical properties will be associated with that shape.
-
Wow, you guys really do know how to read my mind on these details
-
Great minds think alike
Or:
It is a no brainer
take your pick
-
So the basic cell components cover about 85% of all cell operations, and the rest can be used with the old substances, eg. poison/virus, which can also be gradually replaced in later versions.
As for different environmental components such as sand/air/water, this could be more complex if it models real life properly, as they do not differ only in physical but also biological properties.
-
In theory such things would have impacts on the way the bot functions and what it can do, but what actually happens is still to be seen.
Until we have M1 working there isn't much of a chance of seeing anything of this sort just yet. Don't expect to see water in M1, lol.
-
My 2 cents:
You talked about making multibots by making bots "sticky" and creating hinges on contact. Could that be used later on to make shell out of sand by sticking it to the bot's skin?
Also, has it been decided yet whether bots will gain energy by shooting, ties or phagocytosis(sp)? If phagocytosis is chosen, how will it be done? Someone else talked about bots opening "mouths" to their fronts, or bossibly to any side. I think the eater bot could then apply a force to another bot (with a .pull sysvar or something), trying to pull it through its mouth. The other bot could escape by simply running away or killing the eater before getting digested, but if the eater it smart enough to close its mouth, the food stays inside (it could still shoot). They could be treated like a shape in a shape, like bots in the sim.
And then about fat, chloro and muscle: will there be a limit on these total, or individual limits? If there will be a total limit, what happens when it's been reached, and the bot tries to make muscle, for example? Will nothing be made, or will muscle be made and fat/chloro removed?
Yay, first post ever after years of lurking
-
My 2 cents:
You talked about making multibots by making bots "sticky" and creating hinges on contact. Could that be used later on to make shell out of sand by sticking it to the bot's skin?
It could, but I'll probably just do something like a bot eats some sand and then excretes it to form shell. Or more likely a bot can produce 1 shell for X nrg, but if it has sand in its gut it can produce shell for 0.2X nrg, or something like that. But then that sand shell places certain limits on how a bot can move (can't stretch or grow for instance). I'm still playing with the exact specifics. I'm trying to model it relatively closely on how diatoms work vs. how an ameoba works (basically it has no shell) vs. how something with a thick cell wall works.
Also, has it been decided yet whether bots will gain energy by shooting, ties or phagocytosis(sp)? If phagocytosis is chosen, how will it be done? Someone else talked about bots opening "mouths" to their fronts, or bossibly to any side. I think the eater bot could then apply a force to another bot (with a .pull sysvar or something), trying to pull it through its mouth. The other bot could escape by simply running away or killing the eater before getting digested, but if the eater it smart enough to close its mouth, the food stays inside (it could still shoot). They could be treated like a shape in a shape, like bots in the sim.
Again, still working through the specifics. Check out this forum post (http://www.thescienceforum.com/How-do-zooplankton-eat-17827t.php) I did not some long ago in another forum, which lead me to this link (http://www.nova.edu/ocean/messing/protozoaC.html) which talks about how zooplankton feed. It also is almost impenetrable with biology jargon, so progress is slow
What I'm thinking is that phagocytosis involves one bot swallowing another whole, but that bot doesn't necessarily have to be dead so it can fight back. Once in the gut the feeding bot begins releasing chemicals which start dissolving slime and shell, and then eventually begin digesting fat and muscle and all that. The bot that was eaten can fight back if it's still alive, and maybe kill the bot eating it and escape. The feeding bot latches on to its prey with something like a rigid tie, and slowly draws it into its mouth, which ends up moving both bots together if they're about the same mass (think a frog which eats by sticking its tongue onto another frog and pulling really hard).
Shots probably exist as a soley offensive weapon, designed to kill another bot before ingesting it. And ties allow very small bots to attach themselves to a much larger bot and siphon off nrg, sort of like a mosquito. The much larger bot would have a hard time getting rid of the smaller bot.
But as I examine this link (http://www.nova.edu/ocean/messing/protozoaC.html), I'm hoping maybe some new and interesting feeding methods might come to mind.
And then about fat, chloro and muscle: will there be a limit on these total, or individual limits? If there will be a total limit, what happens when it's been reached, and the bot tries to make muscle, for example? Will nothing be made, or will muscle be made and fat/chloro removed?
I'm thinking no limits at all. A bot gets a "normalized" quantity as a readback from its sysvars. Like *.chloro might return 899, meaning that a bot is 89.9% made of chloro. The bot itself might be tiny or really, really massive.
-
And then about fat, chloro and muscle: will there be a limit on these total, or individual limits? If there will be a total limit, what happens when it's been reached, and the bot tries to make muscle, for example? Will nothing be made, or will muscle be made and fat/chloro removed?
I'm thinking no limits at all. A bot gets a "normalized" quantity as a readback from its sysvars. Like *.chloro might return 899, meaning that a bot is 89.9% made of chloro. The bot itself might be tiny or really, really massive.
Right... So if the bot is, say, 70% chloro, 20% muscle and 10% fat, and size 100, and tries to make 10 more fat, it would after that be about 63,6% chloro, 18,2% muscle and 18,2% fat, and size 110? (If chloro, muscle and fat will be the final substances)
-
That sounds reasonable; I think that the rate at which a cell can change its substance should slowly decrease over time.
About the shell, at the moment it looks like there is three ways of doing it: Make the shell out of nothing (no change), digest minerals that are then used to build a shell, or make minerals structures that can be loosened from or fastened to other minerals to manipulate the shape of the environment into a shell, which can then be used as a sort of communal shell.
More as an idea to throw back in, I still think that a cell wall for retaining energy and keeping the bot intact is worth thinking about. Could make for some pressure interactions as well, as currently 'chewing' is impossible to simulate and invariably results in the prey shooting right back out.
-
That sounds reasonable; I think that the rate at which a cell can change its substance should slowly decrease over time.
About the shell, at the moment it looks like there is three ways of doing it: Make the shell out of nothing (no change), digest minerals that are then used to build a shell, or make minerals structures that can be loosened from or fastened to other minerals to manipulate the shape of the environment into a shell, which can then be used as a sort of communal shell.
More as an idea to throw back in, I still think that a cell wall for retaining energy and keeping the bot intact is worth thinking about. Could make for some pressure interactions as well, as currently 'chewing' is impossible to simulate and invariably results in the prey shooting right back out.
You have a good point; the processing power this might require, however, at first frightens me. There could be a few ways to do it: 1) little particles in a bot bounce around, and if they go fast enough, they fly through the cell wall. 2) standard pressure calculations to determine if a bot is about to "Explode"
These two possibilities have complimentary, almost opposite downsides.
1) this is memory intensive, and possibly also slightly processing intensive.
2) this is process intensive, and depending on if shape is accounted for, could be slightly memory intensive.
Now, I know a few complicated algorithms might be able to remedy this to a degree, but in the end, it would have a huge effect on the speed of the simulation.
To put it into perspective, I believe the goal is to have it run reasonably fast at about 1,000 bots, which in DB2 is just a pipe dream. Every cycle, assuming 1,000 bots, the system would have to execute 1,000 DNA's, update 1,000 bots, process the velocity, acceleration, inertia, momentum, rotation, collisions, and torque of at LEAST 1,000 objects; all that, and to make the speed reasonable, do it about 15-30 times every SECOND.
As you can see, every little thing you add in has an effect on how much the computer has to do, so adding even just 10 particles of energy per bot would greatly influence the speed. Looking at it this way, it is possible to use technique 2, but the math is tricky, and if we run into any trig we might as well just forget about it, because computers and trig are not good buddies
-
There is something in real life called an extracellular matrix (http://en.wikipedia.org/wiki/Extracellular_matrix) which is basically anything abiotic (ie: not alive) that a multicellular critter uses to form its structure. I just have no idea how to introduce something like this here, because it ultimately needs to be controlled from the DNA.
-
Seems pretty simple to me, actually, I doubt we even have to code it in.
As long as cells can only survive while they are not being squeezed too much, it is likely that the bots will evolve to use sand or something similar as an outer layer as well as a connection to other bots.
In that way, as long as the bots can to some degree manipulate the objects it is connected to, it can use the sand or whatever it may be using at the time as that extracellular matrix layer.
We may want to allow for some ties though, so that there is an exclusively information based connection allowed between bots, as using the sand in this way would block the cells from touching.
Depending on the physics we implement, this sand-wall layer could also act as a collision buffer, effectively dispersing the forces from a collision.
-
If we're going to run sims on PC's then I don't think processing power is something we should be spending lightly.
DB isn't the real world, and IMO it doesn't have to be in order to simulate evolution. Obviously the closer it is to reality the more interesting the results would be to observe, but I still think the more processing power is required the more we should be looking for a cheaper way to fake it.
Having grains of sand sounds like a bad idea to me, I can't immagine how this would run properly on a normal PC, unless you want to have very few grains which would defeat the purpose.
You COULD allow objects to be made of a certain mineral, so you can place a sand wall that bots can extract materials from... stuff like that.
Or you could maybe make sand grains with no colision and very simple physics if you realy want the actual grains to be there I guess.
But my point is just that for evo sims it takes a loooong time for anything new to sart happening, and it'll take even longer if we add too much new stuff.
Theres other simpler areas I'd find more interesting to change, like the jerky tie physics and generaly tie comunication when using several ties. Or the triggers for shooting and tie feeding that require you to hit -3 .shoot store to fire venom for instance, on top of needing to actualy produce the venom and set .vloc to something usefull... I haven't heard of any zbots ever using venom and I have to admit I doubt they will get there till we have some sick future computers running DB at 10K cycles a sec.
Just saying we all have a very short limited lifespan, and the way the current DNA works I'm not even sure most of us will live to see half the sysvars being put to propper use.
So it might be a good idea to make it easyer for the DNA to evolve more gradualy to see some faster progress in evo sims.
One thing that could help when shooting and tie feeding is allowing a certain negative range to trigger a reaction rather than an exact value, but I think the whole way the DNA works and evolves could probably be set up in ways that favor random mutations far more than the current language (Although the ways I can immagine would make the DNA impossible to read, but you could probably parse it into something more readable somehow).
I don't know how real DNA works though, so I don't know if the current way is more realistic, but DB is a fake universe after all, so I don't think it would be cheating too much.
Also from the few things I think I recall about real DNA it would seem to me like what I have in mind is actualy more realistic... but I may be wrong, will go read about it on wiki...
-
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.
-
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.
-
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.
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.
-
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)
-
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.)
-
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?
-
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.
-
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.
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!!!)
-
Sorry about the double post, but an edit on the last one would have been unnoticeable.
There is a link HERE (http://www.darwinbots.com/WikiManual/index.php?title=Darwinbots_3) 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.
-
Oh, and DNA will be much more robust this time around.
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.
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.
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.
-
I don't quite get what you mean with the whole Mod:ing of base-pairs thing.
Right now, a point mutation call involves specifying the probability of each type of base-pair being the result. For instance, one might choose that for a particular species, a point-mutation returns 25% numbers, 50% operators, 10% commands, and 15% (insert the other thing I can't remember here).
In this way, you could specify a larger % of numbers to be returned, and you would increase the proportion of numbers in the mutation results.
As far as shapes and stuff goes, don't expect to see chunks appearing anytime soon, but reforming will definitely be a factor when we get there.
-
I don't quite get what you mean with the whole Mod:ing of base-pairs thing.
Right now, a point mutation call involves specifying the probability of each type of base-pair being the result. For instance, one might choose that for a particular species, a point-mutation returns 25% numbers, 50% operators, 10% commands, and 15% (insert the other thing I can't remember here).
In this way, you could specify a larger % of numbers to be returned, and you would increase the proportion of numbers in the mutation results.
Well, that's not what I meant
Another example: I created a tester bot whose DNA was a single pb, the number "345". I then set point mutation frequency to 1 and type-value slider to "100% type", put one bot to the simulation and watched. The "345" mutated to "~", then to "cond", then to "~" again. But when it got back to a number, it changed to 1. No value mutations occurred at any point.
What I think happened was that the bp was first of type "number" and value "345". When it mutated to "~", it was changed to type "bit command" and value "345 % X", where X is the amount of different bitwise commands in the program, because there is no bitwise command linked with the value 345. I can't read VB, so I have no idea how all this is actually implemented, but it seems to work this way.
Conclusion: numbers greater than about 50 are quite rare to occur in evolved DNA, because type changes will likely reduce them again.
-
The DNA's underlying framework has changed. In DB2, each element was a pair of numbers representing the type and the value. Which lead to small numbers like you pointed out. In DB3, the representation is fundamentally different. A store command is just a store command. There's no underlying numerical representation. Which is actually a good thing, because it means when changing a store to a number, we just choose a random number. Big numbers are as likely as small numbers.
Also, I do plan on trying to figure out how to have broken shape pieces glue back together. Probably on contact. So that shapes tend to be large instead of numerous and small.
-
btw: How do you update the "https://svn2.hosted-projects.com/Numsgil/Darwinbots3/" Because I see no Tags or Branches, do you commit all the changes directly to the trunk?
-
We update directly to Trunk atm, but there's a Branches and Tags folder. I played with branching a few weeks ago to get the hang of it actually.
-
Branching a project this size can be a real pain if you ever plan to merge again.
I would definately recommend committing to trunk and just run a lot thorough tests before commiting. Unless it's for a mod you want to keep seperate.
-
Yeah, merging doesn't seem to be SVN's strongpoint. We used perforce at work, and that was about the only thing I liked about it. It could merge pretty intelligently.
-
IMO, any sort of mod should be able to be incorporated as an option. The idea behind DB3's coding design is to allow for interchangeable modules to be used. What this means is that you could choose, for example, from two different physics engines, or perhaps add support for neural-network bots by simply adding in the new module that provides the support. Another case is the use of different graphics implementations.
Actually, this is one of the primary features of the DB3 code.
Also, here is a quick screen-capture showing the first tab for the settings window, as well as all the pop-ups you can open from it (except for file selection windows):
[attachment=1183:Settings...een_cap1.bmp]
-
I'll be happy as long as it's object oriented.
Made a neural network mod for the current source (Or I think it was 2.43.h or something) and it was a real pain just finding my may through the source.
To make a long story short the current source is a spagetti monster and it took me a lot longer than expected to do the things I wanted, had to make changes in all sorts of places.
So the more generic DB3 is the happier I'll be
For instance it would be very nice to have a class for serializing a deserializing, and it would generaly be nice to be able to just inherit a class and overload whatever you need to make your mod.
A mod should never (Or atleast very rarely) need to change the base classes.
This way mods could also easily be developed as a branch and merged with trunk when ready (Provided the trunk hasn't changed too much). And if theres a common interface for adding a mod then they could just be enabled from the gui instead of having to build a new drop.
And as DB3 grows it would also be very nice if there where some guidelines for development, atleast a bare minimum code standard and some good tips on making propper OO code. And code reviews would be great if it's actualy possible to uphold, since theres a lot of less experienced programmers who may be checking in code that will cause a lot of trouble in the long run. If the code standard isn't too strict then a code review shouldn't take long, just enough to make sure the code or it's general structure doesn't cause problems in the long run.
The thing is, you can't just make the whole source generic enough to support any new features that may come that would take too long and in the end it would just end up being harder to read the source and harder to tell what it's real purpose it So the structure needs to be expanded as the source grows, and some people may not know exactly how to do this. So if it's possible to uphold a quick code review for new source it would probably save us a lot of trouble in the long run. Possibly ask people to submit a simple class diagram or update the apropriate one, with a brief explanation of what has changed, this way it would be easier to tell right away if it would be enough to just give this new code a quick glance of if you need to read it more thoroughly.
On a not so unrelated note, does anyone know if theres a free version of FogBugs or maybe another similar program we could use for free ? Would make some of the things I'm suggesting a lot easier to manage.
-
I'll be happy as long as it's object oriented.
Made a neural network mod for the current source (Or I think it was 2.43.h or something) and it was a real pain just finding my may through the source.
To make a long story short the current source is a spagetti monster and it took me a lot longer than expected to do the things I wanted, had to make changes in all sorts of places.
So the more generic DB3 is the happier I'll be
For instance it would be very nice to have a class for serializing a deserializing, and it would generaly be nice to be able to just inherit a class and overload whatever you need to make your mod.
A mod should never (Or atleast very rarely) need to change the base classes.
This way mods could also easily be developed as a branch and merged with trunk when ready (Provided the trunk hasn't changed too much). And if theres a common interface for adding a mod then they could just be enabled from the gui instead of having to build a new drop.
And as DB3 grows it would also be very nice if there where some guidelines for development, atleast a bare minimum code standard and some good tips on making propper OO code. And code reviews would be great if it's actualy possible to uphold, since theres a lot of less experienced programmers who may be checking in code that will cause a lot of trouble in the long run. If the code standard isn't too strict then a code review shouldn't take long, just enough to make sure the code or it's general structure doesn't cause problems in the long run.
The thing is, you can't just make the whole source generic enough to support any new features that may come that would take too long and in the end it would just end up being harder to read the source and harder to tell what it's real purpose it So the structure needs to be expanded as the source grows, and some people may not know exactly how to do this. So if it's possible to uphold a quick code review for new source it would probably save us a lot of trouble in the long run. Possibly ask people to submit a simple class diagram or update the apropriate one, with a brief explanation of what has changed, this way it would be easier to tell right away if it would be enough to just give this new code a quick glance of if you need to read it more thoroughly.
On a not so unrelated note, does anyone know if theres a free version of FogBugs or maybe another similar program we could use for free ? Would make some of the things I'm suggesting a lot easier to manage.
First and foremost, what in the world is fogbugs?
Second, yeah, once I know what it is, I say there is a 90% chance I can get my hands on it (or something like it).
Third, you should download the source and take a look yourself. Almost all these suggestions are already (more or less) there. We also use (although I need to start catching up with this, since I have slacked off a little) Unit Testing, to ensure that all classes do what they should, how they should, including throwing exceptions and the like. We also want to use a code profiler, but can't find one for free (well, actually, I think even something under $100 would be acceptable at this point.)
Honestly, if anyone has been making poorly coded classes, I am probably the culprit I am still learning the ins and outs of C#. On the other hand, I am also probably the most capable of identifying and correcting errors, so I redeem myself quite quickly (and I, unlike many programmers, have no problems with people rewriting my code in better, or clearer ways.)
Actually, might you be interested in joining the project? I could use a sidekick in my quest to unravel the workings of Numsgil's mind. He leaves me hanging a lot on what needs to be done, and I don't want to make any executive decisions on my own (he was the originator of this whole project after all). Even if you don't want to do the coding, you at least seem to be thinking along the same lines, so it would be helpful to have you available for consulting (not that big questions won't end up here anyway.)
Getting myself back on track; we did indeed attempt to make all of the classes that one might override easy to extend. For instance, the robot class contains two objects of importance, a robot body, and a brain. One could extend the robot class to have multiple bodies or brains, or could extend the body or brain class to change the shape of the robot, or the behavior.
Also, there is an IShape interface that can be used to describe any shape in the simulation.
One final thing: when writing the code for the mask over a robots memory, a clever thing occurred to me. I realized that in later versions it might be useful if, for instance, on bot in a multibot could apply its mask over the memory of one of its connected bots, effectively allowing the connected bot to act using data from the bot whose mask is being applied. Sort of a "If I were you, this is what I would do" situation, but in this case "I think I am you, so now I will do that which I would do if I were you".
-
Ehm, my bad, it's spelled FogBugz :
http://www.fogcreek.com/FogBUGZ/ (http://www.fogcreek.com/FogBUGZ/)
It's for managing tasks and documentation in a project. It works sort of like a wiki, you form a case for something that needs to be done then assign it as a task to one or more people. Then you'd usualy assign the task of code review to someone else. Point is links are formed to create a wiki like network in between related areas, some are made automaticaly but you'll also want to add your own, both for resources used during development and documentation and such. Kinda hard to explain, but I think theres a good introduction video on the site to get an idea of how it works.
Haven't tried a code profiler before, but I'm pretty sure it can't replace code reviews, it's better than nothing ofcourse, but if poeple are willing to spend the extra time then code reviews are probably a lot safer.
And if we have strict tests it'll be easier to review the code fast and there will probably be far less that needs to be corrected. And when doing a code review and you find yourself having to fix a lot, then don't think of it as extra work, think of it as saving a lot of time by fixing this before it becomes a problem. Its also a great way to learn, even for those who find themselves teaching everyone else (Since teaching is the best way to learn). And who knows it could help draw more developers if people feel they're making real progress as a programmer.
And I think I should have the time to look at the project, I can start by going through the wiki to see how far you guy's are along. That and actualy get the DB3 source and Visual studio
But got some things I have to see to first...
And I'm not sure it's a great idea to allow a bot to just override all the memmory of another bot, that would be a realy powerfull weapon. Maybe if the tie has to stiffen first it wouldn't be a big issue...
-
To make a long story short the current source is a spagetti monster and it took me a lot longer than expected to do the things I wanted, had to make changes in all sorts of places.
That's flying spaghetti monster
And as DB3 grows it would also be very nice if there where some guidelines for development, atleast a bare minimum code standard and some good tips on making propper OO code. And code reviews would be great if it's actualy possible to uphold, since theres a lot of less experienced programmers who may be checking in code that will cause a lot of trouble in the long run.
We have a coding standard (meaning mostly a naming standard) that we've adopted from here (http://weblogs.asp.net/lhunt/attachment/591275.ashx).
I don't have any formal code reviews or proper OO guidelines. Mostly I'm hoping we all just keep an eye on each other and red flag when things look fishy.
On a not so unrelated note, does anyone know if theres a free version of FogBugs or maybe another similar program we could use for free ? Would make some of the things I'm suggesting a lot easier to manage.
There's a Trac that comes with my SVN account we can use. I just have to figure out the permissions so that it's publicly visible.
-
And I think I should have the time to look at the project, I can start by going through the wiki to see how far you guy's are along. That and actualy get the DB3 source and Visual studio
But got some things I have to see to first...
Let me be blunt. We are very close to something that can actually run.
Let me be blunt again. The wiki is nowhere near up to date. In fact, the only updates (for the progress of the DB3 project) have been to the guidelines for the M1 version, and that was only out of necessity when having to rethink the bot design.
Like I said, we could always use a hand. Just because it is almost usable doesn't mean it is almost complete. Actually, this will probably be worked on for many years to come (hopefully it will be workable for much longer than DB2).
And I'm not sure it's a great idea to allow a bot to just override all the memmory of another bot, that would be a realy powerfull weapon. Maybe if the tie has to stiffen first it wouldn't be a big issue...
Of course, only bots in the same organism would be allowed this ability (and maybe virus?), as it is definitely powerful. I was also thinking it could be invoked by the bot that will be masked by targeting in some way the bot whose mask will be used.
Also, as far as a profiler goes, what it would do is tell us how many times each line of code was executed, and how long the execution took. This would be used mainly as a way to find possible speed-bumps in the DB3 program highway (well, metaphorically). We use unit testing to find most of the errors, and when errors are found, we figure out the solution on our own. No program currently in existence can do much in terms of fixing another programs source code .
As for the FogBugz program, we could easily build that into the internet mode of the DB3 program. All it is is a glorified, automated message delivery and sorting system. I could write the whole thing over in Java in about a week if I wanted to (but trust me, I don't want to).
-
I had a look at the repository, and I'm pleased to see so much progress has been done. If there's anything that you want implemented in particular, I'll be keen to get back into DB3.
-
Sure, that would be great. Most of what's left is really technical, though, so it might be a hard nut to crack. I'll try my best to help you figure out any of these tasks. Here's some thoughts:
1. Set up the graphics code to draw ovoids (distorted circles). I'd like to do it through a shader so the edges are smooth and it doesn't use any more vertices than a square. A shader is basically a special computer language to program the graphics card with. You could copy the shader code I have for drawing quads (it's pretty simple), and modify it to use the texture coordinates to draw a circle in texture space. Or even combine squares and circles in the same shader.
2. There's a demo app that draws shapes so I can test the graphics capabilities. There's a menu on the side of the window which isn't really set up, but the idea was that it would let you add shapes to be drawn at run time. The work would be playing with the code to allow "picking" (detecting that the user clicked on an object), picking and then dragging an existing object, adding new objects at the mouse cursor, resizing objects by dragging vertices, and setting up the interface to let you add a shape into the draw field.
3. Set up the actual .exe. here's (https://svn2.hosted-projects.com/Numsgil/Darwinbots3/Trunk/Documentation/ModuleDiagram.png) a crude UML of how the modules might fit together (I think the arrows are backwards maybe). Basically all the modules get packaged together into a single core.dll file, with version numbers attached to the modules. Like Core1.0.dll might be the code for Darwinbots3 1.0. The .exe is designed to do absolutely nothing except search for core.dll files, and dynamically load them and pass command line arguments into them. The idea being that a new version of Darwinbots just has to add a new core.dll file and not overwrite any existing files. The Darwinbots3.exe will determine which core.dll is the latest version and load it. And with any luck we should be able to use the same core dlls with the XBox and just not call the unsupported features.
4. Implement a GDI graphics module. Right now the graphics system is set up so it can dynamically choose the graphics API to use. You'd just need to write an implementation for GDI (the graphics API used to paint windows and stuff in C#), and maybe modify some of the Graphics.Core code as needed.
5. We still need to figure out code coverage. I've been putting it off. Basically all the options either suck or are expensive, and one of my goals for Darwinbots is to make sure all the needed tools are free. You'd probably have to find one of the sucky free ones (there was a free, early version of NCover on sourceforge), and hack on it until it worked right.
6. You could work on the physics. But it's really quite math intensive. The good news is that there's a free book online (http://www.nrbook.com/a/bookcpdf.php) that explains most of the math I'm using (I could at least point you to the right chapters). The bad news is that the book assumes a certain level of math that most people don't have (need to be comfortable with calculus and linear algebra (ie: matrices)).
7. You could try setting up an XBox exe if you have an XBox. You'll also need a creators club membership, which can be expensive (like $50 for a few months, or $100 for a year). Though microsoft also tends to give out free membership for various competitions and the like (check out Dreamspark (https://www.dreamspark.com/)). Mostly just setting up the project.
8. Or you can look at milestone 1 (http://www.darwinbots.com/WikiManual/index.php?title=Darwinbots3/Milestone_1) and see if anything there looks interesting. Quite a bit of it is actually done already, though.
-
Ah the physics...
Well, I suppose I should commit what I have of it so others can build off of that.
I'm positive it still compiles because I hate not being able to compile after finishing a section of code, so I will send what I have done.
-
I would probably be best at getting the physics engine set up. I've been writing one myself, and although it's still primitive compared to the stuff you posted on the wiki, It'll give me a background on how the functions are derived.
To be honest, C# is new territory for me. I understand how the syntax works, but calling up specific functions like UI and stuff like that is a bit of a mystery for me. I started an unrelated project to familiarize myself as I go along...
-
I'm trying to complete the collision physics code atm, but a few questions popped up:
1-Is the collision normal a positioned vector perpendicular to the collision interface, or is it measured from the center to collision interface?
2-I'm guessing j0 is equal but opposite for both mass systems. Anything wrong with this assumption?
3-Is there any auto-complete function in C# Visual Studio?
-
1. Suppose you have a collision between a vertex and an edge. The collision normal is usually perpendicular to the edge. In more convoluted cases it's just a best guess. For the collision response code, assume that you are given the normal as part of the input into the function.
2. This is technically true. However to allow for the system of equations to be solved easily you assume j0 is equal to the impulse along n, and then just remember to negate it when you apply it to the second body.
3. You mean like intellisense? There should be.
So I'm guessing you found this page (http://www.darwinbots.com/WikiManual/index.php?title=Darwinbots3/Physics/Response), right? The case of one-on-one collision should be not too hard. Make sure to add a bunch of tests for it for weird cases (0 or infinite mass, etc.).
Multiple collisions is more speculative. This is really something I've figured out on my own just from first principles, so I'm not totally sure what I'm doing
-
I see how you got that from FP, but I think it's just a case of each object resolving each of its collisions as though they were different single collisions. Remember that the other masses can be reduced to a single mass as they are all external of the concerned mass.
Okay, so j0 represents the scalar exertion upon an object, and n the direction of change, so therefore should have a magnitude of 1. mass/moment of inertia convert the 'force' into an 'instantaneous' acceleration/torque. j0 is acting perpendicular to the center about a point, eg. a tangent.
Okay, that makes sense. But is the code for calculating the normal/tangent/impulse already in place?
EDIT => Are the Azimuth files corrupt? I've tried to update several times at revision 304, but TortoiseSVN still marks it as a deprecated version.
-
I see how you got that from FP, but I think it's just a case of each object resolving each of its collisions as though they were different single collisions. Remember that the other masses can be reduced to a single mass as they are all external of the concerned mass.
You mean like if 10 objects are colliding at the same time, just treat all the collisions pairwise? This won't work, because as you resolve one collision it can invalidate the solution you found for other collisions. You can just iterate over all the collisions pairwise a few times (this is what most commercial engines do), but if you iterate as often as you need to to resolve all the collisions to arbitrary precision it's an [img class=\"tex\" src=\"http://www.forkosh.dreamhost.com/mathtex.cgi?O(n^3)\" alt=\"LaTeX: O(n^3)\" /] process. Essentially it's Gaussian eleminiation (or so I was told once upon a time). If you set up the system of equations from the start, it's still [img class=\"tex\" src=\"http://www.forkosh.dreamhost.com/mathtex.cgi?O(n^3)\" alt=\"LaTeX: O(n^3)\" /], but you can do it much faster using more advanced techniques (LU decomposition to solve the system). Should be something like 3 times faster.
Typical matrices will also be rather sparse as they grow, so I'm researching sparse methods for solving the matrix at the moment. A good method might be more along the lines of [img class=\"tex\" src=\"http://www.forkosh.dreamhost.com/mathtex.cgi?O(n)\" alt=\"LaTeX: O(n)\" /] since there's probably a maximum number of collisions possible per body.
If you read Chapter 2 (http://www.nrbook.com/a/bookcpdf.php), most of what I just said should make sense.
Okay, so j0 represents the scalar exertion upon an object, and n the direction of change, so therefore should have a magnitude of 1. mass/moment of inertia convert the 'force' into an 'instantaneous' acceleration/torque. j0 is acting perpendicular to the center about a point, eg. a tangent.
Okay, that makes sense. But is the code for calculating the normal/tangent/impulse already in place?
[img class=\"tex\" src=\"http://www.forkosh.dreamhost.com/mathtex.cgi?j_0 \vec{n}\" alt=\"LaTeX: j_0 \vec{n}\" /] is the impulse ([img class=\"tex\" src=\"http://www.forkosh.dreamhost.com/mathtex.cgi?j\" alt=\"LaTeX: j\" /] is the traditional symbol for impulse. The 0 is so it makes sense later on when you handle multiple simoltaneous collisions and have multiple impulse terms). An impulse is essentially a crazy large force that acts in a crazy small amount of time. Remember that force needs time over which to act in order to change the position or velocity of an object, so an impulse just does it instantaneously.
As far as what's done, Prsn was working on it. I'm not sure how far he got. Check the changelog from his most recent commit and see what's there. There's no code yet for calculating the collision normal (that's collision detection work, and there's been no real work on that yet).
Basically what needs to happen is that there's an island class which represents all the bodies that are directly or indirectly in contact. You'd iteratively build up the island by adding body pairs (and their collision point and collision normal). And then do something like island.solve() and have it figure out all the impulses necessary. Prsn started on the island code, though I haven't looked at it yet so I don't know how far he got.
EDIT => Are the Azimuth files corrupt? I've tried to update several times at revision 304, but TortoiseSVN still marks it as a deprecated version.
Should all work. What do you mean by deprecated?
-
Should all work. What do you mean by deprecated?
Not the current version.
Okay, I see your point. But that means an extra jn calculation has to be made for each object. Couldn't we reduce it to one multi-collision code, even for single collisions, or would that also be a drag on efficiency?
-
Should all work. What do you mean by deprecated?
Not the current version.
What's not the current version? Your working copy?
Okay, I see your point. But that means an extra jn calculation has to be made for each object. Couldn't we reduce it to one multi-collision code, even for single collisions, or would that also be a drag on efficiency?
No idea what you mean.
-
No idea what you mean.
I get that a lot.
What I mean is that instead of treating a one-on-one collision as a 'special case', we handle every collision the same method, regardless of the number of masses colliding.
-
We don't need a special case for one-on-one collisions in the actual code (though it wouldn't hurt). Mostly I just listed it on the math page so the math behind multiple collisions makes sense.
So feel entirely free to skip writing out a function to solve one-on-one collisions. The important part is that you understand the math behind it. It's the algorithm for multiple collisions that's the work horse.
-
Well, maybe I should just write the code first to actually get something running...
-
Okay, while I'm trying to fix TortoiseSVN, does anyone know if velocity and angular velocity have already been implemented in the Body class? I could write the movement system, it's extremely trivial, but I want to make sure it's not handled somewhere else.
-
Look in PointMass.cs.
Basically the Body class is a pretty thin wrapper taht combines the ideas of collision shapes (the shape list), and a point mass (which it inherits from). Where a point mass is something with heft and inertia but without any physical bounds.
-
If you have source code type questions, log on to chat.darwinbots.com. It's an http chat room I set up for this sort of thing. I'm usually logged in, and I can give you real time feedback on various source-y type things.
-
IMO, it looks like you're going for an unnecessary level of realism. I'd prefer having an unrealistic method of dealing with collisions and get a slightly faster simulation. For example, the slideshow discussed dealing with negative impulses. I wouldn't mind having negative impulses in a simulation if it makes it faster.
-
Actually I think the level of realism will make it faster. Not at first, because I'm cutting corners in places. But when all is said and done there's a lot to be said for fixing things when they're easy to fix. But as far as I know this is all pretty novel. No physics engines work like this. So I can't really make any promises.
-
I definately agree I'll take processing speed over realisme, to a certain point.
And multithreading will also help a lot, at least for my part.
But I was also thinking it would be nice if there was an easier way to set up connected sims with different settings.
I think larger evolutionary steps could sometimes be produced by jumping in and out of different environments.
I know it should be possible to set up with teleporters, but I failed miserably at that.
-
My hope is that we can at least partially leverage something like XBOX live for organism sharing. Or if not that, at least use something slightly more reliable than the current FTP. That should go a long way towards making the multiverse of connected sims large enough to really have an ecosystem going.
-
I'm fairly sure we wouldn't be able to use Live to share organisms, unless you somehow work out a deal with Microsoft It shouldn't be too hard to create a TCP server to handle everything with .net however, so that seems like the best option to me.
-
Hello All
sorry if this questoin is a bit out of turn but im doing my PHD which involves alot of networking, Im not too sure what your currently programming in but if its C, C# or C++ or you can make a wrapper for it then you could possibly use YARP (yet anouther robot platform), its not really ment for the internet but it might work (80% sure) with minimal effort as long as theres one static server of unchanging IP, and would allow you to send robots from one sim to anouther in a string.
I dont know if this is any use to you.
NoZ
-
I'm fairly sure we wouldn't be able to use Live to share organisms, unless you somehow work out a deal with Microsoft It shouldn't be too hard to create a TCP server to handle everything with .net however, so that seems like the best option to me.
From what I understand, community games use live to share high score tables. My thinking is that either you use live to communicate between your XBox and PC, and then use something else on the wide frontier of the internet, or live will work for all of it. I still need to experiment here so I'm really just blowing smoke atm
Hello All
sorry if this questoin is a bit out of turn but im doing my PHD which involves alot of networking, Im not too sure what your currently programming in but if its C, C# or C++ or you can make a wrapper for it then you could possibly use YARP (yet anouther robot platform), its not really ment for the internet but it might work (80% sure) with minimal effort as long as theres one static server of unchanging IP, and would allow you to send robots from one sim to anouther in a string.
I dont know if this is any use to you.
NoZ
My ultimate goal is to let sims share bots using http get/set. That way we don't need a dedicated server or anything like that.
-
I'm fairly sure we wouldn't be able to use Live to share organisms, unless you somehow work out a deal with Microsoft It shouldn't be too hard to create a TCP server to handle everything with .net however, so that seems like the best option to me.
From what I understand, community games use live to share high score tables. My thinking is that either you use live to communicate between your XBox and PC, and then use something else on the wide frontier of the internet, or live will work for all of it. I still need to experiment here so I'm really just blowing smoke atm
I think the only way you could possibly get it to work would be to have a application on your computer running that handles all of the internet stuff, and then passes the data to the xbox -- Through SystemLink (which requires a creators club membership)
As for how the community games use LIVE for high score tables, it is a hack. It is actually a P2P system in most cases, I've also seen talk of setting up a xbox to run as a dedicated server.
-
Sorry I sort of disappeared.
Been playing some MMORPG's >.>
Oh, also had a lot of school-work.
I will try and get back into the groove with this project some time within the next week. I am very glad to hear we have more help and are still making progress.
Keep up the good work everyone!
-
I'm fairly sure we wouldn't be able to use Live to share organisms, unless you somehow work out a deal with Microsoft It shouldn't be too hard to create a TCP server to handle everything with .net however, so that seems like the best option to me.
From what I understand, community games use live to share high score tables. My thinking is that either you use live to communicate between your XBox and PC, and then use something else on the wide frontier of the internet, or live will work for all of it. I still need to experiment here so I'm really just blowing smoke atm
I think the only way you could possibly get it to work would be to have a application on your computer running that handles all of the internet stuff, and then passes the data to the xbox -- Through SystemLink (which requires a creators club membership)
Why not a P2P between your xbox and PC?
As for how the community games use LIVE for high score tables, it is a hack. It is actually a P2P system in most cases, I've also seen talk of setting up a xbox to run as a dedicated server.
Yeah, I heard that, too. But having a P2P network would actually work really well in practice for IM. Have it so that when you first get on you find maybe 3 or 4 "neighbors" you share organisms with. The end result is a vast network of indirectly connected sims. Would be pretty cool.
We'd only need a central server little or at all.
I am very glad to hear we have more help and are still making progress.
Yeah, we're making some good progress. I'm pretty close to actually having physics be runnable.
Also, good work on the island stuff. Looks good.
-
Sorry, I haven't been able to commit anything over the past while. It sounds like the physics engine is all done. If I commit my code now, am I in danger of screwing up any work on the island resolver?
-
Why not a P2P between your xbox and PC?
You can't, the System.Net namespace is one of the areas that is essentially gone from the .NET compact framework, the only things you can use out of it are the ICredentials interface and the NetworkCredentials class. No sockets, no internet access, and really no access to your pc either.
Yeah, I heard that, too. But having a P2P network would actually work really well in practice for IM. Have it so that when you first get on you find maybe 3 or 4 "neighbors" you share organisms with. The end result is a vast network of indirectly connected sims. Would be pretty cool.
We'd only need a central server little or at all.
Very true, the running of the sim its self is not the problem with the xbox, it is getting the bot files from your pc into the sim.
Also note that even if we did get it to somehow work, anyone who wanted to use it would probably have to own a creators club membership.
-
Why do people want it on the xbox?
There is a .NET framework for P2P I think http://msdn.microsoft.com/en-us/library/aa371704.aspx (http://msdn.microsoft.com/en-us/library/aa371704.aspx)
will only work on windows which is a shame but its there
NoZ
-
Sorry, I haven't been able to commit anything over the past while. It sounds like the physics engine is all done. If I commit my code now, am I in danger of screwing up any work on the island resolver?
I haven't touched anything dealing with islands specifically for that reason. Update to latest, and then commit your changes. If there's a conflict, Subversion will let you know.
Why not a P2P between your xbox and PC?
You can't, the System.Net namespace is one of the areas that is essentially gone from the .NET compact framework, the only things you can use out of it are the ICredentials interface and the NetworkCredentials class. No sockets, no internet access, and really no access to your pc either.
Right, but it has LIVE access through XNA. And you can (I think) run LIVE on a PC running an XNA game, too.
So at the very least you should be able to communicate between the XBox and PC that way. My thinking is that the XBox version is a pretty dumbed down version, and you interface with it mostly over soemthing like LIVE.
Yeah, I heard that, too. But having a P2P network would actually work really well in practice for IM. Have it so that when you first get on you find maybe 3 or 4 "neighbors" you share organisms with. The end result is a vast network of indirectly connected sims. Would be pretty cool.
We'd only need a central server little or at all.
Also note that even if we did get it to somehow work, anyone who wanted to use it would probably have to own a creators club membership.
Yeah, that's true for now. Which is why it's so nice that you can get free memberships if you know where to look
Ultimately I'm hoping to have it be a Community game. The barrier for entry is low enough I think we could make it. Then anyone with an XBox could run it.
Why do people want it on the xbox?
Mostly 'cause it's cool And the XBox 360 is sort of like a mini super computer. It has three cores running at 3.2 GHz each. And some crazy SSE (though I don't think it's accessible through XNA). That's more computing power than even most modern desktops have. If you took all my other game systems and desktops (and I have quite a few), and put them together, my XBox would beat them all out hands down.
There is a .NET framework for P2P I think http://msdn.microsoft.com/en-us/library/aa371704.aspx (http://msdn.microsoft.com/en-us/library/aa371704.aspx)
will only work on windows which is a shame but its there
Hey, that's pretty cool. Thanks for the link
-
Right, but it has LIVE access through XNA. And you can (I think) run LIVE on a PC running an XNA game, too.
So at the very least you should be able to communicate between the XBox and PC that way. My thinking is that the XBox version is a pretty dumbed down version, and you interface with it mostly over soemthing like LIVE
Sorry to keep being the downer here, but there is no crossing over with LIVE between the 360 and the pc
-
Right, but it has LIVE access through XNA. And you can (I think) run LIVE on a PC running an XNA game, too.
So at the very least you should be able to communicate between the XBox and PC that way. My thinking is that the XBox version is a pretty dumbed down version, and you interface with it mostly over soemthing like LIVE
Sorry to keep being the downer here, but there is no crossing over with LIVE between the 360 and the pc
I must be misunderstanding something then...
You can use XNA to write a game to use XBox live, right?
And there's something called Games for Windows LIVE which lets PC and XBox gamers play together. (http://www.gamesforwindows.com/en-US/Live/Pages/crossplatform.aspx)
I'm assuming here that the XNA functionality which allows you to write for XBox LIVE seamlessly integrates in to Games for Windows LIVE.
So you should be able to run a game instance on your XBox, and another instance on your PC, and have multiplayer that way. Then, I'm hoping, you can have the PC version be something like we're used to, with mouse interfaces and the whole bit. And you can use it to connect to your XBox over LIVE and send over either parameters for a new sim or bots or something like that.
Since the version on the PC has access to the whole .NET framework, PC instances can even act as an indirect bridge between the XBox instance and the internet at large.
Right?
-
I must be misunderstanding something then...
You can use XNA to write a game to use XBox live, right?
Yes you can.
And there's something called Games for Windows LIVE which lets PC and XBox gamers play together. (http://www.gamesforwindows.com/en-US/Live/Pages/crossplatform.aspx)
I'm assuming here that the XNA functionality which allows you to write for XBox LIVE seamlessly integrates in to Games for Windows LIVE.
Well, yes this is how is should be, but unfortunately no you can not create (with XNA) a game that will work on both platforms through LIVE. GFWL is very much locked down, note how many games actually have cross-platform play versus the number of games that have a xbox and pc version.
So you should be able to run a game instance on your XBox, and another instance on your PC, and have multiplayer that way. Then, I'm hoping, you can have the PC version be something like we're used to, with mouse interfaces and the whole bit. And you can use it to connect to your XBox over LIVE and send over either parameters for a new sim or bots or something like that.
Since the version on the PC has access to the whole .NET framework, PC instances can even act as an indirect bridge between the XBox instance and the internet at large.
Right?
This brings us back to my earlier comment, to do this a person will need some form of visual studio w/ xna (free), and a creators club membership (pseudo-free). With the creators club membership you can use the system link in visual studio (a connection between the xbox and pc) to "test" multiplayer and we could then pass data this way.
-
Ah, well that sucks
Found this link (http://forums.xna.com/forums/p/1594/7987.aspx#7987) saying what you are about GFWL. Sort of surprises me really. But I guess if you could release for PC, Microsoft wouldn't make any money from you using their LIVE infrastructure.
So yeah, looks like we'd need at least one person with creators club to bridge the gap between XBox and PC networks. But the XBox versions can still run zero bot sims and network with other XBox zerobot sims if nothing else...
-
Ah, well that sucks
Found this link (http://forums.xna.com/forums/p/1594/7987.aspx#7987) saying what you are about GFWL. Sort of surprises me really. But I guess if you could release for PC, Microsoft wouldn't make any money from you using their LIVE infrastructure.
So yeah, looks like we'd need at least one person with creators club to bridge the gap between XBox and PC networks. But the XBox versions can still run zero bot sims and network with other XBox zerobot sims if nothing else...
Yes it is annoying, the vibe I get from XNA (though I really like it) is that it is really just meant for the xbox and windows games are somewhat of a "oh well, you can do those too"
-
Say, has something changed in the repository? I'm still using my original username and password, but it keeps rejecting me.
-
Everything should still be set up. It might be using a different password than you think. Search through your email for one called "Your hosted-projects.com user account has been created", it should tell you the password the account was set up with.
You can change it by visiting clicky (https://www2.hosted-projects.com/CCP/changePassword). The "Account Name" is Numsgil.