Architecture and Design

[Alteras1]

For discussing the architecture and design of this. Whether we use a TC or a plugin, which dice roller package to use, how do users interact with it, do we use a table?

TC or Plugin
If it's a TC, we will only have access to the frontend, whereas with a plugin, we have full access. I'm thinking we go with a plugin, that way we can use custom properties on posts or a database if we need. Also makes it difficult to alter the dice roll.

Dice Roller engine
I think we can all agree on just choosing an engine to use instead of handcrafting one? From the BBCode project, we've learned how to shove JS to run isolated in the backend and frontend, so we can search through NPM for any good ones.

I'm leaning towards rpg-dice-roller (documentation) since it seems to be the most feature complete.

User Interaction
Most definitely via posts, but how to format it? whether as an inline bbcode, or maybe as a stylized quote block? Should the roll result be integrated into the post, make a dedicated UI outside the post, or have a bot post the result?

Saving rolls
How do we prevent abuse and lock rolls? Do we seed it based on something like post time? let the bot posting handle it?

Misc features
Where do we save the rolls? In post (custom property) or as a standalone table? Do we have a standalone roll page? Do we add support for rolls in chat????

[Alteras1]

User Interaction
Most definitely via posts, but how to format it? whether as an inline bbcode, or maybe as a stylized quote block? Should the roll result be integrated into the post, make a dedicated UI outside the post, or have a bot post the result?

edit: moved major discussion points to the main post and refocused comment to be UX for better discussion readability.

[kyuukestu]

I believe many of these are questions for the users primarily. I don't use RPN's dice-roller extensively but whenever I do, in-line isn't required and would probably break-up the flow of my post since I use it less as an integrated part of the RP and more as a way to generate a random probability.

I imagine Role Plays that more heavily use the dice system may want an in-line option, especially in scenarios where there may be multiple dice rolls per post (Uncertain how frequently this occurs.).

[Mondrethos]

Being able to type it up as part of the post in-line would be cool and super useful. I'm not sure if providing multiple options would be a bad idea or too much bloat though.

[Alteras1]

I'm also kind of iffy on inline, tho it shouldn't be too big of a problem to make it an option on a bbcode? I imagine the possible syntax to invoke a dice roll in post would be

[roll]1d20[/roll]

[roll description="lorem ipsum"]1d20[/roll]

[roll style=inline]1d20[/roll]

> [!roll] title of roll/roll group
> 1d20
> 3d10 // allow grouped rolls

tbh, i don't find bbcode to be the most elegant, tho that might be just that we haven't found a nice syntax.

---

tied to how we want the dice roll to be displayed, I've quickly roughed up two design for easy visualization on canva. Having a bot post is easy enough to manage, so I'll skip that.

In post quote replacement

Below post insert

I also want to remind that we aren't limited to one or the other. We can combine both of them, and let the user determine an option (via syntax) on whether in post dice roll gets displayed.

[MShultz]

I like the idea of giving users the option of how they want to present the roll itself. It's definitely feasible to give them multiple if we get the syntax right. I am not as familiar with how users typically like to showcase rolls. For a simple use case, we could give an inline option easily enough too, if we think it makes sense--it could get complicated if users try to put too much inline.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. (2d20 🎲 [8, 17] = 25) Etiam lacinia sed dolor ac varius. Nulla facilisi. (1d100 🎲 99) Pellentesque semper tempor libero non eleifend. Suspendisse urna metus, laoreet maximus fringilla ullamcorper, mollis at neque.

The structure could be (2d20 🎲 [8, 17] = 25) or (🎲2d20: [8, 17] = 25) if we wanted to keep them consistent with the in post and below post designs.

[Alteras1]

Saving rolls
How do we prevent abuse and lock rolls? Do we seed it based on something like post time? let the bot posting handle it?

I had a thought that we probably don't need to think too hard on how to prevent abuse. We can keep a permanent history of the rolls attached to the post, and make the full history viewable to anyone.

For example:

Initial post: roll 2d20 = A
> save A at time T1
> show roll A, time T1

edited post roll 2d20+10 = B
> save B at time T2
> hide roll A, time T1
> allow roll history to be viewable via button on post with timeline of rolls

edited post: roll 2d20 = ?
> check syntax of roll matches roll A
> do not reroll, reuse A
> hide roll B
> keep roll history the same

This way, everyone can see the roll history while still immediately seeing which roll the current post has. Any edits would be visible to everyone, and would be up to GMs to handle it. Of course, we can add some extra conveniences like checking for spaces to minimize false positives.

[Alteras1]

For exploring dice roll history on a post, we can probably just fit it into the plugin outlet inside the edit revisions. Will need to check what the model gets, but would make things easier

[MShultz]

TC or Plugin If it's a TC, we will only have access to the frontend, whereas with a plugin, we have full access. I'm thinking we go with a plugin, that way we can use custom properties on posts or a database if we need. Also makes it difficult to alter the dice roll.

Dice Roller engine I think we can all agree on just choosing an engine to use instead of handcrafting one? From the BBCode project, we've learned how to shove JS to run isolated in the backend and frontend, so we can search through NPM for any good ones.

I'm leaning towards rpg-dice-roller (documentation) since it seems to be the most feature complete.

TC/Plugin: I agree that we should go with a plugin for this. It gives us the most flexibility to expand the functionality past what may already exist on the site for rolling.

Engine: Agree, please lets use an engine. It's less work for us and helps us avoid having to think through the many edge cases that come with expanded dice rolling mechanics. (Also less testing, blessed be!) Reviewing the engine you linked, it feels like it would provide even more possible functionality than what we have now; I like that.

Thought: Could the engine that we choose help inform the syntax/notation we choose to use for our encoding? The engine will parse that notation in the backend anyway, and we'd have a reference document to write a simple starter guide from already.

[Alteras1]

Thought: Could the engine that we choose help inform the syntax/notation we choose to use for our encoding? The engine will parse that notation in the backend anyway, and we'd have a reference document to write a simple starter guide from already.

Oh, definitely. I was 100% ready to just use whatever notation the engine used. Most people (and engines) should understand the basic XdY rolls, so I think the only people particularly inconvenienced by having to learn a notation would be those who need particularly complex ones. Assuming we go with rpg-dice-roller, we can probably link to their guide on notation for anything more advanced.

[Mondrethos]

I like your mockups and I really like both. The question I have is, how easy it will be to add new system/dice types?

[Alteras1]

You mean extending the engine? Depends on the engine, but pretty difficult. If it's something that the notation/engine doesn't support, we'd have to make changes to the engine itself. These engines are effectively just parsers, and to extend it would be to extend the parser. When we're looking for an engine, we should choose the one that is most flexible to users while being the most feature complete.