Combat
- 4-Spell casting system with fluid transitions
- Third-person aiming for precise spell placement
- Damage & health system with spell-based calculations
- Spell-hit VFX triggered on impact
Character
- Custom third-person character controller
- Responsive movement mechanics
- Animation rigging and implementation
- Locomotion system for combat and exploration
Enemy AI
- Slime enemy — unique attack patterns and behaviors
- Skeleton enemy — distinct combat requiring different strategies
- Behavior Trees with patrol, chase, and combat states
Environment
- Maze-like dungeon layout blockout
- Spatial planning and atmospheric lighting
- Secrets and puzzle placement
The spell system remained the most stable and polished component throughout development. Spells worked in harmony without interfering with each other, creating fluid combat encounters that successfully anchored the gameplay experience.
Both enemy types added character to the world and required different player approaches, creating tactical variety. The Slime's translucent material and simpler movement contrasted well against the Skeleton's more aggressive melee combat.
Core systems remained stable throughout development, demonstrating a solid technical foundation and systematic approach to game systems design with minimal breaking changes.
Successfully debugged and fixed numerous technical issues throughout the project, building confidence in Blueprint development and confirming it as a preferred development method.
Initial vision exceeded what was feasible in 10 weeks. Features cut to meet deadline:
- Laser beam spell
- Advanced movement systems
- Cinematic sequences
- Additional spell types
Third-person character animation consumed significantly more time than anticipated. Early skeleton setup mistakes prevented player model replacement, forcing work with the default UE5 mannequin throughout production.
Early decisions created barriers that prevented integration of created assets. Over 12 hours spent on the locomotion system early in development should have been allocated to core gameplay instead.
Development stayed on schedule until midterms disrupted workflow. Recovery required cutting planned features to meet the final deadline.
Scope Management
Always aim lower than perceived capability. Unexpected issues consume more time than planned. Feature quantity should be sacrificed for polish and completion.
Technical Planning
Animation systems are significant time investments. Future projects should evaluate whether third-person perspective is essential or adds unnecessary complexity.
Iteration Strategy
Placeholder implementation followed by polish iteration is more efficient than attempting perfect implementation on the first pass.
Development Focus
Blueprint visual scripting confirmed as preferred development method. Future projects should lean into this strength rather than diversifying unnecessarily.
The project represents a success in terms of learning outcomes despite not achieving the original feature vision. More was learned through this project than most coursework — particularly regarding practical Blueprint implementation, scope management, technical problem-solving, and animation system complexity.
The experience built confidence in system design abilities and provided clear lessons carried directly into GAME 380: prioritize completion over feature count, plan conservatively, and leverage personal strengths in Blueprint development.
"This project is currently being refined and polished in GAME 380 as part of the portfolio development course."