Additional page category request: Monsters

[StarSword-C]

Pretty much what it says: right now if I want to have a note about a custom beastie, the closest thing available is the NPC category. It'd be nice to have a dedicated template for generic mobs.

[carlonicora]

Hi @StarSword-C

One of the consideration I did when I was creating the component, was that the component in itself was "unique" to the system.

The non-player character "John" uniquely identifies one non-player character.

In case of monsters, the type monster is not unique, I cannot have a Nazgul as which one of the nine are you referring?

The "Nazgul" can be more than one, is it the Witch King of Angmar or one of the remaining eight?

I understand the need of having a repository of monsters, but are they components of the system, or are they a template?

I can see the possibility to expand RPG Manager to support something different from a component, something reusable, but wouldn't this be better to be distributed (aka, not just in one vault)?

@sigrunixia any feedback is welcome!

[sigrunixia]

@StarSword-C Would be able to provide a screenshot or a copy and paste of how you currently would use the npc template as a custom beastie, and define in your view what is missing from it?

On Mooks

For stat blocks, there are better tools available for that and it would be more conductive for RPGM to look into interfacing with those tools (which is something that is on the roadmap).

Particularly, if we are dealing with same named entities that are to the effect of mooks or zerglings. The generic orc or whelp. In standard rpg programs, hidden unique id's are assigned to entities of the same name type to give them a unique name on the backend to manage this.

On Unique, Named Entities

If you are finding that there are certain questions, elements, linking items, or other things that are preventing you from writing a well-written named beast, deity, or some other unique entity, then there is more flexibility. Making "Dixstraln the Blackwhelp" and "The Lone Orc Warrior" under a different component than NPC is doable.

How Can We Best Help Under RPGM Philosophy

RPGM at its core, is to help you as a user, make better stories, which will make better campaigns.

What help does a GM/DM need writing them? What are the existing, published campaigns missing from them? Are we looking to add creature types? Do we need a bit of ethnic schism? Economic schism? Other moral quandaries? Would a primer on how monsters are created in society traditionally, be beneficial in creating more unique monsters that avoid some existing problematic elements? On a more technical side, do we need more static, but linkable, RPGM templates for available use alongside dynamic templates?

What We Need From Users

1. Feedback. What would you need to write exciting but well-rounded challenging external elements (typically what a "monster" fulfills in a story), out of RPGM.
2. If you are looking for integrations into existing Obsidian applications that handle monsters, or, you have an existing bestiary in markdown format and want to find a way to get it into RPGM to flesh it out further. We'd like to know.

[sigrunixia]

Adding Label of All User Feedback Requested as this is in the same vein as issue #125. It may be a documentation need on my end.

[StarSword-C]

@StarSword-C Would be able to provide a screenshot or a copy and paste of how you currently would use the npc template as a custom beastie, and define in your view what is missing from it?

This is what I'm doing right now:

Besides putting a "The" at the start of the synopsis display, I would suggest a field for typical locations where you'd find the monster, e.g. wetlands, deserts, cemeteries. The date fields can probably be removed.

