Lessons Learned From CodeRuler
| Posted on Monday, September 08, 2008 |
0
commentsAdd comments |
Peer Programmers
• Robin Raqueno (Check out his CodeRuler blog entry.)• Ronn Reeves
What is CodeRuler?
CodeRuler is a medieval simulation game that allows game programmers, students of the Java programming language, as well as, any person interested in strategy/simulation games to create his own personification of a ruler in a predefined world. The CodeRuler world provides a tournament-style competition, where a player may pit his ruler against zero to five opposing rulers at once, including rulers using the same strategy as his.
The objective is to achieve the most points by the end of 500 turns. Each ruler has .5 seconds to complete his turn each round, and if the time limit is exceeded in any round, all future turns are forfeited. Points are earned by peasants through the accumulation resources for the ruler, which are awarded at the end of the game. For every 10 units of resources, 1 point is awarded; in addition, 1 point is awarded for each remaining peasant. Knights earn the ruler points by a) taking enemy peasants (4 points), b) eliminating enemy knights (6 points), or c) conquering enemy castles (15 points). Each remaining knight at game end earns 2 points. Finally, for every castle controlled by the ruler, another 25 points is added to the final score. If a ruler losses all subjects and castles, he is eliminated from game play, however, the game continues until all turns have been completed. This allows the remaining ruler(s) to amass as many points possible in the remaining turns.
The objective is to achieve the most points by the end of 500 turns. Each ruler has .5 seconds to complete his turn each round, and if the time limit is exceeded in any round, all future turns are forfeited. Points are earned by peasants through the accumulation resources for the ruler, which are awarded at the end of the game. For every 10 units of resources, 1 point is awarded; in addition, 1 point is awarded for each remaining peasant. Knights earn the ruler points by a) taking enemy peasants (4 points), b) eliminating enemy knights (6 points), or c) conquering enemy castles (15 points). Each remaining knight at game end earns 2 points. Finally, for every castle controlled by the ruler, another 25 points is added to the final score. If a ruler losses all subjects and castles, he is eliminated from game play, however, the game continues until all turns have been completed. This allows the remaining ruler(s) to amass as many points possible in the remaining turns.
Strategy Implemented
Our strategy was three-fold: 1) use the peasants to acquire as many resources as possible, 2) use knights to control the economy of opposing forces, and 3) control our economy based on the enemy units in play.
We implemented a box pattern path for our peasants to move around the world. This path would direct peasants south, east, north, and west and continuing throughout game play or until no peasants existed. This pattern had a great deal of success by getting the peasants into the other ruler’s kingdom. Once there, due to the box pattern, our peasants would take control of enemy resources. The fewer resources a ruler has, his unit production time increases (the number of turns required to create a new unit in the game). This was the key to our first objective, and lent itself to achieving our second objective as well. We kept the direction acquisition of resources to random moves versus a directed pattern. Finally, we implemented an evasion tactic for the peasants when enemy forces neared their position.
To achieve the knights’ objectives, we chose to have knights attack castles first to eliminate the opposing ruler’s production facility. Once the opposing ruler’s castle was secured, we targeted enemy peasants. This strategy prevented new enemy units from being placed into play, and decreased enemy resources such that if enemy units already in play were able to take or reclaim a castle, their production time would be so high, new units would have a difficult time getting into play before our knights retook the castle. Finally, the knights would target enemy knights in an effort to prevent them from accumulating points from taking our castle, peasants, and knights.
Lastly, the castle was used to control our economy in different ways throughout game play. If our economy was healthy and no enemy units existed, we produced peasants. If an enemy castle existed or enemy knights existed, we would attempt to keep at least 10 knights in play while we had more than 15 peasants in play as well. If our peasants dropped below 15, then we would create more in an attempt to increase resource accumulation.
Lessons LearnedWe implemented a box pattern path for our peasants to move around the world. This path would direct peasants south, east, north, and west and continuing throughout game play or until no peasants existed. This pattern had a great deal of success by getting the peasants into the other ruler’s kingdom. Once there, due to the box pattern, our peasants would take control of enemy resources. The fewer resources a ruler has, his unit production time increases (the number of turns required to create a new unit in the game). This was the key to our first objective, and lent itself to achieving our second objective as well. We kept the direction acquisition of resources to random moves versus a directed pattern. Finally, we implemented an evasion tactic for the peasants when enemy forces neared their position.
To achieve the knights’ objectives, we chose to have knights attack castles first to eliminate the opposing ruler’s production facility. Once the opposing ruler’s castle was secured, we targeted enemy peasants. This strategy prevented new enemy units from being placed into play, and decreased enemy resources such that if enemy units already in play were able to take or reclaim a castle, their production time would be so high, new units would have a difficult time getting into play before our knights retook the castle. Finally, the knights would target enemy knights in an effort to prevent them from accumulating points from taking our castle, peasants, and knights.
Lastly, the castle was used to control our economy in different ways throughout game play. If our economy was healthy and no enemy units existed, we produced peasants. If an enemy castle existed or enemy knights existed, we would attempt to keep at least 10 knights in play while we had more than 15 peasants in play as well. If our peasants dropped below 15, then we would create more in an attempt to increase resource accumulation.
• Eclipse IDE
• CodeRuler Implementation
• Java Language
• Peer Programming
Run Results Against...Migrate RulerEclipse continues to be challenging to use. Its compiler seems to respond slowly to unflagging errors that have been corrected. Occasionally, I needed to save the file to remove the flagged errors that had already been corrected. Other IDEs that I have used bold the opening and closing brackets for a code block, which I prefer over Eclipse’s placing a small light grey border around the matching bracket set. Other features that would be nice to have is a comment/uncomment code and increase/decrease indentation of code commands. Other IDEs typically have these, yet I have not found them in Eclipse.
• CodeRuler Implementation
CodeRuler was a fun experience. It is one of the few games I have had the opportunity to work on. I am typically better at playing a strategy game (e.g., Risk), than trying to implement or create one. Coming from a business intelligence background, simulation game design is challenging to me as most are based on strategy, while my strengths surround analyzing and understanding the relationship of data. Choosing an interesting and viable strategy was the most difficult and interesting aspect of the process.
One of the most rewarding experiences during developing our implementation was creating the evasion tactic for peasants. Once implemented, it was humorous to watch enemy knights chase after some peasants for a fair distance.
One of the most rewarding experiences during developing our implementation was creating the evasion tactic for peasants. Once implemented, it was humorous to watch enemy knights chase after some peasants for a fair distance.
• Java Language
I have not had the opportunity to use JavaDocs to great extent. While my partner created the JavaDocs, and I reviewed them, going over the inclusion of JavaDocs attributes in the code was a valuable experience. I never realized how simple they were to add to a project, and the resulting documentation is quite impressive.
Another aspect I learned about Java is roughly how much code can execute in less than .5 seconds.
Another aspect I learned about Java is roughly how much code can execute in less than .5 seconds.
• Peer Programming
I have not typically enjoyed peer programming experiences in the past with fellow students. For varying reasons, finding time to meet is the biggest factor, the second being the balancing of responsibility and contribution.
Working with Robin has really changed my perspective of the peer programming process. He was very easy to work with and our collaboration seemed very natural. We used Skype to do the majority of our work, as we do not live near one another and this seemed to work well with our schedules. We did meet on separate occasions, spending time at UH’s Hamilton Library to hack code. But, I think using Skype actually worked best for us. We were able to work in areas we were comfortable (our homes) and share files throughout the process. Additionally, Skype keeps a history of the conversation, so we could easily pass code changes to one another by file or pasting directly into the chat window. This sped up the development process considerably. We both shared responsibility of the project and each jumping into the problem solving and communicating effectively with each other.
Working with Robin has really changed my perspective of the peer programming process. He was very easy to work with and our collaboration seemed very natural. We used Skype to do the majority of our work, as we do not live near one another and this seemed to work well with our schedules. We did meet on separate occasions, spending time at UH’s Hamilton Library to hack code. But, I think using Skype actually worked best for us. We were able to work in areas we were comfortable (our homes) and share files throughout the process. Additionally, Skype keeps a history of the conversation, so we could easily pass code changes to one another by file or pasting directly into the chat window. This sped up the development process considerably. We both shared responsibility of the project and each jumping into the problem solving and communicating effectively with each other.
| Run | Raqueno-Reeves | Migrate | Enemy Status |
|---|---|---|---|
| 1 | 694 | 6 | Dead |
| 2 | 676 | 14 | Dead |
| 3 | 652 | 2 | Dead |
Gang Up Ruler
| Run | Raqueno-Reeves | Gang Up | Enemy Status |
|---|---|---|---|
| 1 | 516 | 232 | Dead |
| 2 | 586 | 133 | Dead |
| 3 | 525 | 233 | Dead |
Split Up Ruler
| Run | Raqueno-Reeves | Split Up | Enemy Status |
|---|---|---|---|
| 1 | 439 | 359 | Dead |
| 2 | 479 | 354 | Dead |
| 3 | 529 | 234 | Dead |
Smart Split Up Ruler
| Run | Raqueno-Reeves | Smart Split Up | Enemy Status |
|---|---|---|---|
| 1 | 499 | 385 | Dead |
| 2 | 484 | 343 | Dead |
| 3 | 455 | 386 | Alive |
Migrate, Gang Up, and Split Up Rulers
| Run | Raqueno-Reeves | Gang Up | Split Up | Migrate | Enemy Status |
|---|---|---|---|---|---|
| 1 | 415 | 279 | 414 | 21 | Dead: Migrate |
| 2 | 668 | 473 | 394 | 7 | Dead: Migrate |
| 3 | 877 | 358 | 275 | 1 | Dead: Migrate, Split Up |
Download
• Raqueno-Reeves CodeRuler with JavaDocs (compressed file)
