New Snippet: Calculated Fields

[the_redbeard]

This is a feature that would be needed for daplunk's Player Managed Locations to be implemented.
It would also allow a whole new kind of content to be sold in the content market.

The new snippet type, calculated field, would calculate the result of math adding, subtracting, etc., other snippet values. Yes, some spreadsheet functionality is what I'm talking about.

Who would want to do this and why? Well, daplunk would seem to so that he could calculate the numbers for a player managed location (and wow, he wanted calendar integration!)

But what I was thinking is that there are many rules sets, dating as far back as BECMI and Birthright and up to and including Pathfinder's Kingmaker rules as well as OSR versions like Adventurer, Conquerer, King in which the GM is responsible for calculating all the data needed for managing a kingdom or domain.

If RW had calculated fields, RealmWorks content market could sell pre-inputed kingdoms and their domain data would be calculated for the DM. As of now, DMs have to look around for spreadsheets that others have written or make them on their own. Selling the Kingmaker campaign AND have RW help the DM calculate the domain math? Sold.

 

[daplunk]

Interesting idea...

Would you see this as a single spreadsheet within a snippet that had mathematical capabilities or a mathematical snippet that can interact with other mathematical snippets. The second option would mean every other calculated field would need a unique identifier in order for you to use it with some kind of formula.

 

[the_redbeard]

Interesting idea...

Would you see this as a single spreadsheet within a snippet that had mathematical capabilities or a mathematical snippet that can interact with other mathematical snippets. The second option would mean every other calculated field would need a unique identifier in order for you to use it with some kind of formula.

Everything in RW already does have a unique identifier under the hood and while we do have conflicts in names, I'd hope the same disambiguation code would work in these snippets.

I was imagining an admittedly cumbersome [unique name].[section].[snippet] or somesuch. Hopefully within the same name and section those code be omitted.

Of course, to be really useful would be powerful search criteria like SUM [content type=city].[section=economy].[snippet=gold] where [city].[nation].[name=specific nation] or something. At least some of that sorting and filtering is done already in RW, though it isn't accessible in a function of course.

However, I'm open to whatever way this could be accomplished. I have no misconception that this would be easy or that it would be before say, calendars (ha!) or half a dozen features that people are waiting on. But if you're going to sell people a campaign world, wouldn't you want to sell them how the campaign world works, too?

 

[Silveras]

Functionality like that would be a project on the scale of multiple RealmWorks.

Don't forget that users can ADD or REMOVE snippets at will. Nothing stops a user from having more than one "gold" snippet on a Community, or removing the one that is there to have none.

One of RealmWorks' strengths is that it does not force a GM into a specific format. To do something like what you propose would require that the snippets always be available. Otherwise, the user would also have to indicate how to handle "missing" snippets, and which of many potential duplicates.

[Topic].[Section][.Snippet Name] is not a unique identifier because a) we don't name Snippets (they can have labels, but those are not "names") and b) because the actual unique identifier (if there is one) would not be shown to users and does not necessarily include section or Topic (which is why Snippets can be moved between sections and Topics, and why the same snippet can be added multiple times to a Topic).

You know that you can embed documents like spreadsheets in a Topic, right?

You also know that RealmWorks is system agnostic, right? While the primary content may be Pathfinder based initially, the product supports multiple game systems and genres without favoring any.

Your Kingmaker example is already done. HeroLab already manages Kingdoms and the Mass Combat elements from Ultimate Campaign. The rules in Ultimate Campaign are updated and improved versions of those in Kingmaker. HeroLab also supports the Downtime rules from Ultimate Campaign, allowing PCs who are NOT rulers of Kingdoms to create and manage Buildings and Teams in settlements.

All of that is very Pathfinder-specific, though, which is why it won't be functionality in RealmWorks anytime soon -- even though the Kingdoms somewhat straddle the divide between managing the details of PCs (what HeroLab does) and the broader aspects of the Campaign (what RealmWorks does). For now, you can embed a HeroLab portfolio of a Kingdom and its armies in your RealmWorks Topics.

It is not that I don't see some use-cases for "calculated" snippets.. but the kind of broad, user-defined-formula-processing ones you're describing would be a product on the scale of many times larger than RealmWorks itself .. or a spreadsheet.

Very specific, targeted "calculated snippets" can work, though. Dates make the most sense to me, as a) they are shared by just about all genres regardless of game systems, and b) there are many cases in which a published adventure or campaign does not have a fixed start date but expects the GM to set that.. and there are dates in the adventure or campaign that are "relative" to some of them.

