Code center > Suggestions
Hyperspeed Mode
Numsgil:
--- Quote from: Houshalter ---Alright, so you can do db in CA. Would it then be possible to put a hashlife or similiar algorithm to it. The number of possible states is very large, but in db many bots from the same species have the same dna, or at least very similiar dna, so they will do the same thing in the same situation. You might have to put a special condition in for the randomness factor to.
--- End quote ---
You could probably speed up the physics quite a bit. The DNA is already amenable to caching anyway. It wouldn't be crazy faster like the hashlife is. More like, maybe, 10x faster or something along those lines. Of course, we could cache DNA right now and gain some savings (maybe make the program run 150% as fast or something along those lines. Depends how much work the physics engine is doing).
--- Quote ---
--- Quote ---What I meant was the bots would exist outside of the CA universe but could still influence or be influenced by the universe.
--- End quote ---
How could/would that be done, because thats a cool idea. I can imagine a giant conways game of life replacing "the big blue screen", and the db universe would overlap it. Bots would be able to have a third sense to see the cells and could manipulate them some how. You could do ant bots by having bots create a walls and tunnels with oscilators and stills.
--- End quote ---
That's always an option. There was a plan for something like this for a while (environment grid), but it's memory intensive, and has some other issues, too. For DB3 I'm mostly hoping to get away without any grids of any sort, and just use other techniques that are more "organic", but we'll see how it goes.
jknilinux:
--- Quote from: Numsgil ---
--- Quote from: jknilinux ---
--- Quote from: Numsgil ---Bots would occupy either a single cell or maybe a fat cross or something like that. Shots would be single cells. Not sure how ties would work. Maybe they just stick two bots' cells together. The physics would then just be updating cells based on "velocity" of each cell. Sort of like the falling sand game. The physics could be hyper accelerated on graphics cards so we could have hundreds of thousands of cells simulated in real time (not counting DNA execution speed, game logic, etc. But physics is a significant chunk of sim speed so it would be faster).
But what it gains in speed I think it loses in complexity. You can't really simulate things like accelerating (eg: falling), or spinning about your center of mass (for tied bots), and your range of velocity values is strictly limited to either moving to an adjacent cell or not.
Assuming DB3 were all set up, you could probably jury rig a version that used CA physics. The hard part would be figuring out what physical values to feed in to DNA and the game logic.
--- End quote ---
That isn't a cellular automata... I quote wikipedia:
" A new generation is created (advancing t by 1), according to some fixed rule (generally, a mathematical function) that determines the new state of each cell in terms of the current state of the cell and the states of the cells in its neighborhood."
Just because the universe is broken up into boxes doesn't make it a cellular automaton. The state of each cell depends solely on the states of the surrounding cells. See conway's game of life.
--- End quote ---
Right, a CA means you can do an update cycle using only local information about cells around the currently updating cell. What I described fits that model perfectly, so I think there's a miscommunication here. What in the system I described makes it not a CA?
--- End quote ---
Maybe it's that by CA, I mean an automata obeying very simple mathematical rules, such as those used in conway's game of life. Here, a bot, and even shots, are far too complex to be simulated by single cells. The simplest moving pattern in GoL is 5 cells in size, and a replicating pattern has not yet been discovered, probably because it is suspected to be thousands, if not millions of cells in size.
What you're describing sounds like Evolve 4.0, which does use discrete cells but is not a cellular automaton.
Basically, what I'm suggesting is not programming in any sort of physics, and letting the physics itself emerge out of the cellular automata. CGoL didn't have any physics programmed into it, flying and stationary objects emerged naturally.
Numsgil:
--- Quote from: jknilinux ---
--- Quote from: Numsgil ---
--- Quote from: jknilinux ---
--- Quote from: Numsgil ---Bots would occupy either a single cell or maybe a fat cross or something like that. Shots would be single cells. Not sure how ties would work. Maybe they just stick two bots' cells together. The physics would then just be updating cells based on "velocity" of each cell. Sort of like the falling sand game. The physics could be hyper accelerated on graphics cards so we could have hundreds of thousands of cells simulated in real time (not counting DNA execution speed, game logic, etc. But physics is a significant chunk of sim speed so it would be faster).
But what it gains in speed I think it loses in complexity. You can't really simulate things like accelerating (eg: falling), or spinning about your center of mass (for tied bots), and your range of velocity values is strictly limited to either moving to an adjacent cell or not.
Assuming DB3 were all set up, you could probably jury rig a version that used CA physics. The hard part would be figuring out what physical values to feed in to DNA and the game logic.
--- End quote ---
That isn't a cellular automata... I quote wikipedia:
" A new generation is created (advancing t by 1), according to some fixed rule (generally, a mathematical function) that determines the new state of each cell in terms of the current state of the cell and the states of the cells in its neighborhood."
Just because the universe is broken up into boxes doesn't make it a cellular automaton. The state of each cell depends solely on the states of the surrounding cells. See conway's game of life.
--- End quote ---
Right, a CA means you can do an update cycle using only local information about cells around the currently updating cell. What I described fits that model perfectly, so I think there's a miscommunication here. What in the system I described makes it not a CA?
--- End quote ---
Maybe it's that by CA, I mean an automata obeying very simple mathematical rules, such as those used in conway's game of life. Here, a bot, and even shots, are far too complex to be simulated by single cells. The simplest moving pattern in GoL is 5 cells in size, and a replicating pattern has not yet been discovered, probably because it is suspected to be thousands, if not millions of cells in size.
--- End quote ---
I think you're talking about totalistic CAs, which are a subset of CAs in general.
--- Quote ---What you're describing sounds like Evolve 4.0, which does use discrete cells but is not a cellular automaton.
--- End quote ---
Yes, Evolve is like that (so are other alife programs). No, it is a cellular automata.
--- Quote ---Basically, what I'm suggesting is not programming in any sort of physics, and letting the physics itself emerge out of the cellular automata. CGoL didn't have any physics programmed into it, flying and stationary objects emerged naturally.
--- End quote ---
The problem when you do that is that it's A) hard to determine a good rule and B ) you don't get to pick and choose behavior you want. Many totalistic CAs are quite boring, for instance, because the rules don't result in interesting behavior. If you choose one that does result in interesting behavior, you have to bend whatever game design you want to do around the limitations and features of that rule. It's much better to decide on the sort of behavior you want to see and design the rules, in a broad way, to cater to that behavior. Then you'll get other emergent behavior from the interaction of the rules that is consistent with your original feature set.
Houshalter:
Right. If you want to make a CA that fosters movement and self replication, you have to design the rules around it. Most random rules are 'dead ends', and don't do anything interesting at all.
jknilinux:
--- Quote from: Numsgil ---I think you're talking about totalistic CAs, which are a subset of CAs in general.
--- Quote ---Basically, what I'm suggesting is not programming in any sort of physics, and letting the physics itself emerge out of the cellular automata. CGoL didn't have any physics programmed into it, flying and stationary objects emerged naturally.
--- End quote ---
--- End quote ---
Sorry about that, I was referring to a totalistic CA...
--- Quote from: Numsgil ---The problem when you do that is that it's A) hard to determine a good rule and B ) you don't get to pick and choose behavior you want. Many totalistic CAs are quite boring, for instance, because the rules don't result in interesting behavior. If you choose one that does result in interesting behavior, you have to bend whatever game design you want to do around the limitations and features of that rule. It's much better to decide on the sort of behavior you want to see and design the rules, in a broad way, to cater to that behavior. Then you'll get other emergent behavior from the interaction of the rules that is consistent with your original feature set.
--- End quote ---
There are also ALOT of well-known interesting CAs, CGoL is the most well-known example. There are probably thousands of less well-known rules that also result in interesting behavior, you might need more than 2 states though. (By interesting behaviour, I'm referring to wolfram class-4 automata)
Finally, there are other CAs besides totalistic ones that the hashlife algorithm can be used on... for example, an automata where its state depends on the state of the cells around it at t-2. Or an automata where a cell's state depends on the state of the cells around it, but that are not in contact with it...
Basically, I'm saying that you can "design the rules" of the totalistic/other CA, because there are limitless options.
The main problem I'm thinking of is how to interface a bot with the CA world...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version