So You Want to Build a Game?

Game development sits at the intersection of creative design, software engineering, and real-time performance optimisation. Whether you're an experienced software developer looking to break into games or simply curious about how your favourite games are made, understanding the fundamentals of game development — from early design decisions through to performance consideration — is essential.

This article walks through the key concepts you need to know to get started: the early decisions that shape your entire project, why game engines exist and how they work, how to write game logic in Unity, essential design patterns that keep your code manageable, and the performance traps that trip up even experienced developers.

1 | Decisions to Make Early On

Before writing code, there are several foundational decisions you should think about. These choices influence the systems you'll build, the tools you'll use, and the overall complexity of your project. The further along you are in development, the harder — and more expensive — it becomes to change them.

Starting with an Idea: A Pirate Adventure Game
Let's use a concrete example to discuss these decisions. Imagine you want to build a pirate game. You want to sail the seas, shoot cannons, loot enemy ships, stash treasure on your own island, trade it for gold, and evade getting caught. You have an idea — now let’s look at some of the questions you will need to answer.

Genre
The genre defines the core gameplay systems you'll need to build. For instance, if we make our pirate game an adventure role playing game (RPG) we will need to build an exploration system, a levelling system, a combat system, and a narrative or quest system. If you were to choose an action platformer or real-time strategy game instead, it would change which systems need to be built. Committing to a genre early means you can design your systems consistently rather than adapting them to work as afterthoughts.

Dimensionality: 2D or 3D
Whether you work in 2D or 3D or a hybrid of both, affects a multitude of systems, and the overall complexity your game. If we choose 3D a top-down perspective for our pirate game — it means we must think about ship movement in 3D space, projectile movement in 3D, and how our player will interact with the game in 3D.

Player Count
Single-player and multiplayer games require fundamentally different architectures. Multiplayer requires synchronisation between server/clients, latency management, and a different approach to state management. If you begin building a single-player game and later decide to add multiplayer, you will likely need to rework large portions of your systems. It is best to pick one approach and commit to it — or plan for both from the start.

Target Platform
PC, console, mobile, and web each have different performance constraints, inputs, distribution requirements and costs. For our pirate game, targeting Steam on PC will keep things simple. If we had to expand to mobile later, it would require rethinking controls, optimizing performance, and changing UI layouts. Platform choice also heavily influences which game engine you'll choose since some engines support different platforms.

2 | Why Use a Game Engine?

Game engines simplify game development by providing the essential systems and tooling for you. Unity, for instance, handles rendering (2D and 3D, shaders, lighting, post-processing), physics simulation, scene and entity management, input management, audio management, and asset management. If you decided to build a game from scratch with your own engine, you'd need to implement your own systems – which is no trivial task. Rather use an engine and focus on what makes your game unique — the mechanics, the feel, the content, and the systems that create a compelling player experience.

For our pirate game, Unity is a strong choice. It supports 2D and 3D workflows, handles single player well, has excellent PC platform support, and allows you to script and build custom game logic in C# for our systems.

💡 To give an idea of the amount of effort it takes to build your own engine, The Witness – Jonathan Blow, took roughly seven years to develop using his own custom engine he built with a team. Large game studios like EA have dedicated teams that solely work on and maintain their proprietary engines like Frostbite. There are situations where writing your own engine makes sense — for example, if your game needs to be deterministic, or if your game's systems are simple enough that a full engine is more overhead than it's worth. But these are generally the exceptions in the indie space, not the rule.

Figure 1: Game engine architecture — showing how the game layer, engine layer and system layer interact

The game layer consists of your assets, scenes, and configuration (data and levels), and your game logic (your code). The engine layer sits beneath that and contains four key systems: the Input system, the Physics Engine, the Rendering Pipeline, and — tying everything together — the Game Loop.

The overall flow: input arrives → the game loop updates game logic → the physics engine simulates the world → the renderer draws the scene → the result is pushed to the screen → and the cycle repeats. Every frame, every second, for the entire duration your game is running.

5 | How Does Unity Let You Build Games?

Unity provides an extensive set of tools and systems that help you build games. Understanding the core building blocks — GameObjects, Components, Prefabs, and Scenes — is essential for working effectively in the engine.

