Code center > Suggestions
Emergent Systems
Ulciscor:
Right I do see what you are saying. I guess this is what it comes down to.
DB is based on bot interaction and evolution is driven by arms-races between bots.
The other method is that evolution is driven by a dynamic environment which is altered by the bots in it.
OK bots may be part of the environment but the actual space has no effect in DB apart from giving spatial boundaries.
I think seeing how populations change and adapt due to fluctuations in environmental changes would be extremely interesting too.
Numsgil:
I do think that bots should be able to interact with their environment in interesting ways, but that interaction should likewise be from the perspective of the leavings of other bots, or some inorganic energy source.
Like waste being dumped into the environment should stay and not go anywhere.
Ulciscor:
Woohoo we agree on something! :P
I suppose I just want the environmental stuff there for completeness, even if it doesn't have any real meaning. Although I still think it might... :rolleyes:
Greven:
Now we are right bakc were DB is now!!! Hhhmmm
Why can everybody see problems, were I see opportunity and possiblilities! Why give up, becuase it seems to be impossible?
I dont understand.
And Ulciscor, did drop this thing (not this thread because it started so promising, but know it seems the conclusion that DB is DB ;)) about discussion and trying to wake up PY and NUM (now it is only NUM I think) from their bot sleep. Alot what PY wrote here, were precise the same ideas I had for SoL, the only difference that PY stated them clearly (they (my thoughts) have been a little vague), and put them into another context.
DB's problem lies in that for at Bot to do something, the DNA have to place a value in the memory...
DNA -> MEMORY -> PROGRAM, the problem is the middle! Because, the you need 3 instructions to state this (often more, depending on the thing you want to do).
Avida f.example, uses instructions without any paramters, that is all instructions can work for it self, and will do something even when there could be parameters (this is simplified). DB has the stack, were value are placed from the DNA. That is a solution to the problem with paramters, and any instuction in DB can work without paramters, but that is not good enough.
Okay jumping to something other, but still related (I lost my point, typical me) I think it would be good if we start to reduce the number of sysvars and basic commands (that is store,or etc.) So we get a reduce number of possiblities. THIS WILL NOT (if done correctly) make DB less complex. Actually it could increase complexticty if they are working together of some sort.
I must say I dont have the solution, this was just meant as a proposal to discuss further...
Ulciscor:
I am not giving up [Greven]! Don't you worry. I am already pursuing this idea, and hopefully it will develop into something usable in time.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version