FGU: Functionality

[snupy]

Some time ago I started a thread on the FGU interface which lead to some interesting discussions. I am now trying to do the same but with a focus on functionality. While this website is available for features suggestions, a thread seems more indicated for extended discussions. I am going to make four points, as well as a plea (in the post below this one) for something I had already advocated for in the other thread.

1. Doing more with distance and speed. FG can calculate distance from a point in the map, and is aware of PCs/NPCs speeds. However nothing seems to be done with the speed data. It would be really useful if FG could color code or something similar movement on the map according to the available speed, like here. A possible color coding in PFRPG would be green for a single move action, yellow for twice the speed (move + standard), red for any further than that. The color coding should just be informative and not actually prevent token movement - for example in PFRPG you can decide to be running for the whole round, giving you 3x or 4x the speed.

This feature would be particularly useful to GMs, who have to move a large number of monsters and NPCs all having possibly different speeds. But it would also benefit players, who tend to forget about encumbrance or more complex movement rules. While the specific colouring would depend on the ruleset, the feature itself would be useful in most or all of them.

More advanced incarnations could offer a drop down menu to select a specific speed (normal, fly, burrow, etc) before moving the token, or take into account map areas denoted as difficult terrain.

2. More automation. When I was researching which VTT to use, FG was (almost) always listed as the one with the best automation, at least out of the box. That may well be (or used to be) true, I have never made an extensive comparison, but when I first tried it with PFRPG I was disappointed: not very much (class features, spells, feats) is automated out of the box. In fact, I found other threads with similar complaints. I was still happy enough to stick around, and community modules are largely to be thanked for that. But I think FG should capitalize on its fame, and improve out of the box support for ruleset automation (I mean with already coded effects, I know I can write them myself). As a lot of it has been done already by the community, I think it would make a lot of sense to see if an agreement with the community developers can be reached so that their work can be included in the appropriate FG ruleset rather than duplicating it from scratch. Extending the effect coding possibilities would also be welcome, and again this is already done in some available extensions.

