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]

Originally Posted by 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.

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]

Originally Posted by Silveras

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]

Originally Posted by 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!

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

[Greebo]

Originally Posted by Silveras

(...)

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.