15 years in game engineering. Mobile F2P, Unity, web tech, the works.
Made every architecture mistake. Shipped every performance disaster. Survived every "quick fix" that wasn't.
Starting today: sharing the lessons I wish someone had told me.
First thread: ๐งต
๐ Pro Tip: Optimize your mobile game's performance by using Object Pooling! ๐ฎ Instead of creating/destroying objects, reuse them. Saves CPU/GPU cycles & boosts FPS! #GameDev#UnityTips#MobileGaming ๐ก Example: Bullet/Enemy pooling in shooters! ๐ฅ
Just optimized my mobile game's frame rate from 30 to 60 FPS! ๐ฎ๐ The trick? Reducing draw calls by baking lighting & using occlusion culling. #UnityTips#GameDev Pro tip: Always profile before & after! ๐ #MobileGaming#IndieDev
๐ฑ **Pro Tip**: **Texture compression** can shrink your mobile gameโs size by **50%+** without losing quality.
I switched to **ASTC** and saved **20MB** instantly.
#Unity3D#MobileGameDev#GameOptimization#IndieDev
The fastest way to learn engine internals?
Find a bug that's impossible, open the debugger,
and realize the engine is doing exactly what you told it to.
It is just not what you thought you told it to. ๐ข
Every multiplayer project eventually reaches the same moment:
'Is it a bug?'
'Is it networking?'
'Or is it networking hiding a bug?'
The answer: yes. ๐ข
Scope creep rarely arrives as a big request.
It shows up as:
- 'Could we justโฆ?'
- 'It would only take a dayโฆ'
- 'While you're in thereโฆ'
Death by a thousand favors. ๐ข
Game dev pro tip: if a bug disappears when you add a Debug.Log, you don't have a fix.
You have a quantum event tied to observer effect.
Prepare for pain. ๐ข
Some meetings start as a quick sync and gradually evolve into a weekly ritual nobody remembers scheduling.
The agenda is gone. The purpose is folklore.
But everyone shows upโฆ just in case itโs important. ๐ข
Every codebase has that one feature toggle everyoneโs afraid to turn off.
No one remembers why it exists. No one knows what it controls.
Itโs Schrรถdingerโs switch: both critical and completely useless until observed. ๐ข
Junior dev: "Why not just use reflection for everything?"
Senior dev: *flashback to 200ms frame times on mobile*
Some things you learn from documentation. Others you learn from Apple rejecting your app for performance. ๐ข
"We can fix that in post" works in film production.
In game dev, it means "we'll ship the bug and pray nobody notices."
Spoiler: they notice. They always notice. ๐ข
Every game studio has a "Utils" folder that's 40% actually useful utilities and 60% someone's abandoned experiments from 10 years ago.
Nobody knows what half of it does. Nobody dares delete it.
This is our shared archaeology. ๐ข
These lessons cost me years of pain, crunch, and production incidents.
Sharing them here so maybe you skip a few of those.
More threads coming. Follow along if you want fewer 3am emergencies. ๐ข
15 years in game engineering. Mobile F2P, Unity, web tech, the works.
Made every architecture mistake. Shipped every performance disaster. Survived every "quick fix" that wasn't.
Starting today: sharing the lessons I wish someone had told me.
First thread: ๐งต
Lesson 6: Communication scales worse than code.
At 10 people, you can wing it. At 50, you need systems. At 90, you need documentation nobody reads.
The hard part of engineering isn't code. It's coordinating humans.