DB3 Questions

[bacillus]

I'm including things like cilia and "enzyme gland" as part of the muscles.  Maybe vision organelles as well (add more, increase your sensitivity).

Does that mean different types of specialized muscle or just that muscle does all those functions?

[Houshalter]

If i may make a protest here. You are talking about cillia, organelles, and enzymes. I didn't think darwinbots was intended to simulate only single celled creatures. Single celled creatures are fascinating but higher level behaviors are more on a level we can understand and interact with. DB3 shouldn't become bogged down in the simulation of one aspect of biology. Without specialization db is pretty much universal in that you can simulate, or at least attempt to simulate, various ecosystems and parts of real biology. Im hoping db3's specialization will enhance this, not defeat it.

[bacillus]

I disagree with the new material system specialized cells are encouraged meaning that it is no longer advantageous to simply have each cell in the multibot do the same task    It forces diversity within multibots and pushes the entire program more towards developing complexity


Sorry about thelack of punctuation   My keyboard has gone haywire and it ook me two hours just to boot this morning     Going back and correcting miskates is also no longer an option thanks to this  

[Numsgil]

I'm including things like cilia and "enzyme gland" as part of the muscles.  Maybe vision organelles as well (add more, increase your sensitivity).

Does that mean different types of specialized muscle or just that muscle does all those functions?

Both.  There are specialized muscles and more general muscles.  I'll try to balance it so that under certain circumstances lots of general muscle gets built (if you're a generalist), and under other circumstances lots of specialized muscles get built (if you're a specialist).

If i may make a protest here. You are talking about cillia, organelles, and enzymes. I didn't think darwinbots was intended to simulate only single celled creatures. Single celled creatures are fascinating but higher level behaviors are more on a level we can understand and interact with. DB3 shouldn't become bogged down in the simulation of one aspect of biology. Without specialization db is pretty much universal in that you can simulate, or at least attempt to simulate, various ecosystems and parts of real biology. Im hoping db3's specialization will enhance this, not defeat it.

They're just words which describe components common (or nearly so) to all life: movement, senses, metabolism, etc.  You can easily replace organelle with organ and the analogy would still hold.  When it comes time to actually implement I'll probably pick words that are the least jargon-y, so long as they have a nice mouth-feel when you say them.

[bacillus]

Both.  There are specialized muscles and more general muscles.  I'll try to balance it so that under certain circumstances lots of general muscle gets built (if you're a generalist), and under other circumstances lots of specialized muscles get built (if you're a specialist).

That seems like the best option to go, and the best compromise for multi- and single-bots but wouldn't it be easier to have a general command make equal proportions of all the specialized muscle instead of making a specific type of muscle that adds no unique functionality?

EDIT=>Yay, punctuation's back!

[bacillus]

Maybe something else to think about-this is probably extremely obvious and no doubt already exists, but I should probably mention it anyway.
When handling trig functions, is the angle stored and sin/cos calculated when needed, or are the sin/cos values stored on angle change with the angle having no direct impact on the physics? As I said, pretty obvious, but it has saved me hours of rendering in some of my strange attractor codes.

[Numsgil]

Both.  There are specialized muscles and more general muscles.  I'll try to balance it so that under certain circumstances lots of general muscle gets built (if you're a generalist), and under other circumstances lots of specialized muscles get built (if you're a specialist).

That seems like the best option to go, and the best compromise for multi- and single-bots but wouldn't it be easier to have a general command make equal proportions of all the specialized muscle instead of making a specific type of muscle that adds no unique functionality?

EDIT=>Yay, punctuation's back!

I'll have to work it out to figure if we need a hierarchy of generalized to specialized muscles like I was thinking originally, or if we can get away with evenly building across all specialized muscles.  But it should be a mostly internal detail I think.

Maybe something else to think about-this is probably extremely obvious and no doubt already exists, but I should probably mention it anyway.
When handling trig functions, is the angle stored and sin/cos calculated when needed, or are the sin/cos values stored on angle change with the angle having no direct impact on the physics? As I said, pretty obvious, but it has saved me hours of rendering in some of my strange attractor codes.

I'll pick a range for sysvars such that it's some multiple of 360, so you can exactly represent angles in degrees (the only sensible integer representation for angles  ).  Cosine and Sine will be mapped to that same range.  So cos,sin will be functions mapping [-360,360]->[-360,360] (assuming the range for sysvars was 360).  Angle/distance seems to work better for bots than x/y vectors, so most sysvars will operate with that convention.

[bacillus]

Angle/distance seems to work better for bots than x/y vectors, so most sysvars will operate with that convention.

I don't necessarily mean x/y vectors-I'm talking about using polar vector for DNA purposes and such, and having an unseen Cartesian unit vector which only changes on the angle changing, then multiplying by the magnitude of motion. This part will interact with the physics engine, as using cos/sin functions within the physics engine is exactly the same as updating this unit vector every cycle, which is mostly unnecessary.

[Numsgil]

Oh, I see.  Yeah, the core engine isn't angle based.  It's all vectors and matrices.

[bacillus]

Quick thought - is it possible to have some substances act as gradients, so that each cell will distribute its concentration to cells bonded to it? It's simple, but could be useful in determining multibot size etc.

[Numsgil]

Possibly.  Can you think of a really compelling use case for something like that?

[bacillus]

I was just thinking of most real-life organisms using a chemical gradient to differentiate cells. I also picture a multibot plant that when attacked produces a chemical that quickly transfers through the entire organism, instead of having to send a message one tie at a time.

Another way to solve this which would also help in many more situations would be to make .readtie a command rather than a variable - this way, multiple ties can be manipulated over one cycle. For a more complex organism, chemical gradient would still be the best way to go for reflex responses that have to act rapidly.

[Houshalter]

Thats an awesome idea, making .readtie a command. That would solve alot of tie communication problems. May I suggest that it be easier to write and read on the tin/tout sysvars also. You could have a .tout command/sysvar that writes to the .toutx of the tie specified on the top of the stack. It would also be nice to have a .tin command to because you can write to the number specified on top of the stack but you can't exactly read from it, instead you have to have seprate "*" symbol for each sysvar you plan to read from. Maybe a read command would be a good idea because we already have a store command. Is this to radical for DB3?

[Numsgil]

I was planning on something like that.  I haven't worked through the details, but basically when you're connected to another bot (not using ties, but using "joints", for lack of a better word) you have access to their entire memory structure and can read and write to it.  There's some special code right now that will queue any changes a bot wants to make to another's memory so that there aren't any issues with which bot was executed first.

We might also be able to do something like "port forwarding".  Any memory values written to a specific location get broadcast to other connected bots in the same cycle.  So there wouldn't be a cycle lag for each step in a multibot.  I'd have to play with it a bit, though, to make sure impulses can't travel too quickly.  And I'm not quite sure how it would get set by bots in their DNA.  Maybe bots register codules for events like "something was written to location 459".  I'm probably doing something similar for vision anyway.

[Houshalter]

In real life cells first evolved chemical signals to communicate. Each cell waits till it recieves enough of a certain chemecal or combination of chemicals to reach a threshold then it sends out more chemicals and the proccess continues. This is like what we have now, each bot in a multibot has to communicate with the cells around it one cycle and then wait till the next cycle to communicate with more cells around it. Then evolved the ability to send electrical impulses and suddenly brains were possible. Immagine if you had to wait minutes, even seconds for information from your eyes to go through you brain and then go to your muscles. You wouldn't be able to react to anything! I like this idea of impulses because with well written code, the sky is the limit for what multibots can do.