Karlinator / roll20-character-sheets

My fork of the Roll20 characters sheets. Used for developing the Stars Without Number: Revised sheet. My code here: https://github.com/Karlinator/roll20-character-sheets/tree/master/Stars_Without_Number_Revised
MIT License
1 stars 3 forks source link

Add a place to keep mods. #19

Open Karlinator opened 6 years ago

PanzerUXI commented 6 years ago

So had a thought about Mods that seems to solve a lot of problems, but I'm not sure its entirely possible that way Roll20 is built - need your thoughts too.

We currently have Play Mode and Edit Mode. Why not add a third - Modification Mode?

Imagine it takes all existing modifiable items that Play Mode sees as finished/roll-able and populates and sorts them by type - then allows you to uniquely select and put a "overlay" on top of that item that manipulates the stats it feeds the sheet.

The main benefit of this approach is mods become a agnostic system. It supports Equipment, Hardpoints, Cyberware, plus Drones, Mechs, Trans-human, Shells whatever and whenever they come down the line. We can auto-populate the modifications available to each type of item, and have a custom for people who like to really let their mechanics go batshit.

I hope I'm making sense, if not I'm happy to wire-frame it up. But ya, this solves all current mod problems, plus allows Trans-human and other future initiatives to fold in smoothly.

My fear is this means re-writing the whole backend. Hopefully not.

PanzerUXI commented 6 years ago

Had some great feedback from Dexter on another approach if above isn't possible. its super simple (and a complete and utter bitch to build an interface around) but - in Edit Mode, every item has a checkbox called Mod. If you click mod, it pushes all the content down/away/whatever and that item gets a new row with the options applicable to the source type.

For example, Weapon Items Mods brings up NAME OF MOD | ATTACK BONUS | DAMAGE BONUS | CHXBOX for Double Ammo/Zero Ammo/Special Ammo, etc. This approach scales to different types of source items, and basically is micro vs. macro. But it mechanically works.

joesinghaus commented 6 years ago

The second option sounds more realistic to me. Adding this stuff to EVERY item is going to need a lot of extra fields everywhere, and I'd rather avoid blowing up the number of attributes on the sheet (even if most of them will end up staying at their default values). There's a very real performance impact once the number of fields goes up.

PanzerUXI commented 6 years ago

Does the performance take a hit if it only adds Mod fields when the object is checked as Modded? Or are all the fields there, and chugging the thing down, only to be revealed when Mod is checked?

joesinghaus commented 6 years ago

They are always going to be there.

I think the performance impact of attributes (=fields different from their default) is worse than of fields at their default value, but even input fields at their default slow down the sheet. Maybe I'm needlessly worried about this, but I think it's good to think about performance early before it becomes a problem.

Karlinator commented 5 years ago

Another much less interesting (but far simpler) option is based on the fact that all the weapon etc attributes are editable by default. Simply expecting people to edit them (as I expect they are doing now) and putting a text field (or repeating section) on the bottom of the weapons etc would allow for rudimentary tracking (change the stats and list the mods by name). Not near as elegant or functional, but implementable with little effort.

Could also be used as a stopgap, but that would complicate the process of adding a more complete solution like the ones above because now data migration is an issue.