Today’s article was directly inspired by a call for opinions at Moebius Adventures, “Infinity Loop: Endeavors New and Old” which came to my attention as a result of my review of the One Spot products last month (Places to go and people to meet: The One Spot series from Moebius Adventures). The subject is lists – in general and as gaming products…

List don’t come naturally to me. I’ve learned to work with them, and even to do some nice tricks with them, but it isn’t instinctive.

Some people can toss together a list or three, fill a one-page RPG supplement with them, and have something ready to publish; my lists always seem to be a small paragraph each and sometimes a not-so-small one. In a nutshell, I think in prose, not in bullet points.

Things like Johnn’s lists of character seeds – for example, 63 Wizard Hooks – I have a lot of trouble creating. When confronted by such a challenge, as I was when generating the plot hooks for Assassin’s Amulet, my first thought is to create a generator that creates the seeds, rather than creating the seeds directly. In fact, that’s exactly what I did. (You can read a hand-chosen fifty hooks excerpted from the complete list of 125 here: 50 Assassin Hooks). (No, I don’t intend to share the details at this time – but I might start using it to generate character seeds and extend that series. I’ve actually been holding back on that so that I can use the generator to populate plot lists for sequels to Assassin’s Amulet).

But it’s not just in creating these lists that I have problems, it’s in using them. There are four major problems to be overcome, and while I have answers to some, I’m not sure that they are all even capable of solution.

The four problems that are the heart of today’s discussion are:

  • limited entries
  • entry depletion
  • redundant effort requirements
  • format limitations

(I’m resisting the urge to define each of these within the list, turning them into paragraphs. Like I said, it doesn’t come naturally to me. And don’t get me started about the irony of using lists in an article about the difficulty of using lists….)

Limited Entries

If you have a list of ten items, that’s all you have. Once those ten are used, the entire list becomes obsolete. If you don’t like any of the entries, those are essentially crossed off the list already. The only real solution to this is to make the list longer – much longer – but that imposes it’s own problems.

Entry Depletion

This problem manifests in another way when you attempt to use the list as a table from which entries are randomly selected: there are finite odds of getting the same result more than once. The shorter the list, the more likely this eventuality. Such lists are frequently touted as a source of inspiration to be employed when your own imagination fails to fire – how stimulating is it if the same entry comes up time and time again?

Of course, you can always re-roll – but that means recognizing that you have already used this result (perhaps quite a long time ago) and that you need to generate a new result.

Solution: All such tables should come with a checkbox so that the user can cross it or tick it or something when an entry is used, if a more complex solution isn’t employed.

Redundant Effort requirements

Things get still worse if the list is not intended to be used as a random generator, but to be cherry-picked for ideas when you need them, because every entry needs to be re-read each time you employ the list. You can cut down on the redundancy using a checkbox, but the longer the list, the more redundant effort is involved.

Various procedural approaches are possible – starting your reading at the last entry you’ve actually used, as indicated by the checkbox, for example – that reduce this overhead, but they don’t eliminate it.

A technological solution is possible, at least theoretically, which “hides” entries that are unsuitable or used – and, of course, you would only read as far as you had to in order to find a solution to whatever conundrum of creation the list was being employed to solve. It’s even theoretically possible to have the table recalculate the roll required by not enumerating as part of the list any “hidden” entries – okay, so who’s got a d37 up their sleeve?

But GMs are used to solving such problems, and furthermore, modern technology makes the problem itself go away – using a service such as AnyDice or something similar means that it’s not a problem. “2971, 438, 1110, 2757, 1960” – the first 5 results from rolling a d3141. Not a problem.

But you have to employ this solution every time – and that’s another redundant effort.

What’s needed is an entirely different approach to the usage of lists – a technique where it doesn’t matter if you roll a “six” three times in a row on a table with 10 entries.

I just happen to have one handy.

The Zwicky Approach

Johnn actually came up with it in his Political Plot Generator (I’ve Been Framed), but I had already employed the same approach in another context, which I’ll get to in a little bit.

The principle is to use cross-referenced and nested tables to vastly increase the number of combinations of the output result to such an extent that uniqueness of result is almost a certainty.

Picture a table with twenty entries. Before you actually get an outcome from the tables, you have to make a roll on a second table whose result puts the first one into context. If that second table also has twenty entries, then for the price of two twenty-entry tables, you have 400 possible outcomes. Add a third, and for the effort of creating sixty table entries, you have a whopping 8000 possible results. A fourth yields 160,000 possible outcomes.

With so many outcomes possible, it doesn’t actually matter what you roll, and whether or not you have rolled it before – the odds of the outcome being the same are so remote as to be nonsensical. You don’t need checkboxes. You don’t need to employ redundant effort to use the tables, either – you simply look up your four rolls and go directly to the unique outcome. If the result doesn’t suit – roll again. Some entries may have sub-rolls buried within them.

This is an example of using rolls on a table as the indices of a
Zwicky Morphological Box. I’ve mentioned these before, in the context of determining the optimum construction path for a 3.x character (The Power Of Synergy: Maximizing Character Efficiency), in the section “One structure to rule them all” about 3/5 of the way through the article.

All that we’re doing is altering the format of the output to conceal the fact that we’re talking about a morphological box.

The Zwicky Approach II: The TORG character generator

