Tuesday, October 11, 2011

competitive robot

For the continuing project of our Robocode implementation, we were asked by our professor to create a “competitive” robot based on the knowledge that we had acquired from the earlier exercises.  Utilizing the three basic platforms of movement, targeting and radar, along with some strategic blocks of code, a competitive robot can be built.  What it really comes down to though in the competitive arena is the strategic calls in the code blocks, and how you would expect you robot to perform when certain events happen.  
Well, as far as for my design, I thought that I had a pretty clever strategy which in theory would have been a very difficult opponent to beat.  My strategy was to have my robot circle around its opponent and simultaneously fire in towards its target.  However, through much frustration and a couple of visits to the robocode wiki page, to accomplish something like this while using just the basic robocode package and no other interface would have been near to impossible.  There was a robot from another person that basically had the strategy I wanted to build, however they’re robot extended the advanced robot interface, so to try and build something that just didn’t have the capabilities within its class would have been extremely difficult.
So I settled for a slightly different strategy for my robot. for the movement, I decided that I would have my robot adjust its position only when necessary due to the nature of its targeting strategy.  It turns out that the tracking and targeting style that I chose to implement works best when the robot is stationary, and can inflict the most damage on its target this way.  Therefore, I used the on hit by bullet method to call the movement adjustment.  For the firing strategy, I decided to go with one that would conserve my robots ammo due to the observation that the robot would sometimes run out of ammo before the round would be over.  The robot automatically adjusts its bullet strength according to the distance of the target.
Being that I was unable to implement the strategy that I originally wanted, this other one actually preformed pretty well.  It beat out most of the robots except for the spinbot and ramfire.  I think a weak point in my design probably was due to the fact that I didn’t really have any strategy to execute for something like a collision with another robot.  Its here that i think my robot what become overwhelmed by the ramming bot.  This could probably be improved with something like a fluid movement.  The spinbot seemed to come in first every time because I think its probably one the the hardest targets to hit due to its constant motion.  I think for my design that tracking and adjustment of the gun was a bit delayed and couldn’t pinpoint the targets movement.  This could probably be improved with something a little more advanced that would allow the robot to predict the targets movements.  
The approach for testing that I relied on probably wasn’t the best approach, but was basically a trial and error type of approach.  I would add segments of code in spots that I though it would probably be most effective, and had even tried to build the methods that would perform the circling methods.  However, I think that I probably wasted a lot of time trying to implement such a complicated battle strategy with little that this basic package provided.  
The lessons learned from my experience of building this competitive robot would be to possibly come up with more than one plausible strategy, and something within the range and capabilities of the tools on hand.  Though I knew that my original battle strategy would be very difficult to implement I decided to try and tackle it anyway.  However I should have realized in a much earlier stage that it wasn’t plausible, and should have started on a new strategy within the capabilities of the class and package. 

Monday, September 19, 2011

Battle Bots

    As an assignment for our Ics 314 software engineering course, we were asked to program 12 individually simulated robot tanks using a preexisting development tool called robocode.  The purpose of the assignment was to give us more experience with the Java programming language, as well as a chance to acquire some new knowledge and skills.
Robocode was a project that was initially started by an IBM developer to help people learn code, and has since then grown into something that is now managed by an online community of developers who continue to actively contribute to the project and its cause.
As a starting point, we were given the task of creating 12 robots that would perform different tasks as a means for us to explore the many facets of the software, as well as how to manipulate the code to get the robot to do what we want it to.  The way this is done is through predefined method calls along with customized chunks of code which allow the robot to perform its specific task.

