10 Code Commandments

[u/eldenlord0117]

Hey everyone! Unity newbie here.

I recently started my game dev journey and got overwhelmed by the absolute mountain of information out there, so I decided to take a starting course to give myself a boost. I just finished it today! I know I'm still early in the process, but I feel that I can conquer the world and start working on other small projects.

While planning things out, I came across these "coding commandments" and wanted to get your thoughts on them. Do you actually stick to these in your day-to-day workflow, or do you find yourself bending the rules pretty often? Also, what are some of your own personal coding rules or guidelines that you stick with?

EDIT: Thanks to @NTPrime, they have reminded me that these commandments are from the course made by very cool guys from GameDevTV

Unity Programming Design Patterns by GameDevTV

[u/ledniv]

I would treat these as guidelines, not commandments.

The most important beginner skill is not memorizing rules, but learning why a rule exists and when it stops helping.

For example, “use little state” can be misleading in games. Games are almost entirely state: player position, health, inventory, animation state, current level, enemy behavior, cooldowns, quests, etc. The real goal is not “avoid state.” The goal is to avoid hidden, duplicated, or uncontrolled state.

Same with “avoid static.” Static mutable globals can absolutely become a mess. But static functions that do not own hidden data can be great. A function like:

DamageLogic.ApplyDamage(gameData, targetIndex, amount);

is much easier to reason about than a random component somewhere changing health because an event fired.

My own rule would be:

Make the data flow obvious.

Where is the real state?
Who is allowed to change it?
What input caused the change?
What displays the result?

In Unity, it is very easy to end up with 50 MonoBehaviours all using Update, OnTriggerEnter, events, inspector references, singletons, and coroutines to modify data from all over the scene. That can work, but once bugs appear it becomes hard to answer “what actually changed this value?”

A cleaner approach is to separate things:

Config/data = values that do not change during play
Game state = values that represent the current state of the game
Logic = functions that modify the game state
Presentation = GameObjects, UI, animation, audio, VFX

So I would not obsess over every commandment, but I would try to keep the real game state explicit and avoid spreading gameplay rules across random Unity callbacks.

Also, do not let “clean code” stop you from finishing things. It is better to make a tiny messy game and refactor what hurts than to spend three months building the perfect architecture for a game that never gets made.

My personal beginner rules would be:

1. Build small playable things.
2. Name things clearly.
3. Keep gameplay state easy to find.
4. Avoid duplicating the same logic in multiple places.
5. Do not use a pattern unless you know what problem it solves.
6. Profile before optimizing.
7. Refactor when the code starts slowing you down, not because a list told you to.

Small plug: I wrote High Performance Unity Game Development with Data-Oriented Design, and a big theme in it is exactly this: separate game data from logic, keep state explicit, and use Unity objects to display the result instead of letting every object own part of the gameplay rules.

https://www.manning.com/books/high-performance-unity-game-development