Open rsek opened 2 years ago
rsek
commented
2 years ago some of the issues relevant to this:
rsek
commented
2 years ago started digging around in v10's source, so here's some more notes.
JournalEntry is basically a container with a header a bunch of child JournalEntryPages. JournalEntryPages can be viewed one at a time, or collated into a single long text with subheaders. they're organized into an outline
the "canonical" types of journal entry pages.
it seems those types can be expanded by the system.
markdown and html are both options for page text. nice.
dropping a journal page on to the map creates a map pin, as one might expect. the icon can now be set to anything.
currently it doesn't provide any way of configuring/hiding the square ground, though. 🤔 i've written up an issue for it: https://github.com/foundryvtt/foundryvtt/issues/7255
ben
commented
2 years ago Some thoughts, in no particular order.
I like the idea of having the JE be the source of truth for progress "items". It removes the concept of actor ownership, so now two actors could have shortcuts to a single Vow on their sheets, and not get out of sync.
I still think there's value in having these tabs in the character sheet. I still want it to be possible to play using a single sheet, and also to have a "dashboard" of your current progress at a glance. I'm fine with popping out new apps for notes and changing parameters, but overview information and simple "mark progress" controls should be on the main sheet.
Putting JE's on the map is still clunky. This might change after v10dev1, but out of the box the experience is pretty bad for this:
I think this breaks a lot of flows, so it still seems to me that actors are the way to go. NPC actors will still be just a thin shell around a "progress item" (i.e. a JE), but actors they should be.
Augmenting the JE UI could replace the current progress sheet. Even without the v10 JE fancy-pants stuff, we could still just pop a button into the title bar that opens a sidebar. A quick mockup:
Again, the progress/rank/clock/type data is stored on the JE itself, and references to that JE are spread around to the actors that care about it.
DiceT
commented
2 years ago
- Dragging a JE to the map activates the "bookmark" icon, which means you're now in a different mode and can't interact with the actors on the map
- Switching back to "actor" mode hides the JE pins
- Once you realize you have to activate the "pin" icon in bookmark mode, you still can't drag JE's in actor mode, and you can't interact with actors at all in bookmark mode
- …which means you're switching back and forth between map nodes when you want to move these things around, and you have to remember which ones are which type. Do not want.
There are ways to enable the Journal layer to be available when viewing other layers. Someone has done this, though I do not recall which system/module.
rsek
commented
2 years ago as far as the convenience/clunky experience angle: that's totally fair! but not insurmountable. i think @DiceT has something there, and i reckon there's worse ideas than adding a dependency to make the map/journal experience smoother. IMO "having to go look for modules to create a game experience roughly as-written" is itself a UX flaw (paralleling that notion of "convention over configuration"). by leaving the stock map handling in there, the system is - functionally speaking - shipping with a mapping UX that isn't "fit for purpose".
if it's possible to remedy that with a dependency, then that's a fairly easy problem to solve (though, ideally - make it an option folks can toggle so they can use alternative approaches if desired).
I think this breaks a lot of flows, so it still seems to me that actors are the way to go. NPC actors will still be just a thin shell around a "progress item" (i.e. a JE), but actors they should be.
hmm, reckon you could elaborate a bit on this? like... what functionality does keeping them as actors provide that's useful for ironsworn?
moving actors around on a battlemap is one thing, but battlemaps aren't encouraged or even mentioned (seriously. i checked!) by IS/SF; discussion of mapping dwells almost entirely on setting- and sector-level maps. you know what has more precedent than tactical-level battlemaps in IS/SF? node maps - they're presented in delve for mapping delve sites and relationships. it might make more sense to embed mermaidJS or some other handling for flow-chart like layouts 😉 (TBH i was 100% joking when i started typing that sentence. now i'm only 95% joking, because having a flowchart editor in there...might actually rule?).
so, in other words - making NPCs actors is complicating the system to enable niche variations of gameplay. people going "off-road" in that regard are probably better served by things outside the scope of this game system, like other modules.
alternatively: offer an option to generate a linked actor token from a journal entry with a progress track, but IMO it shouldn't be the default, because it's not the default position of the game itself, and adding optional user-facing complexity is the realm of "advanced options". but, frankly? i wouldn't even bother unless someone specifically requested it and their needs weren't being met by journal entries. like, in a journal-entries-as-the-primary-non-player-entity world, i'm not convinced it'll be a big deal.
and as much as the semantics of "actor = npc" are slightly more obvious - functionally speaking, PCs are the only "actors" in ironsworn anyways. nobody else makes moves.
rsek
commented
2 years ago oh, btw. we wanted a bespoke map-note/placeable solution instead of relying on someone else's code, the API is getting some stuff that could make that easier:
building a whole custom layer might be out of scope though ;) IMO an add'l module depedency is good enough to get a working prototype online.
also - maybe it'd be worth opening a feature request with FVTT to improve the awkward map note workflow out of the box? (i'd do it myself, but i think @ben has a better understanding of its limitations than i do, lol). i reckon the crux of the issue is a mismatch between the expectations of tactical gameplay and setting-level maps; improving it could make the VTT more versatile for non-tactical-battlemap mapping styles. and if there's a time to get it on their radar, it's the update where they're overhauling this stuff!
rsek
commented
2 years ago re: this system including a more "opinionated" default map configuration... on one hand, embedding a highly opinionated map experience in the module might be some overreach. but on the other hand: foundry already has a highly opinionated map experience out of the box - it's just one with an opinion that doesn't match up with ironsworn's presumed gameplay. so we might need to be opinionated just to cancel that out, ha.
possibilities for prototyping a v10-like map experience on v9, or offering backwards compatibility:
QoL improvements:
node-based abstract "maps" (which i'm now only 85% joking about):
ben
commented
2 years ago offer an option to generate a linked actor token from a journal entry with a progress track, but IMO it shouldn't be the default, because it's not the default position of the game itself
Yes, exactly. The default flow would be "open your PC sheet, click the + on the progress/connections tab, and that generates a JE and a linkage to this PC. But there can be a button on the JE sidebar that does a create-or-open on an actor (which also references that same JE), and makes it placeable on the map. This seems to be hard to explain in words, but I have a fairly clear picture in my mind.
hmm, reckon you could elaborate a bit on this? like... what functionality does keeping them as actors provide that's useful for ironsworn?
See #121 and #238 for the original impetus here, but there have been quite a few requests over the lifetime of this project. Especially when these items can represent named NPCs, it sometimes makes sense to plop them onto the map to remind you who your contact is on this planet, or where Admiral Carcosa's fleet is now. The use case isn't "gridded map for tactical combat," it's more "desktop that holds the minimized items that you're working with."
PCs are the only "actors" in ironsworn anyways. nobody else makes moves.
I don't think anyone is going to interpret the Foundry "actors" tab in that literal a sense. I learned on my first day with Foundry that an actor is "a thing you can put on the map."
Regarding Foundry's opinionated division of JE's and actors on the map: the thing they're trying to enable is the "keyed map with location notes" experience. In D&D, when you're dragging PC tokens around, you absolutely don't want to drag the note about the ballroom into the adjoining torture chamber. The interaction model is exactly what they want it to be, and none of the modules you've linked alter this behavior, so it seems like they're fit for their purpose. My overall opinion is that trying to make map pins behave like actor tokens is a lot of swimming upstream, changing a core Foundry feature in ways that will upset those player who want the default experience, and will involve a bunch of effort and bugs for not much advantage over "generate an actor and link it to the JE."
Regarding all the modules you've found: I think most of these fall into the "this is a niche that I'm glad is supported by a module, but isn't core to the experience" category, and I don't think we need to depend on or reimplement them. I'm not generally in favor of taking lots of dependencies unless they're absolutely critical to the system working. I'd love to collect a list of recommended modules somewhere, maybe in the wiki?
building a whole custom layer might be out of scope though
Um, yeah. I'm pretty sure we can do everything we need to without going to that amount of trouble. 😀
rsek
commented
2 years ago See #121 and #238 for the original impetus here, but there have been quite a few requests over the lifetime of this project. Especially when these items can represent named NPCs, it sometimes makes sense to plop them onto the map to remind you who your contact is on this planet, or where Admiral Carcosa's fleet is now. The use case isn't "gridded map for tactical combat," it's more "desktop that holds the minimized items that you're working with."
that's what i'm getting at, tho - can't all of the examples above be accomplished with notes?
like, as of v10:
that ticks all the boxes i can think of. is there some other function of actors that i'm missing that's important here? maintaining familiarity for people who have experience with other foundry systems is reasonable, but would a small learning curve of "this game uses notes for everything that isn't a PC" be acceptable if it improved the experience in other areas? heck, is there more tolerance for it if the game system itself diverges sharply from common VTT assumptions?
there's an additional fringe benefit to not using actors for NPCs, too: the token hud won't be present. IMO it's superfluous for ironsworn NPCs, unless a lot of work were put into modding it too. (yes, this is minor. i have an axe to grind with that HUD ;) )
to put it another way: if we implement the journal entry page extension and include an optional tweak to map note draggability, then NPC map representation is pretty much done, because the maximum mechanical heft of an NPC is a progress track - they don't use any unique components that other journal entries don't.
that's why i suggested seeing if people need (and what they need from) full actors first: get some universal journal-based handling in there as the MVP before looking at re-implementing a whole separate category of NPC actors + managing their associations with journal entries.
welp, had an epiphany - i think the biggest "actors have stuff that just gets in the way, why not use a base Document that's less cluttered" gripe i have might actually be that damn token HUD. great in tactically-oriented games, but it's not doing much here.
so... maybe what actors need here is a modification or default configuration that makes the hud actually useful, or just keeps it out of the way? 🤔
for NPCs, that might look like:
for PCs, this might consist of:
some of these effects can be accomplished via configuration, ofc, but they're not especially nice atm, and them requiring configuration to be useful at all is... not great. having a two-way connection between IS actors and their associated journal entries seems especially handy.
ben
commented
2 years ago can't both of those examples be accomplished with notes?
Yes, but not well. Actors are a much better-developed thing in Foundry. And I've already outlined this clunky interaction mode. Pick pins mode, move your NPC, try to move your PC, remember that it's an actor, switch to actor mode, move it around, back to pins mode, move your NPC, try to double-click on your PC, remember it's an actor, back to actor mode… It's a paper cut every time you want to interact with it. The people who asked for "NPCs on the map" didn't have that in mind. Every time I try this out to see what it would be like to use it, I find another thing that I don't like about it. JE pins are hidden when you're in actor mode until you find the right sidebar button. JE pins don't show their titles unless you hover over them. JE pins can't emit funky animated light patterns.
- the token hud won't be present
There's another one: JE pins can't have status badges. They can't rotate, either. Why should PCs get all these features and NPCs not?
- that's not set in stone any more than the baseline functionality of actors is set in stone
The "not set in stone" phrase is doing a lot of heavy lifting in that sentence. I mean we could make a spreadsheet with Foundry too. It's just code, right? 😉
Look, it seems like we're really at loggerheads about the "just JE's" or "actors that reference JE's" thing. Let's put that on ice until I can whip up a demo and show you what I've got in mind. I suspect that "make it possible to drag map pins around while in actor mode" is both harder to get right and less desirable than it seems at first, and I really think that letting Foundry have its way with canvas layers is going to be better for us than trying to force one kind of entity to behave like another one.
rsek
commented
2 years ago Look, it seems like we're really at loggerheads about the "just JE's" or "actors that reference JE's" thing. Let's put that on ice until I can whip up a demo and show you what I've got in mind. I suspect that "make it possible to drag map pins around while in actor mode" is both harder to get right and less desirable than it seems at first, and I really think that letting Foundry have its way with canvas layers is going to be better for us than trying to force one kind of entity to behave like another one.
yeah, that's fair. FWIW i think i'm basically with you at this point - i walked some of what i said back in later edits of my post before your reply, if you care to take a look :) sorry if you're replying based on an earlier version; i've left the original gist of it intact for historical reasons.
basically, i think that a modified actor token HUD might be leveraged to, say, provide a shortcut to an actor's associated journal entry, display progress, etc.
ben
commented
2 years ago A quick note to say that #508 is actually working now, so we can try it out and see how it feels.
so, there's a lot of new journal features in v10. i have this hypothesis that most or all things that are currently "actors" (aside from PCs) could be journal entries, too, so i'd like to do a brain dump to see if it still seems clever once i read it back ;)
Possible benefits
Possible downsides
vs. Current Actor Functionality
to figure out what these new journal entry types should be able to do, it's worth thinking what the current actor-based approach does first. what functionality could a journal-based approach provide to replace it?
Guiding the player in entity creation
i think there's a lot of value in having a scaffolding/template/form so that people don't have to look up "what's the recommended way to generate this again?"
Possible journal-based approach: could be accomplished in much the same way - multiple journal entry types or templates. user picks on journal entry creation.
Curate a manageable subset of oracle/table shortcuts
the current location builders do this, and it's really useful, but people can only use what's hard-coded in.
i'd file Delve matrices and Site Themes/Domains under this heading. they're structured a bit differently, but their function is similar.
Possible journal-based approach: include shortcuts to roll oracles. this might be via a custom UI element containing a bunch of buttons. ideally, users would be able to customize this themselves. it might also be used used as the basis for oracle arrays?
Curate a manageable subset of moves
i haven't handled the delve module much - does it do this with the Delve moves? another place it might be useful is combat.
Instantly roll a bunch of oracles
e.g. SF locations.
Possible journal-based approach: journal entry can include a "preset" of a group of oracles to roll with a single click?
Associate tracks/clocks with an entity
see #382 for some thoughts on that. making a progress track and clock independently-toggleable items on journal entries could account for this.
Create a representation of the game entity on the virtual tabletop
currently, this is accomplished by actor tokens. IMO actors are way more complicated than any non-PC entity needs to be in ironsworn.
Possible journal-based approach: map pins are getting a refresh in v10. they have an icon, a tooltip, and can be linked to specific journal entries - more than sufficient unless someone needs a battlemap (which, IMO, is out of scope for a game whose default setting is "theatre of the mind", and a pretty substantial divergence from presumed gameplay).
Make the associated content easily findable by other PCs
pretty straightforward translation here. they'll just be in the journal tab (and searchable!) rather than the actor tab.
Putting it all together
at this point, i'm imagining something like this:
foundry-ironswornprovides preset journal entry "templates" corresponding to previous actor types