Project videos
A growing collection of demonstrations showing the combat system and its authoring tools in motion.
Live action timeline window
What it is
Universal Combat System is a project-scale architecture for authoring and executing entity actions. It separates reusable action timing, entity-specific presentation bindings, scene references, and concrete gameplay behavior so each layer has a clear responsibility.
Authored actions
Reusable action definitions describe timing and scheduled windows without taking ownership of scene objects or hardware input.
Combat resolution
Explicit hit and hurt volumes feed a contact pipeline that can resolve effects, damage, knockback, and presentation reactions.
Extensible domains
Movement, animation, audio, effects, shooting, camera behavior, and UI can respond through defined execution contracts.
Core architecture
The runtime resolves a general action definition through an entity profile and scene instance before exposing it to the combat-neutral action boundary.
Action definition
Entity profile
Profile instance
Combat entity
System capabilities
Action execution and state
- Entity actions can be initiated by input, AI, or gameplay commands.
- An optional state machine can approve, deny, remap, or defer commands before execution.
- Timed actions use a shared timeline controller; definition-only actions do not need a generic host component.
- Concrete actions such as blocking, jumping, or shooting can own their local lifecycle behavior.
Combat and presentation
- Combat entities carry identity, pipeline events, and optional capabilities such as weapon or impulse support.
- Hit boxes and hurt boxes receive action bindings and timing through the execution boundary.
- Effects, particles, impact animation, and sound remain separate domain-owned systems.
- Assembly boundaries and architecture tests help preserve dependency direction as the project grows.
Design approach
Clear ownership
The architecture favors the fewest truthful owners: timing belongs to actions, presentation bindings belong to profiles, scene references belong to profile instances, and execution remains at the action boundary.
Built to evolve
Independently organized systems and explicit contracts keep the project practical to author today while preserving a path toward reusable, testable packages later.