Phasing Power-Up
The buff allows the player to pass through forest tiles that normally block movement. Its logic, visual feedback and audio feedback communicate the changed movement rule.
Tile-Based Puzzle Game
Teach two movement mechanics, then ask the player to combine them.
- Problem
- Introduce new movement rules clearly, then build puzzles that depend on their interaction.
- My contribution
- I developed the individual Unreal project, implementing a Phasing Power-Up and a Directional Force Tile, their feedback, and levels that introduce and combine the mechanics.
- Result
- Two implemented movement mechanics support a three-level puzzle sequence, ending in a level that combines them.
Introduce each rule before combining them
The sequence gives each mechanic its own introduction before the final level combines them. This lets the challenge come from applying the rules together, after the player has encountered them individually.
Phasing changes where you can move; force tiles change how you move
Directional Force Tile
Stepping onto the tile propels the player across the board while retaining normal tile interactions. The combined level asks the player to reason about both movement rules.
Individual coursework project by Cody Flanagan, Full Sail University. Implemented with Unreal Blueprint.
Postmortem
This was an individual project developed through three course sprints. I first created my own mechanic and its ClickUp execution plan. In the second sprint, I implemented a classmate’s mechanic from their plan, extended it and integrated it with my own. The final sprint focused on refinement and polish.
What worked
Phasing and directional movement created complementary puzzle choices. Separating the movement loop from each tile’s entry behavior made their interactions easier to maintain.
What I would change
I would plan the interactions between tile types earlier and protect time for level design. The final refactor improved the mechanics, but left less room to explore their puzzle potential in additional levels.
The sprint structure also gave me practice turning a specification into tasks, building on another designer’s intent and revising a working implementation.
Read the complete original postmortem · 3 pages
Navigator, Driver and Leader are the course’s sprint labels. This was an individual submission; the Driver sprint used and extended a classmate’s mechanic specification.
Read as text
Portfolio 2 — Tile-Based Puzzle Game
Full Sail University | March 2026 | Unreal Engine 5 / Blueprint
Introduction
This postmortem covers a tile-based puzzle game developed in Unreal Engine 5 using Blueprints over the course of a multi-sprint class project at Full Sail University. The game takes place on a grid-based board where the player navigates tiles with distinct behaviors — some safe, some hazardous, and some interactive. The project was built across three roles: Navigator, where I designed and implemented my own primary mechanic; Driver, where I adopted and integrated a classmate's mechanic alongside my own; and Leader, where I owned the full project and focused on refining and polishing the work. The two core mechanics are a Phasing Power-Up that temporarily allows the player to pass through otherwise impassable forest tiles, and a Directional Force Tile that propels the player across the board in a set direction when stepped on. This postmortem reflects on what worked, what did not, and what I would do differently.
What Went Right
1. The Navigator Sprint Felt Smooth and the Visuals Landed Well
The navigator sprint was the most straightforward of the three. Building the phasing power-up's core logic — the interactable orb, the buff, the phasing check on forest tiles — came together without major resistance and felt clean at the time. Beyond the logic, the audio feedback for picking up the power-up and the buff itself were genuinely well executed and required no rework across any subsequent sprint. The Niagara visual for the power-up also came together well, with fewer constraints on what I wanted it to look like giving me more creative freedom than the force tile visual ever had. It was not until later sprints that I realized how poorly the underlying code was actually structured, but the surface experience of that sprint was a genuine success.
2. The Two Mechanics Interact Well Together
When both mechanics were finally running in the same build during the driver sprint, they worked together in genuinely interesting ways. A player launched by a force tile through a forest tile they could phase through created puzzle dynamics that felt intentional and rewarding. The fact that no special casing was needed to make them cooperate — the architecture handled it naturally once the bugs were resolved — was a sign that the core design was sound even when the implementation was messy getting there.
3. Every Bug Was Resolved
Despite the volume of bugs encountered across all three sprints, nothing shipped broken. The force tile had numerous interaction bugs that required significant backtracking to fix. The phasing logic had to be restructured multiple times. The sliding architecture was rebuilt from scratch in the leader sprint. Every single one of these problems was eventually diagnosed and resolved without abandoning the design intent. The final build behaves exactly as intended for both mechanics.
4. Level Design Was Enjoyable and Effective
Building the levels during the driver sprint was the most enjoyable part of the entire project. Thinking through how the two mechanics could interact with each other and designing puzzles that required the player to use both created a genuinely satisfying design problem to work through. The levels that exist accomplish what they need to and demonstrate the mechanics working together. The process itself felt natural in a way that the coding work rarely did during that sprint.
5. The Leader Sprint Refactor Produced the Cleanest Work of the Project
The decision to spend the leader sprint on a code refactor rather than new content was the right call. Consolidating the phasing logic into a single CheckPhasingPowerUp function, rebuilding sliding as a HandleSliding custom event with its own clean loop, and stripping MoveToTile back to a single responsibility produced a codebase that is genuinely maintainable. The architecture now handles every tile type through each tile's own On Entered logic without the movement system needing to know about any of them specifically. The visual polish work — the force tile trail color, lifetime, gap fix, and power-up orb rotation — brought the feedback closer to where it needed to be.
What Went Wrong
1. The Navigator Code Was Far Worse Than It Appeared
The navigator sprint felt smooth on the surface but the underlying code was sloppy and poorly structured in ways that did not become clear until later. The phasing power-up was built using an overlap event when the project's architecture required an interact event — a fundamental mismatch that should never have happened and that required a full redo of the mechanic during the driver sprint. What felt like a successful sprint was actually a sprint that produced technical debt that had to be paid in the next one.
2. Planning Before Coding
Multiple times across this project I chose one aspect of a mechanic, built it, and then discovered that the surrounding code needed to be restructured to support what the mechanic actually needed to do. The force tile initially only handled movement to a wall. When I later needed it to interact with other tiles along the way, the code had to be torn down and revised. That was one instance — there were several. Each revision cost time that more careful upfront thinking about the full logic path would have saved.
3. The Force Tile Niagara Visual Was a Consistent Struggle
Unlike the power-up Niagara which had creative freedom and came together well, the force tile visual had a defined goal and fought me the entire time. Wrapping my head around how the ribbon system worked, getting it to behave consistently, solving the gap that appeared on each new activation, and getting the lifetime to feel right were all problems that persisted across the driver and leader sprints. The final result is functional feedback but never reached a level I was satisfied with, and it consumed time disproportionate to the quality of the outcome. In hindsight, starting with a simpler visual approach and iterating toward complexity would have been the smarter path.
4. Time Management
This is the answer I give after every assignment in every class — my entire time at Full Sail this has consistently been my answer. Balancing a contracting business, school, and personal life leaves very little margin, and this project exposed that at every stage. The navigator sprint ran over on code and visuals. The driver sprint did not have enough time for the level design I wanted. The leader sprint ran over on the refactor and visual work and left no time for building additional levels. Better protection of dedicated project time earlier in each sprint would have changed the outcome on almost every item in this list.
5. Additional Levels Were Never Built
Level design was one of the most enjoyable parts of the project and one of the most underserved. The existing levels work and demonstrate both mechanics together, but they do not explore the full puzzle potential that the two mechanics create. The leader sprint was supposed to include new levels that introduced the player to new ways the mechanics interact and created unique puzzles that required combining both — that work never happened because the code and visual work ran longer than anticipated. Level design kept getting treated as what happens with whatever time remains, and there was never enough time remaining.
Conclusion
This project produced two working mechanics, a clean final architecture, and a playable puzzle game built from scratch in Unreal Engine 5 across three sprints. The phasing power-up and directional force tile interact in ways that create genuine puzzle possibilities, and the codebase that supports them is significantly better organized at the end than it was at any point during development. The recurring themes across what went wrong — building before planning, underestimating how long polish takes, and running out of time before level design got its due — are not new lessons, but this project gave them specific and concrete examples. The goal is to carry those examples into the next project with enough self-awareness to do something different.