Monday, September 8, 2008

CodeRuler

Introduction:

CodeRuler is IBM's fantasy ruler simulation game which runs as a plugin to Eclipse ID. The goal is to come up and implement a strategy to not only stay alive but dominate the competition. As the player, we write the Java code for our ruler and try to beat out the rest.

In addition to writing the Java code to our ruler, this is also our first time working with another classmate as we continue to familiarize ourselves with Eclipse and hopefully have some fun.

Partners:


Yasuyuki Kaneshige
John Ly

Download Link:

CodeRuler (Kaneshige-Ly)

Evaluation Runs:



yasuyukikaneshige
-johnczly

vs

Gang Up Ruler

yasuyukikaneshige
-johnczly

vs

Migrate Ruler

yasuyukikaneshige
-johnczly

vs

Split Up Ruler

Test 1

634 – 36

477 – 5

444 – 48

Test 2

536 – 119

656 – 0

571 – 77

Test 3

549 -54

565 – 10

556 – 108


My strategy was simple. I had my knights attack the closest enemies. As simple as that was, it worked for well for 1-on-1 battles against the sample rulers. My peasants running around the border was an okay strategy but definitely not the best. However, it did claim land at an above average pace.

Of the three, the hardest to face was Split Up Ruler because it would divide up their knights. However, it is still predictable in the way that they still target peasants first. With my peasants running around the border of the map, it was fairly easy to defeat the knights and keep my castle.



Lessons Learned:

The one on one battles and one versus two battles were simple after a couple of runs. After observing one or two rounds I noticed their first target is the peasants. So adjusting my strategy accordingly, I won. However, four ruler (or more) battles, however, are difficult.

I wanted to implement something similar to this code my partner Yasu found. Peasants would find any unowned land and claim it. The knights also had a smart system of attacking. If attack level is low, they retreat and target peasants to replenish their strength. It was amazing to see but incredibly hard to implement. I just couldn't quite get my version to work in time so I had to revert back to my original strategy.

Coding-wise, I often found myself trying to clean up my code and trying to comment things properly for my partner to hopefully understand it. I usually do not have readibility as my primary focus but I felt it should be in this case. I guess this is because most of the code up to this point have been one-and-done. I would turn it in for an assignment and never look at it again. I think I need to get used to commenting and documenting so external developers can understand as well as myself if I ever need to look back. My audience has grown and so should my programming style.

Working with a partner is good and bad. There's always the pressure to do well because you don't want to see your partner suffer the consequences. But there's also lot of good that comes with the territory. Yasu helped come up with ideas that I probably would have never thought of. It's like the saying goes, "two heads are better than one."

Although my code didn't come out the way I wanted, our code still faired decent against the three other rulers.



No comments: