A radial polygon which is hooked up to some wheels... It really makes some car-like structures... But I think it would be better to have the shape of the car defined simply by points, points with springs between them. It would make it less rigid.
After having watched it for some time now, I see that some perfectly fine car-structures fail just because they are placed at an angle where the wheels aren't placed in the direction of the ground.
And even without having some pre-filtering algorithms for the potential fitness of a structure, many of these dissapointing failures could succeed by one simple change: to just add the angular force/velocity to the wheels while they are touching the ground!
There could also be other parameters that determines the angular force applied to a particular wheel, like the current velocity of the central body. Or perhaps the current angle of the body, or if another wheel is "activated" (on the ground).
And then you feed these parameters to some learning algorithm, while keeping the structure unchanged, you could evolve a perfect control-system for a car.
That's something which would interest me more... when to apply force... Intelligent control...
It would add more challenge to those who like to create competitive cars. It would no longer be about optimizing shape, but about how to device a control-system for the motion of the wheels, and find really cleaver ways to apply just the right amount of force to pull through a certain obstacle.
I promise you: this will add more complexity than you can imagine!
More later... Now I will watch it some more ^^
The "more later":
Going... no, pushing, for this control-system, I will hereby dedicate some time to outline such a system here, by adding to this first post.
The first alpha-version:
Let's base it on an if-then operation-set. And have each operator as a node in a tree, without any cycles, ie. no GOTO operations, it's simply a tree with the singular control-operation being a simple condition-check. That is: "if(wheel_velocity>10)then enter the first child of that branch and go through them".
The first layer of the tree contains blocks of mixed operations: both actions and condition-tests. As some actions may always be executed, so you keep them at the first layer.
For the alpha-version of a scripting-language, one should always aim for it to run all valid (presumably compiled) code without any possibility of it not terminating, or doing other nasty things.
So once you have this in place, or an even simpler system:
The first test will just require a condition-check for the wheel velocity, the on_ground variable (which you define before) and the angle of the body. And the actions available will simply be: to add torque to a certain wheel. And it may use a variable (a "real" number) as a parameter, and then you will need operators for operating upon the variable.
I suggest just using the basic arithmetical signs in the beginning (+,-,*,/). Where you just increment, decrement or multiply by some other varible (which is usually declared in the code). And with an assignment operator ("=").
A specific example, using a minimalistic code, and for a vehicle with two wheels:
"a" := current angle of the body in degrees (0 and 360 deg being completely to the right).
"w" := velocity of a wheel, where specific wheels are addressed by w1, w2, and w3.
"q" := the current torque, which can be manipulated just like a variable. No need for a specific action!
"g" := a boolean parameter, which is on when the wheel addressed is on the ground.
g1{x1=10;}else{x1=0;}
g2{x2=8;}else{x2=0;}
a>10 and a<350 {x1*=2; x2*=2; q1+=x1; q2+=x2;} //if the body is angled / not on flat ground.
else{q1+=x1; q2+=x2;} //if the body is on flat ground.
This simply makes the vehicle add more torque when it's on sloped terrain. But it could also take the current velocity of the vehicle as a factor instead of "2", like thus: 5/velocity (if it already has a velocity of five, don't add any more). This way it would accelerate eavenly when on flat terrain and not in the air, and then put on some fire at the slopes.
Here I simply demonstrate the usefulness of using variables, and as you should be able to see: they can replace deeper branches. And they can do so much more!
It wouldn't make sense to have an advanced control-system without also having to optimize for fuel! So that's something I think would add a lot to this app as well.
I could write this in C++ right away... And I probably will... But I can't help with the coding here, as I stubbornly stick to C++...
More later...
