Difference between revisions of "Major Code Projects"
LegacyKing (talk | contribs) (New page: The major code subsystems and projects for near term implementation (5.17+): BONUS system This project involves a bunch of refactoring and some thought into how it should be built State...) |
(→Output System) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {| align="right" | ||
| + | | __TOC__ | ||
| + | |} | ||
| + | |||
The major code subsystems and projects for near term implementation (5.17+): | The major code subsystems and projects for near term implementation (5.17+): | ||
| − | BONUS | + | =BONUS System= |
This project involves a bunch of refactoring and some thought into how it should be built | This project involves a bunch of refactoring and some thought into how it should be built | ||
| − | State: | + | '''State:''' |
| − | + | * The BONUS system is currently is very text based, which results in a lot of processing in order to capture the current bonus value for a particular bonus type. | |
| − | + | * The BONUS system is also deeply integrated in the core (code tangles or circular class dependencies depending on your vocabulary) | |
| − | Project Goals: | + | '''Project Goals:''' |
| − | + | * Ideally, the BONUS system should be more "random access" than the incrementing that is required in many cases | |
| − | + | * The BONUS system also has problems with and vs. or logic. One can apply a bonus to all melee weapons, or to all slaphing weapons. However, a BONUS cannot be applied to all weapons that are slashing AND melee (and only slashing AND melee) | |
| − | Output System | + | =Output System= |
This subsystem is primarily composed of our export tokens. | This subsystem is primarily composed of our export tokens. | ||
| − | State: | + | '''State:''' |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | * Output Tokens have a nasty habit of silently consuming errors, and there is very little in the way to validate Output Token Syntax. | |
| − | + | * Ouptut Tokens are half-plugin-ized, meaning many of them are plugins, but some are too tightly integrated in the core. | |
| − | - | + | * We also need a documentation review of Output Tokens, to ensure the documentation is complete and up-to-date. |
| + | '''Project Goals:''' | ||
| − | + | * The system needs a new concept of plugin to give export tokens more flexibility to allow them all to be plugins | |
| − | + | * Review export tokens vs. our documentation | |
| + | * Longer term, it would be nice for export tokens to be able to validate their syntax, as well as import and export tokens from the same file (the plugin). This gives a clean way to test round-robin behavior, as well as allowing us to deprecate tokens and change them to something else much easier. | ||
Latest revision as of 11:29, 17 December 2009
Contents |
The major code subsystems and projects for near term implementation (5.17+):
BONUS System
This project involves a bunch of refactoring and some thought into how it should be built
State:
- The BONUS system is currently is very text based, which results in a lot of processing in order to capture the current bonus value for a particular bonus type.
- The BONUS system is also deeply integrated in the core (code tangles or circular class dependencies depending on your vocabulary)
Project Goals:
- Ideally, the BONUS system should be more "random access" than the incrementing that is required in many cases
- The BONUS system also has problems with and vs. or logic. One can apply a bonus to all melee weapons, or to all slaphing weapons. However, a BONUS cannot be applied to all weapons that are slashing AND melee (and only slashing AND melee)
Output System
This subsystem is primarily composed of our export tokens.
State:
- Output Tokens have a nasty habit of silently consuming errors, and there is very little in the way to validate Output Token Syntax.
- Ouptut Tokens are half-plugin-ized, meaning many of them are plugins, but some are too tightly integrated in the core.
- We also need a documentation review of Output Tokens, to ensure the documentation is complete and up-to-date.
Project Goals:
- The system needs a new concept of plugin to give export tokens more flexibility to allow them all to be plugins
- Review export tokens vs. our documentation
- Longer term, it would be nice for export tokens to be able to validate their syntax, as well as import and export tokens from the same file (the plugin). This gives a clean way to test round-robin behavior, as well as allowing us to deprecate tokens and change them to something else much easier.