GameObjects
A GameObject is the fundamental entity in Unity. Everything in your game world — the player pirate ship, an enemy navy frigate, a cannonball, a UI panel — is a GameObject. On its own, a GameObject has a position, rotation, and scale (via its Transform component). It acts as a container to uniquely identity an entity in the game and track it’s related components.

Components
Components are what give GameObjects their behaviour and appearance. You add components to a GameObject to extend its functionality. A MeshRenderer makes a mesh visible in the game. A Rigidbody gives it physics. A BoxCollider allows collision detection. A custom script adds your own game logic. Components can be added and removed before and during runtime, giving you flexibility.

Prefabs
A Prefab is a reusable blueprint of a GameObject, including all its components and their configurations. You define a Prefab once — say, a Player Ship with a Transform, MeshRenderer, Rigidbody, BoxCollider, and a PlayerController script — and then instantiate it as many times as you need. All instances share the same template, so changes to the Prefab update all instances.

Scenes
A Scene groups a hierarchy of GameObjects and their components. You can think of it as a level your game. Unity lets you save and load different scenes, making it easy to separate your main menu from your gameplay from your game over screen.

Packages and the Asset Store
Unity's package ecosystem and Asset Store let you bring in pre-built tools, systems, and assets created by other developers. Whether you need a pathfinding system, a UI framework, or a set of 3D ship models, there's likely something available. This dramatically reduces the time needed to build common functionality from scratch.

6 | Writing Game Logic

Unity provides three main options for writing your game logic. Choosing the right one for each task keeps your codebase clean and consistent.

MonoBehaviour
MonoBehaviour is the base class for any script that attaches to a GameObject as a component. Use it when you need to hook into Unity's lifecycle methods — Awake, Start, Update, etc — or when you need access to Unity's APIs for input, physics, coroutines, or the editor.

Plain C# Classes
Not everything needs to live on a GameObject. Pure data structures (like a Weapon class holding name, damage, and fire rate), game logic that doesn't depend on Unity's API, utility classes, and manager objects are all better expressed as plain C# classes. They're easier to test and don't carry the overhead of Unity's component system.

Scriptable Objects
ScriptableObjects are Unity assets that live in your project rather than in a scene. They're ideal for shared data — weapon configurations, enemy stats, level parameters — that needs to be accessible across multiple scenes and systems. Designers can edit them directly in the Unity Inspector without modifying code.

Coroutines, Events, and Async/Await
Beyond class types, Unity allows you to use three key tools for managing timing and communication between systems:

Coroutines are Unity-native generators that can pause execution and resume after a fixed time or after a specific event. They're ideal for sequences over time — spawning waves of enemies with delays, driving animations, or sequencing dialogue. Avoid using them for heavy computation or network I/O.

