LegacyKing and MertonMonk discuss specs for replacement app

From PCGen Wiki
Jump to: navigation, search

This page is to lay the groundwork for taking the best of existing PCGen and being unhindered with backwards compatible constraints to build a PCGen "Remastered".


Design Philosophy: Data driven, code engine system agnostic

UI/UX - Every "blade" should be fully customizable and language friendly (Support for any language) - We should be able to define these by 'system'

PCGen built sets based on books, which is a nice structure to understand what is included. But the method of selecting compatible books was painful. A checkbox and tree view would be ideal. Also the idea of optional rules being selected here would make sense. (DISCUSSION TOPIC)

Legal - Systems Licenses should be displayed or available to view, and each content source should clearly delineate it's license.

Code will utilize a simplistic design to replicate to all objects.

OUTPUT/DISPLAY - Most groups use smaller devices at their tabletop, formats like html or pdf that can be viewed is nice. We don't expect the app to be used real-time, but if it is, the displays should work and present the up-to-date details (especially true for temporary bonuses).

  • EXPORT: Do we retain the three formats, or move to a single format? FREEMARKER template engine is an impressive engine, it does have some drawbacks that the export needs to understand to function fully, but the engine has made vast improvements.

PDF - Has the most support and backend configuration (base.xml.ftl with the macros and templates > various blocks to allow for modular sheet building) - Talks surrounding a unified platform that could alter the output to various formats (Honestly a single template with multiple exports would be ideal and cut down on the knowledge required to add/remove features).



CODE / CONTENT

Re-use the code that shows promise:

Formula (Replacement for JEP)

Full Write up here - Setting up the Formula System

Not Coded:

What are we solving for - aka Requirements

In most d20 systems a character must prequalify before taking something (feats, powers); conversely, during some situations, the qualifications may be lost causing the loss of an ability (required)

Examples:

  • If a feat required Dex 13, and the character's dexterity is below 13 they lose access to the benefits of the feat.
  • A spellcaster requires a minimum spellcasting score to cast any given level.

PRE/REQ

PRE: What it takes to take the object REQ: What it takes to use the object


Spells/Power - This system while functional, is outdated and requires a major facelift.

Requirements - Ability to group spells together in a hierarchy (Classification, List, Level, or class/level as required by the system)

Examples:

  • 1e spells were grouped by category, schools, class and level
  • 3e spells were grouped by category, class specific level (Also some had special subcategories of casting/ability such as Specialization for wizards, and Domains for clerics)
  • 4e spells were called 'powers' and categorized by tiers and class
  • 5e spells were grouped by category, level

Spells need to be selectable based upon criteria, assignable to specific class or category. And update in real-time (We've had issues where spell assignments never populated until application or character reload)

Additionally, the ability to add and remove things such as attachments or crystals to equipment (aka containers) is a necessary issue. Tom, Mark and myself had a discussion on how to make sure bonuses would apply when attachments are used here: Attachment Proposal


Character save files: 1) Limitations - The saved file lacks the photo assigned to it (Dimensions, etc.) meaning a GM sent the file cannot have a working copy. The filepaths are absolutes typically meaning companions are broken when shared.

Directory Structure should allow for a more unified experience.

Characters and associated companions should be saved as such:

  • character_directory/game_system/characters <-- all characters
  • character_directory/game_system/characters/companions <-- All support companions

Taking a best practice, we should encode a uid for every character and use that as the reference to the pairing for companions (if we can make these globally unique, great, otherwise, something randomly generated based off of date, time and a random salt created per installation)

I'll use an xml format for illustration purposes, I really don't care how the final file format is made... But some initial ideas 

 <character>
  <name>Baldwin</name>
  <uid>20251029_efffe34437389734</uid>
   <linked_uids>
    <uid_1>
     <uid>20251029_fffejahdkjjkf</uid>
     <reference_name>Baldwin's Familiar</reference_name>
     <reference_relationship>companion</reference_relationship>
    </uid_1>
  <linked_uids>
 </character>

  <character>
   <name>Baldwin's Familiar</name>
   <uid>20251029_fffejahdkjjkf<uid>
   <linked_uids>
     <uid_1>
      <uid>20251029_efffe34437389734</uid>
      <reference_name>Baldwin</reference_name>
      <reference_relationship>master</reference_relationship>
     </uid_1>
   <linked_uids>
  </character>



NICE TO HAVE:

  • - Customizer

SUBPAGES:

PCGen 2e - Token List

Pathfinder 2e - Remastered design

Retrieved from "http://159.203.101.162/w/index.php?title=LegacyKing_and_MertonMonk_discuss_specs_for_replacement_app&oldid=4371"