So I can see a "relative date" type of date/time snippet.. something that very specifically requires the GM to provide "how many", "what time unit", and "relative to what anchor date".. with a GUI that allows you to navigate to a Calendar Date snippet as the "anchor date" the new one is relative to. Of course, it would need to default to no value when there is no value in the "anchor date" snippet. Also, the definition of how it is relative and to what date would not be shown to users even when the snippet (and its calculated value) is revealed.

Pros:

• Supports the existing use of "two weeks before" or "one day before" or whatever by adventure authors/publishers
• Allows the GM to set the required "anchor date(s)" as needed.
• Supports any game system
• Supports any genre

Cons:

• Needs to be able to handle deletion of the "anchor date"
• Needs to be able to handle having no value in the "anchor date"
• Needs to be able to recognize when the relative date crosses into another calendar element (such as "6 hours before" relative to "4 AM" pushes the Date portion into a different day.. which could also be in a different week, month, and even year)

 

[Vargr]

Interesting idea.

But I think Silveras raises some important points.

 

[the_redbeard]

One of RealmWorks' strengths is that it does not force a GM into a specific format. To do something like what you propose would require that the snippets always be available. Otherwise, the user would also have to indicate how to handle "missing" snippets, and which of many potential duplicates.

There is the coming Content Market. Yes, when we create our own realm the format is entirely our own, as are naming conventions and so on. But content from the Content Market is going to come with a structure in each product. Purchasing a game system for RW is going to come with some assumed data structure for that game system - and so on.

Yes, if there is a snippet for gold and then the user deletes or renames that snippet, then they've broken the formula. And after someone purchases content from the Content Market and imports it into their realm, they could change it, delete it, and so on. They'd possibly be able to re-import it I imagine.

Yes, there's a technical issue regarding snippet ID that I didn't think through. That's pretty huge.

[Topic].[Section][.Snippet Name] is not a unique identifier because a) we don't name Snippets (they can have labels, but those are not "names") and b) because the actual unique identifier (if there is one) would not be shown to users and does not necessarily include section or Topic (which is why Snippets can be moved between sections and Topics, and why the same snippet can be added multiple times to a Topic).

You're right that the topics, even of the same type, aren't required to have identical snippet structure. Could RW id a snippet based on its label? Why not? One obvious problem is that snippet labels aren't unique, of course. That would be a big change to RW, probably on the order of the preparation for the content market.

Snippets likely DO have an index or something similar, which is currently invisible to the user. Perhaps that could be used, possibly transparent to the user. But likely there isn't anything that keeps that consistent from topic to topic. So yeah, huge problem.

You know that you can embed documents like spreadsheets in a Topic, right?

You know that an embeded document can't access data from another snippet, which was the point of the feature request, right?

The point was that if I changed one settlement in its topic, the kingdom's calculated field would reflect the change.

You also know that RealmWorks is system agnostic, right? While the primary content may be Pathfinder based initially, the product supports multiple game systems and genres without favoring any.

You realize that several of the other domain game systems I mentioned - BECMI, Adventurer, Conqueror, King were other game systems?

Several game systems have their own kingdom management rules. A calculated field would give RW the ability for users to implement their own, or to create them for sale in the content market.

Your Kingmaker example is already done. HeroLab already manages Kingdoms and the Mass Combat elements from Ultimate Campaign. The rules in Ultimate Campaign are updated and improved versions of those in Kingmaker. HeroLab also supports the Downtime rules from Ultimate Campaign, allowing PCs who are NOT rulers of Kingdoms to create and manage Buildings and Teams in settlements.

That's cool but it doesn't intersect with data within RW.

All of that is very Pathfinder-specific, though, which is why it won't be functionality in RealmWorks anytime soon --

And the people creating content right now for the upcoming Content Market are making content for specific systems. So however soon the Content Market comes, there will be system specific content in RW realms.

The feature request of calculated fields IS non-system specific functionality. My post then gave examples of content market system-specific product that could be achieved with that functionality.

Very specific, targeted "calculated snippets" can work, though. Dates make the most sense to me, as a) they are shared by just about all genres regardless of game systems, and b) there are many cases in which a published adventure or campaign does not have a fixed start date but expects the GM to set that.. and there are dates in the adventure or campaign that are "relative" to some of them.

What you suggest still has the same technical problem of identifying the different snippets. If that problem could be solved then much more could be possible.

 

[rob]

Please keep this thread positive and civil. The tone is starting to flirt with snarkiness and attitude. That needs to stop now. Thank you!