Events (using C#'s Action or UnityEvent) decouple systems from each other. Rather than having your Health UI reach directly into the Player object to read its health, the Player broadcasts an OnHealthChanged event, and the UI subscribes to it. This makes your systems independent and much easier to maintain. Avoid long event chains or circular dependencies.

Async/Await is the right tool for I/O-bound work that happens outside the game loop — network requests, file I/O, web API calls, and database queries. Avoid using it for game loop logic or per-frame updates.

7 | Essential Design Patterns

As your game grows in complexity, unstructured code becomes increasingly difficult to reason about and extend. Design patterns provide proven, reusable solutions to common structural problems. Three patterns are particularly valuable in game development.

Finite State Machine (FSM)
Game logic often involves entities that can be in one of several distinct states — a character might be idle, walking, jumping, attacking, or dead — and transitioning between them based on conditions. Without structure, managing these transitions with a tangle of if/else statements quickly becomes unmanageable.

A Finite State Machine models this explicitly: you define a set of states, the valid transitions between them, and the conditions that trigger each transition. The result is logic that is easy to understand at a glance, easy to extend with new states, and far less prone to unintended side effects.

Object Pooling
Every time you create (Instantiate) or destroy a GameObject in Unity, memory is allocated or deallocated on the heap. When this happens frequently — as it does with projectiles, particle effects, or enemies — the garbage collector must periodically clean up unused memory, causing visible frame.

Object Pooling solves this by maintaining a collection of pre-created objects. When you need a new cannonball, you take one from the pool and reactivate it. When it hits something, you deactivate it and return it to the pool. No allocation, no garbage, no hitches. The pool manages a fixed size of objects, resetting their state rather than destroying and recreating them.

Observer Pattern
Tight coupling — where one system directly references another — is the enemy of maintainable game code. If your Health UI class holds a direct reference to your Player class to read its health value, the two are permanently linked. Change the Player class and you risk breaking the Health UI. Delete the Player and the UI throws null reference exceptions.

The Observer pattern solves this by inverting the relationship. The Player class broadcasts an event (OnHealthChanged) when its health changes. Any number of listeners — the UI, an audio system, a screen shake effect — can subscribe to that event independently. None of them need a reference to the Player; they just need to know what the event signature looks like.

Command Pattern
In many games, different player inputs or game actions share a common structure: they need to be executed and sometimes undone. A switch statement or a chain of if/else blocks that maps input events to action logic becomes difficult to read and extend as the number of actions grows.

The Command pattern encapsulates each action as an object that implements a common interface (Execute and optionally Undo). The input system or game logic simply calls Execute() on whichever command is current, without needing to know what that command does. This makes it straightforward to add new actions, record player input for replay, or implement undo functionality in a turn-based game.

8 | Performance: What to Avoid

Ideal the game loop should run 60 or more times per second. Any inefficiency that happens every frame compounds rapidly. These are some common performance traps and how to avoid them.

Searching for Components in the Game Loop
Searching for a component or entity inside the game loop means the engine needs to traverse through your scene hierarchy to find it. This is an expensive operation. Instead, cache your component references as the game starts or during an expected loading scene.

Allocating Temporary Collections in the Game Loop
Creating a new List or array inside the game loop allocates heap memory on every frame, which triggers garbage collection overhead. Cache your collections on start, clear and reuse them rather than recreating them every time. Prefer standard for loops over other enumerators that allocate memory.

Frequent Instantiate and Destroy Calls
As discussed in the Object Pooling section, creating and destroying GameObjects at high frequency generates garbage collection pressure and frame spikes. Use object pools and disable/enable objects instead.

Physics Calls Every Frame
Physics operations — raycasts, overlap checks, and similar calls — are computationally expensive. Avoid calling them every frame unnecessarily. Use physics layers to restrict queries to relevant objects, batch calls where possible, and prefer non-allocating variants to avoid heap allocations.

Unnecessary Math Operations
Small optimisations in math can add up when applied across thousands of objects per frame. For example, comparing the distances between two vectors typically involves computing a square root (Vector3.magnitude). Squaring both sides of the comparison and using Vector3.sqrMagnitude instead is faster because it skips the expensive square root operation. These micro-optimisations matter when you are trying to save milliseconds.

Boxing and Unboxing Value Types
Value types (structs, ints, floats, bools) are stored on the stack. When they are assigned to a reference type variable or passed to a method that expects an object, they get 'boxed' — copied onto the heap, which creates garbage. Prefer generic collections, avoid passing value types as object parameters, and use structs for small, frequently created data structures.

The genre, visual space, player count, and release platform lock you into specific systems early on. Make these decisions deliberately, because changing them later is costly.
Use a proven game engine. Choose one that fits your needs and focus on what makes your game compelling. Writing your own engine is a valid challenge, but it's a multi-year investment.
A game engine is composed of interlocking systems — input, physics, rendering, and the game loop — that work together to produce each frame. Understanding the game loop is foundational to everything else.
In Unity, work with the engine's built-in abstractions (GameObjects, Components, Prefabs, Scenes) and choose the right tool for each job: MonoBehaviours for components, plain C# for logic, ScriptableObjects for data, Coroutines for timed sequences, Events for decoupled communication, and Async/Await for I/O work.
Use design patterns to keep your code clean and extensible. Finite State Machines tame complex conditional logic. Object Pooling eliminates garbage collection hitches. The Observer pattern decouples your systems. The Command pattern makes actions generic and reusable.
Always keep performance in mind. Avoid unnecessary memory allocation and computation inside the game loop. Cache references, pool objects, batch physics calls, and profile early.

Now go build something amazing! Callum Taylor

You may also be interested in

Are you stagnating?

Entelect Wins Big at 2025 SAGEA Awards

Current Available Positions

Find Out More

Download Our Lore

Apply Now

Available Positions

Ask A Question

Chat with us

Customer?

Corporate website

Stay Connected