Study notes
Our own functional analysis of mechanics worth learning from. This is where reading reference/ material turns into something usable.
These notes are committed, because they are our writing.
How to write one
Describe what a mechanic does and what problem it solves. Never record what a source says.
Follow the procedure in the originality policy: close the book first, then write from understanding. If you cannot restate a mechanic from memory in your own words, you do not yet understand it well enough to derive from it — go read it again rather than transcribing it.
Required shape
| Section | Contents |
|---|---|
| Problem | The design problem the mechanic addresses, stated generally |
| Approach | How it works functionally, in our words |
| Cost | What it charges the table — time, lookups, bookkeeping, arithmetic |
| Convergence | Whether the other reference systems solve this the same way |
| For C.A.T.S. | What we take, what we reject, and why |
The Convergence row matters most. Where several independent games land on the same solution, that solution is a genre convention rather than anyone's property, and it is the safest ground to build on. Where they diverge, there is no settled answer — so take the problem and solve it fresh rather than picking a favorite and reskinning it.
Hard limits
- No quoted rules text, of any length.
- No reproduced tables, and no reproduced values.
- No proper nouns from source games as C.A.T.S. terminology. Naming a source in analysis is fine — design discussion is not publication — but no chassis, weapon, faction, or species name is ever adopted.
- No numbers carried across. Ours come from our own math and playtesting. Matching values are the single clearest evidence of copying.
Naming
NN-topic.md, numbered in the order written — 01-heat-as-a-resource.md, 02-localized-armor.md. Reference them from CHANGELOG.md when a note drives a mechanical decision, so the influence trail stays visible.