I make apps for other people


CombatSim update: CSV files

Posted by Chris Jones
On May 18th, 2007 at 14:41

Permalink | Trackback | Links In |

Comments Off on CombatSim update: CSV files
Posted in Design Journal, Java

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

Log4J lesson learned: working around a greedy logger

Posted by Chris Jones
On May 14th, 2007 at 15:13

Permalink | Trackback | Links In |

Comments Off on Log4J lesson learned: working around a greedy logger
Posted in Java, Work

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.

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

CombatSim todo

Posted by Chris Jones
On May 13th, 2007 at 21:02

Permalink | Trackback | Links In |

Comments Off on CombatSim todo
Posted in Design Journal, Java

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.


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

Tune my combat design

Posted by Chris Jones
On May 10th, 2007 at 20:25

Permalink | Trackback | Links In |

Comments (3) |
Posted in Design Journal, Java

I’m ready to release a buggy version of a combat simulator between two combatants. This is intended to allow me to test assumptions about combat, DPS, hit rate, how long combat should last, what the effective DPS of the participants is, etc., and to perform it over a large number of iterations. To get good and consistent numbers, especially when modelling different kinds of attackers, turn off random actors.

Dowload CombatSim-0.0.1.jar now! (41 KB)

Again, this isn’t without bugs (there is no field validation, for instance), and it’s missing key features (like saving settings, or creating log files and CSV files for spreadsheet import, or using more than one type of attack for combat participants) but it’s enough to give you an idea of how it will work. You can really hose yourself by doing things like making it impossible to hit (and I didn’t give you any way to stop the run short of shutting down the program) or putting in too many iterations.

You’ll need a recent version of the Java JDK or JRE (1.5) or higher. If you’re not a developer, get the JRE.

Once Java is installed, invoke the JAR by double clicking or from the command line with java -jar CombatSim-0.0.1.jar and have fun. If you have any ideas for additional types of combat data I should capture, please let me know.

CombatSim 0.0.1 screenshot

Darkstar: not yet

Posted by Chris Jones
On March 23rd, 2007 at 11:39

Permalink | Trackback | Links In |

Comments (1) |
Posted in Games, Java

Sun’s Darkstar looks promising, but I’m not going to touch it yet. Until it’s under a less burdensome license, I’m loathe to look at it which is very, very unfortunate. I’m certainly not going to deploy it to any boxes I own because of the risks of the commercial license.

Wake me up when it’s open sourced and unrestricted for use. It would be nice to be able to stop mucking around with optimizing server internals and concentrate on developing a game.

Service framework

Posted by Chris Jones
On December 28th, 2006 at 18:30

Permalink | Trackback | Links In |

Comments Off on Service framework
Posted in Java, Tech

I’ve been mucking around with a simple Java based service framework. Configuration is done from a simple (if verbose) XML file when the service is created.

ServiceManager.jar (71k)

This is intended to be used in an system that manages multiple services and provides a base implementation for configurable services. Later, the base service should support remote management.

Why Java and not Python or C#? Execution speed, portability, and that I have an annoying tendency to like statically typed languages. I find it’s harder to verify all execution paths in a dynamically typed program because the compiler won’t catch many runtime type errors. Has anyone found a good solution for that? The biggest problem with C# is that I don’t feel like I have a good development environment on each machine I use. Ironically, Amazon’s laptop has the worst: because I don’t have admin rights, I can’t install a C# IDE.

Shutdown and signal hooking in Java

Posted by Chris Jones
On December 9th, 2006 at 22:33

Permalink | Trackback | Links In |

Comments Off on Shutdown and signal hooking in Java
Posted in Java, Tech

To catch Java VMs when shutting down, you can hook the runtime shutdown process with a custom thread implementation. You can also register signal hooks (like catching HUP) to add behaviors like reloading configuration files, etc.

// register the shutdown hook
Runtime.getRuntime().addShutdownHook(new Thread() {
    public void run() {
        logger.log(Level.SEVERE, “Caught shutdown hook on server.”);
// register the interrupt hook (in Win32, this is CTRL-C)
Signal sigInt = new Signal(“INT”);
SignalHandler sigIntHandler = new SignalHandler() {
    public void handle(Signal arg0) {
        logger.log(Level.SEVERE, “Interrupt signal caught.”);
Signal.handle(sigInt, sigIntHandler);
// register the terminate hook (in Win32, close console window)
Signal sigTerm = new Signal(“TERM”);
SignalHandler sigTermHandler = new SignalHandler() {
    public void handle(Signal arg0) {
        logger.log(Level.SEVERE, “Terminate signal caught.”);
Signal.handle(sigTerm, sigTermHandler);

Improved JVM forking

Posted by Chris Jones
On November 2nd, 2006 at 17:48

Permalink | Trackback | Links In |

Comments Off on Improved JVM forking
Posted in Java, Tech

I’ve beaten JVM forking into submission and discarded this (generic) version of the code for something more appropriate for Amazon’s libraries. In particular, I needed to integrate with a class that would start and wait for external batch processes–I refactored the class so it has both blocking and asynchronous launch methods.

StreamEventListener.java listens for STDOUT or STDERR text. ServiceRunner.java starts and manages forked processes (like a teeny-tiny J2EE container without any knobs for fiddling and tuning).

Forking a JVM

Posted by Chris Jones
On October 26th, 2006 at 17:34

Permalink | Trackback | Links In |

Comments Off on Forking a JVM
Posted in General, Java

It’s not literally forking, unfortunately. What it is instead is a way to invoke another Java server that (because of various reasons such as conflicting static members or classloader issues) runs inside another managed process. The difference between this and a real J2EE server’s container is that I’m not my bidirectional communication and control is gross, on the order of watching what’s going on in the child process and only being able to tell it SIGKILL.

This is a very rough first pass but might save me (or someone else) time in the future if they need to implement a forking Java server, or (as in my case) they need multiple servers to complete a complex unit test. I used the Java2Html Eclipse plug-in to generate the prettified source.

Stupid C++ newbie mistakes

Posted by Chris Jones
On October 24th, 2006 at 17:41

Permalink | Trackback | Links In |

Comments Off on Stupid C++ newbie mistakes
Posted in Java, Tech

I’m refreshing my C++ skills and had a fun “duh” moment this afternoon. Thankfully, this only locked me up for 45 minutes before I clued into the solution. It might help if you know what OCCF means for a C++ developer.

Below are fragments of the code I used to write practice classes and tests.