I make apps for other people

Design Journal

CombatSim 0.0.3 update (in progress)

Posted by Chris Jones
On May 31st, 2007 at 15:38

Permalink | Trackback | Links In |

Comments Off on CombatSim 0.0.3 update (in progress)
Posted in Design Journal

Update on my progress (occasional on the bus work):

  • Refactoring: combat core broken out into its own class, combat configuration and metrics independent classes
  • Importantly, metrics are considered a first class entity and can be used to ad-hoc storage of performance values
  • Identifiable: interface that indicates something has a unique ID in the system
  • This is beginning to resemble the core of a real working system rather than a demonstration of a combat simulator front end.
  • Supports shared and private combat cores. All combat stores metrics at this time, which is excellent from a design point-of-view. Validation of game design takes place as the game is played.

LEDOs revisited

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

Permalink | Trackback | Links In |

Comments Off on LEDOs revisited
Posted in Design Journal, Games

Presupposing a virtual world like Second Life where users can create content, I gave some thought to this a few years ago. LEDOs seemed to me to be a solution. Originally, I believed the LEDOs would be signed and self-authenticating, and should not rely on a central server (which may mean that at the least, each client has a CA cache). However, for auditing purposes, they need to phone home.

This requires a different kind of infrastructure, one in which signed code or LEDOs can’t be copied. CopyBot showed that even this model is threatened.

Now, I’m leaning more toward the LEDO only being visible to other users when the users can verify that the LEDO is legitimate. That means that the LEDO needs to point to its authority (which gives a record of who is using it and how many impressions it makes) or the LEDO points to a proxy for the authority. An attack on this would probably take the form of blackholing the legitimate authority and pointing to a proxy that verifies the LEDO. I imagine that the LEDO should only be visible and active to other users if they receive a key to execute or unlock the LEDO, which combined with watermarked or stegongraphic LEDOs should limit the total number of exploits.

LEDO: contains an encoded pointer to its authority
Viewer: the LEDO attempts to display or execute code, but the viewer won’t do so without a key to unlock the content (this may mean the LEDO only has part of the code or is encrypted)
Authority: verifies the user with the LEDO, the LEDO’s signature, and the viewer and constructs and sends a one-time use key to allow the LEDO to execute
Proxy: a backup authority, used when the authority times out or is too far


  • compromised client accepts all LEDOs — this would likely be suicidal. Imagine LEDOs that are malicious and send bad code to all-trusting clients.
  • LEDO with mangled signature or authority — essentially a copy. The trick to securing the LEDO is making the LEDO incomplete without something from the real authority. Code that permutes over time? Encrypted code, textures, and models that only unlock with the correct holder, time, and public signature?
  • compromised proxy or proxy that always returns “Yep, it’s legit.” Avoid this by, again, using a key that only legitimate authorities and proxies can generate.
  • in memory copy. This is tougher. The structure of the LEDO would have to have the authority burned into it through something like steganography. This means that copies should still carry the authority, while copies should either not function or should obviously have errors or “holes” where the authority encoding was stripped or replaced. I assume that if a LEDO was broken down to its base elements (code, textures, models, animations), it could be rebuilt as a knock-off. Without total control (c.f., Sony Home) I don’t see how Louis Vutton or Calvin Klein can sell LEDO clothes without knockoffs appearing.

I’m trying to avoid DRM, even if the solution starts to look like it in the end. Is there a way to do this without something like DRM?

CombatSim 0.0.2

Posted by Chris Jones
On May 24th, 2007 at 22:26

Permalink | Trackback | Links In |

Comments (2) |
Posted in Design Journal, Java

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.

CoV issue 9: first thoughts

Posted by Chris Jones
On May 22nd, 2007 at 10:25

Permalink | Trackback | Links In |

Comments Off on CoV issue 9: first thoughts
Posted in Design Journal, Games

My wife picked up City of Villains again over the weekend (LOTRO’s travel times were annoying her, and she made her first retail character broke by level nine because she used horses to get from one end of the Shire to the other). This was soon after Cryptic’s City of Heroes Issue 9 patch. We play the City of Villains side, so my terminology will be slanted toward that side.

Auction House
The Black Market has some great features, including recent sales of the item and how much was paid. What’s missing (and was available through add-ons in WoW) are the prices NPC Quartermasters will pay.

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

Not killing each other fast enough

Posted by Chris Jones
On May 17th, 2007 at 11:38

Permalink | Trackback | Links In |

Comments Off on Not killing each other fast enough
Posted in Design Journal

I’ve been tweaking my CombatSim (mostly on bus rides, with a little evening work at home) to get histograms and graphs integrated.
Too slow to die
What should be obvious is that the actors (random stats for each round) are generally doing too little damage to each other to make the fights of reasonable length. Over 10,000 fights to the death, it looks like the tail of attacks count stretches too far. While the average (21.91 for both actors) hits per round is reasonable, in many cases the fights last too long.

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.

Good point on averages

Posted by Chris Jones
On May 10th, 2007 at 21:08

Permalink | Trackback | Links In |

Comments (1) |
Posted in Design Journal

If you play with my CombatSim, you might notice that a lot of the statistics are averages (especially if you read through the source in the JAR file . . . you did unpack the JAR file and look just because, right?). Darius of Measuring Gameplay says that I should be collecting better data, that Averages Suck when developing metrics.

Now, here’s a good question for the peanut gallery: assuming I want to build histograms of activity (and I don’t want to capture every combat but want summaries of all 10,000 combat runs), what’s the best way to build the histogram? Create an array or list of results and iterate across those? Or is there a smarter way to capture that data without resorting to a data structure, some neat math hack where I can shortcut around allocating big chunks of memory to analyze combat results.

Edit: Here’s a hint. Consider that there aren’t 10,000 unique results. Say that I’m collecting damage per hit for an actor–I have a range of damage, of which each point in that range can have a count of times that the damage roll happened. My data set then goes down to a reasonable size. Use an array to represent the histogram.

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

Link to Raph’s UO Resource System

Posted by Chris Jones
On May 10th, 2007 at 14:00

Permalink | Trackback | Links In |

Comments Off on Link to Raph’s UO Resource System
Posted in Design Journal

Raph Koster was kind enough to repost his UO resource system write-up, long lost (and missed by me as reference material)–of course he did this in June 2006 when I was concerned with things like interviewing for a new job.

UO’s Resource System (part 1)
UO’s Resource System (part 2)
UO’s Resource System (part 3)