Skip to content

Feature Request: Resolving Visual Collisions (Wall of Force vs Wall of Stone) with a 7th Attribute (Semantic Enum) #3

Description

@CaioBGalvao

First of all, congratulations on the project! The system is a brilliant mix of procedural generation, graph theory, and world-building.

However, as mentioned in the video, the current 6-attribute system (Level, School, Damage Type, AoE, Range, Duration) faces a collision problem. Because spells like Wall of Force and Wall of Stone (or Bane and Bless) share the exact same mechanical base, they generate the exact same 2D shape.

To solve this while maintaining the system's mathematical rules and keeping the shapes wizard-readable, I would like to propose the addition of a 7th Attribute: The Semantic Descriptor (Enum).

The Proposed Solution

You could add a categorized "Tag" or "Enum" as the 7th attribute. Older systems like D&D 3.5e had something similar called "Descriptors," and modern mechanically optimized systems like Pathfinder 2e use "Traits" to handle exactly what D&D 5e tries—and often fails—to solve using only natural language.

This attribute would define the Nature or Form of the magic. Here is how some of these tags would structurally improve both the visual runes and the game's logic:

  • Aura: Currently in 5e, auras are clumsily described as "Sphere" AoEs with a "Self" range (e.g., Spirit Guardians). Adding an "Aura" tag formalizes that the spell moves with the target and dynamically affects the environment, standardizing interactions with passive abilities without relying on text interpretation.
  • Barrier (Wall): 5e struggles heavily to define Line of Sight vs. Line of Effect for walls (Wall of Force, Prismatic Wall). A "Barrier" property natively resolves total cover rules, instantly defining if the magic blocks physical projectiles, magic effects, or just vision.
  • Blessing / Curse: 5e relies on textual workarounds (e.g., Remove Curse only works if the spell's description literally contains the word "curse"). A tag strongly "types" the magic: "Curse" defines persisting debuffs requiring specific removal magic, while "Blessing" groups buffs that interact with divine protections or targeted dispels.
  • Projectile vs. Ray/Beam: 5e treats both simply as "Ranged Spell Attacks". Splitting them offers huge optimization potential:
    • Projectiles (Ice Knife, Acid Arrow) have physical mass generated by magic and should be blocked by things like Wind Wall.
    • Rays/Beams (Eldritch Blast, Scorching Ray) are pure energy/light. They bypass wind and introduce mechanics like reflection (bouncing off mirrors in a dungeon or a Tarrasque's carapace).
  • Summon: The Conjuration school is too broad, housing teleports, object creation, and entity summoning. A "Summon" property perfectly isolates spells that place new actors (tokens) on the grid and initiative tracker. (WotC tried to patch this recently by standardizing summoning spells, but a native property makes it much more elegant).

The Math (The 15-Sided Polygon)

Following the system's own established formula of (2 * Attributes) + 1 for the number of vertices, adding this 7th attribute would smoothly evolve the base geometry from a 13-sided polygon to a 15-sided polygon (Pentadecagon).
The new Semantic Descriptor would simply occupy the K=7 layer of the drawing.

The Arcane UX (Why this works for lore)

A wizard isn't a computer; they rely on visual pattern recognition. With this approach, a wizard looking at the spell would read the mechanical layers (K=1 to K=6) to understand it's a Level 1 Enchantment with a 1-minute duration, and then look at the K=7 layer to see the "Curse" descriptor.
Through deductive reasoning, the wizard instantly knows it's Bane and not Bless.

It anchors the rigid mechanical data to a conceptual visual cue, completely resolving the uniqueness violation without breaking the legibility of the rune.

Would love to hear your thoughts on evolving the geometry to accommodate a 7th conceptual layer!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions