New Blog

I am going to post everything related to programming and software engineering on my new software engineering blog The Java Logger. See you on the other blog!

Language Learners has moved!

All future posts about Language Learners will be on my personal blog, The Traveling Computer Scientist. To view only those posts relating to this project, click here.

Also, Language Learners will no longer be hosted on Google Code. Rather, I'll be using github. If you're a developer and want to follow me on github, my username is bjpeterdelacruz. The reason for changing blogs is that I also want my family and friends to see what I'm doing for this project, and the reason for switching project hosting websites is that I'll be using Ruby on Rails for development, and Git really works well with it, as opposed to SVN, which I find more difficult to use.

Thanks!

Language Learners and Ruby on Rails Web Development

I just finished creating all of the mockups that I think will be necessary for the Language Learners system. The Mockups page on the Google Code project website has all of them. Feel free to leave a comment or question there or at the end of this blog post.

My plan right now is to check out the Hobo framework and, at the same time, read Agile Web Development with Rails by Ruby, Thomas, and Hansson. I am starting to learn all about Ruby on Rails, so I want to use a framework that is easy enough for a beginner like myself to use, and Hobo seems like a good tool to start with; then from there, I could perhaps move on to something else that is more challenging or flexible, or just stick to it if it has everything I need for development.

I will give my thoughts on Hobo once I'm done taking it out for a test drive.

Language Learners on Google Code

Today, I finished tidying up the Language Learners project website on Google Code. You can now find a description of the project, one wiki page for the project, and the project's current status on there.

You may notice three other developers who are also working on this project. For now, this project is part of a class that I am taking with Dr. Scott Robertson called Human Computer Interaction (ICS 664). These people are only involved in the planning and design of the system. I will take care of the rest, such as development, documentation, and testing, because this project will become my master's capstone project once the semester is over. (Two of the developers are undergraduate students, and one is a graduate student; the latter will be doing something else for her capstone project.)

This week is Spring Break at UH Manoa, so I'm hoping to get as much done as I can. Right now, things are looking good because I already finished two of the three things that I mentioned in the previous post. :)

Language Learners: Main Page

I just finished mocking up the main page for the Language Learners system. Here is the screenshot (click to enlarge):


I like the layout of the main page. Unfortunately, all of the other pages I've been mocking up do not have this design; they need to be redone. I will post mockups of those pages once they are finished.

Spring Break is next week. My plan is to finish mocking up the pages that do not have the same layout as the main page. I also need to create several more mockups of new pages, e.g. one for editing a user's profile and another for allowing a user to upload content to the system (like audio and video files).

Regarding video files, my plan is to host them on YouTube and just embed them within the system, like how I do it on my other blog. As for audio files, I may just have to store them on the server on which the system resides.

The main page is more or less done, but if you have any feedback with regards to how it looks, what I should add to or remove from it, etc., please let me know. Again, this system will be used to help students learn a new language (including those who are already learning it and just need another way to help them learn the material), which is the reason why I am including content such as on-screen flash cards, and audio and video files. There will also be a forum so that students can exchange ideas with each other. If things work out well, I may also include an instant messaging feature similar to MSN Messenger and AIM.

Hopefully, this system isn't too big for an M.S. project, but it will be a good test to see if I can create a successful, database-driven, dynamic social networking web application... by myself. :)

MY PLAN FOR THE WEEK OF 03/21:

1. Finish creating mockups. [COMPLETED March 24, 2010]
2. Redo layout of existing pages. [COMPLETED March 20, 2010]
3. Finish the User Guide for the Ekolugical Carbonometer system (which was left unfinished from the Fall 2009 semester). :) [COMPLETED March 19, 2010]
   

--BJ Peter DeLaCruz

Language Learners: A Master's Capstone Project

I have decided that for my master's capstone project, I will be developing a web application similar to Livemocha. My adviser will be Dr. Scott Robertson of the Information and Computer Sciences Department at the University of Hawaii at Manoa. I will start working on this project next semester. However, in April, I plan on talking to Dr. Robertson about some initial concepts for this web application, which for now is known as Language Learners.

