Categories
Design

Hack100: Release Version vs Original Design Aims

I came into this project with a reasonably clear idea of what I wanted to achieve. Frustrated by the complexity of the most recent versions of my favourite d100 systems (most notably Warhammer Fantasy Roleplay and RuneQuest), my objective was to compile a stripped-down d100 system that would allow me to adventure in those worlds with a minimum of in-game rules referencing.

With that overarching aim in mind, I set myself ten design goals for Hack100 back in a blog of March 2020. Here I’ll review the final product against those original ambitions.

1. A d100 system

We’re off to a good start.

2. A small number of character attributes and skills

This design aim was in reaction to the most recent version of RuneQuest and its 4-page, 70+ skill character sheet. As I discussed previously, both RuneQuest and WFRP have exhibited a significant creep in their number of skills over successive versions, with (in my opinion) little benefit. My original target for Hack100 was to have less than 15 skills. I lost a couple along the way (“Arcane” and “Spiritual”) to end up with just ten core skills (termed “Abilities”) plus a small number of “Specialisms” or “Powers”. Abilities cover the most common in-game actions. Specialisms and Powers provide character differentiation. I dropped separate attributes (e.g. 3d6 for Strength, Dexterity, Constitution, etc.) entirely.

3. Quick character generation

Ten minutes was the target. I think this is achievable in practice. There are just six steps: (i) write a single sentence to describe the character’s Background and Motivation; (ii) roll the ten Abilities; (iii) choose a Specialism or Power; (iv) determine Health; (v) select equipment; and (vi) name. The big time-savers are the Background and Motivation sentence (which tells you a lot about a character in a very efficient way – thanks OpenQuest!) and the freeform approach to starting equipment and encumbrance (no poring over equipment lists and totting up expenditure and weights).

4. Quick combat

The aim was that it should take approximately five rounds to resolve a typical fight. Despite the simulations used to fine-tune the combat system, this is probably the aspect of Hack100 that would most benefit from further playtesting and feedback. The simulations were rather basic. They simply modelled two combatants taking turns to hit one another. What the simulations didn’t capture, and what happens in a real game, is the unpredictability that arises from multiple players when they get creative. I’ve not seen any major problems in my games, but it would be reassuring to get wider feedback. Particularly regarding the quirk that some of the biggest damage arises from wild swings that the target fails to parry or dodge.

5. A skill-based, resource-constrained magic system

At the start of this project, I wasn’t looking beyond fantasy games, which is why this design aim was worded in this way. However, once it became clear that the freeform, negotiated approach to spell casting would be equally well suited to wider types of “Power”, I dropped the exclusive fantasy focus. I also like that Powers deplete Health directly rather than a separate pool of power points. It makes the draining effects of Powers more meaningful. Their use becomes a tactical decision with consequences, hopefully preventing them from dominating and unbalancing a game.

6. Character progression through the use of skills and training

Here I stuck with a traditional experience check system. The only thing I considered was the frequency of such checks. I have always found end-of-scenario checks too infrequent. I like to see more regular progression in characters. Therefore I went with end-of-session checks. I added improvement through training as an optional rule.

7. No complicated maths

The most involved calculation in the game is probably for combat Damage:

Damage = Tens die of the Task Roll + Weapon Damage Modifier +Armour Damage Modifier

This doesn’t seem too onerous. Optional rules for Advantage and Disadvantage even remove the need for any Task Roll Difficulty Modifiers.

8. A minimum of reference tables

The only table that might be referenced in-game is that for Task Roll Difficulty Modifiers. However, even this can be replaced with the optional Advantage and Disadvantage rules.

9. A concise ruleset

A maximum of 32 pages in a digest format was the original target. If we ignore the covers, then I achieved this. The core rules are only 26 pages, with the optional rules occupying a further six. Furthermore, I’m very happy with the layout. Although the rules are short, the presentation is clear and nothing feels “squashed”. The Old School Essentials inspired presentation was a big part of this.

10. Only uses d10s

A slightly arbitrary design constraint. However, I don’t feel that it compromised any aspect of the rules.

On Non-Player Characters

Going into the project, I hadn’t considered how to handle non-player characters and, specifically, monsters. I had probably assumed that I would include a simple monster list in the same way as Whitehack. However, having written the “toolkit” approach to Powers, which removed the need for spell lists, it became apparent that a similar approach could work well for NPCs. Furthermore, by incorporating the “Background and Motivation” element of player character creation, there was the opportunity to root NPCs much more firmly within an adventure or game world than if plucked from a generic list. Hack100’s methodology for creating bespoke NPCs is one of the features that I’m most pleased with, even though it wasn’t something I had considered at the outset.


Overall, I’m satisfied with how the final version of Hack100 stacks up against the original design goals. What also worked well for me was the blog-by-blog approach to writing it. By breaking the development down into small chunks with no time pressures, the project remained manageable whilst retaining a sense of progress.

Now, I just need to decide on my next project …

Leave a Reply

Your email address will not be published. Required fields are marked *