It's the moment you've all been waiting for. The robocode competition. After weeks of testing, learning things with ant, and designing our very own robot, it's time to test our skills as well as our imagination. With this project, I was attempting to design a robot where that would be both offensive and defensive. It is actually quite hard to explain, much easier if you watch it in action.
So what does my robot do exactly. It's actually quite simple. For the movement, I designed my robot to simply follow other robots. At first, it will lock on to a single robot and follow it until either it (the enemy) or itself dies. In the case of a melee situation where more than 2 robots are involved, once the enemy is destroyed, it will then lock on to the nearest enemy and repeat the process. This way, the robot isn't stuck once the enemy is following is destroyed.
Like I mentioned earlier, targeting is done by means of scanning for the nearest robot. It will not change targets until one of the two robots is destroyed. It is a very risky procedure, but it reduces the amount of time required for the robot to re-lock on to a new target. This could potentially save the robot's butt.
Although firing could potentially refuel the robot, it also costs a pretty significant amount of energy to even fire off a bullet. Because of this, my robot will only fire when it is near the enemy. If the enemy begins to move away, my robot will be close enough where the odds of the bullet hitting would be pretty high and for this reason, the robot will always fire at the highest strength allowed by the rules.
Against the sample AI robots, my robot did fairly well. It would always win (obviously) against the ones that didn't move like SittingDuck and the two interactive ones. Against the ones that did move (and even fire back) my robot could consistently beat the Target robot. Against a few of the other robots, my robot would often win between 60 to 90% of the time. However, against the Walls robot I was unable to beat it. It was just too fast and well protected by the walls. The reason it couldn't beat Walls, well, my robot had to know where the other robot was before it moved and since walls basically just goes in a circle, my robot simply could not keep up. Would I change my design? I probably would. I would try to incorporate a faster way for my robot to turn and move, probably by implementing the AdvancedRobot class instead.
Because my robot had such a simple design, not much testing was required. The types of testing I did was to make sure I could beat a hand full of the sample robots more than 50% of the time, along with make sure my robot knew how to move away if it made a collision with the enemy robot. I tried getting my robot to limit itself in a "safety bubble" by having it stay near a wall, but often times it ran out of energy.
So from all of this and weeks of programming, what have I learned? I learned quite a bit actually. I learned the amount of time it takes to create larger programs as well as the sheer amount of testing it takes in order to make the program do what I wanted it to do. I also learned by means of the kata I finished earlier, that it is better to break a large program into smaller pieces of code via the divide-and-conquer technique and just have your code do a bunch of small things before putting it all together. So now that it has all been said, lets FIGHT!
No comments:
Post a Comment