How spells affect the physics layer through force application and tile transformations.

Spells interact with physics in two primary ways:

Shape Definition: Spells define geometric shapes (circles, rectangles, etc.) that cover regions of the game world.

Force Vectors: Each spell shape stores a force vector to be applied to overlapping objects.

Trigger Timing: Forces applied when spell triggers (after delay countdown).

Overlap Detection: Objects check if their center point overlaps any active spell shapes.

Impulse Elements: Apply instantaneous velocity changes (add to current velocity).

Velocity-Set Elements: Directly replace object velocity with spell-specified value.

Element Determination: Spell element type determines which force application method is used.

⚠️ NEEDS SPECIFICATION: Mapping of spell elements to force types TBD through spell system design.

See cross-referenceElement Effects for which elements create which force types.

Overlapping Spells: Objects can be affected by multiple spell shapes simultaneously.

Element Combination: When multiple spells overlap, combine elements using cancellation rules.

Cast Time Ordering: Process spells in cast time order for deterministic element combination.

Force Combination: After element combination, resulting force applied to object.

Primary Duty: Most double-element spells trigger tile type transformations in addition to applying forces.

Transformation Trigger: When spell activates on a tile, triggers type transformation rules.

Physics Integration: Transformations occur during physics pipeline execution.

⚠️ TODO: Triple-element spells will provide passive modifications to reactions and forces for their duration.

Design Intent: Global or area-of-effect modifications to physics behavior while spell is active.

Implementation: TBD through spell system design.

Spell Buffer Lookup: Objects check spell buffer for overlapping spell shapes during force accumulation.

Force Calculation: Calculate spell force based on element type and spell properties.

Vector Addition: Add spell forces to collision and cohesion forces for net force.

Mass Consideration: ⚠️ TBD - Determine if spell forces ignore mass or use standard F=ma.

Force Application Pass: Spell forces calculated in "Apply Forces + Move" GPU pass.

Transformation Pass: Tile transformations may occur in separate pass or integrated with forces.

Coordination: Ensure spell effects and physics forces execute in deterministic order.

See Pipeline Passes for multi-pass execution coordination.

Spell Data (per active spell):

Spatial Partitioning: ⚠️ Future optimization - Partition spells spatially to limit checks per object.

Per-Object Lookup: Each object queries spell buffer for overlapping shapes.

Overlap Test: Geometric test determines if object center is within spell shape.

Parallel Access: All objects can read spell buffer simultaneously (read-only access).

Determinism: All force calculations and transformations use fixed-point arithmetic.

Precision: Force vectors use 16.16 fixed-point format matching physics calculations.

Cross-Platform: Ensures identical spell effects across all hardware.

See cross-referenceDeterminism for fixed-point implementation details.

⚠️ NEEDS SPECIFICATION: Complete mapping of spell elements to force behaviors.

Expected Categories:

Design Source: Element effects defined in spell system documentation.

See cross-referenceElement Effects for complete element catalog.

Shape Evaluation: Spells define shapes that physics checks for overlap.

Element System: Element types determine force application method.

Trigger Lifecycle: Spell timing determines when forces are applied.

Cross-references:

Forces: Spell forces accumulate with collision and cohesion forces.

Movement: Spell forces modify object velocities like any other force.

Reactions: Spell transformations may interact with reaction system.

Internal references:

Buffer Size: Number of active spells affects lookup performance.

Overlap Tests: Geometric tests must be efficient (many objects checking many spells).

Spatial Optimization: Future partitioning can reduce checks per object.

GPU Parallelism: Spell force calculations fully parallelizable across objects.

Force Balance: Spell forces should be noticeable over ambient physics forces.

Element Diversity: Different elements should feel distinct through force behaviors.

Gameplay Clarity: Players should understand how spell elements affect physics.

Tuning Flexibility: Force magnitudes and behaviors exposed as configuration values.