Difference between revisions of "Architecture"
Tom Parker (talk | contribs) (→Current) |
Tom Parker (talk | contribs) (→Current) |
||
Line 46: | Line 46: | ||
==Current== | ==Current== | ||
+ | * [[Formula Parser Equip Vars Proposal]] which includes [[Formula Parser-JEP removal]] (sandbox) | ||
+ | * [[Core Connection to UI]] (DRAFT) | ||
* [[Current Architecture Projects]] (personal scratchpad) | * [[Current Architecture Projects]] (personal scratchpad) | ||
− | |||
* [[LST Token Information]] (scratchpad - relates to facet design and abstracting behaviors) | * [[LST Token Information]] (scratchpad - relates to facet design and abstracting behaviors) | ||
Revision as of 16:04, 25 May 2014
Introduction
Welcome to the Wiki section for the Architecture team!
Mission Statement
To guide PCGen through the re-architecting process, moving PCGen to a more robust and flexible architecture while improving both maintainability and expandability of the PCGen code base as the RPG community grows and the industry changes.
Resources
- Systems within PCGen
- Load UI: The Load UI is responsible for presenting the user with the options of game systems and components available to be loaded. The LoadUI triggers a call to the Rules Persistence system when the user requests for specific data to be loaded, and to the Character Persistence system when the user requests for a Player Character to be loaded..
- Editor UI: The Editor UI is responsible for presenting the user with the contents of the Rules Data Store. It communicates requests to change the contents of the Rules Data Store to the Rules Editor system.
- Player Character UI: The Player Character UI is responsible for presenting the user with the contents of the PC, including all of the PC's characteristics. Requests to modify a PC are sent to the Character Editor system for action.
- Startup System: The Startup System is responsible for the activities required to load PCGen to the state where a user can select an option from the Load UI. This includes discovery of Plugins.
- Rules Persistence: The Rules Persistence system is responsible for loading game system and component data from the data file format and saving it back into that data file format.
- Rules Editor: The Rules Editor system is responsible for providing the capability to modify the Rules Data Store. This includes modifying existing items and inserting new items into the Rules Data Store.
- Character Editor: The Character Editor system is responsible for providing the capability to modify the PC. Changes to the PC are communicated to the Event Controller as well as written into the Character Data Store.
- Character Persistence: The Character Persistence system is responsible for loading and saving PCs into the specified file format. The Character Persistence system is also responsible for creating and initializing a new Player Character.
- Character Output: The Character Output system is responsible for resolving the active objects on a PC, searching those objects to find specific information, and preparing that information for consumption by any of the systems that desire PC information.
- Rules Data Store: The Rules Data Store is the internal data structure used to store the game system and component information.
- Event Controller: The Event Controller acts as a hub to communicate events (typically triggered by changes to a PC) to the UI and to any loaded Plugins.
- Character Data Store: The Character Data Store is the internal data structure used to store the PC.
- Code Base - Key Concepts
- Walkthroughs
- Rules Data Store Concepts
Open Sub Projects
Current
- Formula Parser Equip Vars Proposal which includes Formula Parser-JEP removal (sandbox)
- Core Connection to UI (DRAFT)
- Current Architecture Projects (personal scratchpad)
- LST Token Information (scratchpad - relates to facet design and abstracting behaviors)
Future
- Internationalization
- Data Cleanup Projects
- PREREQ Cleanup
- PCG Round Robin Work (Tom's scratchpad)
- Bonus Subsystem Thoughts
- Bonus Subsystem Design
Past Projects
- Architecture Update 1Q2013
- Subsystem Isolation (out of date?)
- PObject - The Refactoring (effectively completed for most items - CDOMObject)
- Rebuild of the Token/Loader System (effectively completed for most items)
- Architecture Changes 5.17 (completed as much as would be in 5.17)
- Things to Test (now uses TEST- trackers)
Not used
Things not really part of the current architecture, but for context
Active Team Members
Silverback
2nd
- TBA
Lemur
Inactive Team Members
2nd
- Devon Jones