If you’ve written a line of code in any language, you’ve touched an array. But I want you to stop thinking about it as just a list. An array is a homogenous, fixed-size, contiguous block of memory that stores elements of the same type — and in game development, that “contiguous” part is what makes it either a cheat code or a wall you run into. I’ve seen junior engineers treat arrays like dynamic backpacks; they’re not. They’re more like a row of lockers in a hallway: the lockers don’t move, they’re all the same shape, and you have to know the number before construction begins. The memory address of the first element plus an offset (index × element size) gives you instant access to any locker. That’s O(1) read and write — a speed that linked lists can only dream about.
- Homogenous: every element occupies the exact same number of bytes. In C++,
int arr[10]gives you 40 bytes of contiguous memory (assuming 4‑byte ints). Mix types? That’s a struct or a tuple, not an array. - Contiguous: no gaps, no pointers between elements. This lets the CPU’s cache line load multiple elements at once — huge for performance in tight loops.
- Fixed size: once declared, the capacity is locked. For dynamic needs, you move to dynamic arrays (e.g.,
std::vector), but under the hood those are just arrays that get re‑allocated and copied when they grow.
History: From Punch Cards to Vertex Buffers
The idea of an array predates computers. FORTRAN (1957) gave us the first language‑level array — because scientists needed to store matrices for missile trajectories. But in those days, arrays were just a way to map indices to memory cells. Fast‑forward to the 1970s: C adopted arrays with zero‑based indexing (a decision that still confuses beginners but simplifies pointer arithmetic). Then came game engines. In the early 1990s, Quake used arrays of vertex data to render 3D worlds — and performance was so critical that id Software manually unrolled loops over arrays to avoid branch penalties.
By the time Unity and Unreal Engine emerged, arrays were baked into every subsystem: transform arrays for instanced rendering, index buffers for mesh topology, and input arrays for gamepad states. Modern GPU hardware still expects data in flat arrays (structured buffers, constant buffers). So the “old” array isn’t going anywhere — it’s just wearing a different uniform.
The Pivot: From Static to Dynamic
The 2000s brought generic collections — Java’s ArrayList, C++ STL’s vector, C# List. These are not technically arrays, but they are array‑backed. The real innovation? Amortized O(1) insertion at the end. But every time you insert beyond capacity, the entire array gets copied to a new memory block. In a real‑time game, that copy can cause a frame stutter if not handled (which is why object pools with pre‑allocated arrays are still used for bullets and particles).
Core Principles: Memory Layout, Cache, and Complexity
Let’s get surgical. An array A of n elements of type T sits in memory like this:
A[0] at address base
A[1] at base + sizeof(T)
A[i] at base + i * sizeof(T)
That formula is the heart of array random access. It is constant time. But the real magic — and the reason every game engine evangelizes arrays over linked lists — is cache locality. When you iterate over an array sequentially, the CPU prefetcher loads a full cache line (usually 64 bytes) into L1 cache. That means after reading A[0], A[1] through A[15] (if sizeof(T)=4) are already hot. In a game loop processing 10,000 entities, that difference can be 100x.
- Time complexity: O(1) access, O(n) search (unless sorted — then O(log n) with binary search). Insertion/deletion at arbitrary index is O(n) because elements must be shifted.
- Space overhead: Zero overhead for the data itself. Only the array reference/pointer (e.g., 8 bytes in a 64‑bit system). But dynamic arrays waste space for future growth —
std::vectortypically allocates 1.5x or 2x capacity. - Cache miss penalty: Random access across a large array kills performance. That’s why data‑oriented design (DoD) in games like Overwatch rearranges arrays into hot/cold splits — to keep frequently accessed fields in a small, contiguous array.
Multidimensional Arrays and Jagged Arrays
Game grids (tile maps) often use 2D arrays. In C/C++, int map[10][10] is stored row‑major: all of row 0, then row 1, etc. Iterating row‑by‑row is cache‑friendly; iterating column‑by‑column is a disaster. In C# or Java, a “2D array” can be a jagged array (array of arrays), which allows non‑rectangular shapes but breaks contiguity. For particle systems, I always prefer a flat 1D array with an index formula: y * width + x. That’s one contiguous block, and you can even pass it to the GPU as a buffer resource.
Application Scenarios: Where Arrays Dominate in Games
Let me walk you through three real combat‑tested uses — this is not theory, this is what I’ve shipped.
1. Vertex and Index Buffers (Rendering)
Every mesh you see in a game is stored in one or more arrays. A vertex buffer is an array of Vertex structs (containing positions, normals, UVs — each field itself an array of floats). An index buffer is an array of uint16 or uint32 that tells the GPU how to connect vertices into triangles. Why arrays? Because the GPU expects data in contiguous memory to stream through its pipeline efficiently. Storing these as linked lists would require the GPU to chase pointers — a guaranteed frame‑rate killer.
2. Entity Component Systems (ECS)
Modern engines like Unity’s DOTS or Flecs store components in parallel arrays. Instead of one array of entity objects, you have separate arrays for Position, Velocity, Health. When a system processes only entities with Position and Velocity, it iterates over two tight arrays — no indirection, optimal cache usage. This pattern can push a simulation from 50,000 entities to over a million.
3. Input State and History
For fighting games like Street Fighter, input buffers are arrays of button states (pressed/released) per frame. The engine keeps a circular buffer (array with a head pointer) of the last 60 frames. Detecting a combo like “forward, down, down‑forward, punch” means scanning a fixed‑size array in reverse — O(60) worst case, which is trivial. Any other structure would add unnecessary complexity.
4. Sound Buffers and Streaming
Audio engines fill arrays of floating‑point samples at 44.1 kHz. A ring buffer (array with wrap‑around indices) holds the next 1024 samples. The interleaved audio format for 5.1 surround is literally an array of float where indices 0,2,4… are left channel and indices 1,3,5… are right. The DSP code uses SIMD instructions to process these arrays in chunks of 8 or 16 — again, only possible with contiguity.
A Word of Caution: When NOT to Use an Array
If you need frequent insertion or deletion in the middle (e.g., a priority queue for AI pathfinding), an array will cost you O(n) shifts. Use a binary heap (array‑backed, actually!) or a linked list. If your data elements vary wildly in size, an array of pointers to objects is not an array of objects — that’s a fragmentation nightmare. And if you’re writing a multiplayer netcode packet, a fixed‑size array is fine, but beware of bounds checking: one out‑of‑bounds write and your server crashes, or worse, opens a vulnerability.
So that’s the array. It’s boring. It’s old. It’s the foundation your entire game stack is built on. Respect the cache line, and the array will carry you to 60 fps.
