Reflection:

On this project, I served in a technical lead role, overseeing core gameplay systems like movement, reality switching, and GAS implementation. While I successfully shipped a quality and solid movement overhaul, the overall leadership responsibilities proved far harder than anticipated. This project has highlighted insights into my working style, my strengths, and my weaknesses.

Early on, I was a do-it-myself problem-solver. I often chose to do hard or foundational work myself, both because I trusted myself to create high-quality work and because I struggled to delegate. This was not out of distrust, but from a desire to keep things consistent and a reluctance to burden others with tasks which may be difficult to accomplish to the standard I envisioned. This plan put an unrealistic workload, and underdeveloped other facets of the project underdeveloped. One person cannot, and should not, attempt to carry the weight of a 25-person game project alone.

Looking back, I understand now that my reluctance to delegate was not about control but about a fundamental discomfort with leadership itself. I far prefer being a technical contributor of sorts, with distinct tasks and autonomy to delve thoroughly into system implementation instead of organizing and planning such systems. Had I known this earlier, it would have been a good idea to shift leadership to someone more at ease with coordination, planning, and team management. By clinging to the leadership role that was inappropriate for me, I was limiting my own performance and the performance of the team.

Despite all this, I am content with what was delivered - particularly in the movement system. I closely collaborated with the team through iteration, feedback, and testing. Taking lessons from Titanfall 2's, TF2's and Counter Strike Source movement systems, I re-designed the player movement system to be centered around smoothness, chaining, and player expression. It was the sole redeeming quality of the project, and I believe it is a good example of collaborative iteration and technical design implementation from collaboration between the technical and designer teams.

All in all, this project was a learning process on two main levels. One, that the intense collaboration and shared responsibility are absolutely essential to team-based development. Two, that leadership isn't just a matter of claiming authority - it's a matter of enabling others, leaving space for them to input, and believing in the team to excel together. In the future, I will look to apply for jobs that play more to my strengths as a systems developer, where I can excel supporting rather then directing team efforts.

Leadership and Technical Planning:

Perhaps the most critical aspect of my experience was creating a good technical foundation in Unreal Engine 5. I set up early on GAS for ability-based combat, player health, and status effects - this enabled modular, data-driven mechanics in both sci-fi and fantasy environments (if the sci-fi had not been cut). I learned that good system design must be forward-thinking regarding scalability; by establishing extensible ability classes, I enabled the the ability to create new character and weapon features without an extensive refactor.

As Technical Lead, I began by onboarding new designers into the GAS, as well as GitHub workflows. Through branch naming conventions, there was more collaboration among level designers, artists, and engineers, with the merges remaining destructive-free. This helped me refine my project management skills and know how crucial systems need to be clearly explained across disciplines.

Reality switching level streaming was a technical challenge that included the integration of persistent sublevels and custom blueprint logic to manage seamless reality switching. It required asynchronous level loading and synchronizing player state between realities.

Time constraints and shifting priorities also meant that a few systems were left unfinished. Some of the weapon bullet types were not used, most of which didn't get finishing visual flair or shine because stability of a finished experience came first. In hindsight, cross-discipline syncing more frequently might have ensured better gameplay and priorities.

Working with a big, mixed team helped me learn how to be independent yet work together. I had weekly tech syncs and group retrospectives, where I learned to provide feedback constructively. Breaking down small tasks such as updating data tables or defining tags enabled me to focus on architectural issues while providing opportunities for junior designers to learn.