Human Fall Flat 2

Why this project matters

Human Fall Flat 2 is the strongest evidence of my professional production experience. The value is not only that it is a Unity/C# title; it is that the work happened in a real multidisciplinary production environment with milestones, production locks, QA passes, pull requests, TeamCity builds, Jira bugs, code reviews and runtime constraints.

I describe the work here in NDA-safe terms. Some systems cannot be named publicly, but the engineering patterns are clear: modular feature packages, runtime systems, internal tools, debugging workflows, profiling and ownership from requirement clarification to production merge.

Production context

The project was a multiplayer, physics-driven Unity 6 title developed by a 20-30 person team. Work was organized around milestones, typically followed by production lock, bug-fixing/stabilization, large QA test passes, merge into the production branch and build verification.

My role evolved from Junior Programmer to Programmer. Most assigned work was individually owned: I was responsible for the feature or fix, but the code still went through PR review, programming feedback, QA validation and production constraints.

Systems and tools, NDA-safe

Publicly safe categories of work include:

• modular gameplay/runtime systems built as independent packages.
• designer-facing level-authoring and validation utilities.
• runtime timing/action workflows to reduce ad-hoc coroutine-style logic.
• level-scoped audio loading and audio-positioning workflows.
• physics-driven gameplay interactions and object-response systems.
• component-based data capture/serialization workflows.
• feature-specific test scenes and logs for validation.
• multiplayer-sensitive debugging where host/client output had to be compared frame-by-frame.

The important signal is not the exact feature names. It is that these were systems with ownership, constraints, users inside the team and production review.

Architecture and maintainability

My approach was to avoid monolithic feature code. Systems were usually split into small scripts/classes, packaged independently when possible and configured through data containers such as ScriptableObjects. Where behaviour needed extension points, interfaces or abstract classes were used so objects could implement their own response without hard-wiring every case into one central script.

A recurring design principle was: if a system might change because gameplay, physics, level design or production constraints change, avoid direct coupling to a single specific content case.

Debugging and runtime behaviour

Debugging work included multiplayer divergence, physics-ordering edge cases, crash/freeze investigations and runtime behaviour problems. Two representative NDA-safe examples:

• A multiplayer interaction produced different visual output on host and clients. The debugging path was to compare host/client runtime data in the same frame, isolate the divergent calculation and fix an incorrect vector/normal result on the client side.
• A physics-driven interaction was not deterministic enough between repeated runs. Investigation showed that a physics query returned unordered results, so the result set needed explicit ordering before applying game logic.

For performance, profiling was part of feature development. I used Unity Profiler, Memory Profiler and ProfilerMarkers to inspect total cost, call counts, GC, allocations, memory and inner loops. When relevant, optimizations included object/list reuse, reducing allocations, splitting work across frames, parallelizing calculation-heavy work and using task scheduling.

Testing and verification

Verification was not limited to “it works on my machine”. Depending on the feature, testing included unit tests, integration tests, playmode tests, editor tests, manual QA passes, feature-specific validation scenes, logs, assertions and local self-testing before handing the work to QA.

Feature-specific scenes were especially valuable: they isolated a system from the full level, reduced noise, allowed repeatable reproduction and made it easier to see whether a change had introduced regressions.

Collaboration and ownership

The normal delivery path included requirement clarification, breaking ambiguous features into smaller tasks, investigation, architecture, implementation, self-testing, TeamCity builds, pull request review, code review discussion, QA validation and final merge. PR discussion often continued in Slack or weekly code reviews where programmers presented problems, solutions and trade-offs.

Professional takeaway

This project proves production engineering maturity: not just writing C# scripts, but owning runtime systems under real constraints, debugging difficult state-dependent issues, building tools for other disciplines, working through review and QA, and keeping software maintainable in a large interactive product.