Designing a Random Table Generator

[Janx]

That's not far off what I was imagining. We're more on the same page than not, I think. We're just getting bogged down in terminology. Well, I'm getting bogged down in terminology!

The only major difference is that I didn't see the main screen as an input box to generate stuff, but rather a list of pre-created generators which can be execusted with a button press with an easy link to start creating your own.

I would worry that a box saying "type some syntax in here to use this system" is an offputting thing for the first-time casual user. But "Press this button and get a town description" is inviting.

Regarding things like the GridView whatchamacallit, vBulletin already has a crapload of listing and browsing functionality built in; we can just hook in to that stuff with the bonus that the interface remains familiar to the user.

I like the idea of the field-edited table for casual users. Much less intimidating tha making them type syntax.

We're making stuff up on the fly. Technically, Generator is a good word for what I called asset. Both tables and blocks are generators.

And the List screen is closer to what you envisioned as "pick a thing and click the Generate!" button.

the Main screen i describe is what most table-engines have as their UI to generate content. It's like the command-line interface to make the beast work. Let's call it the Console screen, and defer the details to later.

The list and edit screen are REALLY what you need, no matter what.

As you surmised, the GridView example is just to demonstrate what I'm talking about. It's a list with columns that you can sort by, filter, etc. if vBulletin has similar, great!

to recap on current terminology I propose:

• Generator: a table or a block. It has a name, and the user can run it to get results back. A Tag that names a Generator can be embedded in another table or block, enabling generation of complex things
• Table: A type of generator that rolls a dice result and looks up the result on a chart and returns that result. The result MAY have Tags in it to use other tables or blocks
• Block: a potentially large bit of formatted text that MAY have Tags in it to use other tables or blocks. Useful to define monster stat blocks with random hit points and treasure from the treasure tables, or room descriptions or even an entire adventure, and randomly generated each time based on using Tags.
• Tag: the markup in text that the Parser will find and run the named Generator to replace the Tag with its results. Tags begin and end with a square bracket [].
• Parser: the engine that interpret text content sent to it to identify Tags and run the appropriate Generator.
• Script: like a tag, but using curly braces {}. Script can be dice notation or other advanced functions.
• Dice Notation: the standard nomenclature for saying roll 2 six sided dice, add them up, then add 4. Ex: 2d6+4. Dice Notation enclosed ina Script tag will be executed and the script tag will be replaced with the results.

 

[Morrus]

OK, I think I have a better way to put it.

• Tables and Blocks are tables and blocks, two types of Asset.
• A Generator is a completed, saved, formatted collection of Assets with a pretty names and description. In other words, it's a Block, but it's one we've declared complete, prettified, described, saved, and accessible to all to use.
• Scripts, tags, dice notations are all types of syntax.

Our pages:

MAIN PAGE: Your Generators. Latest Generators. Top Rated Generators. Popular Generators. Search Generators. This is just a presentation of some saved blocks. Not all blocks will necessarily be considered a "generator" but all generators are blocks. Generator is our own word to just denote a completed, finished, polished, saved top-level block with a purpose.

ASSETS: All tables and blocks in easily browseable list form. From here you can create a new asset (a table or a block).

CONSOLE: An empty text block page where you can just chuck in some syntax and stuff and grab some results.

HELP: A page which just describes the syntax and stuff.

 

[Janx]

I like your breakdown. I'm sold.

I would add that the AssetEditor is likely a seperate screen (or modal pop-up from the Asset list screen). Some people merge the two (as in you see a list, and you edit on that same list screen), but functionally, they are seperate, but tied together.

In defining Assets, I think we'll need to a Category aspect and some kind of flag indicating this is a Top-Level Asset. That way, the user can hide the baby-helper tables/blocks that are needed, but you wouldn't really use directly. Some of your wording refers to this same concept.

