Test one controller decision before adding a routing policy
Start with JavaScript in the game's init and update functions and press Start to observe the simulation. Use the in-game API reference for the exact idle event and goToFloor behavior. A first exercise is to understand when an idle elevator receives its next task. Watch that event and resulting movement before adding several conditions, so you can explain which part of the controller issued a request.
Then inspect passenger destinations. Movement alone does not mean passengers are being served. Read the floor_button_pressed event in the reference and compare requests with the route you observe. If several elevators repeat the same route, some queues may still wait. Build from a small controller you understand instead of copying a complex policy and assuming it satisfies the current challenge's passenger or waiting-time objective.
Compare a code change with the challenge's actual goal
Before a run, read the pass condition and choose one behavior to inspect, such as idle time, repeated stops or passengers waiting on a particular floor. Change one decision and run again. A car that moves more often is not necessarily a controller that passes the challenge. Compare the visible queues and displayed result with the objective rather than using movement as the only sign of success.
When editing destinationQueue directly, follow the reference's requirement to call checkDestinationQueue so the revised queue takes effect; normal goToFloor requests already handle queued destinations. Keep those approaches distinct while debugging. This center describes a browser programming simulation, not software for a real elevator or a production safety system. It does not guarantee one controller will pass every challenge. Use the exact API documentation inside the game, then record which event and routing change improved the particular test you just ran.
For a concrete review, watch a floor with a queue while an elevator becomes idle. Identify which handler issues the next goToFloor request and whether that request serves the waiting passengers or sends the car elsewhere. Change that one routing choice, then compare the challenge result. If several handlers compete, simplify the controller until you can explain the sequence of requests. Use the API reference for the exact supported events. Observing one queue and one decision at a time gives you evidence for a revision without claiming that it is a universal optimal controller.
Elevator Saga tips and strategy
Tick a tip to focus on in your next run. This checklist does not change your game or save progress.
Elevator Saga questions and answers
Which language do I write?
The controller uses JavaScript, with init and update functions in the game’s editor.
Does this operate a real elevator?
No. It is a programming simulation entirely inside the browser game.
Can I use it to practice coding?
Yes, particularly event-driven control and testing small changes. The game is based on magwo’s MIT-licensed Elevator Saga project; it is not a certification course.
Why does a moving elevator leave passengers waiting?
A repeating route does not automatically serve every requested floor. Handle floor_button_pressed to send passengers to their destinations with goToFloor. Compare waiting queues with the challenge’s goal before adding more stops. If you edit destinationQueue directly, call checkDestinationQueue so the changed queue takes effect; goToFloor already handles normal queued requests.
Controls and full game instructions
Controls and full game instructions
Play Elevator Saga