For clarification, the only thing that will be game-specific about upcoming content is the STRUCTURE of that content. There are NO game-specific mechanisms within Realm Works. That's the domain of products like Hero Lab. So calculated fields like have been proposed here are not something we're even considering at this juncture, and adding them would be an incredibly complex addition (since we'd be replicating much of Hero Lab in a very different manner). Obviously, that could change in the future, and discussing its usefulness and how it might work is great, so placing this here in the Feature Requests forum is perfect.

Just because something will be difficult doesn't mean it's without merit. And just because someone says something will be complicated doesn't mean they are attacking your ideas. Ideas are ideas. Facts are facts. Reality is reality. Everything in this thread thus far can all be true, and there's no reason for anyone to takes offense at either the ideas OR truths presented.

 

[Silveras]

Please keep this thread positive and civil. The tone is starting to flirt with snarkiness and attitude. That needs to stop now. Thank you!

I apologize. The phrasing "you know... , right?" was needlessly snarky on my part.

 

[Greebo]

(...)

It is not that I don't see some use-cases for "calculated" snippets.. but the kind of broad, user-defined-formula-processing ones you're describing would be a product on the scale of many times larger than RealmWorks itself .. or a spreadsheet.

Very specific, targeted "calculated snippets" can work, though. Dates make the most sense to me, as a) they are shared by just about all genres regardless of game systems, and b) there are many cases in which a published adventure or campaign does not have a fixed start date but expects the GM to set that.. and there are dates in the adventure or campaign that are "relative" to some of them.

(...)
[/list]

After reading all the comments, I agree with Silveras. And I consider calendar dates to be by far the most important calculated snippets

Maybe the random generator option could also profit from it by taking seasons, geographical regions and such into consideration for weather or random encounters.


Everything else could (and probably should) be done in HeroLabs. Even though I still have to learn the ropes to bring our homebrew rules into it.
And for the management and calculation of realms, manors, companies and the like there might be the need for more integration than just importing portfolios.

 

[kbs666]

I would think that there should be some way to do calculated snippets at least if all the source data was in the same topic.

Doing calculations across topics could run into some real issues, primarily in identifying the source snippets. Snippets obviously have a unique ID but exposing that to the user may not be desirable for a variety of reasons.

 

[Silveras]

Right.. the broader the scope, the more likely there is to also be a resource issue.. a matter of slowing the application while it searches for applicable snippets in applicable topics.

In addition, there is also the need for greater complexity in the search criteria. A calculated snippet that operates on all values of a certain target snippet may still require additional parameters.. otherwise, the calculated snippet may operate on too broad a range. Using the example above, a snippet of "gold" on Community Topics... it is highly unlikely to be desired that it total all gold for all Communities in all countries of the game world. So there would need to be some way to filter the Topics across which it operates.

Even the "relative date" snippets I mentioned could require additional limitations. Probably, the "relative date" snippets would need to limit their updates to when the Topic they are on is re-visited (much like how existing links recognize that their linked topic has changed, and prompts to change the text to match). Yet that could mean that the Timeline display shows inaccurate information for Topics that are not visited often. The alternative.. that changing the "anchor date" triggers an update of all related "relative dates" is possible, but then it becomes necessary to consider whether it is necessary to limit the number of such "anchor dates" and/or "relative dates"'; otherwise, the application may appear "stuck" while it is applying the changes.

 

[Cornelius]

Although I find this an interesting idea, I wonder when this option will be used.
As I see it it is mainly used when you input data into an existing realm. the data would only change during the input, not thereafter. Or is there a way you want to use it in other circumstances I do not see at the moment.

If during input is the only moment the data changes it should be possible to fixate it at that moment.

Calculating snippets would create a new sort of relationship. In this case between snippets instead of topics. The program should identify that the relationship changes when one of them is deleted or changed.

 

[Silveras]

Although I find this an interesting idea, I wonder when this option will be used.
As I see it it is mainly used when you input data into an existing realm. the data would only change during the input, not thereafter. Or is there a way you want to use it in other circumstances I do not see at the moment.

If during input is the only moment the data changes it should be possible to fixate it at that moment.

Calculating snippets would create a new sort of relationship. In this case between snippets instead of topics. The program should identify that the relationship changes when one of them is deleted or changed.

In the case of the "relative dates", it would come up in the course of using the material to run a campaign.

For example, Rise of the Runelords AP from Paizo.

The dates are left flexible for the GM to decide when the campaign begins. A number of key events are tied to "Five years before". The pace of the adventure is also left dependent upon the group... some aggressive groups will move from part to part faster than others who take more time. But when they are prepared to move on, there are encounters with histories that are based on "1 year ago", "six months ago", "1 week ago", etc. Exactly when those events occurred will be determined by when the players trigger that part of the adventure to begin (although, the longer back it is, the less need for it to be exactly that long ago).

In other cases, a particular part of the adventure may be on a "timer".. the players may have only a fixed amount of time in-game to prevent something bad from occurring. The date/time of the bad outcome is undefined until the date/time of the players' start is determined.

 