I made an NPC page and sorted it under a "Monsters" subfolder. At the moment the note is just a Markdown download of the web page I read about it from. (The given statblock is for the wrong system: it's for D&D 5E and I run Pathfinder 1E.)

The only time I've put a statblock into a note so far, I just made a table with another plugin and adapted the Pathfinder SRD format (this one is a specific NPC I lovingly ripped off from a 3.5E book):

[sigrunixia]

Initial Thoughts - Location

It may make more sense to tweak locations to allow for environment as a subcomponent. Enough rpg's use environment as a factor that adding it as a core feature in an upcoming release might be warranted.

Possible Implementation

How that would look in this case is under the Locations component, a new column would be added with a name of Type and would be filled with the environment, ideally linked. This would provide quite a bit more flexibility overall from a design standpoint.

Locations	Name	Type	Synopsis
Taligras	Dessert	A planet made of fruit. yes, fruit. This sugary world is experiencing a "sugar gold rush" after the discovery of Sugar-Wyrm eggs and their explosive properties.

Initial Response - Entities or Backgrounds

If we're not looking to create a monster-specific function with a new component, then perhaps what you might be looking for, and what might be missing, is the ability to define and track more thoroughly, an entities biological grouping. Whether it is ethnicity, taxonomy, and so on. I see the use case in wanting to and needing to be able to focus on the storytelling of where a group of merchants might run into a Hortlak enjoying their dinner, or in defining that its gnomes who come upon the unwelcoming village of Chieftain Meh whose tribe is named Guhgnomes-Tastee.

More Feedback Please!

Anything else you can think of? @StarSword-C

Edit: Adding tag documentation as no matter what additional documentation will be needed on "Plotting custom monsters."

[StarSword-C]

An Entities tab as you describe would probably be a good thing. Right now I'm using the Factions tab for things like tribes (a significant portion of the campaign is intended to take place in Karazh, a confederation of horse nomad tribes in Casmaron a la the Mongols, Kazakhs, Uzbeks, etc.) and Locations for nation-states (the Karazh page itself is there, ditto the Empire of Kelesh to the south).

[sigrunixia]

For @carlonicora's sake, the initial defining lines between these components as they can appear related Factions - Something the player characters, non-player characters, and entities can join, leave, born into, forced into, die from.

Entities - The current manifestation of what the player characters, non-player characters, other beings are.

We specifically leave the rest up to the DM/GM and players to define further. This can be monsters, this can be races, this can be bacteria, this can be gods, supernatural stuff, living weapons, spells, you name it, it can be it. I suppose the only requirement is it might have some sense of self awareness as that is what entity means?

Example: Kerry the entity (human) is born into a faction (democrat). They decide to leave the faction-democrats and become a faction-RaMen, wherein they are subsumed by an unknown entity (aberration) and become an entity-aberration themselves.

[carlonicora]

@StarSword-C Thanks for the feedback and thanks @sigrunixia for helping out so brilliantly!!!

I would like to think about this, especially how to make it work. I think that it would be feasible to create a new type of components that works in a different way from the current elements, but there are both implementation and logic challenges. Give me a few days and I will come back with a working proposal based on what you discussed and came up with!

[StarSword-C]

Sweet!

[carlonicora]

So, I have been pondering over the monster request, and I have a couple of points here.

Preface

I use the word component to define every entity read by RPG Manager. The component can be of three types:

1. Plot (Campaign, Adventure, Act and Scene)
2. Run (Session)
3. Element < bad naming convention here! > (Player character, Non-player character, Clue, Event, Location, Faction, Music, Subplot)

Whenever I speak about an entity recognised by RPG Manager, I speak about a component.

Domain

The major point behind my skepticism in creating a new type of component, was not entirely clear to me, but digging deeper I got there. When we talk about a non-player character, we define the campaign as the domain of this component. The component lives and breathes inside a campaign. Obviously, the campaign is the only exception to this, as it is the parent to all the other components.

A monster, on the other side, has a completely different domain: the setting. A Nazgul is in the setting MERP, while a Dragon can either be in 5e or MERP (and the two will be different).

This distinction is fundamental, because the advantage of having a setting-specific type of component is something that would allow a storyteller to reuse the same monster in multiple campaigns. At the moment the components cannot be shared amongst campaigns.

Possible solutions

I can see three possible solutions to @StarSword-C need, and they all have pro and con. Let me show you the three possible scenarios:

The cheap, dirty and fast

I create a new component called monster, that remains in the domain of a campaign and you simply duplicate everything you need in multiple campaigns.

Pros: fast and cheap Cons: you need data duplication, and you mix apples (implementation of entities) with pears (generic entities)

Carlo's consideration: I would avoid it, in the long run it doesn't pay off

A new type of hierarchy

From the get-go, RPG Manager was designed to be setting-agnostic (after all I play with my own custom rules, so...). However, with the idea of starting a Vampire Campaign soon, I designed a system that would lend itself to allow granular customisations to specialise certain component for a specific setting (Vampire, Cthulhu, 5e, etc...). This is something that is not fully present in RPG Manager, but it is coming: the system already handles it well in a few tests.

That said, I could extend the flexibility of the component to allow a parenthood not just to a campaign, but to a system setting. This would allow the creation of reusable components in multiple campaigns. Monsters are an example, but in a way or another I could extend it to Locations and Factions as well...

Pros: super flexible, component become reusable and, in a way or another, they can be extended from generic to specific Cons: This is a bit time consuming and will require some re-tinkering of how RPG Manager handles certain information

Carlo's consideration: Definitely the way to go

Elevating the system setting

Consider the previous point and now imagine a service on which you can share and download multiple component and adapt them. You need a Red Dragon, and you find a version of the Red Dragon in the online service. In return, you may want to upload your goblin (well, a goblin is cheap compared to a mighty red dragon, but I am sure you get the gist).

Pros: as many as you like to count. Flexible, scalable and fast as hell (as you reuse someone else's work Cons: Hell, it's time consuming... VERY time consuming

Carlo's consideration: That's a cool future, one in which you can share even your adventure plot structure and get ideas, but I am not sure this can come before the previous step...

Final Consideration

Implementing a cheap solution is not the best option. In the same way as you are creating your custom notes, you could create a custom monster. I would go for option 2. Something to be implemented in the next month(s), but something which would add value for the storytellers, for RPG Manager and would lay the foundations for the third option.

Thoughts?

[sigrunixia]

Option 1 would not fit within the philosophy, mission, or scope of RPGM, so I would not even take it a step further. Kludging together new features for the sake of new features is within your normal standards of practice, I sense. No reason to start now.

Option 2 is what I would consider to be the base or core feature. A system that can expand to support new key-lock pairings for new modules. Basically, an api but expressed as components and modules. At first, it would be limited to base RPGM and Carlos "mods".

Option 3 is the expression of Option 2 when given more function. It requires that we tackle other things before doing this. If we're considering sharing adventures and plot lines and campaigns, we'll need some mandatory standardization of how those files are to be shared, how they are to be written, and so on. Its a long term project. :)

---

If we're voting, I'm for number 2.

[StarSword-C]

To be clear, I'm very much a novice with Obsidian: my brother introduced me to it literally last week when I mentioned to him I was developing this campaign (I've got a good year+ before I actually have to run it). I didn't expect to open this big of a can of worms when I made this feature request, I just seem to have a tendency to do that lol. 😋

Looking back through the thread, to be clear, you're using the word "component" to mean the same thing I meant by "template" in the OP ("template" to me = blank component).

If I was in your shoes, I probably would start with option 1 — create a campaign-level Monster component — because it solves the immediate problem (I don't have enough irons in the fire GM-wise to make duplicating files time-prohibitive), and then turn around and address the larger question of cross-campaign reusability (option 2) in a subsequent version.

[sigrunixia]

@StarSword-C Close. Let me use an analogy. A template in your case would be, design wise, a turtle shell. A component as we are defining it is the turtle itself, sans shell.

• Option one would result in a stuffed turtle with a pretty shell, like a vehicle crash-test dummy. Temporary to set up that will work, but gets destroyed in short notice. It's created purely to be destroyed.
• Option two grows the turtle, feeds it, and it grows a healthy shell. It will live as long as RPGM does.
• Option three grows the turtle, feeds it, and also equips it with the ability to get nitrogen speed boosts. And its red. And maybe somehow learns the spell finger of death down the road.

[sigrunixia]

I'm still mulling about possible ways to make this more functional. In the interim~

• [ ] Explore the possibility of building a wrapper around obsidian-5e-statblocks. #189

[sigrunixia]

Closing this as this will be rolled into the rewrite considerations.