Code center > Suggestions

Hyperspeed Mode

<< < (13/15) > >>

Houshalter:
@jknilinux, awesome idea, i don't know how you could program it but if you did it would be awesome. You can defeat the whole speed of light thing just by having the code execute through the entire bot at once, not one cell at a time. I like the idea of bots changing their shape. You could have glider gun bots just by forming a glider shape and filling it with cells. Optimally you could have each cell in the bot have a state. Eg, wether that cell was counted as dead or alive by the simulator. Then each cell change the state of any or all of the eight squares around it each cycle. Bots would also be able to grow new cells in the same way, and any cells unconnected from the main body would die. Also any cells not connected to a group of cells of a certain size (say 100) would die, so reproduction would just be growing a body segment large enough and detaching it. They would be a pain to program manually so maybe some kind of visual programming interface where you could define what each cell should do each cycle? That would be a pain to program in and of itself but it might be worth it.

jknilinux:

--- Quote from: Houshalter ---@jknilinux, awesome idea, i don't know how you could program it but if you did it would be awesome. You can defeat the whole speed of light thing just by having the code execute through the entire bot at once, not one cell at a time. I like the idea of bots changing their shape. You could have glider gun bots just by forming a glider shape and filling it with cells. Optimally you could have each cell in the bot have a state. Eg, wether that cell was counted as dead or alive by the simulator. Then each cell change the state of any or all of the eight squares around it each cycle. Bots would also be able to grow new cells in the same way, and any cells unconnected from the main body would die. Also any cells not connected to a group of cells of a certain size (say 100) would die, so reproduction would just be growing a body segment large enough and detaching it. They would be a pain to program manually so maybe some kind of visual programming interface where you could define what each cell should do each cycle? That would be a pain to program in and of itself but it might be worth it.
--- End quote ---


Yup, that's the plan!  The bot is composed of multiple cells, but the cells don't each execute the code themselves, it's the whole organism acting as a single cell that executes the code. Each cell would be better described as a molecule, and a single-celled organism is a large collection of these molecules.

But I'm gonna try to start with a simple version first... maybe I should use DB or E 4.0 as a base, instead of making it from scratch or combining the two... what do you think nums?

Ofc, This is one difficult undertaking... and school is driving me CRAZYY!!!! But I'll try to put in as much work as I can. Expect development to be slow, but it might actually be here sooner than DB3 since CAs are far easier to program than building a physics engine from scratch.

Numsgil:

--- Quote from: jknilinux ---How many bodies does it take for a physics approach to be faster than a CA? Also, are you referring to a very complex pattern in a CS versus few bodies in the large sim? If you don't want to explain it, maybe you could give me a keyword to search on google/wiki? Thanks!

BTW did my explanation of the possible implementation make any sense?

Also, thanks for putting up with all my annoying questions, I swear I'm almost done!
--- End quote ---

I don't know that you can put hard numbers to it.  It just sort of depends on the implementations.  Professional physics engines, though, usually handle several hundred rigid bodies in real time (eg: at 60 FPS) for video games.  I'm not sure what sort of CA speeds are realistic, though the falling sand game programmed in Java (so without any real hardware optimizations) runs a world maybe 640x480 or so in more or less real time.  If you moved most of the update to a graphics card (using fragment shaders) you'd probably be looking at more like full 1080p resolution running in real time or faster (probably much faster, since fragment shaders are specifically built for CAs).

Yes, your explanation made sense.

jknilinux:
Would it be best for me to begin with DB or E 4.0 as a base, or start completely from scratch? Or, alternatively, I could use DB3 as a base.

Numsgil:
Well you could certainly steal KForth or DB DNA for the language, but for the core CA you're probably better off starting from scratch.

Navigation

[0] Message Index

[#] Next page

[*] Previous page