Many Units, One Array

One box that moves is a demo. An RTS is many things that move, and the moment it starts to feel like the genre is the moment you drag a rectangle over a group of units and they all light up.

That is what you are building here. It also forces the first question Odin makes you answer that Go and Rust answered for you: who owns this memory, and when does it go away?

The program

package main

import rl "vendor:raylib"

WINDOW_WIDTH  :: 960
WINDOW_HEIGHT :: 540
UNIT_RADIUS   :: 12

Unit :: struct {
	pos:      rl.Vector2,
	selected: bool,
}

selection_rect :: proc(a, b: rl.Vector2) -> rl.Rectangle {
	return {
		x      = min(a.x, b.x),
		y      = min(a.y, b.y),
		width  = abs(a.x - b.x),
		height = abs(a.y - b.y),
	}
}

main :: proc() {
	rl.SetConfigFlags({.VSYNC_HINT})
	rl.InitWindow(WINDOW_WIDTH, WINDOW_HEIGHT, "Selection")
	defer rl.CloseWindow()

	units: [dynamic]Unit
	defer delete(units)

	for row in 0 ..< 3 {
		for col in 0 ..< 6 {
			append(&units, Unit{pos = {200 + f32(col) * 60, 160 + f32(row) * 70}})
		}
	}

	drag_start: rl.Vector2
	dragging := false

	for !rl.WindowShouldClose() {
		mouse := rl.GetMousePosition()

		if rl.IsMouseButtonPressed(.LEFT) {
			drag_start = mouse
			dragging = true
		}

		box := selection_rect(drag_start, mouse)

		if rl.IsMouseButtonReleased(.LEFT) {
			for &unit in units {
				unit.selected = rl.CheckCollisionCircleRec(unit.pos, UNIT_RADIUS, box)
			}
			dragging = false
		}

		rl.BeginDrawing()
		defer rl.EndDrawing()

		rl.ClearBackground({34, 36, 40, 255})

		for unit in units {
			rl.DrawCircleV(unit.pos, UNIT_RADIUS, rl.SKYBLUE)
			if unit.selected {
				rl.DrawCircleLinesV(unit.pos, UNIT_RADIUS + 4, rl.LIME)
			}
		}

		if dragging {
			rl.DrawRectangleRec(box, rl.Fade(rl.LIME, 0.15))
			rl.DrawRectangleLinesEx(box, 1, rl.LIME)
		}
	}
}

odin run .

[dynamic]Unit — a growable array you own

units: [dynamic]Unit
defer delete(units)

append(&units, Unit{pos = {200, 160}})

Three things are happening, and each has a Go or Rust equivalent worth naming so you can stop translating and start reading.

The third row is the one that matters. Odin has no garbage collector and no borrow checker. Nothing frees units for you and nothing tracks who else is holding it. The memory is yours until you call delete.

Odin’s answer to that is not a type-system feature, it is a habit: write the delete on the line after the thing is created.

units: [dynamic]Unit
defer delete(units)         // written now, runs when main returns

defer puts the release next to the acquire, where you can see both at once. It is weaker than Rust’s guarantee — you can still forget — but it is visible, and a reviewer scanning the file can check it without leaving the screen.

for &unit in units — iterating by pointer

Look closely at the two loops. They are different on purpose.

for &unit in units {                     // by POINTER — writes go back to the array
	unit.selected = ...
}

for unit in units {                      // by VALUE — a copy, read-only in effect
	rl.DrawCircleV(unit.pos, ...)
}

Odin iterates by value by default: for unit in units hands you a copy of each Unit. Prefix the name with & and you get a pointer instead, so writes land in the array.

The good news is that Odin does not let you get this wrong quietly. Drop the & from the update loop and the compiler stops you, by name:

Error: Cannot assign to 'unit.selected'
	for unit in units { unit.selected = ... }
	    ^~~^
	   'unit' is immutable, declare it as '&unit' to make it mutable

The loop value is immutable, not merely a copy — so the mistake is a compile error with the fix written into the message, rather than a bug you find twenty minutes later. Coming from Rust this will feel familiar: it is the same distinction as iter() versus iter_mut(), enforced at the same moment, just spelled with one character.

What Odin does not do is decide for you. The update loop needs to write, so it takes &. The draw loop only reads, so it does not. Making that call deliberately, loop by loop, is where “data-oriented” starts to mean something in practice.

Press, release, and the rectangle in between

The selection box needs three pieces of state, and it is worth seeing why:

if rl.IsMouseButtonPressed(.LEFT) {      // the ONE frame the button goes down
	drag_start = mouse
	dragging = true
}

box := selection_rect(drag_start, mouse)  // recomputed every frame while dragging

if rl.IsMouseButtonReleased(.LEFT) {      // the ONE frame it comes up
	// commit the selection
}

Pressed and Released are edges — true for exactly one frame. Down is a level — true for as long as you hold. Selection is an edge-triggered interaction with a level-triggered preview in the middle, and getting that wrong is why hand-rolled selection boxes so often feel broken.

selection_rect exists because rl.Rectangle cannot represent a negative width. Drag up-and-left and mouse - drag_start is negative on both axes, so you normalise with min and abs — both builtins in Odin, no import:

return {
	x      = min(a.x, b.x),
	y      = min(a.y, b.y),
	width  = abs(a.x - b.x),
	height = abs(a.y - b.y),
}

That bare { ... } is a composite literal with no type name in front of it. Odin knows the procedure returns rl.Rectangle, so it infers the type from context — the same inference that lets you write .LEFT instead of rl.MouseButton.LEFT.

Prove it

Change 3 is the first time you allocate every single frame. Leave the free_all out, run it for a minute, and watch the process memory climb — that is the lesson, and it is worth seeing once with your own eyes.

Previous: The Game Loop and Delta Time · Reference: Odin cheatsheet · raylib quick reference