Main Page - Revision history

Dcurrent: /* Why OpenBOR? */

2026-08-26T03:49:26Z

Why OpenBOR?

← Older revision		Revision as of 23:49, 25 August 2026
Line 23:		Line 23:
	* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.		* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.
	* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.		* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.
	* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set an area's Z axis to a bounded ~~value~~ and the engine natively assumes 2D world behaviors.		* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set an area's Z axis to bounded values and the engine natively assumes 2D world behaviors.
	* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.		* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.
	* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.		* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.

Dcurrent: /* Why OpenBOR? */

2026-08-26T03:45:04Z

Why OpenBOR?

← Older revision		Revision as of 23:45, 25 August 2026
Line 13:		Line 13:
	OpenBOR deliberately limits itself to the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. Within that foundation, virtually any sprite-powered concept is possible.		OpenBOR deliberately limits itself to the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. Within that foundation, virtually any sprite-powered concept is possible.

	That focus means we spend our development resources on ~~quality~~ and depth: butter-smooth motion, asset handling, controls, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are integrated and ready to use. Everything works together out of the box, with no need to build these foundations or assemble them from ~~third-party~~ plugins.		That focus means we spend our development resources on performance and depth: butter-smooth motion, asset handling, controls, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are integrated and ready to use. Everything works together out of the box, with no need to build these foundations or assemble them from plugins.

	Then we layer beat ’em up-oriented behavior over those systems as the default starting point. Supply the necessary assets and configuration, and characters can already move, fight, react, navigate depth, cooperate, and progress through levels. You can have a functional game running within hours, but those defaults don't dictate the finished product.		Then we layer beat ’em up-oriented behavior over those systems as the default starting point. Supply the necessary assets and configuration, and characters can already move, fight, react, navigate depth, cooperate, and progress through levels. You can have a functional game running within hours, but those defaults don't dictate the finished product.

Dcurrent: /* Why OpenBOR? */

2026-08-25T17:39:31Z

Why OpenBOR?

← Older revision		Revision as of 13:39, 25 August 2026
Line 28:		Line 28:
	* '''[[Subscreens\|Recursive graphics composition]]''' - Script-created subscreens support nested rendering, layer capture, transformations, masks, split screens, and feedback effects.		* '''[[Subscreens\|Recursive graphics composition]]''' - Script-created subscreens support nested rendering, layer capture, transformations, masks, split screens, and feedback effects.
	* '''[[Runtime Script Compilation\|Runtime metaprogramming]]''' - Modules can load and combine source files, compile them into independently owned programs, retain persistent state, execute them repeatedly, and replace them during play.		* '''[[Runtime Script Compilation\|Runtime metaprogramming]]''' - Modules can load and combine source files, compile them into independently owned programs, retain persistent state, execute them repeatedly, and replace them during play.
	* '''Optimized performance''' - Native systems, high-frequency simulation, and script integration are engineered to maintain steady frame rates and ~~butter-smooth~~ motion with dozens or hundreds of active objects.		* '''Optimized performance''' - Native systems, high-frequency simulation, and script integration are engineered to maintain steady frame rates and seamless motion with dozens or hundreds of active objects.

	== Getting Started ==		== Getting Started ==

Dcurrent: /* Why OpenBOR? */

2026-08-25T17:38:05Z

Why OpenBOR?

← Older revision		Revision as of 13:38, 25 August 2026
Line 23:		Line 23:
	* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.		* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.
	* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.		* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.
	* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set a bounded ~~Z axis~~ and the engine natively assumes 2D world behaviors.		* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set an area's Z axis to a bounded value and the engine natively assumes 2D world behaviors.
	* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.		* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.
	* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.		* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.

Dcurrent: /* Why OpenBOR? */

2026-08-25T17:34:52Z

Why OpenBOR?

← Older revision		Revision as of 13:34, 25 August 2026
Line 23:		Line 23:
	* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.		* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.
	* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.		* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.
	* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting.		* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set a bounded Z axis and the engine natively assumes 2D world behaviors.
	* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.		* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.
	* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.		* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.

