Skip to content

patterns.md

Latest commit

 

History

History
279 lines (209 loc) · 5.46 KB

patterns.md

File metadata and controls

279 lines (209 loc) · 5.46 KB

Patterns

VectorRen games are intentionally small, isolated, and behavior‑driven.
Even though no game shares code, they do share ideas.
This document captures the recurring conceptual patterns that appear across games — movement, collisions, spawning, timing, input, and world rules.

These patterns are conceptual, not prescriptive.
They describe how things behave, not how they are implemented.

1. Movement Patterns

Movement in VectorRen is deterministic and time‑based.
Entities move according to their velocity, and velocity changes according to forces or input.

Linear Movement

Given an entity with position and velocity  
When time advances  
Then its position changes by velocity multiplied by elapsed time

Angular Movement

Given an entity with angular velocity  
When time advances  
Then its rotation changes accordingly

Acceleration

Given an entity with acceleration  
When time advances  
Then its velocity changes by acceleration multiplied by elapsed time

Thrust‑Based Movement

Given a ship facing a direction  
When thrust is applied  
Then its velocity increases along that direction

Movement patterns should be simple, predictable, and testable.

2. Wrapping Patterns

VectorRen games often use a bounded world where entities wrap around edges.

Horizontal Wrap

Given an entity beyond the right boundary  
When wrapping is applied  
Then it appears on the left boundary

Vertical Wrap

Given an entity beyond the top boundary  
When wrapping is applied  
Then it appears on the bottom boundary

Full Wrap

Given an entity outside any boundary  
When wrapping is applied  
Then it reappears on the opposite side

Wrapping keeps the world continuous and avoids invisible dead zones.

3. Collision Patterns

Collisions in VectorRen are conceptual, not pixel‑based.
They rely on simple geometric rules.

Circle‑Based Collision

Given two entities with collision radii  
When the distance between them is less than the sum of their radii  
Then a collision occurs

Destructive Collision

Given a bullet and an asteroid  
When a collision occurs  
Then both are removed and the score increases

Splitting Collision

Given a large asteroid  
When it is destroyed  
Then two smaller asteroids appear with new velocities

Collision patterns should be deterministic and easy to reason about.

4. Spawning Patterns

Spawning introduces new entities into the world.

Timed Spawning

Given a spawn timer  
When the timer expires  
Then a new entity appears and the timer resets

Event‑Driven Spawning

Given a destroyed entity  
When a specific condition is met  
Then new entities appear

Randomized Spawning

Given a spawn region  
When an entity is created  
Then its position and velocity are chosen from a controlled random range

Randomness should be bounded and testable.

5. Input Patterns

Input affects behavior, not rendering.

Continuous Input

Given a key is held  
When input is processed  
Then the associated action continues

Discrete Input

Given a key is pressed  
When input is processed  
Then a single action occurs

Input Cooldown

Given an action with a cooldown  
When the player triggers it  
Then it cannot be triggered again until the cooldown expires

Input patterns should be simple and predictable.

6. Timing Patterns

Timing governs updates, cooldowns, and lifetimes.

Delta‑Time Update

Given a previous timestamp and a current timestamp  
When the game updates  
Then elapsed time is the difference between them

Cooldown Timer

Given an action with a cooldown  
When the action is used  
Then the cooldown timer starts and must reach zero before reuse

Lifetime Timer

Given an entity with a lifetime  
When time advances  
Then the entity is removed when its lifetime expires

Timing patterns keep the game deterministic.

7. State Patterns

State is explicit, minimal, and easy to inspect.

Entity State

Each entity tracks only what it needs:

  • position
  • velocity
  • rotation
  • radius
  • flags

World State

The world tracks:

  • entities
  • timers
  • score
  • lives
  • input state

Immutable or Clean Updates

Given a state update  
When applying changes  
Then produce a new state or a clean mutation

State patterns keep logic clean and testable.

8. Rendering Patterns

Rendering is separate from behavior.

Transform‑Based Rendering

Given an entity with position and rotation  
When rendering  
Then apply transforms to its SVG group

Stable DOM

Given an entity that persists  
When updating  
Then its DOM node remains the same and only transforms change

Declarative Styling

Given visual rules  
When styling entities  
Then use classes and CSS instead of inline attributes

Rendering patterns keep the DOM readable and debuggable.

9. Pattern Anti‑Patterns

Avoid these:

  • mixing logic and rendering
  • mutating DOM attributes every frame
  • deep DOM nesting
  • clever abstractions
  • hidden state
  • random behavior without bounds
  • tests that depend on rendering

Patterns should simplify, not complicate.

Final Note

Patterns are shared knowledge, not shared code.
They help contributors build consistent, explainable games without creating a framework or engine.

Use patterns when they clarify behavior.
Ignore them when they get in the way of fun.