So, thus far for Fields on an Asset:
Name
Type
CreatedBy (who first made this)
CreatedOnDate
UpdatedBy (who last updated this)
UpdatedOnDate
Category (from some arbitrary list of categories: encounter, treasure, dungeon, etc)
IsPublic (a flag so the owner can indicate he's ready for others to use it)
IsHelper (a flag that indicates this is a minor table and should be hidden from the Main screen, but available to use as a sub-table)
Body (this is where the table or block content and meat goes, The parser reads this and does what it needs to do)

There's be other relational DB tables to link users to favorite Assets and record user votes, etc. But that's all secondary to the functionality.

Does all that sound like what you expected?

 

[Morrus]

Yep.

One minor issue that might arise. A user could wreck or remove his own table for a variety of reasons, and in doing so wreck a whole bunch of other peoples' stuff. We need a way to ensure that that doesn't become a problem.

Also gonna need a very clear design document for the developer. He's really not going to intuitively understand the concepts here, so it needs to be crystal clear.

 

[lmbarns]

Seems like you guys want a database, maybe a MVC framework where the user fills out a web form which gets posted to the server, some queries do some logic on posted forms, and add non-duplicate entries to relevant tables. The user is returned a view of the database with some options for querying against different tables which randomly kicks out [monster + action + property] or whatever randomized truncated results you're looking for.

Like, you could divide tables into categories, and randomly pick entries from different categories and append them into a result.

[Base Weapon table][properties table][modifier table]

Randomly chooses weapon [broadsword], picks 2 random properties from "properties table" say [green, poisoned] + a modifier ["of the wicked"]

which outputs "A green, poisoned, broadsword of the wicked"

in javascript it would be something like: var myResult.innerHTML += "A "+ property + ", " + property + ", " + baseWeapon + " " + modifier;

Where you'd have an array of each table's entries, you randomly pick a an index from the array and .push it into a new array to store it to pass back to the user to format/display on the webpage.

 

[Janx]

Yep.

One minor issue that might arise. A user could wreck or remove his own table for a variety of reasons, and in doing so wreck a whole bunch of other peoples' stuff. We need a way to ensure that that doesn't become a problem.

Also gonna need a very clear design document for the developer. He's really not going to intuitively understand the concepts here, so it needs to be crystal clear.

ah yes, that's Dependency checking in developer parlance. the inifinite loop test helps detect that. Because we can collate the entire chain of tags an Asset has relations to, we can then verify that they all exist.

Additionally, we can allow for the Parser to ignore tags that it cannot resolve (find an Assset for). So if it found [JanxTable1] in the text, but no such table existed, it would leave that tag in place in the output. It'll be pretty obvious to the user what happened.

For a developer specification, I think you'll need:

• glossary of terms
• DB table definitions
• screen explanations and sketches
• use case/user stories of usage examples
• syntax of Tags/Scripts
• syntax for Tables in Asset Body (what are the delimiters, structure for defining a table, similar to TableSmith or other tools
• syntax for Blocks in Asset Body (does it allow html or vBulletin formatting, etc)
  Parser flow chart/ pseudo-code explanation of its process

For the parser, here's the basic pseudo code:

function string ParseText(string Input) {
  string Output = Input;
  List<Tag> arrTags = GetAllTags(Input);
  foreach(Tag t in arrrTags) {
    Output = t.ExecuteTag(Output);
  } //end of looping on arrTags
  return Output ;
}

class Tag {
  //properties and stuff would be defined here.
  function string ExecuteTag(string Output) {
    string result = this.TagValue;
    switch (Tag.Type) {
      case "Asset":
        result = this.ExecuteAsset();
        break;
      case "Script":
         result = this.ExecuteScript();
        break; 
    } //end of switching on tag type
    
    this.UpdateOutputforTag(result,Output);

    return Output;
  }
}

function string ExecuteAsset() {
   string result = this.GetAssetResult();
   
   result = ParseText(result);

   return result;
}

the ExecuteAsset() function would go look up the Asset in the asset library, and do a table result or block result and call ParseText() on that result before returning it.

the ExecuteScript would be similar, but do whatever script parsing meant.

This is all just pseudo-code. Not entirely correct, but shows the gist of the process for a programmer to follow.

 

[Morrus]

Janx, do you have the time/inclination to help out directly? Not the coding itself, but the spec document and liaising with the developer?

I can do all that, but I can't help feeling that you'd do it ten times better. I feel slightly out of my depth on this one.

I'm sure we can come up with something to make it worth your while.

 

[Janx]

Seems like you guys want a database, maybe a MVC framework where the user fills out a web form which gets posted to the server, some queries do some logic on posted forms, and add non-duplicate entries to relevant tables. The user is returned a view of the database with some options for querying against different tables which randomly kicks out [monster + action + property] or whatever randomized truncated results you're looking for.

the system will be stuck with whatever vBulletin expects for code or modules to be done as. Mostly PHP, using whatever libraries vBulletin demands.

the actual Parser can be mostly detached from the vBulletin. Anybody could code it in PHP as a class library or set of functions the other code can call.

The one caveat to that is that Assets are likely to come from vBulletin's DB and that'll require whatever architecture constraints to access it. A developer could get clever with his code and ini files to make it so an Asset could come from different sources (text file, simple MySQL DB or vBulletin DB) and the rest of the code would be clueless when it uses the Asset object.

thus, a developer could work on the Console and Parser to get it working, then somebody more knowledgeable in vBulletin coding could hook up the rest.

 

[Morrus]

So I'm having trouble describing even the basic concept to a non-gamer programmer; the one I'm talking to just doesn't understand what I'm talking about. We all know what random generators are in RPG terms, but translating that into English for someone who's never seen a random encounter table is proving hard!

Can anyone help me out with this, and figure out how to describe this system in plain English?

 

[Janx]

Janx, do you have the time/inclination to help out directly? Not the coding itself, but the spec document and liaising with the developer?

I can do all that, but I can't help feeling that you'd do it ten times better. I feel slightly out of my depth on this one.

I'm sure we can come up with something to make it worth your while.

I'm not sure how I missed this post, but yes, I'd be happy to help out. Time's a little tight, but clarifying what is need to a developer isn't as time consuming as actually doing the work.