Designing a Random Table Generator

[Morrus]

Yup, it's not a random table, it's a generator of random tables. Lemme explain.

It's a system whereby random generators are crowdsourced. NPC generators, random encounter tables, name generators... and they can all be mixed and combined easily to create bigger more complex generators.

Any member can create tables. These may be simple, such as:

EVIL DRAGON COLOURS
d6
1: Red
2: Green
3: Blue
4: Yellow
5: Black
6: White

Or they may be more complex. Basically, they define the random roll and what each roll outputs.

That's the easy bit.

Next, all tables are saved with a name. Any member can then reference any table. A table can reference another table.

So you could have a second user creating a table of GOOD DRAGON COLOURS, which might look like this:

d6
1: Copper
2: Bronze
3: Silver
4: Gold
5: Brass
6: Platinum

So two member have separately created two tables.

Now a third user might want to create an ANY DRAGON table. And since two members have done the work for him, he simply creates a table which is:

ANY DRAGON
d3
1: [EVIL DRAGON COLOURS]
2: [GOOD DRAGON COLOURS]
3: Tiamat

This tells the system to roll d3, and then use the indicated table. Unless it rolls a 3, in which case he gets Tiamat.

So that's a very basic example. But it naturally scales up to the point where a member can create a vast, complex network of tables which could generate detailed room descriptions, or NPC descriptions. From a basic such as:

[FIRSTNAME] [LASTNAME] is a [GENDER] [RACE] of [AGE] age.

(Could output to: "Bob Bobblehat is a male dwarf of venerable age.")

And stuff much more complicated and intricate, all created by sharing tables. I can see entire D&D characters being generated with it with some careful generator creation. The possibilities are pretty open-ended.

So you create your generator by referencing tables which you or others have made. Tables are searchable, rated, etc., as are the generators created using them.

Your generator is saved, and can be used by anyone. So if you create your massive town description generator which references 60 tables, anyone can use it to generate a town.

The concept might need some tweaking.

Is the logic of use sound? Am I missing any glaring problems or issues? I'm thinking that the generators may need some logic functions in some way, but I'm not sure how, exactly. It's just a gut feeling that IF/THEN statements might prove to be a fundamental tool in slightly more advanced tables. I can't quite think of an example though.

 

[jedavis]

One place you might want if/else is in generating say random spellbook contents. Joe Wizard is unlikely to have spent the time and dough to copy fireball into his spellbook twice. Duplicate checking pretty much requires if/else (or some kind of card-drawing simulation without replacement).

One other (admittedly silly) edge case I've played with for random generation scripting is automatically rolling monster ability score arrays, adding racial mods, and then recalculation of derived stats (to-hit, HP, saves, damage, special ability save DCs, and so forth). Nothing to scare players like owlbears with stats rolled on 5d6 drop 2. Are you planning to support arithmetic ops and function application (which were kind of essential for this task)? These would also be useful in say random treasure generation; for a "triple standard" monster like a dragon, you're rolling coins thrice, and it would be nice to be able to coalesce results of the same type.

Overall, though, I quite like the idea. Just some technical details to iron out. Building frameworks is always harder than building things to operate within them.

 

[LostSoul]

Main Page - Abulafia Random Generators

 

[Morrus]

Main Page - Abulafia Random Generators

Cool site. That's a good example of the basic concept, though I'd hope to make some thing a bit more powerful than a wiki can manage.

Glad to see I'm not completely crazy with this idea, though!

 

[Janx]

a topic after my own heart.

you're basically needing a table definition language and a macro language to engage it.

An old DOS tool I used call Campaign Manager had this.

So you could easily define basic tables, and use the macro language to make some of the line items in the table cascade to another table, etc.

the foundation should actually be a macro language that you can embed in other text (like an adventure document). I'm not quite sure where the final usage would be, maybe a big text box users can paste their adventure in?

Anyway, the macro language is basically interruptions in normal text/html that your engine can detect and replace with the correct content after processing.

Much like your example:
[FIRSTNAME] [LASTNAME] is a [GENDER] [RACE] of [AGE] age.
There are [1d6] [CR1MONSTER] in the room.

The table entries are in effect interpreted text, so you can have a row in the table call up another macro that might be another table.

Because you want to consider a variety of uses for your macro language, you'll want to define the syntax to be robust enough to handle future uses, but not so complicated nobody can use it.

what you've demonstrated so far is:
macros are enclosed in brackets (perhaps to differentiate from html)
[table:TABLENAME] will output the result from a table
[1d6] will cause it to output the result from a dice roll specification
[1d6 table:TABLENAME] will cause it to output 1d6 results from the table
[result=table:TABLENAME] will create a variable called result and put the outcome of TABLENAME and output it[result] will output the value of result
[?result=table:TABLENAME] will create a variable called result and put the outcome of TABLENAME but and not output it (you might not want it yet in your text)
[table:TABLENAME:result] will output the result from a table by looking up result in the table.

