During wave 4, the frame rate would stutter every 3–4 seconds. Not a crash, not a freeze — a noticeable 20ms hike that made the game feel janky. I had 40 bullets on screen at peak. My first instinct: bullets are expensive.
I immediately rewrote the bullet system to use object pooling. Bullets no longer instantiate and destroy — they activate and deactivate from a pool of 100. It took most of a weekend.
The stutter didn't go away.
I opened Unity's Profiler. Five minutes after opening it, I found the actual culprit: the damage number UI.
Every hit spawned a TextMeshPro popup that displayed the damage value, animated upward, and then destroyed itself. At peak combat, that was 30–50 Instantiate calls per second — far more garbage than any bullet.
The fix took 45 minutes: a small pool of 20 text popups that get recycled instead of destroyed.
The bullet pooling I spent the weekend on was still a good idea — it'll matter at higher bullet counts. But it was not the source of the problem I was trying to fix.
Profile before you optimize. This is advice I'd heard a hundred times. Now I've paid the tuition.
My new process: reproduce the problem, open the Profiler, find the actual spike, then write code. Not before.
Frame time: 32ms (frame 1847)
GC.Collect 12.4ms ← here
TextMeshPro.Update 6.1ms
Physics.Simulate 4.8ms
Render 5.3ms
The GC.Collect call is the giveaway — that's the garbage collector running because something is allocating heavily. Bullets after pooling: 0 allocations. Text popups before pooling: ~800 bytes per popup × 50 popups/sec = ~40KB/sec of garbage.
Three things generate GC pressure more than anything else in my experience:
Update() — $"Score: {score}" creates a new string every frame.Where(), .Select() allocate enumeratorsProfile first. Know which of the three you're actually hitting before you rewrite anything.
Sharpshooters dev log. Follow along as I build a 3D shooter from scratch.
]]>Unity has MonoBehaviour. Unreal has AActor. Both are components attached to game objects that run every frame. The mental model transferred almost directly.
What is different: Unreal's ownership model. In Unity, game objects get destroyed and the garbage collector cleans up. In Unreal, you manage lifetime more carefully — TObjectPtr<>, weak references, and understanding when the engine owns vs. you own.
I hit my first crash because I held a raw pointer to an actor that got destroyed. Unity never taught me to think about this.
Every guide I read said "learn C++ first, Blueprints are a crutch." I disagree — at least for a complete beginner to Unreal.
I prototyped the entire Infinite Runner movement system in Blueprints in a week. Then I ported it to C++ over the next week. Having a working Blueprint reference made the C++ translation much cleaner — I wasn't learning the engine API and solving gameplay design problems simultaneously.
Blueprints are also excellent for tweaking values. I kept the difficulty curve tuning in Blueprints (exposed variables) so I could adjust without recompiling.
Unity is near-instant iteration. Unreal C++ builds take 30–120 seconds depending on change scope. This changes how you work:
After two weeks I stopped noticing the wait. But the first week was painful.
Unity's documentation is clearly written for people learning the engine. Unreal's documentation assumes you already know what you're looking for.
The community around Unreal is great, but it's weighted toward visual/Blueprint content. Finding C++ answers sometimes required reading source code or asking on the Unreal forums directly.
I'm comfortable in both engines now. The things that felt alien in Unreal — the actor lifecycle, the build system, the C++ conventions — are now just normal.
The bigger lesson: the fundamentals transfer. State machines, object pooling, event systems, data separation — none of that is engine-specific. Understanding why patterns work makes picking up new engines much faster.
Yisi Liu — building the Infinite Runner in Unreal Engine 5.
]]>My first game jam was in early 2024. Here's what I learned — most of it the hard way.
The theme dropped: "One Room."
My first idea: a mystery game where the player explores a single room across different time periods, past and future versions overlapping. Dialogue system. Multiple endings. Inventory. 48 hours.
I started building the dialogue system.
Two hours in, a friend looked at my project and said: "Can you finish that in 46 hours?"
I couldn't. I scrapped it.
I made myself answer three questions:
New idea: a single-screen puzzle where the player moves a box around a room to reach a door. Simple. Clearly scoped. Done = puzzle solved, fade to credits.
I started building it.
No polish until core is working. No effects until the mechanic works. No music until I can complete the puzzle.
This felt wrong. I'm used to iterating on feel as I go. But under a deadline, working ugly beats pretty-but-broken.
By hour 24, the puzzle was completable. The box moved, the physics felt okay, you could reach the door and win.
Polish. Music (a free CC0 track). Sound effects. Title screen. "You Win" screen. Build it. Upload it.
I submitted with 20 minutes to spare. The game had 8 levels and took about 12 minutes to complete.
Finishing is a skill. It sounds obvious but I hadn't practiced it. Every project before the jam had always been "in progress." The jam forced me to make the hard call: this is what ships, everything else is cut.
Scope is a prediction. You don't know if something fits until you try. The dialogue system felt totally reasonable until the clock made it concrete. Now when I plan projects, I ask: can I build the core mechanic in one weekend? If not, the design is probably too complex for the time I have.
The game doesn't have to be good — it has to be done. My jam game is not impressive. The puzzles are easy and the graphics are programmer art. But it's a finished thing that exists in the world, and that feels completely different from an unfinished project that exists only on my hard drive.
I've done two more jams since. Each time, I scope smaller than I think I should, and each time I'm glad I did.
Yisi Liu — learning to ship, one game at a time.
]]>