"Technique: Eat only certain apples" - challenge ;-)

Ruepelzahl posted this 20 May 2015

Hi everyone.

In the world "Technique: Eat only certain apples", which comes sort of builtin with the Kodu Game Lab, I changed a little of the kode, so that it is now as follows:



Kodu 1

Page 1

1 WHEN see apple green -- DO move toward

2 WHEN see apple green -- DO glow orange

3 WHEN always -- DO glow off

4 WHEN see apple green close by LOS not -- DO

5 WHEN see apple red close by -- DO move avoid

6 WHEN bump apple green -- DO eat

7 WHEN always -- DO set score red 50 points 10 points

8 WHEN always -- DO score green 1 point

9 WHEN always -- DO move wander


Cloud 1

Page 1

1 WHEN always -- DO set score red 50 points 10 points

2 WHEN always -- DO set score white 1 point

3 WHEN timer second 1 -- DO switch page 2

Page 2

1 WHEN always -- DO move on path white

2 WHEN see apple green not -- DO create Star 1 once

3 WHEN scored red 0 points -- DO end

4 WHEN timer second 1 -- DO subtract red 1 point

5 WHEN always -- DO score white 1 point

Star 1

Page 1

1 WHEN always -- DO glow blue

2 WHEN on land -- DO switch page 2

Page 2

1 WHEN always -- DO glow blue

2 WHEN always -- DO launch apple green north

3 WHEN always -- DO launch apple green south

4 WHEN always -- DO launch apple green east

5 WHEN always -- DO launch apple green west 6 WHEN always -- DO boom


I set the scores red, green and white to Quiet Labeled, and named them "Time to end" (red), "Apples" (green) and "Time elapsed" (white). The challenge is to program the red Kodu so that you get as high a white score as possible, but of course wihtout player interaction, i.e. without any kode to control it , strictly automatic.


You may introduce any object, or paths or whatever, but not the keyboard, nor a X-Box controller, nor the mouse or any other means of controlling the Kodu by player actions (like, say, have an object created at the point where the mouse is clicked, and have the Kodu move towards it).

I would really love to hear about a solution, that keeps the game going forever, but usually the red Kodu gets itself stuck on an edge within less than five minutes, the next green apple just across a gap in the terrain.

Good luck ;-)

Stephen posted this 21 May 2015

One thing you could try to keep it going would be to put a path node in teh center of the world and then program Kodu to switch pages every once in a while and move toward the path.  This would get it away from the edge.  Doing Move Wander for 10 seconds every minute should also work.


Originally we had a "blocked" sensor that detected when you were stuck trying to move somewhere.  At the time it didn't work so well so we removed it.  Maybe it's time to think about bringing it back. 


Ruepelzahl posted this 21 May 2015

Hi Stephen.


Actually, I did try that, before my post. I have the cloud circle along an eight-node path in the center, still, to make the creation of the green apples more randomly. And I had the Kodu move towards the cloud for 10 seconds, thus also following the path, whenever it hadn't eaten an apple in 40 seconds. This about tripled the time it took until the Kodu got stuck, from an average of, say, 2 minutes, to an average of about 6 minutes at best.

6 minutes is silghtly less than "virtually forever", I dare say ;-) Thus I would call it rather bold of you, to mark your answer as solution ;-)

Right now I have introduced two sticks, to which the Kodu retreats, one after 20 seconds, and the other after 10 more seconds, within which the Kodu hasn't eaten an apple. At first I tried with one stick, and got the time score higher by optimizing the placement, but that got me to only 1,572 seconds as highest score.

With two sticks now, at first try, which I did not watch all the time, it was just about 1,300 seconds, and from where the Kodu stood at the end, I could not make out why and how it might have gotten there, and have not moved away. On a second try it ran for more than 2 hours, and would have gone on, so I was tempted to call it a win, but I won't, until I find out, what went wrong on first try, and make a third test run, of course.

So, the "contest" is on, still ;-)


If you had the time and the desire to examine Bureaumania, you might see the "system" I used therein to detect if one of the non player driven Kodus gets stuck.

This takes up a felt good third of the programming, which is only necessary as a workaround against stuck Kodus, which is, to my mind, not the most encouraging thing about the Kodu Game Lab, but what the ..., there's no problems, but only challenges, right?

Meanwhile I think I understand how paths work. Basically the object, which is programmed to move along a path, does just
WHEN See PathNode DO Move Towards
WHEN Bump PathNode DO ... (forget for the moment, that this node exists)

in a loop. So the object moves to the next path node, and once it reaches there, it is set on a course to the next path node it sees. But this "See" can not be modified, sadly. I would need a "LOS" modifier to this, and in addition, if the desired node got out of LOS (because the programmed object is bumped off it scourse by other objects), the nearest LOS node would have to be set as next node.

So if there were a
DO Move Path LOS
I could use this instead of, dunno, 30?, 50?, lines of kode.

Thus, for the moment I am thinking about mimicking a path by a series of invisble Wisps, changing the color of the currently bumbed Wisp for some seconds, to get it out of the See filter, when it comes to deciding, which Wisp to move towards next. Luckyly I have already stumbled over the concept of clones ;-) Nonetheless it means a massive change in my game and will thus take me quite a while, but, hey, that's life ;-)