From all of my experiences as an ICS major I'd have to say that working on this project was by far one of the most enjoyable programming experiences I've had to date...and dare I say a little fun...
Although the process of learning the ins and outs of the software was initially quite time consuming, it became enjoyable to watch my custom made robot duke it out with some of the sample bots provided with the software. Personally, I think the reason why this project was successful at not being such a pain was due to its GUI which gave the immediate gratification of seeing your code acted out by a little tankbot.  It even minimized the painstaking process of debugging the code, which for me was simple because it usually entailed either removing of adding one or two lines of code.  The good thing was that a lot of the robots did call on similar movements, so this made modularity possible.  For the most part, I created method blocks and used they same blocks on the robots that had similar movements.
    Although I did complete all 12 robots, the one robot that I did have some considerable trouble with was the position five robot, which was by far the most complicated of movements.  The robot was supposed to move to a corner of the field, then next to the corner diagonal from it, and repeat process for the unvisited corners.  The only solution I saw possible for this problem was to use the center of the map as the robot's pivot point to go to each corner since the capabilities of the robot at this time were limited. Although the robot I created for this task did complete the task, I know the code that I wrote was quite inefficient.  This was the only one I felt questionable about.
 Next, we're supposed to program a fully fledged battle bot that will compete against all the other bots created by the other students.  These exercises were a really good introduction to the world of robocode and I feel have given me enough confidence to build a successful battle bot.  I think I have a pretty good attack and avoidance strategy that I've devised  from observing some of the sample bots, which I won't talk about here because I don't want to give away the best tactics!  All I can say is that it will be aggressive + aloof = perfect killing machine...game on

Wednesday, August 31, 2011

The implementation of the FizzBuzz program took me about 10 minutes to implement.
Most of the time could be attributed to the fact that I had never really used eclipse before, and had a little
trouble seting up the workspace correctly.  Another reason why it took me a little longer was that I had to
remember how to program in Java becuase it has beena while since the last time I programmed in Java.
however, once I remembered the format it was relatively quick to get it working and obtain an output.
I had to make a slight adjustment to my original algorithm because ot was testing and printing the case of 3 before it
reached the case of 3 and 5 multiples.  So the fix was to put that test case before the test of 3.
package edu.hawaii;

Program:
public class FizzBuzz {
    public static void main (String [] args){
   
    for(int x = 1; x < 101; x++){
     if ((x % 3 == 0)&&(x % 5 == 0)){
            System.out.println("FIZZBUZZ");
        }
     else if (x % 3 == 0){
        System.out.println("FIZZ");
        }
    else if (x % 5 == 0){
        System.out.println("BUZZ");
    }
    else{
        System.out.println(x);
    }
        }
    }
}

Tuesday, August 30, 2011

Open source software and the three Prime Directives

Overview:
The Java based package that I downloaded and installed from Sourceforge was a simple beat mapping application called OrDrumbox.  It supplies the user with a simple drum machine tool for their computer so that they may create simple computer based music.

http://sourceforge.net/projects/ordrumbox/

Prime Directive 1:
First of all, the installation of the application was very simple and fast.  It took all of a minute to download and install, and also created an icon on the desktop to make access to it easy.  The interactive GUI that comes up once the application is started is actually quite sophisticated.  There are a number of controls that correspond to the drum sounds, and even a list of pre-programmed rhythms that can be selected and instantly loaded into the beat map.  There was obviously a lot of thought put into the structure of the application to make it a viable tool for users as an alternative to other expensive software on the market. This certainty was not the first software release due to the complexity and efficient design of the GUI.  Fulfills Prime Directive 1.

Prime Directive 2:
The user documentation for an application of this level is quite exceptional.  Within the help contents pull down tab of the application window is a link to a OrDrumbox website. The website has a simple user manual as well as screen shots to help guide the user, and downloads page for upgrades and tutorial videos.  This website was designed in order to keep the application self-sufficient and provide the user  with enough information to effectively navigate its different features.  Fulfills Prime Directive 2.

Prime Directive 3:
Unfortunately, the developer-level documentation is somewhat limited.  There is a simple forum page mostly consisting of topics of already existing features.  However, there is a contact link to the developers so I suppose if one wanted to attempt to create a plug-in or enhancement to the application, the developers have left it open-ended.  Does not completely fulfill Directive 3.