Author Topic: Hyperspeed Mode  (Read 21940 times)

Offline Houshalter

  • Bot Destroyer
  • ***
  • Posts: 312
    • View Profile
Hyperspeed Mode
« Reply #60 on: February 17, 2010, 09:44:23 PM »
@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.

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
Hyperspeed Mode
« Reply #61 on: February 17, 2010, 11:04:57 PM »
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.


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.
« Last Edit: February 17, 2010, 11:06:38 PM by jknilinux »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Hyperspeed Mode
« Reply #62 on: February 18, 2010, 12:46:45 PM »
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!

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.

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
Hyperspeed Mode
« Reply #63 on: February 18, 2010, 01:53:30 PM »
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.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Hyperspeed Mode
« Reply #64 on: February 18, 2010, 04:07:59 PM »
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.

Offline Houshalter

  • Bot Destroyer
  • ***
  • Posts: 312
    • View Profile
Hyperspeed Mode
« Reply #65 on: February 18, 2010, 04:36:36 PM »
How is the dna going to work. Wether you use KFORTH or DB dna, or some weird combination of both, how is the bots input output going to work. If its getting input from every single one of its hundreds of cells, then it will be a pain to write code for it, and even harder for evolution to work with.

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
Hyperspeed Mode
« Reply #66 on: February 18, 2010, 04:41:22 PM »
How easy would it be to just replace the physics engine of DB3? Changed physics is the main idea behind this, I don't think it requires a completely new project...

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Hyperspeed Mode
« Reply #67 on: February 18, 2010, 06:35:27 PM »
DB3 isn't really a cohesive enough program to where you could "replace" the physics engine.  At the moment it's more a rough collection of various modules (physics, graphics, DNA).

You might be able to engineer something with DB2, but then you're dealing with VB6.  Ugh.

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
Hyperspeed Mode
« Reply #68 on: February 18, 2010, 08:34:34 PM »
I uh, *ahem... dislike... VB6.

What I meant was once everything but the physics engine is complete, it could be easy to just put in a custom one.... So I'll probably work on it once you're close to finishing DB3.


Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Hyperspeed Mode
« Reply #69 on: February 19, 2010, 12:42:17 PM »
That is part of the design for DB3: that you can hot swap in different modules.  Not sure if a CA will just be too different or not, but it might be worth a try once it's that far.

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
Hyperspeed Mode
« Reply #70 on: February 19, 2010, 01:11:57 PM »
Wonderful! I probably wouldn't have had time to work on it anyway just yet.