DaVinci Unlimited Software

Kisai is by Michael Madsen of Dynamics NAV in Denmark

Took 2nd place.

This is part of [Delphi Robot Rage]

[Download] (You will need D-Robots to run the bot.)

Michael Madsen is 21 years old and lives in Denmark. He works as a programmer for a Dynamics NAV (formerly known as Navision) consulting firm.

His bot’s named Kisai (pronounced Ki-sa-i, with short vowels – it is Japanese for “wizard”), and is conceptualized as having a female nature and being from Japan. The skin was modified to include the kanji for “battle” (on the front, mirrored due to how the skin works) and “victory” (on the back).

To add some flavor to its behavior, it will write to the log when entering the fray, and whenever it is hurt. As the bot is Japanese , these statements are of course in Japanese as well.

The statement upon entering the battle is “Iku wa yo!”. “Iku“ means “to go”, and “wa yo” are sentence-final particles used by females to express exclamation, so it is literally translated as “Go!”.

When it is hurt, “Kyaaaa!” is written. This is an onomatopoeia for a female that is screaming (out of fear, shock, whatever).

Basically, the bot just constantly looks around in a fairly wide field (up to 2 radians left or right and 0.2 radians up or down – the exact point is random). If it sees an enemy, it will try to shoot, using a rocket if the distance is more than 20 units, otherwise a rail. If it cannot shoot, and more than 25 milliseconds has passed since its last shot, it will begin to strafe for a quarter of a second. Additionally, a jump counter is set to 3, regardless of whether or not it can shoot. I’ll cover this below.

If the bot sees health, rockets or rails, it will go after those things if its health/rocket count/rail count is below a certain threshold, defined using constants.

After it has done this, the jump counter is used. He uses a variable to say how many times the bot should jump, and it will do that as quickly as possible, trying once every pass until the counter is returned to 0. This code is used to help it flee, as this should make it harder to hit the bot.

Below that, there is a huge block of code that’s been commented out. The code was written to make the bot move towards a certain spot, but I had issues making it work, so I disabled the code for my submission. The basic idea was to record the position of each recharging item, and make the bot go to the nearest one on the X/Z plane if it was low on any of those things. It includes code that would allow it to try a different path if it runs into a wall, but as I never got it working, I don’t know if it’s good enough. He choose to ignore the Y-coordinate for simplicity, since the effect of that coordinate makes less of a difference for the bots.

At the top, there are a couple of functions. Of these, CalcPos, IdenticalPos and GetBest are of particular interest.

CalcPos is supposed to calculate the position of an object spotted by the bot – since we know the distance and the angles, this is possible using the principles of spherical coordinates to get an offset. I am, however, not sure if it works properly – He have never dealt with 3D geometry before, so I based it off the Wikipedia article on spherical coordinates. I’m not sure it works, though, as he occasionally seemed to receive weird coordinates – that’s likely why the “go to“-system doesn’t work.

The purpose of IdenticalPos was to determine if a given rechargeable was already spotted and recorded in the array. It compares two positions – expressed using a record – to see if X, Y or Z are more than (sum of bot’s dimensions)*2 units away from each other. If any of them are that far away, the objects are considered different, which would allow for the new position to be added to the appropriate array. The reason for this code is that the bot won’t always look at the same spot of the rechargeable, and treating them the same could easily lead to the array filling up with multiple instances of the same object. Although this is not a major issue for Light Plaza, St. Helen contains two of each item, and without such a check, it might never record the second item.

GetBest goes through all the TPos variables in the array parameter it receives to determine which is closest – it was meant for use with the “go to”-system. It uses the Pythagorean theorem, implemented in the Dist function.