I have another blog, called The Traveling Computer Scientist, that you can check out; I will be posting information relating to this project on both blogs (I go by the pen name Joe Mercer on that one, and the other blog I have will be less technical and more for the lay person than this one).

Stay tuned, and I will keep you updated with the progress of this new and exciting project that I am about to undertake!

--BJ Peter DeLaCruz

Learning from the Enemy: Analyses of Other Developers' Robots

Before I design my competitive robot, I thought it would be necessary to see what other people did with their robots first. In particular, I looked at the sample robots that came with the Robocode installation package. Specifically, I will talk about how the authors of the Corners, Crazy, Fire, RamFire, Sitting Duck, SpinBot, Tracker, and Walls robots implemented the movement, tracking, and firing functions for them.

Robot #1: Corners
Movement
The goCorner method handles the movement for the Corners robot. As its name implies, the robot will face perpendicular to the wall that is to the right of the corner that it chose to go to and then go to that wall. Then it will turn left ninety degrees and move to the chosen corner. It is worth mentioning that the number of pixels to move forward, which is specified in goCorner, is hard-coded, so if the battlefield size is gigantic (say, 20,000 x 20,000 pixels), the robot may not reach the chosen corner; in this case, it can easily be defeated by attacking it from behind.

Tracking
The robot swings its gun from zero to ninety degrees once it reaches the chosen corner; it does not rotate its gun from zero to 360 degrees continuously. If it makes radar contact with an enemy, it will try to track the enemy with its gun and fire at it both at the same time. However, if an enemy is to the rear of it and stays there all the time, and the latter never reached the chosen corner, the enemy will never be found because of the constricted movement of the robot's gun. Even worse, the enemy will have the perfect opportunity to destroy the robot without taking any hits.

Firing
The robot will open fire once radar contact is made. If the robot's energy is below a certain level, or if the enemy is very far away, it will use low power for its bullets. On the other hand, if the enemy is very close, it will use maximum power.

Robot #2: Crazy
Movement
Based on my observation of the Crazy robot in action, it appears that the waitFor method that is called in run will make the robot turn and move ahead at the same time. These two actions are accomplished by calling setTurnRight (and setTurnLeft) and setAhead, respectively, before calling waitFor. Also, it is important to note that the Crazy class extends AdvancedRobot, not Robot. In classes that extend Robot, one must call turnRight (or turnLeft) and ahead to make the robots turn and move forward, respectively; however, unlike the Crazy robot, they will not do these two actions concurrently, only sequentially. By turning and moving forward concurrently all the time, the Crazy robot appears to be moving around randomly.

Tracking
Because the robot's gun and radar are both stationary, and because of the way the robot moves, there is no tracking mechanism used to lock onto an enemy once radar contact is made; radar contact is made only when the robot is facing in the direction that the enemy is located, and radar contact is lost when the robot turns in another direction.

Firing
The robot uses low power for its bullets and opens fire at any enemy that comes into radar contact with it.

Robot #3: Fire
Movement
The code to make the Fire robot move is located in the onHitByBullet method; no other method contains code for movement. Thus, the robot will only move if a bullet hit it; the robot will turn perpendicular to where the bullet came from and move fifty pixels.

Tracking
The robot sits still and rotates its gun throughout the entire battle until an enemy hits it with a bullet. Once radar contact is made, the robot will track the enemy with its gun and open fire at it both at the same time; however, radar contact can easily be lost once the enemy fires a bullet at the robot and the latter moves as a result of being hit.

Firing
If an enemy comes into radar contact and is very close to the robot, and the amount of energy left in the latter is greater than fifty, the robot will use maximum power for its bullets against that particular enemy. Otherwise, the robot will use low power. Also, it will use maximum power against the enemy that comes into physical contact with it.

Robot #4: RamFire
Movement
The RamFire robot is similar to my Tracking01 robot; the former will rotate its entire body until it comes into radar contact with an enemy. Once radar contact is made, the robot will move to the enemy's location and attempt to ram it. If the robot arrives at the enemy's location but the enemy is not there, the robot will rotate its body again until an enemy comes into radar contact. Basically, the robot will follow the enemy and try to ram it.

