Define shared semantic colors and non-color gameplay cues

[zoeyrose]

Important

This preserved product issue is now part of the fresh MIT replacement program. Final implementation owner: atrinik/client. Legacy C/SDL2, packet, global-state, and file-path details below are historical evidence only.

Replacement implementation contract

Preserve every semantic role, theme, contrast, and non-color accessibility rule. Implement Rust semantic presentation tokens consumed by client UI and renderer materials; no widget may embed authoritative RGB meaning.

New implementation and tests are independent MIT work unless an exact contribution by an approved MIT provenance grantor is admitted through the recorded file-level MIT grant. Do not copy or mechanically translate other GPL source/tests. Preserve every player-facing, accessibility, disclosure, and performance design decision below.

Required verification

• Add deterministic Rust and/or Go tests at the owning boundary plus cross-language protocol fixtures for new fields.
• Exercise malformed/stale/reordered inputs and lifecycle failure without partial state.
• Use the shared renderer rather than a client/editor fork.
• Validate through a wrapper-managed replacement scenario where the feature is interactive.

Preserved product/design specification and historical implementation notes

Summary

Define one client-wide semantic color and accessibility contract before monster danger, skill-XP suitability, and item rarity all reuse the gray-through-purple palette with unrelated meanings.

Color may reinforce meaning, but context, text, symbol, shape, and state must carry enough information that players never need to infer a gameplay concept from hue alone.

Ownership

This issue owns semantic presentation tokens and accessibility rules. It does not own gameplay thresholds or rarity assignment:

• Show monster XP suitability for a selected combat skill #9 owns server-authoritative monster danger and selected-skill XP bands.
• Add visible loot rarity tiers server#6 owns the item-rarity enum and item presentation requirements.
• Add resolution-independent UI scaling and native display/frame pacing #20 owns resolution-independent UI, typography, scaling, and settings integration.

Contract

Create a small semantic-token API and documented presentation matrix covering at least:

• danger relative to character level;
• XP suitability relative to the selected combat skill;
• item rarity;
• friendly/hostile/selected/disabled states;
• warnings, errors, success, and informational text.

For every semantic state, define:

• color token and contrast requirements in supported themes;
• required text label or accessible description;
• icon, frame, line style, pattern, or shape where the state appears graphically;
• permitted compact treatment and the location of its expanded explanation;
• composition and priority when multiple states share one widget or sprite;
• grayscale and common color-vision-deficiency expectations.

The same raw color may be reused in clearly separated contexts only when the accompanying label/shape makes the meaning unambiguous. Do not expose protocol enums as arbitrary RGB values, infer gameplay state from a rendered color, or make localized display text the stable semantic identity.

Implementation direction

• Keep server protocols categorical and bounded; clients map stable semantic enums to theme tokens.
• Centralize client token lookup rather than duplicating RGB literals across target, map, inventory, tooltip, and comparison widgets.
• Provide a high-contrast/default theme and enough override structure for future theme work without making every widget independently configurable.
• Let automated screenshot/UI tests inspect semantic roles or tokens rather than fragile exact pixel colors where practical.
• Coordinate item-icon composition with Show mana-crystal charge on inventory and quickslot icons #7/#230's shared adornment helper.

Acceptance criteria

• Danger, XP suitability, and item rarity remain unambiguous when shown together or in rapid succession.
• Every color-coded gameplay state has a text, symbol, shape, pattern, or expanded explanation that does not depend on hue.
• Target, map, inventory, quickslot, tooltip, and comparison presentations consume shared semantic tokens.
• Contrast is validated for default and high-contrast themes at supported UI scales.
• Grayscale and representative color-vision-deficiency checks preserve the required distinctions.
• Protocol and saved-state contracts contain semantic enums/IDs, never theme-specific RGB values.
• Focused visual tests cover combined selection, hostility, rarity, charge, status, danger, and XP cues without obscuring critical information.

Validation

Add token-table validation, contrast checks, semantic screenshot fixtures, and manual review at multiple UI scales. Exercise ordinary and high-contrast presentation in target, map, inventory, quickslot, tooltip, and item-comparison contexts.