Future features / Changes

[EricL]

Here is a brain dump of some things I may do in 2.42.7 or beyond.  Some are simple, well thought out things, others are just pie in the sky may never happen inklings.   I'll update the list over time, probalby prioritize it as some point, cross off things that get implemented or voted down, etc.

Please chime in if you have an opinion.

1) Change the Dynamic Costs population target so that it refers only to extant (alive) heterotrophs instead of all bots.  The reasons for this are several.  First, I think most people running evo sims are primarily interested in evolving heterotrophs, not autotrophs, so setting the target this way would be more intuitive.  But more important, counting corpses in the target population causes problems in that it's too easy to end up with a sim full of corpses and no extant organisms where the population is still above the target.  At the very least, I think we need to exclude corposes and walls from the target.  Autotrophs, I could go either way on.

2) Change No Shot Decay mode so that only energy shots don't decay or perhaps give this as a separate option.  The issue is that now that shotvals are MODed, an evo sim full of non decaying shots ends up being really deadly to unevolved bots because a huge percentage of the shots flying around are memory shots or -1 or -6 shots.  You end up with a sim full of shots and dead bots.

3) Allow autotrophy to be an evolved trait.  Being an autotroph is a way to make a living.  It should have advantages (free nrg) and disadvatnages and IMHO organisms should be able to evolve the trait or give it up as selection favors or disfavors it.   Perhaps there is a sysvar you have to write to to take advatange of autotrophic energy each cycle but if you do, then a bunch of other sysvars don't work.  You can't move under your own power, you can't originate shots or ties, etc.  Just the beginnings of an idea...

4) Ties to nowhere.  Think of these as quiles or spines for defense.  Would need to implement tie/bot collision detection, but one can imagine a bot growing spines to keep preditors at distance...

5) The ability to see shots and shotrefvars.  Bots can dodge dangerous shots, seek out -2 shots, smallness has it's advantages, bigness disadvantages, etc.

6) Vector sysvars or somethign like them as described here.

7) Real shapes and walls with features that use them - mountains, rivers, mazes, capture the flag leagues, rabbit warrens, ant farms, etc. and dynamic features that can change the topology over time.

Jumping.  If you need to dodge a shot, esxcape a preditor or leap over a thin wall or stream, a .jump sysvar will take you in the Z direction for some duration as a function of your mass, how much energy you use to jump and the Z axis gravity of the sim.

9) Walls and shapes with Z-Axis height.  Ramps.  Multi-level sims, accessed via jump or by climbing a ramp.   Conversly, burrowing in the field...

10) The option for Brownian motion, fluid viscosity, friction,. etc. to impact shots.

 
More to come.  Saving this for the moment...

[shvarz]

1) Change the Dynamic Costs population target so that it refers only to extant (alive) heterotrophs instead of all bots.

How about setting these separately for each species?  I agree that corpses and walls should be excluded.

3) Allow autotrophy to be an evolved trait.

The proper way is the metabolism, which Nums is working on for DB v.3 (or at least he claims he's working  jk).  Just having a command for autotrphy is too artificial and disabling certain commands is too.  If you want to go that way, think of something more general.  For example, give out energy according to bot's size and make it a very small amount for small bots, but large enough to survive for larger bots.  In a very viscous medium being an autotroph will automatically make bot very slow, because it would have to be very large.  Here is your automatic balance system.

But again, the proper way is to implement metabolism.

4) Ties to nowhere.

I like this

5) The ability to see shots and shotrefvars.

Then you have to allow bots to figure out "what" they are seeing.  Not impossible, but would require some extra variables.

7) Real shapes and walls with features that use them - mountains, rivers, mazes, capture the flag leagues, rabbit warrens, ant farms, etc. and dynamic features that can change the topology over time.

That's another feature in store for V.3 - environment grid.  If you can implement it, that would be great.  But from what Nums was telling me it is very difficult to do it in VB - much easier in C.

Jumping. If you need to dodge a shot, esxcape a preditor or leap over a thin wall or stream, a .jump sysvar will take you in the Z direction for some duration as a function of your mass, how much energy you use to jump and the Z axis gravity of the sim.

That would be pretty cool   Would they still be able to see stuff and make ties?  What happens to their shots?  Fall down too?

9) Walls and shapes with Z-Axis height. Ramps. Multi-level sims, accessed via jump or by climbing a ramp. Conversly, burrowing in the field...

Extra varaibles would be needed to allow bots gather information on their surrounding and on their position.

[Elite]

I want to see a greater expansion of the tieport concept, and easier manipulation of multiple ties at once

This is a slight variation of your idea:

Maybe you could have your vector sysvars store two values instead of one, using the number on the top of the stack as the tie port, and the number before that in the usual way so:

50 2 .tielenV store

Would make tie number 2 50 units long

Maybe you could use a 2D (2 by X) array as the sysvar, so that combinations like this are possible without overwriting the previous command:

35 1 .tieangV store
70 2 .tieangV store

Thoughts?

[Testlund]

1. This whould be a very good thing to implement. I've been wondering about that. Heterotrophs are the ones that usually die out first, because they have to work for their food.

3. How about making to kinds of energy, one with autotroph label and one with heterotroph label, and put in a sysvar that gives the bots the ability to evolve to use one or both energy types. I imagine I could start an evosim with these simple zerobots and wait to see if they will evolve to use autotroph or if they chose to be hunters, or both. That whould be more realistic.

4. I whould prefere very short ties instead so the bots form close colonies instead of looking like a spiderweb.

7. That whould be very cool!

8. Naa... It whouldn't be realistic I think. I imagine the environment as a thin liquid. Jumping whould look silly. Jumping through bodies of water?  

9. Yeah, that whould be nice. ..except for the jumping. Is there any single cellular organisms that can jump anyway?

[Numsgil]

How about setting these separately for each species?  I agree that corpses and walls should be excluded.



The proper way is the metabolism, which Nums is working on for DB v.3 (or at least he claims he's working  jk)

 Hehe.  I am now.  I was working on learning OpenGL for the last month so nothing was getting accomplished.  Finished that.
 
 

But again, the proper way is to implement metabolism.

 I agree.
 
 

That's another feature in store for V.3 - environment grid. If you can implement it, that would be great. But from what Nums was telling me it is very difficult to do it in VB - much easier in C.

 Again, yeah.  I was thinking of having a large grid of dirt, etc. that bots could dig into, or not alter in anyway (walls).  It's on the to do list anyway.
 
 Eric, if you want to, you can start helping me debug and move your new features into the C++ version.  I still have a little work to do in some areas, particularly physics, but it is mostly working.  You could start on the various large projects I haven't yet.  Read my notes and try implementing metabolism for instance, or whatever.