@inglorious/engine 0.2.0 → 0.3.0

package/README.md

@@ -1,75 +1,75 @@
-# Inglorious Engine
-
-[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
-
-A JavaScript game engine written with global state, immutability, and pure functions in mind. Have fun(ctional programming) with it!
-
-## Features
-
-- **Functional & Data-Oriented**: Uses a single, immutable state object as the source of truth, inspired by functional programming principles.
-- **Composable by Design**: Build complex behaviors by composing pure functions and decorators, offering a powerful alternative to inheritance.
-- **Renderer Agnostic**: The engine is headless. You can use any rendering technology you like, from Canvas2D and HTML to React components.
-- **Zero Build Step**: Write plain JavaScript and run it directly in the browser. No complex build configurations to worry about.
-
-## Documentation
-
-The best way to get started is with the official documentation, which includes a **[Quick Start Guide](https://inglorious-engine.vercel.app/?path=/docs/quick-start--docs)**.
-
-Full documentation is available at: **[https://inglorious-engine.vercel.app/](https://inglorious-engine.vercel.app/)**
-
-## Why Functional Programming?
-
-What makes this engine different from all the others is that, instead of Object Oriented Programming (OOP), which seems the most obvious choice for a game engine, this one is based on Functional Programming (FP).
-
-FP has many advantages:
-
-1. **Single Source of Truth**: Your entire game state is a single, plain JavaScript object. This gives you complete control over your game's world at any moment, rather than having state scattered across countless objects. This is the core idea behind the Data-Oriented Design (DOD) paradigm that many modern engines are now adopting. With this engine, you get that benefit naturally.
-
-2. **Efficient Immutability**: A common misconception is that creating a new state on every change is slow. This engine uses structural sharing (via Immer), meaning only the parts of the state that actually change are copied. The rest of the state tree is shared by reference, making updates extremely fast. This provides a huge benefit:
-   - **Optimized Rendering**: Detecting changes becomes trivial and fast. A simple reference check (`prevState === nextState`) is all that's needed to determine if data has changed, enabling highly performant UIs (especially with libraries like React). This is much faster than the deep, recursive comparisons required in mutable systems.
-
-3. **Pure Functions**: Game logic is built with pure functions — functions that return a value based only on their inputs, with no side effects. This makes your game logic predictable, easy to test in isolation, and highly reusable, freeing you from the complexity of class methods with hidden side effects.
-
-4. **Composition over Inheritance**: Instead of complex class hierarchies, you build entities by composing functions. Think of it as a pipeline of operations applied to your data. This is a more flexible and powerful alternative to inheritance. You can mix and match behaviors (e.g., `canBeControlledByPlayer`, `canBeHurt`, `canShoot`) on the fly, avoiding the rigidity and common problems of deep inheritance chains.
-
-5. **Dynamic by Nature**: JavaScript objects are dynamic. You can add or remove properties from an entity at any time without being constrained by a rigid class definition. This is perfect for game development, where an entity's state can change unpredictably (e.g., gaining a temporary power-up). This flexibility allows for more emergent game mechanics.
-
-6. **Unparalleled Debugging and Tooling**: Because the entire game state is a single, serializable object, you can unlock powerful development patterns that are difficult to achieve in traditional OOP engines.
-   - **Time-Travel Debugging**: Save the state at any frame. You can step backward and forward through state changes to find exactly when a bug was introduced.
-   - **Hot-Reloading**: Modify your game's logic and instantly see the results without restarting. The engine can reload the code and re-apply it to the current state, dramatically speeding up iteration.
-   - **Simplified Persistence**: Saving and loading a game is as simple as serializing and deserializing a single JSON object.
-   - **Simplified Networking**: For multiplayer games, you don't need to synchronize complex objects. You just send small, serializable `event` objects over the network. Each client processes the same event with the same pure event handler, guaranteeing their game states stay in sync.
-
-7. **Leverage the Full JavaScript Ecosystem**: As a pure JavaScript engine, you have immediate access to the world's largest software repository: npm. Need advanced physics, complex AI, or a specific UI library? Integrate it with a simple `npm install`. You aren't limited to the built-in features or proprietary plugin ecosystem of a monolithic engine like Godot or Unity.
-
-## Architecture: State Management
-
-The engine's state management is inspired by Redux, but it's specifically tailored for the demands of game development. If you're familiar with Redux, you'll recognize the core pattern: the UI (or game view) is a projection of the state, and the only way to change the state is to dispatch an action.
-
-However, there are several key differences that make it unique:
-
-1.  **Events, not Actions**: In Redux, you "dispatch actions." Here, we "notify of events." This is a deliberate semantic choice. An event handler is a function that reacts to a specific occurrence in the game world (e.g., `playerMove`, `enemyDestroy`). The naming convention is similar to standard JavaScript event handlers like `onClick`, where the handler name describes the event it's listening for.
-
-2.  **Asynchronous Event Queue**: Unlike Redux's synchronous dispatch, events are not processed immediately. They are added to a central event queue. The engine's main loop processes this queue once per frame. This approach has several advantages:
-    - It decouples game logic from state updates.
-    - It ensures state changes happen at a predictable point in the game loop, preventing race conditions or cascading updates within a single frame.
-    - It allows for event batching and provides a solid foundation for networking and time-travel debugging.
-
-3.  **Core Engine Events & Naming Convention**: The engine has a few built-in, **single-word** events that drive its core functionality. To avoid conflicts, you should use **multi-word `camelCase`** names for your own custom game events (`playerJump`, `itemCollect`). This convention is similar to how custom HTML elements require a hyphen to distinguish them from standard elements. Key engine events include:
-    - `update`: Fired on every frame, typically carrying the `deltaTime` since the last frame. This is where you'll put most of your continuous game logic (like movement).
-    - `add`: Used to add a new entity to the game state.
-    - `remove`: Used to remove an entity from the game state.
-    - `morph`: Used to dynamically change the behaviors associated with an entity's type.
-
-4.  **Ergonomic Immutability with Immer**: The state is immutable, but to make this easy to work with, we use Immer. Inside your event handlers, you can write code that looks like it's mutating the state directly. Immer handles the magic behind the scenes, producing a new, updated state with structural sharing, giving you the performance benefits of immutability with the developer experience of mutable code.
-
-5.  **Composable Handlers via Function Piping**: Instead of large, monolithic "reducers," you build event handlers by composing smaller, pure functions. The engine encourages a pipeline pattern where an event and the current state are passed through a series of decorators or transformations. This makes your logic highly modular, reusable, and easy to test in isolation.
-
-6.  **Handlers Can Issue New Events (Controlled Side-Effects)**: In a strict Redux pattern, reducers must be pure. We relax this rule for a pragmatic reason: event handlers in this engine **can notify of new events**. This allows you to create powerful, reactive chains of logic. For example, an `enemy:take_damage` handler might check the enemy's health and, if it drops to zero, notify of a new `enemy:destroyed` event.
-    - **How it works**: Any event notified from within a handler is simply added to the end of the main event queue. It will be processed in a subsequent pass of the game loop, not immediately. This prevents synchronous, cascading updates within a single frame and makes the flow of logic easier to trace.
-
-    - **A Word of Caution**: This power comes with responsibility. It is possible to create infinite loops (e.g., event A's handler notifies of event B, and event B's handler notifies of event A). Developers should be mindful of this when designing their event chains.
-
-## Contributing
-
-We welcome contributions from the community! Whether you're fixing a bug, adding a feature, or improving the documentation, your help is appreciated. Please read our Contributing Guidelines for details on how to get started.
+# Inglorious Engine
+
+[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
+
+A JavaScript game engine written with global state, immutability, and pure functions in mind. Have fun(ctional programming) with it!
+
+## Features
+
+- **Functional & Data-Oriented**: Uses a single, immutable state object as the source of truth, inspired by functional programming principles.
+- **Composable by Design**: Build complex behaviors by composing pure functions and decorators, offering a powerful alternative to inheritance.
+- **Renderer Agnostic**: The engine is headless. You can use any rendering technology you like, from Canvas2D and HTML to React components.
+- **Zero Build Step**: Write plain JavaScript and run it directly in the browser. No complex build configurations to worry about.
+
+## Documentation
+
+The best way to get started is with the official documentation, which includes a **[Quick Start Guide](https://inglorious-engine.vercel.app/?path=/docs/quick-start--docs)**.
+
+Full documentation is available at: **[https://inglorious-engine.vercel.app/](https://inglorious-engine.vercel.app/)**
+
+## Why Functional Programming?
+
+What makes this engine different from all the others is that, instead of Object Oriented Programming (OOP), which seems the most obvious choice for a game engine, this one is based on Functional Programming (FP).
+
+FP has many advantages:
+
+1. **Single Source of Truth**: Your entire game state is a single, plain JavaScript object. This gives you complete control over your game's world at any moment, rather than having state scattered across countless objects. This is the core idea behind the Data-Oriented Design (DOD) paradigm that many modern engines are now adopting. With this engine, you get that benefit naturally.
+
+2. **Efficient Immutability**: A common misconception is that creating a new state on every change is slow. This engine uses structural sharing (via Immer), meaning only the parts of the state that actually change are copied. The rest of the state tree is shared by reference, making updates extremely fast. This provides a huge benefit:
+   - **Optimized Rendering**: Detecting changes becomes trivial and fast. A simple reference check (`prevState === nextState`) is all that's needed to determine if data has changed, enabling highly performant UIs (especially with libraries like React). This is much faster than the deep, recursive comparisons required in mutable systems.
+
+3. **Pure Functions**: Game logic is built with pure functions — functions that return a value based only on their inputs, with no side effects. This makes your game logic predictable, easy to test in isolation, and highly reusable, freeing you from the complexity of class methods with hidden side effects.
+
+4. **Composition over Inheritance**: Instead of complex class hierarchies, you build entities by composing functions. Think of it as a pipeline of operations applied to your data. This is a more flexible and powerful alternative to inheritance. You can mix and match behaviors (e.g., `canBeControlledByPlayer`, `canBeHurt`, `canShoot`) on the fly, avoiding the rigidity and common problems of deep inheritance chains.
+
+5. **Dynamic by Nature**: JavaScript objects are dynamic. You can add or remove properties from an entity at any time without being constrained by a rigid class definition. This is perfect for game development, where an entity's state can change unpredictably (e.g., gaining a temporary power-up). This flexibility allows for more emergent game mechanics.
+
+6. **Unparalleled Debugging and Tooling**: Because the entire game state is a single, serializable object, you can unlock powerful development patterns that are difficult to achieve in traditional OOP engines.
+   - **Time-Travel Debugging**: Save the state at any frame. You can step backward and forward through state changes to find exactly when a bug was introduced.
+   - **Hot-Reloading**: Modify your game's logic and instantly see the results without restarting. The engine can reload the code and re-apply it to the current state, dramatically speeding up iteration.
+   - **Simplified Persistence**: Saving and loading a game is as simple as serializing and deserializing a single JSON object.
+   - **Simplified Networking**: For multiplayer games, you don't need to synchronize complex objects. You just send small, serializable `event` objects over the network. Each client processes the same event with the same pure event handler, guaranteeing their game states stay in sync.
+
+7. **Leverage the Full JavaScript Ecosystem**: As a pure JavaScript engine, you have immediate access to the world's largest software repository: npm. Need advanced physics, complex AI, or a specific UI library? Integrate it with a simple `npm install`. You aren't limited to the built-in features or proprietary plugin ecosystem of a monolithic engine like Godot or Unity.
+
+## Architecture: State Management
+
+The engine's state management is inspired by Redux, but it's specifically tailored for the demands of game development. If you're familiar with Redux, you'll recognize the core pattern: the UI (or game view) is a projection of the state, and the only way to change the state is to dispatch an action.
+
+However, there are several key differences that make it unique:
+
+1.  **Events, not Actions**: In Redux, you "dispatch actions." Here, we "notify of events." This is a deliberate semantic choice. An event handler is a function that reacts to a specific occurrence in the game world (e.g., `playerMove`, `enemyDestroy`). The naming convention is similar to standard JavaScript event handlers like `onClick`, where the handler name describes the event it's listening for.
+
+2.  **Asynchronous Event Queue**: Unlike Redux's synchronous dispatch, events are not processed immediately. They are added to a central event queue. The engine's main loop processes this queue once per frame. This approach has several advantages:
+    - It decouples game logic from state updates.
+    - It ensures state changes happen at a predictable point in the game loop, preventing race conditions or cascading updates within a single frame.
+    - It allows for event batching and provides a solid foundation for networking and time-travel debugging.
+
+3.  **Core Engine Events & Naming Convention**: The engine has a few built-in, **single-word** events that drive its core functionality. To avoid conflicts, you should use **multi-word `camelCase`** names for your own custom game events (`playerJump`, `itemCollect`). This convention is similar to how custom HTML elements require a hyphen to distinguish them from standard elements. Key engine events include:
+    - `update`: Fired on every frame, typically carrying the `deltaTime` since the last frame. This is where you'll put most of your continuous game logic (like movement).
+    - `add`: Used to add a new entity to the game state.
+    - `remove`: Used to remove an entity from the game state.
+    - `morph`: Used to dynamically change the behaviors associated with an entity's type.
+
+4.  **Ergonomic Immutability with Immer**: The state is immutable, but to make this easy to work with, we use Immer. Inside your event handlers, you can write code that looks like it's mutating the state directly. Immer handles the magic behind the scenes, producing a new, updated state with structural sharing, giving you the performance benefits of immutability with the developer experience of mutable code.
+
+5.  **Composable Handlers via Function Piping**: Instead of large, monolithic "reducers," you build event handlers by composing smaller, pure functions. The engine encourages a pipeline pattern where an event and the current state are passed through a series of decorators or transformations. This makes your logic highly modular, reusable, and easy to test in isolation.
+
+6.  **Handlers Can Issue New Events (Controlled Side-Effects)**: In a strict Redux pattern, reducers must be pure. We relax this rule for a pragmatic reason: event handlers in this engine **can notify of new events**. This allows you to create powerful, reactive chains of logic. For example, an `enemy:take_damage` handler might check the enemy's health and, if it drops to zero, notify of a new `enemy:destroyed` event.
+    - **How it works**: Any event notified from within a handler is simply added to the end of the main event queue. It will be processed in a subsequent pass of the game loop, not immediately. This prevents synchronous, cascading updates within a single frame and makes the flow of logic easier to trace.
+
+    - **A Word of Caution**: This power comes with responsibility. It is possible to create infinite loops (e.g., event A's handler notifies of event B, and event B's handler notifies of event A). Developers should be mindful of this when designing their event chains.
+
+## Contributing
+
+We welcome contributions from the community! Whether you're fixing a bug, adding a feature, or improving the documentation, your help is appreciated. Please read our Contributing Guidelines for details on how to get started.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@inglorious/engine",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "description": "A JavaScript game engine written with global state, immutability, and pure functions in mind. Have fun(ctional programming) with it!",
   "author": "IceOnFire <antony.mistretta@gmail.com> (https://ingloriouscoderz.it)",
   "license": "MIT",
@@ -9,13 +9,15 @@
     "url": "git+https://github.com/IngloriousCoderz/inglorious-engine.git"
   },
   "homepage": "https://inglorious-engine.vercel.app/",
+  "bugs": {
+    "url": "https://github.com/IngloriousCoderz/inglorious-engine/issues"
+  },
   "keywords": [
-    "game-engine",
+    "data-oriented",
+    "ecs",
     "functional-programming",
     "gamedev",
-    "javascript",
-    "ecs",
-    "data-oriented"
+    "game-engine"
   ],
   "type": "module",
   "files": [
@@ -31,33 +33,21 @@
   },
   "dependencies": {
     "immer": "^10.1.1",
-    "react": "^19.0.0",
-    "react-dom": "^19.0.0",
-    "react-redux": "^9.2.0"
+    "@inglorious/utils": "1.1.0"
   },
   "devDependencies": {
-    "@chromatic-com/storybook": "^4.1.1",
-    "@storybook/addon-docs": "^9.1.3",
-    "@storybook/addon-links": "^9.1.3",
-    "@storybook/react-vite": "^9.1.3",
-    "@types/react": "^18.2.15",
-    "@types/react-dom": "^18.2.7",
-    "@vitejs/plugin-react": "^4.3.1",
     "husky": "^9.1.7",
     "prettier": "^3.5.3",
-    "sass": "^1.77.8",
-    "serve": "^14.2.4",
-    "storybook": "^9.1.3",
     "vite": "^7.1.3",
     "vitest": "^1.6.0"
   },
+  "engines": {
+    "node": ">= 22"
+  },
   "scripts": {
-    "lint": "eslint . --ext js,jsx --report-unused-disable-directives --max-warnings 0",
     "format": "prettier --write '**/*.{js,jsx}'",
+    "lint": "eslint . --ext js,jsx --report-unused-disable-directives --max-warnings 0",
     "test:watch": "vitest",
-    "test": "vitest run",
-    "start": "serve",
-    "storybook": "storybook dev -p 6006",
-    "build-storybook": "storybook build"
+    "test": "vitest run"
   }
 }

package/src/{engine/ai → ai}/movement/dynamic/align.js

@@ -1,63 +1,63 @@
-import { abs, clamp } from "@inglorious/utils/math/numbers.js"
-import { toRange } from "@inglorious/utils/math/trigonometry.js"
-
-export const DEFAULT_TARGET_RADIUS = 0.1
-export const DEFAULT_SLOW_RADIUS = 0.1
-export const DEFAULT_TIME_TO_TARGET = 0.1
-
-const DEFAULT_MAX_ANGULAR_ACCELERATION = 0
-const DEFAULT_MAX_ANGULAR_SPEED = 0
-
-const DEFAULT_ANGULAR_SPEED = 0
-const DEFAULT_ORIENTATION = 0
-
-const HALF_ANGULAR_ACCELERATION = 0.5
-
-export function align(
-  entity,
-  target,
-  dt,
-  {
-    targetRadius = DEFAULT_TARGET_RADIUS,
-    slowRadius = DEFAULT_SLOW_RADIUS,
-    timeToTarget = DEFAULT_TIME_TO_TARGET,
-  } = {},
-) {
-  const maxAngularAcceleration =
-    entity.maxAngularAcceleration ?? DEFAULT_MAX_ANGULAR_ACCELERATION
-  const maxAngularSpeed = entity.maxAngularSpeed ?? DEFAULT_MAX_ANGULAR_SPEED
-
-  let angularSpeed = entity.angularSpeed ?? DEFAULT_ANGULAR_SPEED
-  let orientation = entity.orientation ?? DEFAULT_ORIENTATION
-
-  const direction = toRange(target.orientation - orientation)
-  const distance = abs(direction)
-
-  if (distance < targetRadius) {
-    return entity
-  }
-
-  let targetAngularSpeed
-  if (distance > slowRadius) {
-    targetAngularSpeed = maxAngularSpeed
-  } else {
-    targetAngularSpeed = (distance * maxAngularSpeed) / slowRadius
-  }
-  targetAngularSpeed *= direction / distance // restore rotation sign
-
-  const angularSpeedDelta = targetAngularSpeed - angularSpeed
-
-  let angularAcceleration = angularSpeedDelta / timeToTarget
-  angularAcceleration = clamp(
-    angularAcceleration,
-    -maxAngularAcceleration,
-    maxAngularAcceleration,
-  )
-
-  angularSpeed += angularAcceleration * dt
-  orientation +=
-    angularSpeed * dt +
-    angularAcceleration * HALF_ANGULAR_ACCELERATION * dt * dt
-
-  return { angularSpeed, orientation }
-}
+import { abs, clamp } from "@inglorious/utils/math/numbers.js"
+import { toRange } from "@inglorious/utils/math/trigonometry.js"
+
+export const DEFAULT_TARGET_RADIUS = 0.1
+export const DEFAULT_SLOW_RADIUS = 0.1
+export const DEFAULT_TIME_TO_TARGET = 0.1
+
+const DEFAULT_MAX_ANGULAR_ACCELERATION = 0
+const DEFAULT_MAX_ANGULAR_SPEED = 0
+
+const DEFAULT_ANGULAR_SPEED = 0
+const DEFAULT_ORIENTATION = 0
+
+const HALF_ANGULAR_ACCELERATION = 0.5
+
+export function align(
+  entity,
+  target,
+  dt,
+  {
+    targetRadius = DEFAULT_TARGET_RADIUS,
+    slowRadius = DEFAULT_SLOW_RADIUS,
+    timeToTarget = DEFAULT_TIME_TO_TARGET,
+  } = {},
+) {
+  const maxAngularAcceleration =
+    entity.maxAngularAcceleration ?? DEFAULT_MAX_ANGULAR_ACCELERATION
+  const maxAngularSpeed = entity.maxAngularSpeed ?? DEFAULT_MAX_ANGULAR_SPEED
+
+  let angularSpeed = entity.angularSpeed ?? DEFAULT_ANGULAR_SPEED
+  let orientation = entity.orientation ?? DEFAULT_ORIENTATION
+
+  const direction = toRange(target.orientation - orientation)
+  const distance = abs(direction)
+
+  if (distance < targetRadius) {
+    return entity
+  }
+
+  let targetAngularSpeed
+  if (distance > slowRadius) {
+    targetAngularSpeed = maxAngularSpeed
+  } else {
+    targetAngularSpeed = (distance * maxAngularSpeed) / slowRadius
+  }
+  targetAngularSpeed *= direction / distance // restore rotation sign
+
+  const angularSpeedDelta = targetAngularSpeed - angularSpeed
+
+  let angularAcceleration = angularSpeedDelta / timeToTarget
+  angularAcceleration = clamp(
+    angularAcceleration,
+    -maxAngularAcceleration,
+    maxAngularAcceleration,
+  )
+
+  angularSpeed += angularAcceleration * dt
+  orientation +=
+    angularSpeed * dt +
+    angularAcceleration * HALF_ANGULAR_ACCELERATION * dt * dt
+
+  return { angularSpeed, orientation }
+}

package/src/{engine/ai → ai}/movement/dynamic/arrive.js

@@ -1,42 +1,42 @@
-import { matchVelocity } from "@inglorious/engine/ai/movement/dynamic/match-velocity.js"
-import {
-  magnitude,
-  setMagnitude,
-} from "@inglorious/utils/math/linear-algebra/vector.js"
-import { subtract } from "@inglorious/utils/math/linear-algebra/vectors.js"
-
-export const DEFAULT_TARGET_RADIUS = 1
-export const DEFAULT_SLOW_RADIUS = 100
-export const DEFAULT_TIME_TO_TARGET = 0.1
-
-const DEFAULT_MAX_SPEED = 0
-
-export function arrive(
-  entity,
-  target,
-  dt,
-  {
-    targetRadius = DEFAULT_TARGET_RADIUS,
-    slowRadius = DEFAULT_SLOW_RADIUS,
-    timeToTarget = DEFAULT_TIME_TO_TARGET,
-  } = {},
-) {
-  const maxSpeed = entity.maxSpeed ?? DEFAULT_MAX_SPEED
-
-  const direction = subtract(target.position, entity.position)
-  const distance = magnitude(direction)
-
-  if (distance < targetRadius) {
-    return entity
-  }
-
-  let speed
-  if (distance > slowRadius) {
-    speed = maxSpeed
-  } else {
-    speed = (distance * maxSpeed) / slowRadius
-  }
-  const velocity = setMagnitude(direction, speed)
-
-  return matchVelocity(entity, { velocity }, dt, { timeToTarget })
-}
+import { matchVelocity } from "@inglorious/engine/ai/movement/dynamic/match-velocity.js"
+import {
+  magnitude,
+  setMagnitude,
+} from "@inglorious/utils/math/linear-algebra/vector.js"
+import { subtract } from "@inglorious/utils/math/linear-algebra/vectors.js"
+
+export const DEFAULT_TARGET_RADIUS = 1
+export const DEFAULT_SLOW_RADIUS = 100
+export const DEFAULT_TIME_TO_TARGET = 0.1
+
+const DEFAULT_MAX_SPEED = 0
+
+export function arrive(
+  entity,
+  target,
+  dt,
+  {
+    targetRadius = DEFAULT_TARGET_RADIUS,
+    slowRadius = DEFAULT_SLOW_RADIUS,
+    timeToTarget = DEFAULT_TIME_TO_TARGET,
+  } = {},
+) {
+  const maxSpeed = entity.maxSpeed ?? DEFAULT_MAX_SPEED
+
+  const direction = subtract(target.position, entity.position)
+  const distance = magnitude(direction)
+
+  if (distance < targetRadius) {
+    return entity
+  }
+
+  let speed
+  if (distance > slowRadius) {
+    speed = maxSpeed
+  } else {
+    speed = (distance * maxSpeed) / slowRadius
+  }
+  const velocity = setMagnitude(direction, speed)
+
+  return matchVelocity(entity, { velocity }, dt, { timeToTarget })
+}

package/src/{engine/ai → ai}/movement/dynamic/evade.js

@@ -1,38 +1,38 @@
-import { flee } from "@inglorious/engine/ai/movement/dynamic/flee.js"
-import {
-  magnitude,
-  multiply,
-  zero,
-} from "@inglorious/utils/math/linear-algebra/vector.js"
-import { subtract, sum } from "@inglorious/utils/math/linear-algebra/vectors.js"
-
-export const DEFAULT_MAX_PREDICTION = 10
-
-export function evade(
-  entity,
-  target,
-  dt,
-  { maxPrediction = DEFAULT_MAX_PREDICTION } = {},
-) {
-  let velocity = entity.velocity ?? zero()
-
-  const direction = subtract(target.position, entity.position)
-  const distance = magnitude(direction)
-
-  if (!distance) {
-    return entity
-  }
-
-  const speed = magnitude(velocity)
-
-  let prediction
-  if (speed <= distance / maxPrediction) {
-    prediction = maxPrediction
-  } else {
-    prediction = distance / speed
-  }
-
-  const position = sum(target.position, multiply(target.velocity, prediction))
-
-  return flee(entity, { ...target, position }, dt)
-}
+import { flee } from "@inglorious/engine/ai/movement/dynamic/flee.js"
+import {
+  magnitude,
+  multiply,
+  zero,
+} from "@inglorious/utils/math/linear-algebra/vector.js"
+import { subtract, sum } from "@inglorious/utils/math/linear-algebra/vectors.js"
+
+export const DEFAULT_MAX_PREDICTION = 10
+
+export function evade(
+  entity,
+  target,
+  dt,
+  { maxPrediction = DEFAULT_MAX_PREDICTION } = {},
+) {
+  let velocity = entity.velocity ?? zero()
+
+  const direction = subtract(target.position, entity.position)
+  const distance = magnitude(direction)
+
+  if (!distance) {
+    return entity
+  }
+
+  const speed = magnitude(velocity)
+
+  let prediction
+  if (speed <= distance / maxPrediction) {
+    prediction = maxPrediction
+  } else {
+    prediction = distance / speed
+  }
+
+  const position = sum(target.position, multiply(target.velocity, prediction))
+
+  return flee(entity, { ...target, position }, dt)
+}

package/src/{engine/ai → ai}/movement/dynamic/face.js

@@ -1,19 +1,19 @@
-import { align } from "@inglorious/engine/ai/movement/dynamic/align.js"
-import {
-  angle,
-  magnitude,
-} from "@inglorious/utils/math/linear-algebra/vector.js"
-import { subtract } from "@inglorious/utils/math/linear-algebra/vectors.js"
-
-export function face(entity, target, dt, options) {
-  const direction = subtract(target.position, entity.position)
-  const distance = magnitude(direction)
-
-  if (!distance) {
-    return entity
-  }
-
-  const orientation = angle(direction)
-
-  return align(entity, { ...target, orientation }, dt, options)
-}
+import { align } from "@inglorious/engine/ai/movement/dynamic/align.js"
+import {
+  angle,
+  magnitude,
+} from "@inglorious/utils/math/linear-algebra/vector.js"
+import { subtract } from "@inglorious/utils/math/linear-algebra/vectors.js"
+
+export function face(entity, target, dt, options) {
+  const direction = subtract(target.position, entity.position)
+  const distance = magnitude(direction)
+
+  if (!distance) {
+    return entity
+  }
+
+  const orientation = angle(direction)
+
+  return align(entity, { ...target, orientation }, dt, options)
+}

package/src/{engine/ai → ai}/movement/dynamic/flee.js

@@ -1,45 +1,45 @@
-import {
-  angle,
-  clamp,
-  magnitude,
-  multiply,
-  setMagnitude,
-  zero,
-} from "@inglorious/utils/math/linear-algebra/vector.js"
-import { subtract, sum } from "@inglorious/utils/math/linear-algebra/vectors.js"
-
-const DEFAULT_MAX_ACCELERATION = 0
-const DEFAULT_MAX_SPEED = 0
-
-const MIN_SPEED = 0
-
-const HALF_ACCELERATION = 0.5
-
-export function flee(entity, target, dt) {
-  const maxAcceleration = entity.maxAcceleration ?? DEFAULT_MAX_ACCELERATION
-  const maxSpeed = entity.maxSpeed ?? DEFAULT_MAX_SPEED
-
-  let velocity = entity.velocity ?? zero()
-
-  const direction = subtract(entity.position, target.position)
-  const distance = magnitude(direction)
-
-  if (!distance) {
-    return entity
-  }
-
-  const acceleration = setMagnitude(direction, maxAcceleration)
-
-  velocity = sum(velocity, multiply(acceleration, dt))
-  velocity = clamp(velocity, MIN_SPEED, maxSpeed)
-
-  const position = sum(
-    entity.position,
-    multiply(velocity, dt),
-    multiply(acceleration, HALF_ACCELERATION * dt * dt),
-  )
-
-  const orientation = angle(velocity)
-
-  return { velocity, position, orientation }
-}
+import {
+  angle,
+  clamp,
+  magnitude,
+  multiply,
+  setMagnitude,
+  zero,
+} from "@inglorious/utils/math/linear-algebra/vector.js"
+import { subtract, sum } from "@inglorious/utils/math/linear-algebra/vectors.js"
+
+const DEFAULT_MAX_ACCELERATION = 0
+const DEFAULT_MAX_SPEED = 0
+
+const MIN_SPEED = 0
+
+const HALF_ACCELERATION = 0.5
+
+export function flee(entity, target, dt) {
+  const maxAcceleration = entity.maxAcceleration ?? DEFAULT_MAX_ACCELERATION
+  const maxSpeed = entity.maxSpeed ?? DEFAULT_MAX_SPEED
+
+  let velocity = entity.velocity ?? zero()
+
+  const direction = subtract(entity.position, target.position)
+  const distance = magnitude(direction)
+
+  if (!distance) {
+    return entity
+  }
+
+  const acceleration = setMagnitude(direction, maxAcceleration)
+
+  velocity = sum(velocity, multiply(acceleration, dt))
+  velocity = clamp(velocity, MIN_SPEED, maxSpeed)
+
+  const position = sum(
+    entity.position,
+    multiply(velocity, dt),
+    multiply(acceleration, HALF_ACCELERATION * dt * dt),
+  )
+
+  const orientation = angle(velocity)
+
+  return { velocity, position, orientation }
+}