Homses Battle
Project Info
Gameplay/AI Programmer
Action
Unreal Engine
w/ AngelScript
Ongoing
1 Programmer
Project Summary
Homses Battle is a solo‑developed action game prototype focused on building a robust foundation for fast‑paced, character‑driven gameplay. The project centres on designing responsive, modular abilities and a flexible component system to support future expansion.
Originally envisioned as a testbed for the Capability Pattern, Homses Battle has grown into a sandbox for gameplay experimentation, prioritising player control, combat flow, and a dynamic systems architecture.
​
Early AI groundwork is already in place (perception, line‑of‑sight, blackboard state), with full behaviours planned once the core gameplay loop is refined.
Built in Unreal Engine 5 with AngelScript integration, the project takes advantage of scripting flexibility to rapidly prototype complex mechanics and build reusable systems without engine recompiles.
Core Gameplay Architecture
In Homses Battle, the Capability Pattern is the backbone of gameplay. A Capability is a self‑contained behaviour module, movement, dash, jump, hitbox, camera offset, portal rendering, projectile logic, that owns its own activation logic and ticking.
Capabilities are managed by a Capability Component, which schedules them by priority (PreMovement → Movement → PostMovement → etc.) and handles safe add/remove queues. Components store state and provide services (movement input, health, locking, camera control), while data assets configure behaviour without code changes.
Capabilities
-
Capabilities: self-contained behavior units with an activation lifecycle:
-
ShouldActivate → OnActivate → TickActive → ShouldDeactivate → OnDeactivate
-
Prioritized scheduling (PreMovement → Movement → PostMovement → etc.)
-
Examples: movement, dash/jump, hitboxes, camera offset/shake, portal rendering/teleportation, projectile behaviors
-
-
Components: state and focused services
-
Store and expose state (health, locks, movement, input, ability registry, camera)
-
Provide stable interfaces for capabilities (e.g., movement input, locking, camera springs)
-
-
Data: configure behavior without code changes
-
Tunable UPROPERTY fields on components/modifiers
-
Asset-driven composition for projectiles (UProjectileData with behavior modules)
-
Abilities: Modular in Design
Abilities build on the capability pattern and are composed from three pieces:
​
-
AbilityCapability: the ability’s phase machine (warm-up, active, cooldown, fire) and condition checks (input, grounded, locked, cooldown).
-
AbilityModifiers: plug-in modules that parameterize behavior (active/cooldown durations, charge time, camera offsets, initial projectile velocity/angle, component locks per phase).
-
AbilityContexts: transient per-ability state (charge ratio, spawned projectiles, buffered hits).
At runtime, a character’s AbilityComponent registers an array of AbilityCapabilities at BeginPlay.
Example flow: Charged lobbed projectile
-
While input is held:
-
ChargeAbility increments ChargeRatio in context
-
ProjectileDisplayTrajectory shows a segmented static-mesh trajectory preview
-
ProjectileInitialVelocity and InitialZVelocity compute the firing vector from charge and controller pitch
-
-
On release:
-
SpawnProjectile builds the projectile from a data asset (mesh, gravity, drag, damage, bounce, etc.)
-
FireProjectile launches it
-
-
Afterward:
-
CooldownAbilityModifier gates reactivation
-
Optional Component lock per phase avoids conflicts with other inputs
-
Projectiles: Modular, Bahaviour-Driven Logic
Lobbed Projectile with gravity and trajectory visual.
Repeating and Bouncing Projectile.
Projectiles are fully asset-composed. A UProjectileData asset holds a list of behavior modules (UProjectileDataComponent). On spawn, each module applies configuration and attaches the matching capability.
-
Movement/forces: Gravity, Drag, Acceleration (with curve or oscillation), Oscillation
-
Guidance: Tracking (optional predicted target location), Obstacle Avoidance
-
Collision: Bounce (max count, energy retention), DestroyOnHit (after final bounce)
-
Impact: Damage + on-hit effects (knockback, stun), SpawnActorOnDestroy
-
Visuals: Mesh, scale, initial offset/lerp
Portal
The portal system is implemented as a set of capabilities:
-
Rendering: USceneCaptureComponent2D feeds a dynamic portal material, with recursive captures gated by visibility checks
-
Actor duplication: visual‑only duplicates (UPoseableMeshComponent) mirror skeletal poses for views through the portal
-
Clipping: dynamic material parameters + Niagara intersection effects when actors intersect the portal plane
-
Teleportation: correct transform of location, rotation, and velocity; camera handoff uses a near‑clip safety window
-
Collision handling: temporarily ignores collisions between an actor straddling either side of the portal/link
Work-in-progress notes:
-
Niagara components for duplicates are being tracked and cleaned up
-
Unlinking/linking behaviour is robust when the number of active portals changes
Work in Progress & Next Steps
While Homses Battle is moving along well, it remains an active work in progress. Core gameplay systems, including the modular ability framework, data-driven projectile logic, and movement mechanics, are now functional and form a good foundation for further development.
The next major focus will be on expanding the depth of player abilities and beginning integration of more complex AI systems using the same modular, capability-driven approach. Improvements to combat feel, visual feedback, and system scalability are also on the roadmap.
Development is ongoing and transparent. The project is open-source and available on GitHub, where progress can be followed.