Tracking
Both the robot's gun and radar remain stationary throughout the entire battle. Because the robot only moves to an enemy's location and does not track an enemy with its gun or radar, this strategy will be ineffective against enemies that move around a lot, e.g. Crazy and Walls, because the only way to fire at them is to come into physical contact with them (i.e. by ramming them).

Firing
The robot fires at the enemy only when the former makes physical contact with it. Despite this strategy's ineffectiveness when it comes to very mobile enemies, the robot makes up for it by using maximum power for its bullets when it fires.

Robot #5: Sitting Duck
Movement
The Sitting Duck robot sits still throughout the battle. In the code file, there is only one method, run, but no method is called that will make the robot move; the only things that are done in this method are reading in a file that contains the total number of rounds and battles that the robot has been in, incrementing the two numbers, and displaying the results to the screen.

Tracking
The robot does not move both its gun and radar at all during the battle. No methods are called in run that will make the robot move either of them.

Firing
The robot does not fire its gun at all during the battle. Surely, the robot is a sitting duck, perfect for target practice, because it does absolutely nothing at all.

Robot #6: SpinBot
Movement
The SpinBot robot moves in a circle throughout the entire battle. After examining the code file for the robot, I saw that, like the Crazy class, the SpinBot class also extends the AdvancedRobot class, and it uses the setTurnRight method, which, according to the API documentation, will execute when an action takes place or the execute method is called. In this case, ahead is the next method that causes the robot to take action, so both turning and moving ahead are executed at the same time, concurrently.

Tracking
The robot's gun and radar remain stationary throughout the battle, so no tracking mechanism is implemented.

Firing
Once radar contact is made with an enemy, the robot will open fire at it with maximum power. However, it is important to note that because the robot is firing with maximum power, if there are two or more enemies on the battlefield (say, two Sitting Duck robots) and are in close proximity to each other, not every enemy will be fired upon until the gun cools down.

Robot #7: Tracker
Movement
The Tracker robot will rotate its radar until radar contact is made. Like my Tracking02 robot, once radar contact is made, the robot will turn its body towards the enemy and move to the enemy's location, stopping when it is 150 pixels away from the enemy. If it gets too close, the robot will back up forty pixels.

Tracking
Once the robot arrives at a location 150 pixels away from the enemy but the latter moved to another location, the robot will try to find it again by moving its radar ten degrees to the left and right. If it did not find the enemy that it was tracking, it will rotate its radar until it makes radar contact, either with the same enemy or a different one. The tracking mechanism implemented here is similar to the one I used in my Tracking02 robot, but instead of using a string to keep track of an enemy and setting it to null once radar contact is lost, I used an integer, which I set to one once radar contact is made and zero once radar contact is lost or my robot is not tracking an enemy at the moment.

Firing
The robot will open fire with maximum power once it is 150 pixels away from an enemy's location. If another enemy bumps into the robot, the latter will back up, open fire with maximum power at that enemy, and track it until radar contact is lost.

Robot #8: Walls
Movement
The Walls robot will face perpendicular to a wall and then go to that wall. Then it will follow the edge of the wall in a clockwise fashion.

Tracking
The robot's gun and radar remain stationary throughout the entire battle, so no tracking mechanism is implemented.

Firing
Once the robot reaches the edge of the battlefield, its gun will be perpendicular to the wall, and it will open fire with medium power once radar contact is made.

My Final Analysis
The robots that remain stationary (Corners, Fire, and Sitting Duck) are more at risk than the other robots, all of which are mobile, no matter how good their tracking mechanisms are. Why? Think of battles involving three, four, or more robots. I do not think they would last very long.

The tracking mechanism that the Corners robot uses is not a good one because it does not cover a wide area--that is, its radar sweep only covers only one-fourth of the battlefield, not all of it--and like I mentioned before, the robot's most vulnerable area is its rear.

If no tracking mechanism is going to be implemented, the robot should be on the move at all times (Crazy, SpinBot, Tracker, and Walls); even better, the robot should move randomly (e.g. Crazy) and quickly.

Hopefully, I did not give away too much information... ;)

--BJ Peter DeLaCruz