An off-hand discussion at work (“This application is being used by more groups now . . . wouldn’t it be cool to make it so they can develop independently?”) led to me looking into Java classloaders this weekend. Here’s the core for an application that’s treated like a bus in that it looks to see what’s plugged into it and provides communications (context) to each plug-in.
(more…)

I’ve dealt with Java services at Amazon too long when I can spot one by the CPU/memory signature.

This is pretty typical of a long-running service garbage collecting with old generation objects. Note the CPU utilization as the VM removes old generation objects and subsequent drop in memory utilization.

B: size of the buffer
K: number of items having distinct access probabilities

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

CombatSim version 0.3.0 is now available. This is still considered alpha quality, although it has undergone some testing.

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

CombatSim-0.1.0 is a bug-fixed re-release of 0.0.3. Elapsed combat time calculations are correct, as is effective DPS calculation. The code has been refactored (since 0.0.2) to facilitate reuse in a real game, albeit a trivial one given the state of the combat core, and the overall sim is ready for the next set of enhancements, including n-attackers and multiple combat skill use. Later, I’d like to add the capability to define your own combat rules (within the data structures the sim provides).

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.

A new (buggy) version of CombatSim. This one has some combat tuning problems (specifically when actors are very imbalanced in stats) and doesn’t as strongly check for bad rounds (combats that take too many rounds).

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.

Written on buses and during the occasional evening, CombatSim 0.0.2 is ready for your use. It requires Java JRE 5.0 or higher and must be uncompressed into a folder before it can be used. CombatSim can be started by either double-clicking the batch file, or from the command line with (roughly):

[Win32]    C:\CombatSim-0.0.2> CS

This version adds histogram support, writing CSV files of the results, and saving settings between runs. It is in no way completely tested, so consider it of alpha release quality.

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.

The development version of CombatSim writes CSV files. It’s not terribly particular about where it puts them, but it tries not to clobber data. At this time, it generates:

• 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.)

Use Case: divert specific log messages while capturing all other log messages. Errors that happen because of a bad RSS feed or connection problem should go to a specific log, while program errors should continue to go to the existing log files.

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).
(more…)

If you haven’t tried out my CombatSim statistics generating program alpha release, feel free to download it an give it a try. All the source is inside the JAR.

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.