LRU eviction: O(KB)
FIFO eviction: O(K)

Unless it costs a lot more to load an object into the cache, FIFO eviction may make the most sense. In most LRU implementations I’ve written, the cost to maintain the “use” status of the cached object was more expensive than a cache miss because of the object had been evicted. Consider the cost of loading the object versus the SLA for the service. Also, if the cache objects retrieved tend to be clustered very strongly with few if any changes, the cached objects won’t be evicted from the cache very often. A FIFO strategy only loses in the case of a full cache where rarely used objects are occasionally inserted and frequently used objects are evicted and reloaded.

The JVM garbage collector is generally less efficient with larger heap sizes. Heaps over 1 GB with efficient garbage collection is possible if the JVM is properly tuned. Concurrent Mark and Sweep collector may be buggy in very large heaps–tiny JDK 6+ JVMs in federation worked okay. Cache growth should be limited (especially with hashmap caches). The number of long living objects is a problem moreso than the size of those objects, so consider serializing/deserializing the objects to byte arrays (the JVM is optimized around short-lived object garbage collection and the cost of young generation garbage collection is proportionally lower than older generation garbage collection).

Tuning JVM Garbage Collection JDK 5.0

JCS vs Ehcache metrics

Download CombatSim-0.3.0.zip now!

Changes:

• Various logic fixes
• Actors are now internally stored as a dynamic data structure, so future versions will allow the user to specify complex arrangements, including friends or allies
• Actors have a very basic aggro mechanism for determining who to attach and when
• The combat core is now invoked externally and does not require a separate thread or real time clock; callers specify what time the core is invoked, so attacks in the past or using an accelerated clock can be run
• A basic metrics system (including sums and histogram data) is integrated to the combat core and simulator for reporting
• Reporting is dynamic for the number of actors, including graphical, table, and CSV reports
• Problems with excessively long combat rounds in random actor testing have mostly been resolved: actors could have unrealistic or out of balance stats which caused cases of exceptionally high hit points coupled with very low damage or change to hit
• Random combat order for actors can’t be overridden at this time
• Combat rounds may not exceed 5000; the metrics take up too much room in the Java heap and can cause an out of memory error (I didn’t increase heap size in the launcher script)

Instructions for use:

1. If you’ve been using an old version of CombatSim, remove your combatsim.settings file
2. Download CombatSim-0.3.0.zip
3. Unzip CombatSim-0.3.0.zip
4. On a Windows box, double-click CS.bat; on a Linux or OS X box, execute ./CombatSim-0.3.0/CS.sh; on an OS X box, double-click CS.sh
5. Press the “Fight!” button to simulate combat

I think I’ve spent around 40 or 50 hours on the iterations of this simulator. The end is in sight:

• Change the UI to allow the user to edit arbitrary numbers of actors
• Change the UI and default actor load to include more than one skill
• Implement the method on the actor to choose the appropriate skill in combat
• Add Focus as an attribute to the actor to guide skill use
• Consider how to allow new combat rules to be plugged-in without recompiling the program

Between 0.0.2 and 0.0.3, the format of the combatsim.settings file changed slightly and the old version is no longer completely compatible (two fields were added). As this is not an alpha quality application, I didn’t see the need to back-down to the prior version of the settings file and transparently upgrade it.

Overall, I believe that with the recent reexamination of the code, the new metrics classes, and iterative development, this is the most accurate and useful version of CombatSim yet. You’ll need the Java 5 or Java 6 runtime (JRE or JDK) and this version has been tested against Win32 and Linux.

One last word: this combat engine is the most primitive version of the engine I plan on using in my next development project.

Consider this an intermediate version with heavy refactoring (all for the best in the end) and many improvements in the API and code quality. It’s still very buggy, though.

CombatSim-0.0.3.zip

As before, this is a Win32 only release (I didn’t update the shell script). Install a recent version of Java 5 or Java 6 (JDK or JRE 1.5 or 1.6) and double click on CS.bat to start CombatSim.

Download CombatSim-0.0.2.zip here (3.4 MB).

This is a much bigger download than version 0.0.1 because of the chart library used. It’s late and the shell interpreter on OS X is pwning my startup script, so don’t count on CS.sh working. It tested fine on Cygwin but is very unhappy on my PowerBook.

Feel free to post any questions as comments or contact me via email.

