ronn.reeves\software.engineering.blog

“Even the ant has his bite.” — Turkish Proverb

In Lessons Learned From CodeRuler, I explored how that project influenced my understanding of the Java language, the Eclipse IDE, and especially, peer programming. In this article I continue that exploration of peer programming by examining and evaluating the CodeRuler implementation from a group of peers in my ICS 413 course this semester. The main aspect of the evaluation is the adherence to Java programming standards defined by these sources:

• The Elements of Java Style by Vermeulen, Ambler, Bumgardner, Metz, Misfeldt, Shur, & Thompson• ICS 413 Supplemental Standards from Philip Johnson
The Elements of Java Style (EJS) had been informally introduced prior to the CodeRuler assignment to the class, but had not yet been mandated as the formal coding style to which course work should adhere. The latter standards, referred to as ICS-SE-Java or ICS-SE-Eclipse, were introduced to the class after completion of the CodeRuler project. Doing the CodeRuler assignments in this manner provides each developer within the class the opportunity to discover his/her baseline adherence to the standards expected through code reviews of our peers’ course work. By discovering deviations from the standards by our peers, we learn to look for deviations in our own programming methodology. Additionally, this assignment begins our exposure to the expectations that will be placed on us as programmers entering into the workforce, as well as laying down a foundation of programming best practices and tools we will need for our eventually rise into management and executive positions.

Peers Being Reviewed
For the purpose of this review, I will be examining the CodeRuler implementation provided by

• Arthur Shum (Check out his CodeRuler blog entry.)• Aric West (Check out his CodeRuler blog entry.)
Their implementation may be downloaded directly from either’s blog or from here:

• aricwest-atshum.zip
The Good
To say that this implementation provides an effective solution to the CodeRuler challenge would be an understatement. Even its designers describe it as an “aggressive” solution. Ruthless is probably a better word. This implementation is quite successful, and after watching it successfully conquer ruler after ruler in just a few moments of game play, even in 3 to 6 ruler competitions, I had difficulty finding a better suited word than “ruthless” to describe West-Shum’s implementation. Their ruler does quite a good job of dispatching opposing rulers and their forces in a very short period. The salt-in-the-wound for opposing rulers is West-Shum’s boxing of enemy peasants by using their peasants such that the opposing peasants are unable to move, and this on top of having already decimated all opposing offensive and defensive units.

The supporting JavaDocs are in order with short, concise descriptions of how to use their implementation. The documentation is easy to read, well-organized, and defines the class and implementation features appropriately.

For the most part, the class definition (MyRuler.java) is organized appropriately being arranged such that readability is reinforced.

The Bad
The following table displays the violations of the EJS, ICS-SE-Java, and ICS-SE-Eclipse standards occurring within the West-Shum implementation of CodeRuler.

Source Code File:  MyRuler.java

* Denotes this violation occurs in additional lines of code not indicated.
And What I’d Suggest
By in large these violations of the standards are minor issues that can easily be addressed by these adept programmers. Their ability to program well is evident in the success of their solution, and being as such, addressing these minor infractions will require little more than an awareness of them. However, I have two observations regarding the implementation that I personally would change: 1) keeping the methods smaller and focused to a single task, and 2) more appropriate use of member fields. Regarding the first observation, the orderSubjects method performs 6 tasks within its body: gather information, create knight teams, prioritize enemies, attack enemies, order peasants, and castle production. I would suggest breaking most of these code blocks into separate methods, such that orderSubjects reads similar to

   1  public void orderSubjects(int lastMoveTime) {
   2    //Gather information
   3    this.myPeasants = getPeasants();
   4    this.myKnights = getKnights();
   5    this.myCastles = getCastles();
   6    this.enemyCastles = World.getOtherCastles();
   7    this.enemyKnights = World.getOtherKnights();
   8    this.enemyPeasants = World.getOtherPeasants();
   9        
  10    createTeams();
  11    prioritizeEnemies();
  12    attackEnemies();
  13    orderPeasants();
  14    controlProduction();
  15  }

Of course, this is just my personal style, but I prefer this style due to its readability and the ability to focus on the specific components in the larger method.

The second observation is that some variables seem to be unnecessarily long lived. For example, several field members are created (i.e., myCastles, myKnights, myPeasants), then initialized on each call of the orderSubjects method. These are then passed as method parameters throughout the rest of the implementation, instead of using direct calls to them. There is one instance where the myKnights member field is referenced directly, but it could just as easily been passed as a parameter by the calling method. I don’t see any benefit to making these member fields, since they are not used in that capacity within the implementation. Personally, I would just make these method level variables and pass as method parameters as needed from the orderSubjects method.

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.

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.

• Eclipse IDE

• CodeRuler Implementation

• Java Language

• Peer Programming

JFreeChart is an open source chart library created by Object Refinery Limited, and may be downloaded from SourceForge.org. JFreeChart’s target consumers are Java developers looking to bring high quality, professional charts to their applications. The library provides a comprehensive collection of chart types, including pie, bar, line, area, scatter, and many others that when combined with JFreeReport provide Java developers powerful presentation tools.

Having used .NET reporting and charting solutions over the past several years, I chose to evaluate JFreeChart against the three prime directives of open source software (OSS) engineering. Specifically, I was interested in determining whether I would consider using a Java OSS charting solution such as JFreeChart over the .NET charting tool I have experience using, as well as, how similar or dissimilar it is to .NET charting tools. Some of the most impressive .NET charting tools I have seen on the market are Dundas Chart for .NET, The XtraCharts Suite by DevExpress, and integrated into its reporting tool Active Reports for .NET from Data Dynamics (ARNET). My experience is with the latter of these applications, which are all designed for developer integration into their applications.

According to Philip Johnson, Professor of Information and Computer Sciences at the University of Hawaii, and Director of the Collaborative Software Development Laboratory,