I mentioned in passing the course of the celebratory milestone article, The meaning of 400, that 400 was one-fiftieth of the number of NPCs I created using a random NPC generator that I wrote for Torg. This is another example of the same type of solution, and really illustrates the power of the concept.

It’s easy to write a character generator using BASIC (or just about any other programming or scripting language, for that matter). Roll 3d6 for each stat, roll 1dN to choose character class, and so on.

It’s quite another to write a smart character generator that produces interesting and consistent ready-to-use characters every time, with all the attendant complications. That was the task that I set myself, many years ago (the late 1990s, I think). Here’s an actual entry from the output, chosen at random:

378  DEX: 8  STR:11  TGH: 6  PERC: 8  MIND:12  CHAR:11  SPIR: 7   Possibilities:12   Reality (SPIR)+3=10/-   Corruption+6=13/-   TAG: Science (MIND)+4=16/-   DEX: Melee Weapons+1=9/- Unarmed Combat+2=10/-   STR: Climbing+2=13/-   PERC: Trick+1=9/- Water Vehicles+3=11/-   MIND: Apportation Magic+1=13/- Artist+1=13/- Test Of Wills+2=14/-   CHAR: Persuasion+1=12/- Personality:  Primary: pansy Secondary: arguementative Tertiary: extreme

Here’s what’s so clever: the generator used a couple of randomly-generated unofficial meta-characteristics: “focus” and “expertise”. The first described how likely the character was to have a skill outside of their core expertise (i.e. how much of a jack-of-all-trades they were), and the second described (in broad terms) how good they were at their core expertise, the “Tag skill” (you don’t need to know the Torg rules for this).

The core skill was then randomly chosen from the full list, sometimes with sub-lists for specialties within the field, the stats were randomly generated and intelligently allocated based on “expertise” and the characteristic on which the tag skill was based, then on appropriate patterns, from high-to-low, weighted by the “focus” meta-characteristic.

Probabilities were then assigned to every other skill, based on those meta-characteristics, intelligently weighting them from a zero (the character will never have this skill) to 100% (this character will always have this skill). A skill table was then automatically compiled, with as many subtables as necessary, to reflect these scores. Each skill carried modifiers to subsequently probabilities – so if a fighter-type went down the path of archery, he was less likely to study heavy armor, and so on. A skill was then randomly chosen from this table, the table itself modified as a consequence, and a new skill chosen. Each random “choice” more closely restricted the options available to the character to produce intelligent, consistent choices – with the occasional oddball curve thrown in.

Something akin to the “Skill points” of 3.x were used to keep track of how many skill points the character had. These were intelligently allocated based on the meta-characteristics, established skill levels, and effective skill totals – and weighted according to the order of selection of the skills. So you could get a character who was an excellent soldier and an accomplished painter, with a background in farming – or, in this case, a sailor who uses Apportation magic, but whose first love is some form of science. The dominant characteristic, “pansy,” makes him unlikely to be a mission commander or ship’s captain. The secondary characteristic, “argumentative” has to be resolved within the context of the primary – perhaps he’s argumentative about his research (his chosen field of expertise) but meek and mild outside of it? The third personality trait, “extreme”, could be interpreted to mean that he routinely goes too far when his argumentative characteristic is triggered, or that he’s extreme in some other respect like personal hygiene.

Finally, an independent personality generator was used to create the personality profile at the end of the entry.

In essence, the system grew a unique character generator for each character based on the three primary values – what the character was good at, how good at it he was, and what else he was interested in – then threw it away and started anew for the next character.

The really, really clever part was that it also compiled an index of characters – this was character #378 – according to the chosen Tag skill – so to choose one, I simply had to decide what one skill I wanted this character to be good at according to the in-game situation at the time. Five seconds later, or less, and I had the character profile in front of me, ready to go.

And yet it was all composed of lists and tables, and the only intelligence in the system was in the design, for all that the characters it produced had logical themes and avoided illogical faux pas.

Getting Back To The Subject

Using lists that compound to produce many different outcomes in some sort of intelligent manner doesn’t require sophisticated programming, Johnn’s article proves that, and it solves the first three problems with Lists as gaming products very nicely indeed.

I guess what I’m really saying is,

Make the lists more than the sum of their parts.

Format Limitations

By far the biggest limitation that List products face is that of perceived value – which is such an important subject that I wrote a two-part article addressing it a while back (Value for money and the pricing of RPG materials – Part 1 and Part 2).

As soon as I see a game product described as a “list”, all those limitations described above come to mind, and they all reduce the perceived value-for-money of the product. Once again, the Zwicky proposal of interrelated and interwoven nested tables comes to the rescue, with a simple stratagem: don’t describe it as lists, or tables. Describe it as a System, or a Generator, or, in fact, anything but a list or table. Design and create it with this goal in mind and you avoid all those negative connotations while implying additional value that makes a sale more likely to result.

Of course, all this is my personal opinion. Others may be attracted to the simplicity of the list/table format. Would I buy a product which was a list of 1,000 ready-to-use NPCs? Depends on the price, but very probably. So the deficiencies – perceived or actual – of the list format can be overcome; it’s all a question of effort and inspiration. Having a generator that made your lists in your back pocket and only selling the product of that generator is definitely the way to go – if you can pull it off.

Related Posts with Thumbnails
Print Friendly