unity-csharp-scripting
Write Unity 6.3 LTS C# gameplay scripts: the MonoBehaviour lifecycle (Awake/OnEnable/Start/Update/FixedUpdate/LateUpdate), GameObject and component access, coroutines, and Inspector serialization. Use when creating or editing .cs scripts in a Unity project, or when the user mentions MonoBehaviour, S
By gamedev-skills · 2,332 installs
npx skills add gamedev-skills/awesome-gamedev-agent-skills --skill unity-csharp-scripting
Source repository · Upstream listing
Unity C Scripting (MonoBehaviour)
Write correct, idiomatic gameplay scripts in Unity 6. Get the lifecycle, component
access, serialization, and coroutines right so behaviour is deterministic and the
Inspector stays useful. Targets Unity 6.3 LTS (6000.3) , C / .NET Standard 2.1.
When to use
Use when authoring or fixing a MonoBehaviour : choosing the right lifecycle callback,
reading/caching components, exposing fields to the Inspector, or running timed logic
with coroutines.
Use when the project has .cs files, an Assembly CSharp or .asmdef , and a
ProjectSettings/ folder.
When not to use: moving rigidbodies / collision response → unity physics ; reading
player input → unity input system ; shared data assets / config → unity scriptableobjects ;
Animator parameters → unity animation . This skill owns the script lifecycle and C
plumbing , not those subsystems.
Core workflow
1. Pick the callback by purpose, not habit. Awake (cache references, runs once on
load), OnEnable (subscribe to events), Start (init that depends on other objects'
Awake ), Update (per frame logic/input polling), FixedUpdate (physics), LateUpdate
(camera follow after movement), OnDisable / OnDestroy (unsubscribe/cleanup).
2. Cache component lookups in Awake — never call GetComponent every frame.
3. Expose tunables with [SerializeField] private , not public fields, so other code
can't mutate them but designers can edit them in the Inspector.
4. Scale per frame values by Time.deltaTime in Update (and Time.fixedDeltaTime
semantics are automatic in FixedUpdate ).
5. Use coroutines for time sequenced logic (delays, tweens, "do X then wait then Y");
start them with StartCoroutine and stop them deterministically.
6. Verify in Play mode : check the Console for null reference exceptions, confirm values
in the Inspector update as expected, and watch the Profiler if Update is hot.
7. Check .meta files before you finish. When you create, move, rename or delete
scripts or assets outside the Editor, always move a file together with its .meta
(a new .meta means a new GUID and broken references). Then run
python scripts/check unity project.py <project dir ( json for machine readable
output), fix every ERROR (duplicate or malformed GUIDs, files moved without their
.meta , missing script references) and re run until it exits 0. A missing .meta on a
brand new file is only a warning; Unity creates it on the next import. Run the script
path relative to this skill directory, or resolve the installed skill path first. It
needs Python 3.10+ and nothing else, reads only text serialized assets, and does not
replace opening the project in Unity.
Patterns
1. Lifecycle + cached components (the canonical skeleton)
2. Safe component access with TryGetComponent
3. Serialization that shows up correctly in the Inspector
4. Coroutines for time sequenced logic
Pitfalls
GetComponent in Update — it searches every frame and tanks performance. Cache the
reference in Awake / Start .
Physics in Update — moving a Rigidbody with forces or MovePosition outside
FixedUpdate causes jitter and timestep dependent behaviour. Read input in Update ,
apply physics in FixedUpdate .
Relying on Start order across objects — Start runs after all Awake s, but order
among Start s is undefined. Do cross object wiring in Start , self setup in Awake .
public fields just to show them in the Inspector — that also lets any script mutate
them. Use [SerializeField] private instead.
gameObject.tag == "Enemy" allocates a string and is slower; use
gameObject.CompareTag("Enemy") .
Coroutines stop when the GameObject is disabled — a disabled object's coroutines are
killed; re StartCoroutine in OnEnable if it must survive toggling. Setting only the
script's enabled = false does not stop them.
Obsolete warnings on FindObjectOfType / FindObjectsOfType — Unity 6 replaced them.
Use FindFirstObjectByType (old behaviour), FindAnyObjectByType (faster, any match) or
FindObjectsByType(FindObjectsSortMode.None) ; all are slow, so cache the result.
An async method keeps running after its object is destroyed — await is not tied to
the GameObject the way a coroutine is. Pass destroyCancellationToken to the
Awaitable waits (they then throw OperationCanceledException ), and never await the same
Awaitable instance twice: instances are pooled.
Update never runs before Start , but the first Update can run on the same
frame as Start — guard against not yet initialised fields if you split setup oddly.
References
For the full event execution order table, advanced coroutine patterns (custom
CustomYieldInstruction , stopping by handle, WaitUntil / WaitWhile ) and the Awaitable
equivalents of coroutine waits, read references/lifecycle and coroutines.md .
scripts/check unity project.py — read only .meta /GUID and missing script checker;
help lists every check and the exit codes.
Primary docs: Unity Manual "Event function execution order"
( https://docs.unity3d.com/Manual/execution order.html ), ScriptReference/MonoBehaviour ,
and the Manual page "Asynchronous programming with the Awaitable class".
Related skills
unity physics — Rigidbody , collisions, and FixedUpdate motion.
unity input system — reading player input into these scripts.
unity scriptableobjects — sharing data/config between scripts without singletons.