Dcurrent: /* Why OpenBOR? */

2026-08-25T17:30:48Z

Why OpenBOR?

← Older revision		Revision as of 13:30, 25 August 2026
Line 15:		Line 15:
	That focus means we spend our development resources on quality and depth: butter-smooth motion, asset handling, controls, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are integrated and ready to use. Everything works together out of the box, with no need to build these foundations or assemble them from third-party plugins.		That focus means we spend our development resources on quality and depth: butter-smooth motion, asset handling, controls, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are integrated and ready to use. Everything works together out of the box, with no need to build these foundations or assemble them from third-party plugins.

	We layer beat ’em up-oriented behavior over those systems as the default starting point. Supply the necessary assets and configuration, and characters can already move, fight, react, navigate depth, cooperate, and progress through levels. You can have a functional game running within hours, but those defaults don't dictate the finished product.		Then we layer beat ’em up-oriented behavior over those systems as the default starting point. Supply the necessary assets and configuration, and characters can already move, fight, react, navigate depth, cooperate, and progress through levels. You can have a functional game running within hours, but those defaults don't dictate the finished product.

	Configuration and script expose the same engine objects, properties, and low-level primitives beneath that native behavior. Creators can inspect runtime state, customize selected operations, replace complete subsystems, or combine the primitives into something we never anticipated. The same technical model can support platformers, shooters, role-playing games, puzzles, and other designs far removed from the default.		Configuration and script expose the same engine objects, properties, and low-level primitives beneath that native behavior. Creators can inspect runtime state, customize selected operations, replace complete subsystems, or combine the primitives into something we never anticipated. The same technical model can support platformers, shooters, role-playing games, puzzles, and other designs far removed from the default.

Dcurrent: /* Why OpenBOR? */

2026-08-25T17:28:46Z

Why OpenBOR?

← Older revision		Revision as of 13:28, 25 August 2026
Line 13:		Line 13:
	OpenBOR deliberately limits itself to the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. Within that foundation, virtually any sprite-powered concept is possible.		OpenBOR deliberately limits itself to the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. Within that foundation, virtually any sprite-powered concept is possible.

	That focus ~~lets us invest~~ our development resources on quality and depth~~. Butter~~ smooth motion, asset handling, controls, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are integrated and ready to use. Everything works together out of the box, with no need to build these foundations or assemble them from third-party plugins.		That focus means we spend our development resources on quality and depth: butter-smooth motion, asset handling, controls, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are integrated and ready to use. Everything works together out of the box, with no need to build these foundations or assemble them from third-party plugins.

	We layer beat ’em up-oriented behavior over those systems as the default starting point. Supply the necessary assets and configuration, and characters can already move, fight, react, navigate depth, cooperate, and progress through levels. You can have a functional game running within hours, but those defaults don't dictate the finished product.		We layer beat ’em up-oriented behavior over those systems as the default starting point. Supply the necessary assets and configuration, and characters can already move, fight, react, navigate depth, cooperate, and progress through levels. You can have a functional game running within hours, but those defaults don't dictate the finished product.

Dcurrent: /* Why OpenBOR? */

2026-08-25T17:23:32Z

Why OpenBOR?

← Older revision		Revision as of 13:23, 25 August 2026
Line 13:		Line 13:
	OpenBOR deliberately limits itself to the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. Within that foundation, virtually any sprite-powered concept is possible.		OpenBOR deliberately limits itself to the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. Within that foundation, virtually any sprite-powered concept is possible.

	That focus lets us invest our development resources in depth. ~~Asset~~ handling, controls~~, movement~~, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are integrated and ready to use. Everything works together out of the box, with no need to build these foundations or assemble them from third-party plugins.		That focus lets us invest our development resources on quality and depth. Butter smooth motion, asset handling, controls, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are integrated and ready to use. Everything works together out of the box, with no need to build these foundations or assemble them from third-party plugins.

	We layer beat ’em up-oriented behavior over those systems as the default starting point. Supply the necessary assets and configuration, and characters can already move, fight, react, navigate depth, cooperate, and progress through levels. You can have a functional game running within hours, but those defaults don't dictate the finished product.		We layer beat ’em up-oriented behavior over those systems as the default starting point. Supply the necessary assets and configuration, and characters can already move, fight, react, navigate depth, cooperate, and progress through levels. You can have a functional game running within hours, but those defaults don't dictate the finished product.