Side note: I think that the amount of automation included in sold modules should be made much clearer. It seems natural to think that a paid module will expand functionality, while this is almost never the case. I know that now (well, it's been a while), but I was not happy when I first discovered it, and again I found that I was not the only one to be disappointed. The module description (at least for PFRPG) is a fairly generic blurb which really does not make this clear. I think that at a minimum the general description should include a line to the effect that the module does not add any new functionality. In fact, I think that the module description should specify which effect coding has been added, if any. In comparison, the description in the syrinscape module is very honest.

3. Triggers/events associated to fixed or moving areas in the map. Kind of building on 1, the possibility of denoting fixed or moving (associated to a token) areas on the map, and associate to them an event in response to some trigger. Fixed areas could be used for traps or environmental hazards - in fact the pit terrain is a rather specific case of what I am describing. However, it would be great if you could use more complex triggers and events, which apply effects to token, roll dice, and support if/then constructions and boolean logic. For example, if any character enters a specific square (trap) it triggers a spell which means it plays an animation (I wish) and a save roll is automatically triggered, or things like that. Moving areas could be used for things like auras, attacks of opportunity, flanking detection.

4. While I am dreaming, a natural extension of 2 would be the availability of a large number of triggers, e.g. entering an area, attacking, dealing damage… and associated events, like playing an animation, displaying a dialogue, applying an effect, rolling something, all supported by robust coding possibilities for the final user.

Now, I am aware 3, 4 are very complex, and not far at all from being a full implementation of the coding needed for a computer game. I certainly would expect them to be implemented very gradually over a long period of time. Perhaps some discussion here could help isolating reasonable requests/features, and identifying ways to implement them.

Also, functionality of this kind often draws critique on the basis of moving too much into computer game territory. I think this is a serious point, but I suggest it is discussed in a separate thread.

[snupy]

In the FG interface thread I advocated for a certain way of dealing with the duplication of, say, items which happens when loading several modules. As I still think it is a good idea, which applies rather generally, is backward compatible and could be implemented for the most part with relatively little effort, let me go over it again.

For simplicity, I will refer to items, but it applies to all other record types (classes, spells…). For each ruleset there is a master list for items, associating to each item a unique identifier. Importantly, this list is in the ruleset, not in one or many of the modules. If the module needs a longsword, ID 31, it calls for ID 31 from the master list when loaded (and probably copies the corresponding item from the master list but I am not very knowledgeable about FG inner workings). To preserve the ability to filter items by module, one extra data should be associated to "loaded" items: a list corresponding to all the modules which requested it. So you'd have something like loaded items: ID 31, [all the data of the corresponding to ID 31], {requested by: "Core rulebook", "Ultimate equipment", "Burnt offerings"}. When looking at the items record list, if no group is selected each unique id is only listed once, and "Multiple modules" displayed as the source on the right. If a module is selected only the items it calls are shown.

Advantages:

- Avoids duplications of code/text as each item, class, etc needs to be entered only once.
- Consequently, makes fixes or the addition of new features (say adding the coding of effects for a spell as I advocated for in 2) much easier as only one instance needs to be changed.
- In the case of modules fully developed with this system, solves the duplication of entries problem while preserving the ability too filter results by module.
- Backward compatible: the master list can happily coexist with a list of items within the module as done so far (of course it would not fix duplication of entries in this case).
- The new system would benefit all rule systems.
- In many cases, most of the advantages can be obtained by switching to the new system for a restricted number of books/modules. For example in PFRPG most items are in Ultimate Equipment, and items in secondary splatbooks but not in UE are unlikely to cause duplication issues.
- Creation of data for new modules within the new system is at least as fast as it was before (if say copying an item from UE was the method used), or much faster (if entering the item from scratch).
- For new modules, as far as I can see the system brings only advantages. Conversion of key older modules perhaps could be offloaded to the community by offering some incentive as it is currently done for the addition of LOS to maps. In any case conversion is not needed.

Now, the existence of a master list within the ruleset potentially means that its content is available to everyone, without having to purchase any specific module. Honestly, I think that people purchasing modules for the most part do so to support SmiteWorks and/or the RPG creator, and would still buy the module, but if this is a concern I suppose master lists could be encrypted.

[Zacchaeus]

As regards your second post, whilst a ruleset cannot be copyrighted everything else can. So including stuff in the ruleset which is copyright isn’t an option. Apart from that community developers who convert books into modules don’t have access to the ruleset in order to add anything into it (and I’m pretty sure the developers wouldn’t want them to be able to do that anyway - it would be really impractical to have several people all adding in stuff at the same time). I can see where you are coming from as regards duplicates but it is unavoidable and there are filters which somewhat mitigate that.

[Nylanfs]

And to follow up, the FG data isn't all in a database so that the ID numbers could be called by other modules.

[snupy]

And to follow up, the FG data isn't all in a database so that the ID numbers could be called by other modules.

Sorry but I don't understand what you mean.

[LordEntrails]

I like the ideas around distance and speed and even to some extent the movement triggers. Distance I would put higher on the list, but neither of them would be in my top 50 improvements. But, I hope you put them on the Feature Request list so others can voice their opinions with votes.

About More Automation, well when you look at PFRPG ruleset you need to keep something in mind, (unless I'm reading the Paizo website wrong) its an obsolete ruleset. I don't mean that in terms that people don't play, but all new product from Paizo is PF2E or Starfinder. Given that, I doubt it makes financial sense for FG to implement any new functionality in that ruleset. Realistically (from a business perspective), any automation needs to be justified for D&D 5E, and then ported to other rulesets via CoreRPG when (again) it makes financial sense. Not that such isn't possibly a good decision, but I think the financials needs to be considered and the realization that its only going to happen if it makes sense for the biggest ruleset.

To the sidenote, Perhaps more details on what automation is included should be detailed on the store page, but in general I know to assume zero unless the store page says that the product actually includes an extension. Because w/o an extension, a product can't change the ruleset code. But the 30 day policy is, imo, a better approach. Because whatever words are chosen, they are never going to be perfect. Being able to buy, try, and return is always going to be superior.

As for the 4th idea, about advanced automation. There is actually a lot of resistance to that from many GMs. Simply because they do not want to play a video game. But, I actually think it's inevitable to appear sooner or later. But this doesn't even top my top 100 list for improvements. And even if it were a goal adopted by the devs, would take years to get to that level. There are tons of foundational improvements that would be needed before we got there. Yes AAA games do this after a few years of development, with ~30 times the number of developers and a budget to go with it. We have to remember, we are in a very niche market.

I just don't see talking about it as particularly useful, it's so far down the roadmap and in the mists of uncertainty as to be practically useless because by the time FG gets close, technology will have completely changed and the current state of FG and VTTs will be vastly different than now. Perhaps the best approach would be to discuss a broad goal or approach to the VTT experience.

There is a ton of problems with the idea for removing duplicates. Many or most as previously discussed. Besides the fact that FG can not legally copy the text from numerous sources and make that available to the ruleset without purchase of the source, how do you handle When Item 10 from source ABC is mechanically the same as from Source EFG, but the text is slightly different? Who draws the line? Because if the text (or linked image, or...) isn't exactly the same, then who decides it's close enough? Or which one is the official one? Not that these things can't be solved, but really, what the value to the product? GMs often have multiple sources open, players don't to the same degree.

Now, I do see a couple of other ideas that would help with this without needing to determine which is unique and which is the master copy and would not incurring the huge cost of going back and editing old products.
A) Change the list filter behavior. Instead of All or One option we have now, enable check boxes for each list. This way you could display Source 1, 2, 5, & 8, but not 4, 6, & 7.
B) Enable the sources to be able to have a GM assigned priority. So that when two items have an identical name, only the one from the highest priority enabled (see idea A) source is displayed.

