I make apps for other people

Design Journal

It’s elementary

Posted by Chris Jones
On August 7th, 2009 at 16:37

Permalink | Trackback | Links In |

Comments (1) |
Posted in Design Journal, Games

I’ve been considering what would make a good, unique quest. Putting aside Becky’s concerns about griefing, competition for mobs or clues, etc., and that this is intended for a text game (although it would work in a graphical game), I’ve got the skeleton of a design for generating mysteries that I’d like to try to implement sometime.

We’ll call it, for lack of a better term, Mystery Quest.

One outstanding question remains: do you believe players need feedback when collecting correctly clues, interviewing witnesses, and assembling evidence?

Mobile HTTP clients

Posted by Chris Jones
On December 30th, 2007 at 11:59

Permalink | Trackback | Links In |

Comments Off on Mobile HTTP clients
Posted in Design Journal

Mobile clients have several limitations:

  • small screen size
  • network latency
  • poor, limited, and unreliable connectivity
  • severe memory and script execution speed or time restrictions
  • input restricted to (slow) text entry and click-only (no drag, no mouseover)

…in addition to browser limitations. The best browser for mobile web applications at the time of this writing is Safari on the iPhone.

Some of these can be addressed through careful design of the user interface.

Band aids? Upfront process and design are better

Posted by Chris Jones
On December 29th, 2007 at 10:37

Permalink | Trackback | Links In |

Comments Off on Band aids? Upfront process and design are better
Posted in Design Journal, Tech

From Zubon of Kill Ten Rats:

Fixing the fundamental only gets worse once you already have a dozen band-aids on the wound. You must tear them all off and throw them away. But at least you get to do all those things you wanted to do if you had it to do over again.

And this is why we Unit Test.

Games that ship and have few bugs have well developed and scrupulously followed development processes. Games with bugs just get shoved out the door because scope creep and featuritis are given more importance than good project management. And for one-off, traditional single-player games, it wasn’t so bad, especially when the game developers were also designers and a four person development team was big. Check out High Moon Studios’ “Day in the Life” seminal article on SCRUM and Unit Testing a modern console game.

An MMO is more like a corporate ERP system than a Pac-Man or Tetris clone, and cutting corners to hit deadlines or out of sheer laziness (and believe me, programmers are lazy–it’s a virtue) helps create emergent behavior or bugs. Strong, comprehensive Unit Testing at the cost of adding dubious features to still meet the development schedule is the best defense against this. The Unit Test becomes a kind of document, an artifact that demonstrates how the developer believed the code was to be invoked and what it should return, and future changes against the code can be verified with execution against the entire suite of Unit Tests. The designer, developer, and producer will sleep well at night knowing that the vision has been translated to code or scripts accurately.

Mockup in progress

Posted by Chris Jones
On December 28th, 2007 at 17:49

Permalink | Trackback | Links In |

Comments Off on Mockup in progress
Posted in Design Journal, Tech

Demo in progressAn iPhone web app mockup

Supposedly (I’ll have to test this at home) it’ll display without the iPhone graphic framing the content on a real iPhone. I’m not sure that I understand logic in CSS files well enough to guarantee that.

Does anyone have a lead on good tilesets for demos or mockups, game oriented (I don’t care about the theme, as long as people look distinctive and there’s a little bit of furniture or props available), around 20×20 pixels? I don’t want to make a smiley demo.

Note that I don’t have any of the Javascript hooked up for this, and I’ve only tested it under Firefox (so far).

Edit: The media tag didn’t work as I needed it to–I could restructure the CSS and probably fix it under the iPhone so that the fake iPhone frame won’t show up. Internet Explorer 6, on the other hand, can’t render it properly in any case: problems with DIV tags, or so it looks.

Designing for the iPhone could be a full time job

Posted by Chris Jones
On December 28th, 2007 at 12:36

Permalink | Trackback | Links In |

Comments Off on Designing for the iPhone could be a full time job
Posted in Design Journal, Tech

Check out Apple’s iPhone Safari Web Content guidelines (PDF, 6.1 MB) for some ideas about why iPhone web page development is different from typical web page development. A lot is the same: CSS, layout and positioning, XHTML and standards, etc. Some is different, like a META tag that defines the viewport size. And some new page events are generated, like onorientationchange–and there’s a hell of a lot you simply can’t do. It makes you, as a web application designer or developer, think hard about the interactions you plan on using and consider if they’re necessary or other ways that they can be done. And as a web app developer, you’re suddenly thinking about minimizing content sizes again and keeping an entire page under 30 MB, stripping unnecessary whitespace, and optimizing for a relatively slow 100 Kbps EDGE connection with 500 ms latency (since your users won’t always be using WiFi).

onorientationchange is going to require an additional 30% or more work for designing the page layout.

Here’s a thought for budding iPhone web app developers to mull on:

The finger and tap interface isn't the same as using a mouse

Thoughts about mobile and multiple client type gaming

Posted by Chris Jones
On December 27th, 2007 at 15:52

Permalink | Trackback | Links In |

Comments (2) |
Posted in Design Journal

I identified several components as being critical to enabling mobile multiuser gaming through an HTTP interface (such as an iPhone). I assume the mobile device is capable of CSS and Javascript/AJAX and presents a standard DOM.

Based on my experience with T-Mobile’s GPRS system in Seattle, I assume that HTTP over GPRS, EDGE, or 3G is unreliable. My wife’s experience with AT&T’s EDGE service with her iPhone has been much more positive, but this could be because of the flexibility and reliability of Safari over Windows Mobile’s Internet Explorer. In any case, I have to assume the worst.

Flatten those levels

Posted by Chris Jones
On August 23rd, 2007 at 20:15

Permalink | Trackback | Links In |

Comments (1) |
Posted in Design Journal

Playing City of Heroes with the Giant Monster code gave me some inspiration about how to make a level-less system play like a leveled game. Ignoring the ground-breaking sidekick and exemplar mechanics, how can players of disparate levels cooperate against foes, and can this be expanded to the entire game?

Flattening levels is almost entirely dependent on scaling. A low level character is hit by the monster for 5% of his hit points just like a high level, before resists and mitigation. However, a high level character has 500 or 1000 hit points available, while a low level has 100 or 150. Likewise, damage done by the player against the monster must scale: to the high level, the monster has 2000 hit points, while to the low level, it’s more like 200.

A high level still kills it faster because he’s specialized or has (in general) more and higher damage attacks. A low level, used to fighting mobs with low pools of hit points, may only do 10 hit points per attack against mobs of 70 hits (roughly 14%) while a high level may do 200 hit points against a mob with 2000 hits (roughly 10%)–the damage output of players can’t scale the same way monster attacks do or else groups would be zergs of low level characters. Assume scaling based on specialization or customization of the character, plus an inherent bonus based on level, such that the low level does 3.5% or 5% damage while the high level keeps the relatively powerful 10% figure.

Formula and proof of concept later.


Posted by Chris Jones
On June 22nd, 2007 at 15:41

Permalink | Trackback | Links In |

Comments (2) |
Posted in Design Journal, Java

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!


  • 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


Posted by Chris Jones
On June 7th, 2007 at 09:39

Permalink | Trackback | Links In |

Comments Off on CombatSim-0.1.0
Posted in Design Journal, Java

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.
CombatSim-0.1.0 on Linux
One last word: this combat engine is the most primitive version of the engine I plan on using in my next development project.

CombatSim 0.0.3

Posted by Chris Jones
On June 5th, 2007 at 18:19

Permalink | Trackback | Links In |

Comments Off on CombatSim 0.0.3
Posted in Design Journal, Java

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.


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.