Dcurrent: /* Why OpenBOR? */

2026-08-25T17:21:14Z

Why OpenBOR?

← Older revision		Revision as of 13:21, 25 August 2026
Line 9:		Line 9:

	=== Why OpenBOR? ===		=== Why OpenBOR? ===
	What sets OpenBOR apart is how we define its scope. Some engines concentrate on a particular ~~genre. Role~~-playing games~~. One~~-on-one fighters~~. Shoot~~-’em-ups~~. Real~~-time strategy~~. Puzzle games~~. Others attempt to support every technical medium, leaving developers to build most game-specific functionality themselves. Both are valid approaches. We take a third path by ~~choosing~~ a technical ~~lane rather than a~~ result ~~lane~~.		What sets OpenBOR apart is how we define its scope. Some engines concentrate on a particular result: role-playing games, one-on-one fighters, shoot-’em-ups, real-time strategy, or puzzles. Others attempt to support every technical medium, leaving developers to build most game-specific functionality themselves. Both are valid approaches. We take a third path by specializing in a technical medium without prescribing the result.

	OpenBOR deliberately ~~stays within~~ the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. Within that foundation, virtually any sprite powered concept is possible.		OpenBOR deliberately limits itself to the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. Within that foundation, virtually any sprite-powered concept is possible.

	That focus lets us ~~concentrate~~ our development resources ~~on making OpenBOR the most capable, efficient, and complete engine possible for its chosen medium~~. Asset handling, controls, movement, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are ~~fully~~ integrated and ready to use. ~~Creators do not~~ need to build these foundations or assemble them from third-party plugins ~~before they can begin making a game~~.		That focus lets us invest our development resources in depth. Asset handling, controls, movement, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are integrated and ready to use. Everything works together out of the box, with no need to build these foundations or assemble them from third-party plugins.

	We ~~then~~ layer beat ’em up-oriented behavior over those systems as the default starting point. ~~Characters~~ can move, fight, react, navigate depth, cooperate, and progress through levels ~~as soon as creators supply the necessary assets and configuration~~. ~~Those defaults~~ can ~~put~~ a functional game ~~on screen~~ within hours, ~~though they do not~~ dictate ~~what~~ the finished ~~game must become~~.		We layer beat ’em up-oriented behavior over those systems as the default starting point. Supply the necessary assets and configuration, and characters can already move, fight, react, navigate depth, cooperate, and progress through levels. You can have a functional game running within hours, but those defaults don't dictate the finished product.

	~~The~~ same engine objects, properties, and low-level primitives ~~remain exposed through configuration and script~~. Creators can inspect runtime state, customize selected ~~behavior~~, replace complete subsystems, or combine the primitives into something we never anticipated. ~~Platformers~~, shooters, role-playing games, ~~puzzle games~~, and other designs ~~can all operate within~~ the ~~same technical model~~.		Configuration and script expose the same engine objects, properties, and low-level primitives beneath that native behavior. Creators can inspect runtime state, customize selected operations, replace complete subsystems, or combine the primitives into something we never anticipated. The same technical model can support platformers, shooters, role-playing games, puzzles, and other designs far removed from the default.

	~~Staying within~~ a ~~technical lane therefore allows us to make OpenBOR more~~ complete ~~without making it less versatile. Native functionality provides a high~~ starting point, ~~not a boundary. We are not trying to make~~ an ~~engine that does everything. We are working to make the most complete, efficient, and open-ended engine possible for the medium we have chosen~~.		The result is a deliberately bounded medium, a complete starting point, and an ending defined only by your imagination.
	* '''Complete native gameplay''' - Controls, movement, gravity, level trees, platforms, combat, blocking, grabbing, throwing, artificial intelligence, cameras, audio, menus, HUDs, and saving work without custom code.		* '''Complete native gameplay''' - Controls, movement, gravity, level trees, platforms, combat, blocking, grabbing, throwing, artificial intelligence, cameras, audio, menus, HUDs, and saving work without custom code.
	* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.		* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.

