Ever tried to create an ambitious game only to be met by a thousand setbacks ? Don't worry it happens. In fact this list is compiled from my own experience building horror games in unity(painful memories). This are for the versions unity LTS 2023 and previous but is not limited to them and applies to unity 6 as well. I hope it was worth a read, enjoy :)

Planning & Project Architecture

1. Always create a GDD first.
A Game Design Document (GDD) is your blueprint. Include story drafts, pseudo code, environment design, post-processing ideas, everything. It keeps you grounded. I personally use notion for that.

2. Always plan your target platform.
PC? Console? Mobile? VR? Everything from UI scaling to shader complexity hinges on this decision.

3. Decide on your render pipeline early.
URP, HDRP, or Built-in. Each has pros and cons. Switching mid-project is painful, and also later on, you may realize that your project is too complex for that certain pipeline but too broad to change, so plan carefully.

4. Prototype first, optimize later.
Get the gameplay right before sweating performance. Because, later on, you will need to reoptimize again anyways.

5. Never render what the player can't see.
Use occlusion culling, cull distances, and smart camera frustums, fog to hide stuff far away.

6. Break down logic into manager scripts.
GameManager, AudioManager, UIManager, etc. Modular systems scale better.

7. Use version control.
Git, Plastic SCM, or Perforce, use something with at least 100GB of storage. You'll thank yourself later. And also get an UPS, because electricity can go out anytime, and unity corrupts itself when suddenly closed. So get yourself an asset that autosaves!

8. Functionalize everything.
Keep logic modular. Reference shared systems, don’t duplicate them.

9. Document your code in the GDD.
Track your systems, variables, and data structures alongside your design. Trust me, it WILL pay off. You are a human, today you know everything about your code, tomorrow you will be confused as hell. Granted that code should be self documented, having an external documentation helps too.

10. Use ScriptableObjects for shared data.
They're ideal for configuration, global state, and shared resources without hard references.

Code Architecture & Performance

11. Don’t overuse singletons.
Limit them to essential systems, and keep logic out of them.

12. Separate core logic from UI.
UI should reflect state, not control it. At best, assign runtime references for buttons.

13. Use the Addressable Asset System.
Especially for large projects. It’s efficient, modular, and memory-friendly.

14. Organize your project folders early.
Structure matters: Scripts/, Prefabs/, Audio/, Art/, Scenes/.

15. Async load big scenes and assets.
Prevent hard freezes by using SceneManager.LoadSceneAsync() or Addressables.

16. Profile early and often.
Use Unity Profiler, RenderDoc, or external tools regularly. And watch out for every thread !

17. Use nested prefabs.
Makes your systems modular, reusable, and scalable.

18. Never animate UI directly on GameObjects.
Use DOTween or Unity’s Animator for flexibility and polish.

19. Pick your input system early.
Switching between the legacy Input and the new Input System mid-project is painful. And Both input systems aren't ideal for phones. So my recommendation is to use the newer one, if you're planning on multi-platformed games.

20. Avoid FindObjectOfType() in runtime.
Use serialized fields, dependency injection, or event systems. Why? Because they are mad expensive to run.

21. Use event-driven architecture.
UnityEvents, C# delegates, or custom event buses keep your code modular.

22. Set up physics layers and a collision matrix.
Do it from day one to avoid debugging chaos later.

23.Keep FixedUpdate() lean.
It’s for physics, don’t clutter it with heavy logic. It impacts performance badly.

24. Use object pooling.
For bullets, blood splats, enemies, etc. Avoid instantiate/destroy hell.

25. Don’t hardcode references.
Use ScriptableObjects, serialized fields, or managers to handle resources like audio clips.

Content, World, and Performance

26. Implement localization early.
Retrofitting it later is a nightmare. Unity's localization package helps.

27. Use gizmos for in-editor debugging.
AI ranges, vision cones, nav paths, etc just draw them.

28. Use logs, but don’t rely only on Unity Editor.
Implement on-screen logs or console toggles for builds.

29. Avoid MonoBehaviour bloat.
Large classes are hard to debug. Keep responsibilities separated.

30. Understand Unity’s garbage collection.
Watch out for allocations from string operations and LINQ. Use object pooling where needed.

Advanced Systems & Optimization

31. Bake lighting for static geometry. Use light probes for dynamic objects.
This gives you the best performance and visual fidelity mix.

32. Divide large scenes into loading zones.
Use additive scenes or addressables for seamless streaming.

33. Manual occlusion for dynamic content.
Unity’s occlusion only works for static objects. Use frustum checks or portals for the rest.

34. Bake navmesh per scene. Use links for transitions.
This allows AI to transition between areas cleanly.

35. Build a custom audio system.
For horror, layer ambient loops, whispers, distant cries, and stingers. Audio is 70% of fear.

36. Use post-processing volumes for mood shifts.
Transition colors, fog, exposure per room or area.

37. LOD logic for non-visual elements.
Disable scripts, triggers, and AI systems far from the player.

38. Use tags/layers wisely in AI.
Detect “Player” or “SoundSource” with custom logic instead of brute-force raycasts.

39. Create a persistent “Manager Scene.”
Game state, UI, audio, and input all live here. Load game levels on top of it.

40. Simulate memory pressure during testing.
Force GC, simulate low-end hardware, and test worst-case scenarios.

AI, Horror Systems, and Tools

41. Visualize AI logic.
Use rays, gizmos, or debug UIs to show what AI sees, hears, or targets.

42. Build a robust save/load system.
Don’t just save position! track doors, enemies, notes, and more. Serialize with JSON or binary.

43. Create an event queue system.
Chain scares, animations, and sequences across scenes with reusable logic.

44. Separate physics layers for enemies and players.
Allows fine control over interactions like footsteps, traps, or triggers.

45. Use real-time reflections sparingly.
Mirrors, blood puddles? yes. Everywhere else? no. Use baked probes for everything else.

46. Compress textures intelligently.
Use mipmaps and Crunch compression to save memory, especially on detailed horror assets.

47. Use custom shaders and contact shadows.
Creepy lighting, fake subsurface scattering, or screen-space effects all boost horror atmosphere. And also use decals for shadows, less expensive and good visual results.

48. Log or simulate player behavior.
Record test sessions to improve pacing, scare timing, and level layout.

49. Bundle environmental effects together.
Avoid chaos when a scare triggers. Group sound, light, camera shake into a timed package.

50. Build internal tools to speed up workflow.
Editor scripts for placing lights, randomizing props, or testing paths will save days. For example, I built editor tools to advance through quests and acts to playtest faster.

Some additional tips:

• Always use simplified colliders like box, sphere, capsule instead of mesh colliders unless needed.
• Always use simplified materials like simple lit instead of standard lit or complex lit.
• Realtime Lighting shouldn't be used unless you need light that needs to be turned off or on at some point.
• Your game is more prone to be gpu intensive than cpu, so debug accordingly.
• Use shader graphs and vfx graphs as they run on the gpu and take less resources
• Have people playtest your game but not actual players, as it may impact their impression.
• If you want to release on ios but don't have a mac or enough money to pay for unity cloud, then run mac os on VMWare, Virtual Box and compile your game there after exporting from unity. (indie dev core)

If you made it this far, thank you. These tips come from many hours (and sleepless nights) building large Unity games, especially in the horror genre. Hopefully, they save you some pain and help you build better, smarter, and faster.

You can check out my free beta horror game which I made in last two months.

Got your own tips or horror dev stories?
Drop them in the comments. We’re all in this haunted house together.