Game Objects

Summary

A game object is the fundamental "thing that exists in the world" in most game engines — a container that has a position, can hold a name and other identity, and gains all of its actual behavior and appearance from the components attached to it. A game object with nothing attached does nothing and is invisible; it's the components attached to it — a mesh renderer, a health script, a collider — that make it a player, an enemy, a pickup, or a wall.

Why This Matters

Without a common "thing that exists in the world" concept, every kind of object in a game — the player, an enemy, a pickup, a wall — would need its own bespoke way of having a position, being placed in a scene, and being found or destroyed. Engines solve this by giving every object in the world the same underlying container (a game object / Actor), regardless of what it represents, so the engine's scene management, physics, and rendering systems only need to understand one kind of "thing" — while what that thing actually does is entirely determined by what's attached to it (see [[CON-0036]]).

Mental Model

A game object is an empty shipping container, not the cargo inside it. A shipping container has a known size, a location, and a way to be tracked and moved by a port's crane system — regardless of whether it's carrying furniture, electronics, or nothing at all. The container itself doesn't "do" anything interesting; what it carries determines its purpose. A game object is exactly this kind of neutral, trackable container — its identity, position, and purpose in the game come entirely from the components loaded into it.

Core Explanation

A game object has an identity and a position, but not inherent behavior. Every game object carries basic properties (a Transform — position, rotation, scale — a name) regardless of what it represents; behavior comes exclusively from attached components.
Behavior and appearance come from attached components. A completely "empty" game object is invisible and does nothing — adding a mesh renderer component makes it visible, adding a script component gives it custom logic, adding a collider lets it participate in physics.
Game objects can be nested, forming a hierarchy. A Weapon game object might be a child of a Hand game object, which is a child of the Player — moving the parent moves every child along with it, which is how compound objects (a character holding an item) are typically structured.
Different engines use different names for the same underlying idea. Unity calls it a GameObject; Unreal calls the equivalent an Actor. Both are the engine's "a thing that exists and can be placed in the world" primitive, built to hold components.

Syntax / Theory

C# (Unity)

csharp

GameObject enemy = new GameObject("Goblin"); // Empty — invisible, no behavior yet.
enemy.transform.position = new Vector3(5, 0, 0);

enemy.AddComponent<MeshRenderer>();  // Now it's visible.
enemy.AddComponent<EnemyAI>();       // Now it has behavior.

C++ (Unreal — Actors)

cpp

AActor* Enemy = GetWorld()->SpawnActor<AActor>(FVector(500, 0, 0), FRotator::ZeroRotator);
UStaticMeshComponent* MeshComp = NewObject<UStaticMeshComponent>(Enemy);
MeshComp->RegisterComponent(); // Attaching a component the same way — behavior via composition.

An Unreal AActor and a Unity GameObject fill the identical structural role: a neutral world-placeable container that components attach to. The "empty until composed" model is the same in both engines, even though the API surface differs.

Unreal Blueprint

Dragging a new Actor into a level and adding components in the Components panel is the visual equivalent of new GameObject(...) followed by AddComponent<T>() — the same composition model, expressed through the editor rather than code.

Practical Example

A simple pickup is assembled from a plain game object plus exactly the components it needs — nothing more.

csharp

GameObject coin = new GameObject("Coin");
coin.AddComponent<SphereCollider>().isTrigger = true;
coin.AddComponent<MeshRenderer>();
coin.AddComponent<CoinPickup>(); // Custom script handling the pickup logic.

Nothing about GameObject itself knows what a "coin" is — the identity of "coin" emerges entirely from this specific combination of components attached to an otherwise generic container.

Common Mistakes

Expecting a bare game object to do anything by itself. A newly created game object with no components is invisible, has no collision, and has no custom behavior — every capability has to be explicitly added.
Building deep, unnecessary hierarchies "just because objects seem related." Parenting objects together should reflect an actual positional/logical relationship (a weapon following a hand); parenting unrelated objects together purely for scene organization makes their positions unexpectedly coupled.
Holding a reference to a destroyed game object without checking. Destroying a game object doesn't automatically null out every variable that referenced it — code that still calls into a destroyed object's components will throw a null/missing-reference error.
Treating "game object" and "the script/class representing the gameplay concept" as the same thing. The EnemyAI component is not the GameObject — the GameObject is the container the component lives on; conflating the two makes it harder to reason about composition (see [[CON-0031]]).

Game Development Example

A modular enemy is built by combining generic, reusable components on a plain game object, rather than writing one monolithic "Enemy" class.

csharp

GameObject skeleton = new GameObject("Skeleton");
skeleton.AddComponent<Health>();
skeleton.AddComponent<NavMeshAgent>();
skeleton.AddComponent<MeleeAttack>();
skeleton.AddComponent<SkeletonAnimator>();

A FlyingSkeleton variant could reuse Health and MeleeAttack unchanged, swap NavMeshAgent for a FlightMovement component, and add nothing else — the game object itself never needs a special "flying" subtype; its capabilities are simply a different set of attached components.

Best Practices

Keep a game object's hierarchy shallow and meaningful — nest only when positions genuinely should move together.
Treat a game object as a neutral container; put all actual behavior into focused, reusable components attached to it, not into the container concept itself.
Name game objects clearly and consistently in the hierarchy — this is the primary way both designers and other programmers navigate a scene.
Null-check or use lifecycle-safe references when holding onto a game object that might later be destroyed.

Exercises

Create an empty game object, attach a MeshRenderer, Collider, and a custom script component to it one at a time, and describe what capability each addition unlocks.
Take the Coin pickup example and build a HealthPack pickup by reusing the same collider/renderer pattern but swapping in a different custom pickup script — explain what stayed the same and what changed.
You're designing a Door game object that needs to be both a static piece of the environment and, when unlocked, an interactive object with a script and trigger collider. Decide whether "locked" and "unlocked" should be different components toggled on/off, or a single script with internal state, and justify the choice.
Research Unity's Transform hierarchy versus Unreal's Actor/Component attachment model and explain one meaningful difference in how parenting affects a child's position when the parent moves.

Components — the mechanism that gives a game object its actual behavior and appearance; a game object is meaningless in isolation from the components attached to it.
Composition vs Inheritance — the game object model is a direct, engine-level application of favoring composition: capability comes from assembling parts, not from a rigid class hierarchy.
Scenes — a game object exists within a scene, which is the container that holds and organizes every game object currently active in a level.

Game Objects

Game Objects

Summary

Why This Matters

Mental Model

Core Explanation

Syntax / Theory

Practical Example

Common Mistakes

Game Development Example

Best Practices

Exercises

Further Reading

Related Concepts