Progress

While progress has been slow, I have been making some. Take a quick look at this screenshot of the forces screen v0.1, showing off Dark Elf unit artwork by Ryan Barger, as well as sample battle calculations.

Impassable Terrain

Here is a sneak peak of the new movement interface for Kingdoms of Arcania. We removed the hex grid that we used in Fall of Rome to better show off the stunning map. The movement arrow now changes colour to let you know if the proposed path is allowed, would result in a force march, or is impossible.



The shaded area in the middle of the group's path is a gaping chasm cannot be safely traversed. Impassable terrain in Kingdoms of Arcania introduces several strategic considerations that players will have to take into account.

Version 0.1 launched

A pre-alpha version of Kingdoms of Arcania was finally launched to the development environment and the first test game was created featuring members of the design team. There is still a great distance left to travel, but it's great to finally be here.

Obscure Duplication

Many people have written about the evils of duplication in code. Refactoring tools have evolved to the point where they can often detect it. Eclipse's "extract method" refactoring will identify similar blocks of code and replace all instances with a call to the extracted method.

There are other forms of duplication in software development that are harder to find, but cause just as many problems. One common example is duplicating state between code and configuration files.

I just finished removing one such case. Fall of Rome uses rules files to define variable elements of the game, including emissary definitions. An example might be:
{ //Emissary Rank
1 //Rank
"King" //Description
}

Unfortunately, the code for determining the icons for representing the emissaries on screen relied upon static variables defined in a Java class:

public static final int kRank_King = 1

public String getIconFilename() {
switch( rank ) {
case( kRank_King )
iconName = "king"
...
}

The Emissary Rank concept is duplicated between the configuration files and the code. This makes it hard to change the Rank definitions, as I discovered accidentally when the Drow Queen I created looked like a Provincial Governor.

Fortunately, this particular instance was not hard to change. Most of the emissary descriptions are very close to the icon filenames, and I was able to replace the switch statement on emissary ranks with one line of code:

return emissary.getEmissaryRankInfo().description.toLowerCase();

Put Code Where It Belongs

Kingdoms of Arcania feedback has been coming in, and one of the requests was to turn off the banners for controlled pop centers. The banners will still be displayed in the pop center tool tips, but will not be rendered on the map itself. I decided that the boys should nap long enough today for me to implement this - it's a simple if statement to prevent the rendering in KOA, right?

Well, the solution is that simple, but the process turned into a game of Hunt the Wumpus. All the pop center rendering code is contained in one class... or so I thought. A quick read through the code turned up an icon rendering method that includes: if a banner exists, render it. I commented out the line and ran the game to see the effects. None.

Scratching my head, I took a look around, and realized this line controlled the tool tip banner rendering, but not the flags that are displayed on the map. Several frustrating minutes later, I found the following piece of code in an unrelated class:

if( actor instanceof PopCenter ) {
... draw Banners ...
}

After a few minutes studying the code, I was able to apply an Extract Method and Move Method refactoring (with a few other tweaks to make the refactorings possible). This is the frustrating part. A few seconds thought when this code was written could have saved me a great deal of precious time today.

I've been guilty of this type of code in the past. This will serve as a reminder to myself:

"Whenever you're tempted to add instanceof to the code, you're missing an opportunity to improve your design."

Flexible Persistence (Or: More PCType Woes)

Note to self: when designing a persistence mechanism for an application, make the underpinnings as flexible as possible. If the container doesn't impose any restrictions (Relational database, I'm looking at you), then don't arbitrarily create them.

Many of the Fall of Rome rules definitions are persisted to a flat file. There are several methods that talk to an Archive, asking it to load and store items into the flat file. To make the developer's life easier, the API allows me to ask for an int when I know it's an int, and ask for a String if I know the data type is a string. Unfortunately, the items written and read from the underlying file also encode the type of data. This makes life extremely compilicated when trying to change from a char (the old PopCenterType encoding) and a String (much handier for new pop center types, like Small Towns).

If I want to change how PopCenterTypes are archived, I shall have to hand edit every existing file where they are archived, introduce some method of changing them within the code itself, or altering the underlying persistence mechanism to be type agnostic. All three of these methods will require hand editing the files where the information is stored (and it's duplicated in several places - the master rules file and each individual game turn file).

I believe it will be possible to solve this by attempting to read items the new way, failing, and defaulting to the old way. That's a messy solution to a problem that never had to exist. The rules are stored in flat files. Flat files store bytes with no concept of data type. Lets store everything as a String. Strings can be manipulated to whatever is required by the internal application. It might not be as performant, but for a game where each turn is run every three days, adding an extra couple cycles to the loading time to improve developer flexibility seems like a fair trade.

Encapsulate - Please!

I just spent the last hours trolling through the Fall of Rome source encapsulating Pop Center types. The concept of pop center type was littered throughout the code as public characters - either 'C', 'T' or 'V'. This has made it exceedingly painful to introduce the new Kingdoms of Arcania pop center types, like the hamlet. The code never cares about the letters C, T or V - they care about what these letters represent. Unfortunately, the logic that applies to cities, towns and villages is now spread throughout the application instead of being encaplated in one centralised location.

This work has laid the foundation for proper Cities, Towns and Villages to come to life in the code. Once I manage to encapsulate the behavior, I will then be able to add the new pop center types.

For any software develoeprs reading this, please encapsulate your data. It makes life so much easier for the next person.