This syntax is a bit more complicated, but it opens up more correct possibilities like:
[table:FIRSTNAME] [table:LASTNAME] is a [table:GENDER] [result=table:RACE] of [table:AGE:result] age.

Compared to Morrus's example, this is more correct because Age is affected by Race (elves live longer, so the valid ages should be different).

I don't like prefixing table names with table:, but it's good to have a clear syntax that makes it easier to parse. You could rule that all variables are prefixed with $ like the old Basic used to be. That would actually simplify things.

[FIRSTNAME] [LASTNAME] is a [GENDER] [$race=RACE] of [AGE$race] age.

this makes it like Morrus's example, but allows for easy detection of variables. Starting with a $ means it's a variable. An equal sign indicates an assignment to a variable, and a $ in the middle of the table name indicates to use that variable.

From there comes the table definition syntax. the old CM program I mentioned chose numbers randomly from a range. To do a multi-die effect (like 2d10), you'd have to calculate where to put the numbers:

RACE:2d10
2: Elf
5:Human
10:Gnome
15warf
17:Half-Elf
18:Halfling
20: Half-Orc

Anything equal or less than but greater than the previous was a match.

Note, the conundrum of the concept of using a variable to get from Race to Age. There's index (or key) for the table is numbers only.

Let's modify our syntax one more time to allow for passing a number into the table instead of rolling, versus generating the name of a table.
[TABLENAME$VARNAME] concatenates the two to use a different table named by the combination thereof. [AGE$race] where $race=Elf means to use the AGEElf table.

[TABLENAME:$VARNAME] means to return the result as if the value of $VARNAME had been rolled. thus [AGE:20] or [AGE:$val] where $val=20 would return the result where a 20 had been rolled on the table.

PS. Make this macro language be case-insensitive. It's too easy for humans to goof that up and not worth the hassle. When in doubt, force macro strings to uppercase when interpeting them.

 

[enrious]

It looks a lot like the syntax for NBOS' Inspiration Pad random generator program.

A program that has made DMing a lot more fun and flavorful. Oh and it's free.

Inspiration Pad Pro v2.0

 

[Morrus]

[MENTION=8835]Janx[/MENTION] - You definitely get where I'm going with this, though I think your syntax will be too complex for the casual user. Above all, this needs to be easy because its value will lie in the amount of user generated content.

It'll be written as a vBulletin extension (php files and templates, all hinged out of the EN World database to allow for easy sharing and usage).

 

[Penthau]

[MENTION=8835]Janx[/MENTION] - You definitely get where I'm going with this, though I think your syntax will be too complex for the casual user. Above all, this needs to be easy because its value will lie in the amount of user generated content.

It'll be written as a vBulletin extension (php files and templates, all hinged out of the EN World database to allow for easy sharing and usage).

You could try Tablesmith. It has a mailing list on Yahoogroups.

 

[Janx]

[MENTION=8835]Janx[/MENTION] - You definitely get where I'm going with this, though I think your syntax will be too complex for the casual user. Above all, this needs to be easy because its value will lie in the amount of user generated content.

It'll be written as a vBulletin extension (php files and templates, all hinged out of the EN World database to allow for easy sharing and usage).

yeah, that's what some of my commentary was breaking it down to. Just launching a table lookup can be as easy as [TABLENAME]. And that'll be good enough for most people. But you'll need just a little more oomph for advanced options.

I think you'll need dice notation interpretation and incorporation into the table lookup multiple entries.

I had all of the old 2e random encounter, and treasure tables wired up in Campaign Manager. It's syntax was a bit more complex.

I think you'll also want to be able to macro-include a text block (which might have its own macros). This way, when a random encounter roll says "Orc" it can then include the statblock for the Orc.

You might be able to make it so tables and blocks are defined and called the same way:

GM: show me a [$result=monster] and it's stats [$result] table monster: 1d4 1: Orc 2: Goblin 3: Ogre 4: Kobold endtable block Orc Orc HP: [1d8] AC: 7 THAC0: 19 Damage: 1d8 endblock

All the tables and blocks would be defined elsewhere in the shared "script" space. But this would let you call it all up with that simple 2 lines of text and macros.

I'm not sure how it'd fit in with a wiki, but a special page with a big text box users could paste content into and "run" it would then generate the content would work. or wire it up to process stuff from the chat command line.
The processing engine should be relatively easy to write. It's been done a few times.

Each table or block could be stored seperately as a row in a table or as a file. Figure out which way is best for security and speed. Since you've got lots of people potentially editing them...

 

[Morrus]

I might need to talk to you about this.

It'll be an incremental release by necessity. But the hard part is ensuring the foundation is expandable. The worst thing to do would be to make an early design decision which prohibits a bright idea a year later.