Luau tables: route lists and lookup by key

Separate two questions #

Our fictional walk has a start, a bridge end and a lookout. Which station comes next is one question; which description belongs to a selected station is another. Order and station details are related, but keeping them as explicitly different data sets makes their roles clearer.

Use routeStart, bridgeEnd and lookout as the ordered identifiers, and use the same keys in a details table. These names are original exercise data rather than existing game objects. Rearranging the sequence then need not turn a position number into a station's permanent identity.

Read the first list element #

Curly braces construct a table. The first example places three values consecutively to form a simple array. route[1] reads the first position and route[3] the third. Luau indexes this kind of list from one, so zero does not designate its first element.

Before running the short example, predict the output lines routeStart and lookout. Compare values rather than merely checking that a message appeared. This is an in-memory data exercise: it moves no character, creates no Workspace object and does not preserve a route between sessions.

Open full-size image ↗

local route = {"routeStart", "bridgeEnd", "lookout"}
print(route[1])
print(route[3])

Use a key for details #

The second example puts named records in stations. stations["bridgeEnd"] selects a record by its exact key rather than the entry's position in the written table. Inside the record, title is an instructional output label while enabled is a separate boolean flag.

The connection uses a matching identifier: read an ID from the list, then look up stations[ID]. Keep the ordinary array consecutive. Do not use dictionary traversal order as the route; the separate list determines the sequence, and the key identifies a particular record.

Distinguish absence from false #

A missing key has value nil. enabled=false instead stores an existing boolean value. Our station can be found even though the flag is off. Missing record and present-but-disabled record should produce different observations.

Check that the record exists before reading its fields. For an unknown identifier, keep a clear message containing the ID and stop the relevant exercise step. Substituting the first station would make a data mistake resemble a successful lookup and conceal the actual mismatch.

Open full-size image ↗

local stations = {
    routeStart = {title = "Start", enabled = true},
    bridgeEnd = {title = "Bridge", enabled = false},
    lookout = {title = "Lookout", enabled = true},
}
local station = stations["bridgeEnd"]
if station == nil then
    print("Missing station")
else
    print(station.title, station.enabled)
end

Insert an intermediate station #

In the third example, table.insert places restSpot at position two. The previous second station bridgeEnd moves to third, and lookout moves further along. Compare the sequence before and after. This changes position rather than renaming bridgeEnd.

If a future interface stores only the number two, insertion can make it refer to another station. Pass the stable ID when naming a station and an index when describing position. A table does not decide how your project should store its selected route step.

Remove an element and reread positions #

table.remove deletes an element at a selected position and shifts following elements back. Our example removes temporary restSpot from position two, restoring the initial sequence. Check that bridgeEnd is second and lookout third again. Reading an old position without reconsidering it can yield a different value.

Keep this teaching array consecutive. Do not replace removal with arbitrary nil in the middle and treat the sparse result's length as an ordinary route length. Define real insertion and removal rules before connecting positions to player progress.

local route = {"routeStart", "bridgeEnd", "lookout"}
table.insert(route, 2, "restSpot")
print(route[2])
print(route[3])
table.remove(route, 2)
print(route[2])
print(route[3])

Separate data and gameplay action #

The route list describes order; the station record describes data. Moving a character, showing a hint or granting a reward needs separate logic consuming those values. A successful print does not establish correct object interaction, networking or persistence.

Keep exercise identifiers identical across translations and localize player-facing labels separately. Translating a technical key in only one set breaks the connection. Review IDs against records rather than matching attractive display names on screen.

Run a small data check #

Check the first element, a known key, an unknown ID, a false flag and positions after insertion. Independent expected-value checks accompany the article's examples. They concern ordinary Luau tables and are not a run of an existing Roblox Studio game.

Include a negative case where a route ID is absent from stations. Detecting the mismatch is the useful outcome, rather than silently continuing with a different station. Record the problematic ID and which set needs correction instead of changing the whole route at once.

Remember table references #

Assigning a table to another variable does not create an independent copy. A name such as backupRoute does not preserve earlier contents if it refers to the same table. For planned experiments, distinguish a reference and an actually prepared separate copy.

These examples start with their own small data sets. They do not provide a universal nested-configuration copying method. For another task, identify nested data and what should remain shared; a shallow copy should not automatically be considered independent at every level.

Hand over the structure #

The final note contains ordered IDs, station details, field meanings, missing-key behavior and expected position changes. Explain which examples were checked separately and which parts are not connected to game objects. This gives another developer a concrete data agreement rather than a promise of a completed mechanic.

The official link explains Luau tables; the walk, keys and checks are original teaching material. Existing games were not changed. Route processing, interaction and progress can be implemented later as separate work while preserving the distinction between data and actions actually performed.