Three Dollar Quill

Status of thinking about getting this working in the browser: my two big constraints are from my punq fork, which uses Python 3.8 syntax and the stdlib ast module. The syntax constraint narrows the choices I have, out of everything I know about, to Brython and Pyodide. (Python 3.8 eliminates for now, I think, transcrypt, Batavia, pyjs, Skulpt, and PyPy.js) Using either one would take some work from where I am now:

• Brython doesn't provide the ast module, which the fork currently uses to parse and partially evaluate type annotations. I believe there are several ways I could attempt to work around this.
• Because I'd be bundling several un-published packages with Pyodide, I'd need to install the wheels from a URL, which means it won't do dependency resolution, and I need to calculate the installation order at build time with some kind of topological sort.

Either of these could be worth working on, but I think I'm ready to get back to Mythic for now.

I'll catch up on that, and later work on finally getting the coverage up, as well as patching some holes I noticed.

Okay, there are various difficulties with implementing the Fate roll from base Mythic. One is the choice of focus table. There's just one focus table in base Mythic, but Variations does a bunch of stuff, and The Adventure Crafter has a different way of handling focus tables as well. Separating out concerns... The different parts of a Fate roll are as follows:

• Determine the target
• Roll d100, to produce the result
• If the result is divisible by 11, MAYBE produce a random event, given the focus table and chaos factor. (The choice of whether to generate one is influenced by the dominant theme, which may not be the theme whose focus table to being rolled against.) (Since I'm trying to make each package standalone to start with, this implies to me that I should drop some of the logic and classes I have currently.)
• Given the target and result, produce a set of outcomes accessible by spending up to 25 favor points
• Present the outcomes, and wait for input to determine if a different outcome was taken
• Deduct spent favor points
• The previous three bullets assume that there is an available pool of favor points. The answer to that should be consistent, or at least possible to determine ahead of time. So... write a factory that determines it, maybe? Still need to be able to line up the types, though. If I want to be a stickler, I could just have two high-level functions that package up the different flows. The question then, is what to return from the version that prompts to spend favor points.

Thinking about this has made me decide that these functions should make as few decisions about the context they're used in as possible, so I should avoid making them rely on sheets. That means the favor point version has to take a favor point count, and return a new total, along with everything else.

...

And the classes are ballooning out of control. I'm going to try to sketch out exactly what the sequence of events is supposed to be:

• Determine the target number (this relies on varying factors and should be abstracted away; just expect a target)
• Roll against the target number
• Determine the outcome
• Optionally apply favor points to shift the outcome
• Use the roll result, among other inputs, to determine whether a random event occurred.

I'm kind of tempted to try using punq for this, at kind of a higher level. Just, like, pass in stuff from the broader container, as well as volatile arguments.

Okay, I've sketched some stuff out on paper, and I think I have a solid plan for this. However, I'm tired, and I don't want to mess with the code any more while I'm tired.

Good night.