Data Structures — GDScript

Skill codes on this page

Definition. A data structure is a method of organising data to allow particular operations to be performed on it efficiently.

C635 — Arrays

Definition. A list of elements indexed by position. In most programming languages, the first element has index zero.

# C635 — Array[float]: fares need decimal places
var fares: Array[float] = [5.30, 8.00, 11.20]

func show_fare() -> void:
    $ResultLabel.text = "Zone 1: $" + str(fares[0])

Typed (Array[float]) earns it. Bare var fares = [] does not — no type for the marker to see.

In tile-matching-game (board.gd) — a typed array of your own class:

# tile-matching-game — board.gd
var found: Array[Card] = []   # C635 — Array[Card]: only cards can get in
for child in get_children():
    if child is Card:
        found.append(child)

Two-dimensional array — a grid organised into rows and columns, accessed with two indices:

# C635 — 2D array: fare by [zone][day type], 0 = weekday, 1 = weekend
var fare_grid: Array = [
    [5.30, 3.60],
    [8.00, 5.40],
]

var weekend_zone2: float = fare_grid[1][1]

C636 — Records

Definitions.

• Record: a complete set of fields relating to an entity, such as a person.

• Field: a single data item in a record (e.g. FamilyName).

GDScript has no record keyword — a Dictionary is the everyday record, one key per field:

# C636 — record: one journey, fields of different types
var journey: Dictionary = {
    "date": "2026-08-11",
    "zone": 2,
    "fare": 8.00,
    "concession": false,
}

print(journey["fare"])   # access one field

In tile-matching-game (deck.gd) — each CSV row becomes a record, and the deck is an array of them:

# tile-matching-game — deck.gd
cards.append({
    "pair": pair,   # C636 — fields: which card matches which
    "text": row[1].strip_edges(),
    "image": row[2].strip_edges() if row.size() > 2 else "",
})

An array of records is a table — the shape most SAT data layers need:

# C635 + C636 — a table: array of journey records
var journeys: Array[Dictionary] = []

func add_journey(zone: int, fare: float) -> void:
    journeys.append({"zone": zone, "fare": fare})

A custom class is the stronger record — typed fields the editor can check — and doubles as level 9–10 evidence (see OOP Concepts).

In club-ladder (team.gd) — the class-as-record, real: its own doc comment says "A Team is plain data."

# club-ladder — team.gd
class_name Team
extends RefCounted

var team_name := ""   # C636 — the fields of the record
var wins := 0
var draws := 0
var losses := 0

An Array[Team] (season.gd) is then the table — the class version of the array-of-dictionaries above.

C638 — Why these types and structures

Level 5–6 asks you to identify the reason in internal documentation — one line on each structure:

# C638 — Array[Dictionary]: journeys arrive one at a time in order (array),
# and each journey has mixed-type fields (record)
var journeys: Array[Dictionary] = []

The "why" comes from how the structure behaves — see the input/storage/output table in Data Type Characteristics.

Model documentation in the wild: the header comment of tile-matching-game/deck.gd identifies the whole design — one CSV row per card face, rows sharing a pair value match — before any code runs. That is C638 done as a file-level comment.

Check Your Understanding

1. Why does var scores = [] fail C635?

2. Name two ways to build a record in GDScript.

3. What everyday shape is an "array of records"?