Code center > Darwinbots3
DB3 progress and networking
Numsgil:
Problem is that maybe 70% of the simulation cost is doing physics and vision and the like, 20% is the DNA execution, and 10% is random stuff. Even if you offloaded everything that wasn't physics to other machines, you're only maybe going to make things 40% faster. Not exactly compelling.
Even if you offloaded physics too, there's something like a 100ms latency between computers on the internet (more like 20-200ms, but on that order). Even if there was a computer that could instantly give you the answer, if you have to wait 200 ms (for the round trip) for it, best case the simulation runs at 5 cycles/sec. Again, not exactly compelling.
Finally, you have to consider the bandwidth of the server. Let's say conservatively that a simulation has about 100K of state that you have to send and receive every cycle. At a guess of $10/Mbps, that works out to a cost of about $10/month just for the bandwidth. Which isn't a lot, but that's not really scaling the way I want either.
...
On point, having different parts of the "universe" for a bot run at different time rates isn't really a problem as I see it. In fact, that's how are universe works anyway. Even ignoring things like relativity, life in the tropics is more rapid than life in the arctic. The more energy in an ecosystem the faster life there tends to evolve (Evolution and latinitudinal diversity). In a virtual landscape, faster simulations become valuable real estate, which adds texture.
I would say the biggest problem (or at least, area that could do with some thought) with the current method for IM in DB2 is the teleporters. Not to say that the way they work now is bad, but the exact mechanism of transfer has a huge effect on what sort of simulation IM would be.
For instance, it makes me think of Eve Online's wormhole space. Basically there's a part of Eve Online where different star systems are connected with non-stable wormholes (so two different systems might be connected one hour and not connected the next). The different star systems are tiered, with difficult but rewarding systems deeper in, and easier systems closer to "normal" space. Generally the wormholes are two way, so if A connects to B, B connects to A, and the entrances and exits are next to each other in either system.
A few months back they made a fairly innocuous change to how entering a system through a wormhole works which made heavier ships spawn further from the entrance back to their original system. Which made it harder for people to scout out systems for "content" (ie: other people to fight) because once a heavier ship had jumped in they were pretty much committed to fighting ("slow boating" it back to the wormhole taking so long that you'd be dead before you got there if things went sour). The small change made a fairly large change to the competitive landscape: it changed the playing field to encourage fewer, larger corporations, since they were the ones that could afford to lose expensive ships.
We might want to consider what sort of competitive landscape we want DB3 to look like, and then decide on a serving architecture that supports that goal. For instance, do we want a single dominant species across all machines? (ala Pando?). A fairly well connected universe with similar settings on machines would probably look like that. I think that's what the current DB2 model encourages. Or do we want regions of computers rules by the same species, but different species on the whole (ala Eve Online nullspace)? Sort of a chunky ownership map basically. Machines connected so that there are a few choke points here and there would encourage that, I think. Or do we want each machine to almost be an island with different species holding different machines? Maybe something like the wormhole connectivity from Eve online would work for that.
Then there's issues of what can teleport out and what can teleport in and where. If large multibot structures can be teleported in anywhere on the incoming sim, a species would be well advised to only allow its large multibots to teleport in to sims it's sure it can dominate. If there's a single place to teleport in, then species can camp the entrance to their local sim to prevent incursion. Or if only single bots can teleport, it might be more difficult for a species to invade another's machine, because they can't bring as much to the fight.
spike43884:
Weve also got to decide how we want life to progress in it. I mean your making a point a lot of these systems might run at 5 cycles/sec but if its dedicated then it can run for a long time slowly.
Remember, not everyone runs at 100 cycles/sec or wants to have a complete mad evolution in 1 and a half minutes. Plus, your point of tropics having faster evolution, they still don't have faster time. The mutation rates check how fast our evolution goes...Not the speed of time.
Second, heres a possible solution to the multibot transportation problem. Make the simulations 'overlap'
The simulations have a 1st border, then 2nd border. The 1st border gives you visual output, its the edge of the overlap really...Its a region around the edge, then just after that the 2nd border. The 2nd border is the other ends 1st border, its more transfering infomation of what is going on there to the 1st border on your simulation. Thus you might not nessisarily transport the entire multibot at once, but it'll appear seamless still.
Finally, Compatibility is still something you need to prioritise, And latency you need to think of along with floating points. Irregularities in area's are fine, except for the most extreme ones. Plus everyone wants to equally enjoy IM, and if someone has a quantum computer running in their house, and end up creating a super-monsterous-cancerous-bot it might run fine on their computer, but on a computer that struggles it would obliterate. Now, I can understand your points that your coming from, but compatibility and everyones equal enjoyment are key factors to consider, which in DB2 weren't nessisarily as prioritised and should be one of the highest things on the IM agenda.
Peter:
--- Quote from: Numsgil on April 02, 2015, 11:10:48 PM ---We might want to consider what sort of competitive landscape we want DB3 to look like, and then decide on a serving architecture that supports that goal. For instance, do we want a single dominant species across all machines? (ala Pando?). A fairly well connected universe with similar settings on machines would probably look like that. I think that's what the current DB2 model encourages. Or do we want regions of computers rules by the same species, but different species on the whole (ala Eve Online nullspace)? Sort of a chunky ownership map basically. Machines connected so that there are a few choke points here and there would encourage that, I think. Or do we want each machine to almost be an island with different species holding different machines? Maybe something like the wormhole connectivity from Eve online would work for that.
--- End quote ---
What would the wormhole connectivity do? Make it so only a minimal amount of bots arrive, weaken the bots before they can attack the native bots?
Added a image for DB2 and 'choke' points.
Assuming that DB2 random sends from any sim to any sim to any location. And choke points to sims 'nearby' at stuck locations.
Numsgil:
--- Quote from: Peter on April 03, 2015, 03:24:39 PM ---What would the wormhole connectivity do? Make it so only a minimal amount of bots arrive, weaken the bots before they can attack the native bots?
--- End quote ---
Well in Eve the wormholes collapse after a certain amount of mass goes through them. So in that scenario you'd sever the outbound connection after some total number of bots, or their total mass, exceeds some threshold. Not sure if that's a good idea or not, but something to consider and think through the implications.
spike43884:
If you used the overlaps instead of wormholes, shapes could drift as well, because its not a teleporter and more a solid connection...the shapes could move across, or if arranged solidly in a simulation form a chokepoint, which would be more realistic as in real life objects get in the way ;3
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version