Technical Problems We've Solved

ShadowStrike FPS needed to feel responsive on mobile touchscreens. Initial implementation had noticeable input lag - acceptable for casual games, unacceptable for a competitive shooter.

First approach: Unity's standard Input class with Update polling. Lag was around 100-150ms from touch to visible response. Not good enough.

Second approach: Moved input handling to FixedUpdate, thinking the physics timestep might help. Made it worse - added frame timing inconsistency.

Switched to Unity's new Input System with "Update" processing mode (not "Fixed Update"). Cached all input references at startup. Moved camera/aim updates to LateUpdate to ensure they process after all input for that frame.

Also reduced touch input polling area - instead of processing the entire screen, we tracked active touch zones only. Less garbage generation, faster processing.

TOGETHER: OR WE DIE targets HDRP for visual quality. Early builds ran 45-50 FPS on a GTX 1070, with dips below 30 in complex scenes. Target was stable 60 FPS on GTX 1060-class hardware.

Initial instinct was to reduce shadow quality and disable ray tracing features. Helped slightly but didn't hit targets. The problem wasn't any single expensive feature.

Profiling revealed the actual bottlenecks: overdraw from overlapping transparent effects, too many realtime lights in the same view, and expensive post-processing running at full resolution.

• Implemented aggressive occlusion culling with manual occluder geometry in key areas
• Created LOD configurations for lights - distant lights bake to lightmaps, only nearby ones are realtime
• Reduced post-processing resolution to 75% with FSR upscaling
• Batched particle effects and reduced overdraw by using additive blending instead of alpha where visually acceptable

MATH FPS needed satisfying weapon feedback despite being an educational game. First implementation felt like clicking a button rather than firing a gun. The math mechanics were working, but the shooting felt terrible.

Added screen shake. Made it worse - felt disorienting rather than impactful. Added camera punch (instant rotation up, gradual return). Better, but still missing something.

The key insight was that good weapon feel is about timing and layering, not intensity. Final solution:

• Visual recoil: immediate camera punch (0.05s), smooth recovery (0.15s), with a slight S-curve easing
• Weapon kick: physical model moves backward then returns, slightly out of phase with camera
• Screen effects: subtle chromatic aberration pulse (2 frames), very slight vignette flash
• Audio: layered shot sound with sub-bass impact, plus distant reflection for environment

Each element alone is subtle. Together they create satisfying feedback without being distracting from the math puzzles.

Zones in TOGETHER: OR WE DIE are large - players need to navigate, explore, and potentially backtrack. Initial approach of loading entire zones caused 4GB+ memory usage, making console targets impossible.

Unity's built-in scene streaming with additive loading. Worked functionally but caused visible hitches during load/unload. Not acceptable in a game where you might be running from enemies.

Implemented custom streaming with predictive loading based on player position and velocity. Zones are divided into cells; we maintain a loaded radius around the player plus predicted future positions.

Critical change: all asset loading is async and spread across multiple frames. We budget 2ms per frame for loading operations. This caps worst-case hitching regardless of what's being loaded.

Additionally, implemented an aggressive pooling system for enemies, loot, and effects. Nothing gets instantiated during gameplay - everything comes from pre-warmed pools.