Luau numeric for: a finite batch of three stations

Define the batch before writing the loop #

Imagine a workshop preparing three numbered stations for a shift. The practice task uses numbers 1, 2, and 3, with no Roblox objects, connected players, or rewards. Write the expected result first: each number appears exactly once and the completed count is three. An explicit expectation makes a boundary mistake visible before the example grows into complicated gameplay code.

A station number here is a counter value, not an object name or a player identifier. A real project must separately connect that number to a verified object. This exercise only demonstrates repeated execution. Successful output does not prove that a scene is configured, player progress was saved, or a game objective was completed.

Run three operations #

The first standalone example below runs numeric for from 1 through 3 and increments processed after each operation. Expect Station 1, Station 2, Station 3, followed by Processed 3. print separates its arguments in the output; compare the values and their order rather than treating whitespace as gameplay data. Run this example alone so earlier messages do not obscure the result.

Read all three station numbers as well as the final count. A total of three would also be possible in faulty code that repeats one operation and misses another. processed is a simple check of the number of completed actions. The station counter belongs to the loop body; do not rely on that local counter after end without deliberately storing a separate result.

Open full-size image ↗

local processed = 0
for station = 1, 3 do
    print("Station", station)
    processed += 1
end
print("Processed", processed)

Check both boundaries #

For this batch, both 1 and 3 are included, producing three iterations rather than two. A common mistake is to subtract the starting number from the ending number and forget the initial position. For consecutive integer numbers with a step of one and a suitable direction, the count is last minus first plus one. Confirm the rule using a small batch before expanding it.

Two boundary cases are especially useful. Running from 2 to 2 with a positive step performs one operation. Running from 4 to 3 with a positive step performs none. Zero can be the correct result, rather than broken printing. If a nonempty batch was intended, inspect the input bounds and direction first; do not repair the symptom by arbitrarily extending the ending number.

Visit stations in reverse #

The second independent example starts at 3, ends at 1, and explicitly uses step -1. Its expected order is 3, 2, 1, followed by Processed 3. Think of this as a practice closing procedure that examines station numbers in reverse. With the ordinary positive step, a range from 3 to 1 would instead be empty.

Compare the two outputs side by side. Their totals match, but their order differs, which is part of the requirement. Express the direction in the loop header instead of manually changing the counter inside the body. Keep this beginner exercise to a small, understandable, nonzero integer step. Fractional boundaries, enormous ranges, and external inputs need additional validation beyond this example.

Open full-size image ↗

local processed = 0
for station = 3, 1, -1 do
    print("Station", station)
    processed += 1
end
print("Processed", processed)

Separate continue and break #

To skip station 2 temporarily, a continue inside the matching condition moves execution to the next iteration. For the range 1–3, the completed station numbers become 1 and 3. Increment processed after the skipping condition if it measures finished actions. Incrementing before continue measures visited numbers instead, which is a different quantity even if the variable has the same name.

To stop the entire batch, break exits the nearest loop. Stopping before processing station 2 completes only the action for station 1; station 3 is never reached. The nearest-loop rule matters when loops are nested. Do not describe break as stopping every script or shutting down a server: that claim would hide the actual scope of the control statement.

Record expected results #

Before extending the exercise, write four cases: forward 1–3 produces three actions; equal bounds 2–2 produce one; a positive step with 4–3 produces zero; reverse 3–1 with step -1 produces three. For each case record the numbers in execution order too. This distinguishes a correct sequence from an accidental match in the final counter.

Then check skipping and stopping as separate scenarios on the same short batch. Do not combine them into a single ambiguous condition. Predict each sequence before running the code, then compare the output. When a result differs, locate the first unexpected operation; it normally gives a more useful clue than repeatedly reading only the last total.

Finite work still has a cost #

A finite loop can still do too much expensive work in one run. Three printed numbers illustrate counting; creating a million objects or sending repeated network requests is a different workload. Before adding a real operation, define a permitted batch size and consider the cost of one operation. Reject inappropriate external bounds rather than accepting an unchecked player-supplied count.

Numeric for does not provide a timer: iterations do not represent seconds. This guide does not implement endless polling, periodic rewards, or network synchronization. A real system needs separate decisions about scheduling, execution location, and operation failures. Passing this small arithmetic exercise confirms loop behavior, not readiness of an entire game system for publication.

Hand off a reproducible check #

Include the bounds, step, expected station sequence, and observed action count in a handoff note. Attach both independent examples and the results of the four boundary cases. For continue, state whether the counter measures visits or completed operations. For break, describe the stopping condition and identify which part of the batch remains unprocessed.

The examples in this guide were executed in a standalone Luau interpreter; they were not run against real stations in Roblox Studio. Another developer can reuse the checks as a starting point but must verify their own objects and game rules. Keep expectations beside the code so changing the station count exposes a boundary error before an update is published.