• a summary CSV using the data from the table
• many histogram CSV files, one per combatant per histogram type (all of Arnold’s hits, for instance, are in one CSV file)

The CSV output files append new rows to the end by default. To merge multiple histograms into one spreadsheet or CSV file will require scripting (aka, I’m too lazy to do the work for you) as each histogram has a separate set of buckets and is spread across two rows. Hence, when writing histogram data of a particular actor, I need to record two rows, one for the buckets and one for the values in the buckets. I use IDs (common to each execution of CombatSim and unique to that run) so that rows can be pasted back together if you want to perform additional analysis.

At this time, all combat sim data is written to the working directory. I’ll change that before the next release so that the user can specify the base file name and path.

Coming up next, storing configuration settings and default values. Once that’s complete, I’ll release a new version of the sim to the world and start work on arbitrary numbers of combatants and multiple attack skills or types. (Did you ever want to model a raid against a dragon or another boss mob? You should be able to with an upcoming version.)

Simple Solution: create a new logger and write feed errors to that logger.

Other Solution: when you can’t create a new logger, create a wrapper around Log4J to log messages to a specific log file, with changes to the log4j.properties file.

Notes:
In the hierarchy of com.company.reader.feed, a logger is defined as com.company.reader.feed.FeedLog which lightly wraps Log4J logging methods. This FeedLog will need to be excluded from the parent logger(s) that already log its hierarchy, and will need to point to a different logging destination (file or database table).

log4j.properties

# assuming the rootCategory logger is already configured...
# everything RSS related we want to see in the logs
log4j.logger.com.company.reader.feed=(DEBUG)
 
# set up FeedLog logging to capture parser errors
log4j.logger.com.company.reader.feed.FeedLog=(DEBUG, parserFile)
log4j.additivity.com.company.reader.feed.FeedLog=false
log4j.appender.parserFile=org.apache.log4j.FileAppender
log4j.appender.File=feed_parser.log
log4j.appender.parserFile.layout=org.apache.log4j.PatternLayout
log4j.appender.parser.layout.ConversionPattern=%d [%-5p] %c - %m%n


additivity indicates if messages from this category (package and class) will be forwarded to parent loggers.

FeedLog.java (partial implementation)

public class FeedLog {
    private static Logger logger = LogManager.getLogger(FeedLog.class);
 
    public static void debug(String message, Throwable t) {
        if (message != null) {
            logger.debug(via() + message, t);
        } else {
            debug(t);
        }
    }
 
    private static String via() {
        // this is an expensive operation--it stops the VM momentarily
        // to handle the exception and get the stack trace
        try {
            throw new Exception();
        } catch (Exception e) {
            StackTraceElement [] ste = e.getStackTrace();
            if (ste != null && ste.length >= 3 &&
                !ste[2].isNativeMethod()) {
                return "(From " + ste[2].getClassName() + "." +
                    ste[2].getMethodName() + ":" +
                    ste[2].getLineNumber() + ") ";
            } else {
                return "(From native code) ";
            }
        }
    }
}


Todo:

• Allow each divisor for a stat/attribute or skill to be stated as a linear function (as it is today), geometric, exponential, or logarithmic value.
• Collect histogram data for each weapon swing, damage done, etc. Do this by allocating an array (or list backed by an array) where each integer value amount is in the index into the count. Graph those values.
• Allow entry of a seed value in the random number generator so combat results can be regnerated. Include the seed in the combat results.
• Use a Mersenne Twister instead of java.math.Random generator to guarantee equivalent results given the same seed between versions and platforms of the API.
• Write log entries to disk.
• Allow the users to tag and save runtime configurations.
• Allow the user to add or remove parts of the combat (such as disabling dodge).
• Add new combat defenses (such as parry and block).
• Support more than one attack type.
• Assign attack types to each attacker.
• Give each attacker attack type selection logic.
• Support more than two attackers and support target selection logic (and designation).
• Refactor the combat logic to include genericized metrics collection (rather than specific to the Combat Sim class).

It’s a hell of a lot to go through for a combat simulator, but in the end I should be able to calculate combat results that would be similar to what could be expected in a completed multiplayer game. Additionally, the creation of target and attack selection logic, much like the core of the combat simulator, should be portable to the real game and will result in a savings in development and testing time later. It would be nice to essentially be able to drop combat logic into the game and know that it will generate the results I expect.