[Nick Frost]

Checking the "drag ruler" module for Foundry really made me miss the movement presentation from FG Classic. Simple lines and waypoints look so much nicer to me than the current token duplication + bold arrows. So yeah, I just made a feature request...

[claedawg]

I already have a request in the special place to add tracking of distance (although no mention of adding triggers to it or anything). Basically my idea was to make the current arrow/circle image that shows up when a player moves the character stay up and track the amount of distance moved between each point and the distance remaining until the character has completed its turn.

[JohnD]

Good to remember that Smiteworks has a 30-day money back policy if you decide any particular purchase just doesn't do it for you.

[snupy]

Thanks all for the comments.

@Zacchaeus I am not sure it is unavoidable. I was not aware of the legal difficulties, but all is needed is for IDs to be global and not internal to the module, could be e.g. an extra file which is encrypted instead of the ruleset. But ok, it may be too complicated to be worth implementing, and LordEntrails idea would help a lot with the duplication thing while being much easier to implement.

@LordEntrails nice to read your thoughts, I would be curious to read about you top wanted 5 or 10 features!
Re:automation
PFRPG is obsolete, but probably the second most played ruleset here, and one of the strong points of FG I believe? And as I wrote there are some great community resources, which hopefully could be integrated in the official product thus minimizing the amount of effort required.
Re: sidenote
sure, for a more experienced user it should be clear that modules essentially provide data, while extensions, well extend functionality. But that's not clear at all to a new user. Also I believe there are exceptions (advanced bestiary springs to mind), and in any case coding for effects is sort of a hybrid beast, as strictly speaking it does not extend functionality but merely provides already coded stuff, a bit like modules provide e.g. already entered items or NPCs. I think I remember a post with some developer writing that they try to include all reasonable effects when porting a product, and that's the kind of information which I think should be included.
Re: 4th idea. Fair enough it may be premature to talk about it. To be honest it's not clear to me how wide is the gap between 3 and 4, that is passing from a trigger which is location based (token enters a square) to more general ones, and/or how complicated would be different events (applying an effect vs rolling dice vs...) in response to a trigger to implement.
Re: duplicates. Ok, I am not convinced there is a tons of problems, but probably enough not to make it worth it, and I like what you suggest.

@JohnD I don't know if you are reminding me in particular, anyone who is reading, or both. As far as I am concerned, I am well aware. I genuinely think the description is inadequate, and I am not pointing it out because I am looking for a refund, but on behalf of new users. I don't think that having a refund policy (which I consider a bare minimum, and is legally required in many countries) means that descriptions can be inaccurate and it is the responsibility of the buyer to buy, test the product to see what really is contained, and in case ask for a refund. Now one may or may not agree with my take that the description is inadequate, but that is a different point.