[Cornelius]

In the case of the "relative dates", it would come up in the course of using the material to run a campaign.

For example, Rise of the Runelords AP from Paizo.

The dates are left flexible for the GM to decide when the campaign begins. A number of key events are tied to "Five years before". The pace of the adventure is also left dependent upon the group... some aggressive groups will move from part to part faster than others who take more time. But when they are prepared to move on, there are encounters with histories that are based on "1 year ago", "six months ago", "1 week ago", etc. Exactly when those events occurred will be determined by when the players trigger that part of the adventure to begin (although, the longer back it is, the less need for it to be exactly that long ago).

In other cases, a particular part of the adventure may be on a "timer".. the players may have only a fixed amount of time in-game to prevent something bad from occurring. The date/time of the bad outcome is undefined until the date/time of the players' start is determined.

Interesting ideas. Some comments (not at critizism, but something that sprang to my mind reading this).

That would require some sort of anchor snippet that the GM fixates at a certain moment. Namely the moment (part of) the adventure is started.

The second part requires that you input the time that is used as they proceed through the adventure, in order for the timer to set. This also means that in the plot view suddenly certain paths become closed as the timer has ran out. I am not sure if you can program that into RW at all.

 

[Silveras]

Interesting ideas. Some comments (not at critizism, but something that sprang to my mind reading this).

That would require some sort of anchor snippet that the GM fixates at a certain moment. Namely the moment (part of) the adventure is started.

The second part requires that you input the time that is used as they proceed through the adventure, in order for the timer to set. This also means that in the plot view suddenly certain paths become closed as the timer has ran out. I am not sure if you can program that into RW at all.

Oh, I am not advocating any kind of programmatic timer within RealmWorks. The "timer" scenario I was talking about would simply mean that, when the "anchor" date for the start of the time period was set, the end date would be a calculated snippet (+3 days or the like).

The GM should be keeping track of current date and time, to some degree, anyway. It doesn't have to be as precise as "Oh, and you're out of time.. too bad.. the villains win" because the PCs were late by a round or two (except in rare cases for specific encounters).

Really, most Adventure Paths move "at the speed of plot", meaning that any "timer" is not literally a timer in the sense of an hourglass or stopwatch... except that specific encounters may have a requirement that the PCs finish their actions within "X rounds". For the dramatic tension in the campaign, though, the PCs always arrive "just in time" to interfere.

 

[Silveras]

On a different note.. a case for another calculated snippet occurs to me: Victory Points.

Some adventures/scenarios award the PCs "Victory Points" (or another term) for actions taken during the adventure. Sometimes it is a war situation, with the PCs acting as a small unit within the larger battle -- the degree of the PCs' success determines the degree of overall victory, as measured by the points they accumulate.

In this case, a table-like snippet for entering the awards of points, with the sum calculated, would be useful.

Note that this is, again, a limited-scope type of thing. The data is entered on one Topic in a single complex snippet. This would help to keep performance impact lower.

 

[Cornelius]

On a different note.. a case for another calculated snippet occurs to me: Victory Points.

Some adventures/scenarios award the PCs "Victory Points" (or another term) for actions taken during the adventure. Sometimes it is a war situation, with the PCs acting as a small unit within the larger battle -- the degree of the PCs' success determines the degree of overall victory, as measured by the points they accumulate.

In this case, a table-like snippet for entering the awards of points, with the sum calculated, would be useful.

Note that this is, again, a limited-scope type of thing. The data is entered on one Topic in a single complex snippet. This would help to keep performance impact lower.

To me this feels as something that is more on the Herolab side of things than on the RW side. Only the end result is something I would enter into Realmworks.

 

[Silveras]

To me this feels as something that is more on the Herolab side of things than on the RW side. Only the end result is something I would enter into Realmworks.

I could see that.... IF HeroLab supported "group operations" of some kind. The points I am talking about are not per-character, they are shared as "campaign progress" sorts of things.

I actually have considered suggesting a "The Party" new Hero-type for HeroLab, as a potential way to implement some of the desired improvements to the Tactical Console for Pathfinder without actually touching the Console itself.

 

[Cornelius]

I could see that.... IF HeroLab supported "group operations" of some kind. The points I am talking about are not per-character, they are shared as "campaign progress" sorts of things.

I actually have considered suggesting a "The Party" new Hero-type for HeroLab, as a potential way to implement some of the desired improvements to the Tactical Console for Pathfinder without actually touching the Console itself.

Ok. I am not that familiar with Herolab myself, as I usually play systems that are not supported by it. I think this option is one of those grey area things. I agree that it is a sort of campaign progress tracker so in that it could be part of RW.