Dcurrent: /* Why OpenBOR? */

2026-08-25T17:13:11Z

Why OpenBOR?

← Older revision		Revision as of 13:13, 25 August 2026
Line 11:		Line 11:
	What sets OpenBOR apart is how we define its scope. Some engines concentrate on a particular genre. Role-playing games. One-on-one fighters. Shoot-’em-ups. Real-time strategy. Puzzle games. Others attempt to support every technical medium, leaving developers to build most game-specific functionality themselves. Both are valid approaches. We take a third path by choosing a technical lane rather than a result lane.		What sets OpenBOR apart is how we define its scope. Some engines concentrate on a particular genre. Role-playing games. One-on-one fighters. Shoot-’em-ups. Real-time strategy. Puzzle games. Others attempt to support every technical medium, leaving developers to build most game-specific functionality themselves. Both are valid approaches. We take a third path by choosing a technical lane rather than a result lane.

	OpenBOR deliberately stays within the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. ~~Those choices limit how an OpenBOR world~~ is ~~represented, not what creators can produce within it~~.		OpenBOR deliberately stays within the simulation and presentation of flat, two-dimensional visual assets in an effectively limitless three-dimensional world. No polygons. No meshes. No skeletal rigs. Just raster graphics moving through three axes. Within that foundation, virtually any sprite powered concept is possible.

	That focus lets us concentrate our development resources on making OpenBOR the most capable, efficient, and complete engine possible for its chosen medium. Asset handling, controls, movement, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are fully integrated and ready to use. Creators do not need to build these foundations or assemble them from third-party plugins before they can begin making a game.		That focus lets us concentrate our development resources on making OpenBOR the most capable, efficient, and complete engine possible for its chosen medium. Asset handling, controls, movement, gravity, collision, combat, blocking, grabbing, throwing, artificial intelligence, cameras, level trees, audio, menus, HUDs, saving, and local multiplayer are fully integrated and ready to use. Creators do not need to build these foundations or assemble them from third-party plugins before they can begin making a game.

← Older revision		Revision as of 23:49, 25 August 2026
Line 23:		Line 23:
	* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.		* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.
	* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.		* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.
	* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set an area's Z axis to a bounded ~~value~~ and the engine natively assumes 2D world behaviors.		* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set an area's Z axis to bounded values and the engine natively assumes 2D world behaviors.
	* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.		* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.
	* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.		* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.

← Older revision		Revision as of 13:38, 25 August 2026
Line 23:		Line 23:
	* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.		* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.
	* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.		* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.
	* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set a bounded ~~Z axis~~ and the engine natively assumes 2D world behaviors.		* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set an area's Z axis to a bounded value and the engine natively assumes 2D world behaviors.
	* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.		* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.
	* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.		* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.

← Older revision		Revision as of 13:34, 25 August 2026
Line 23:		Line 23:
	* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.		* '''[[Script Overview\|Engine-wide scripting]]''' - Object APIs and [[:Category:Script Events\|more than 70 event hooks]] expose input, animation, movement, collision, damage, spawning, audio, drawing, and other runtime systems for inspection, modification, or replacement.
	* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.		* '''[[Time\|High-resolution simulation]]''' - The configurable logical clock runs at 200 Hz by default and remains independent of display updates.
	* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting.		* '''[[Geometry Overview\|Three-dimensional sprite worlds]]''' - Floating-point X, Y, and Z geometry provides subpixel movement, terrain, altitude, and depth sorting. Set a bounded Z axis and the engine natively assumes 2D world behaviors.
	* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.		* '''[[Collision\|Declarative combat collision]]''' - Indexed three-dimensional attack and body boxes carry damage, reaction, motion, status, and presentation behavior.
	* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.		* '''[[Factions\|Composable relationships]]''' - Four independent 52-bit faction masks provide hardware-speed membership, hostility, direct-damage, and indirect-damage rules.