Make an original theme park sim with two rides, a path fork and a few arriving parties. In the fictional Alder Pier, Kite Coaster fills first while Lantern Carousel has spare room. A sign at the fork can send flexible parties to the carousel before they enter either queue.
Hold ride capacity constant and replay the same arrivals. You can then see exactly which parties changed routes, which boarded and which were still waiting when the simulation stopped.
Start with one fork and two rides

Atari's official page for RollerCoaster Tycoon Classic credits Chris Sawyer and describes building rides and running a park for its guests. Use that broad management premise to frame a specific question: can a different arrival route make better use of the rides you already have?
Start Kite and Lantern with empty queues. Each ride boards up to two parties each tick. It boards one if only one party is waiting and none if its queue is empty. Each party uses one slot in this fixture. The numbers describe a game rule, not a real ride's operations.
Separate arrival routing from boarding
Eight parties arrive at the fork over three ticks. A, E and F are flexible. Every other party wants Kite. With the sign off, send all arrivals to Kite. With the sign on, send only flexible arrivals to Lantern. Once a party joins a queue, it stays there until boarding.
| Tick | Arrivals in order | Flexible parties |
|---|---|---|
| 1 | A, B, C, D | A |
| 2 | E, F, G | E, F |
| 3 | H | None |

Process all arrivals before boarding. Append each party to its assigned queue, then board the oldest parties first. Record who boarded and who is still waiting. Keep party IDs in the trace. Two schedules can show the same queue length while boarding different parties, which would hide a first-in, first-out error.
Read the queue after boarding
Read the table as a pair of replays from the same empty park. Waiting means the number still in line after the boarding step. The queue just before boarding is a separate reading.
| Tick | Sign off, Kite boards | Kite waiting | Sign on, Kite boards | Sign on, Lantern boards | Kite waiting |
|---|---|---|---|---|---|
| 1 | A, B | 2 | B, C | A | 1 |
| 2 | C, D | 3 | D, G | E, F | 0 |
| 3 | E, F | 2 | H | None | 0 |
Lantern has no remaining queue after any boarding step. With the sign off, six parties board and G and H remain waiting. With the sign on, five board Kite and three board Lantern, leaving no parties waiting. The arrival schedule and two slots per ride never change.

For a quick debug check, read Kite just before baseline boarding on tick two. The queue must be C, D, E, F, G. If E and F board first, new arrivals are being placed ahead of the backlog. If only two parties are recorded as waiting, find the missing party by comparing the five queued IDs with the two boarded IDs.
Give AI the complete park fixture
Begin with a single-step control and a readable queue log. This prompt supplies the data and the assertions a first build needs.
Build a fictional browser park management game called Alder Pier.
Use two initially empty FIFO queues: Kite Coaster and Lantern Carousel.
Before tick 1, choose a fixed sign setting for the whole run. Default is off.
Arrivals in order: tick 1 A B C D; tick 2 E F G; tick 3 H.
A, E and F are flexible. Everyone else wants Kite Coaster.
At arrival, route all parties to Kite if the sign is off.
If on, route A, E and F to Lantern and everyone else to Kite.
Append arrivals in order. Do not move any party after they join a queue.
Each tick, after all arrivals, board up to two from each queue, oldest first.
Record the boarded IDs and IDs still waiting after every boarding step.
Sign off: Kite boards AB, CD, EF. Kite post-boarding counts are 2, 3, 2.
Sign on: Kite boards BC, DG, H. Lantern boards A, EF, nobody.
Sign on: Kite post-boarding counts are 1, 0, 0. Lantern always finishes empty.
Stop after three ticks. Reset clears queues and logs and turns the sign off.
Include a step button, sign status, keyboard controls and original park art.
Step through both settings from reset. Check that the same eight parties arrive, boarded parties never reappear, and every party is either boarded or waiting at tick three. Read the first-build guide for the prompt-led workflow.
Build the Alder Pier queue in SEELE AI Game Maker and verify both logs before adding more paths or changing ride throughput.
Frequently asked questions
How many rides should my first park sim have?
Start with two rides and one path fork. Give one ride a backlog while the other has spare room, then change a single routing rule. Two rides let you compare demand and available capacity without needing a full map or visitor economy.
What does waiting mean in the queue trace?
In this fixture it means the parties remaining after the ride boards. Count the line immediately before boarding separately. Use the same measurement point in both runs so the comparison always includes the same arrival and boarding steps. Label the two readings clearly if you display both.
How can I test that the queue boards in arrival order?
Write down party IDs and compare the pending queue with the boarded list at each tick. On baseline tick two, C and D should board ahead of the new arrivals E, F and G. Checking IDs catches order bugs that total counts can miss.
Why keep capacity the same when testing the sign?
Keeping capacity fixed isolates the effect of routing. Both replays start with the same arrivals and two slots per ride. If you later test extra seats, start a separate run and change only the boarding limit so each difference has a clear cause.


