Testare una decisione del controller prima di aggiungere una policy di routing
Inizia con JavaScript nelle funzioni init e update del gioco e premi Start per osservare la simulazione. Utilizza il riferimento API in-game per il comportamento esatto di evento idle e goToFloor. Un primo esercizio è capire quando un ascensore inattivo riceve il suo prossimo compito. Osserva l'evento e il movimento risultante prima di aggiungere diverse condizioni, in modo da poter spiegare quale parte del controller ha emesso una richiesta.
Quindi controlla le destinazioni dei passeggeri. Il solo movimento non significa che i passeggeri siano serviti. Leggi l'evento floor_button_pressed nel riferimento e confronta le richieste con il percorso che osservi. Se più ascensori ripetono lo stesso percorso, alcune code potrebbero ancora attendere. Costruisci partendo da un piccolo controller che comprendi invece di copiare una policy complessa e dare per scontato che soddisfi l'obiettivo del passeggero o del tempo di attesa della sfida attuale.
Confronta una modifica al codice con l'obiettivo effettivo della sfida
Prima di avviare la simulazione, leggi le condizioni per superare la sfida e scegli un comportamento da controllare, come tempi di inattività, fermate ripetute o passeggeri in attesa su un piano particolare. Cambia una decisione e avvia di nuovo la simulazione. Un movimento più frequente dell’ascensore non garantisce che il controller superi la sfida. Confronta le code visibili e il risultato visualizzato con l'obiettivo anziché utilizzare il movimento come unico segno di successo.
Quando si modifica direttamente destinationQueue, seguire il requisito del riferimento per chiamare checkDestinationQueue in modo che la coda modificata abbia effetto; le normali richieste goToFloor gestiscono già le destinazioni in coda. Mantieni questi approcci distinti durante il debug. Questo centro descrive una simulazione di programmazione tramite browser, non un software per un vero ascensore o un sistema di sicurezza di produzione. Non garantisce che un controller supererà ogni sfida. Utilizza l'esatta documentazione API all'interno del gioco, quindi registra quale evento e modifica del routing hanno migliorato il test specifico che hai appena eseguito.
Per un resoconto concreto, osserva un piano con una coda mentre un ascensore diventa inattivo. Identificare quale handler emette la successiva richiesta goToFloor e se tale richiesta serve i passeggeri in attesa o invia la cabina altrove. Modifica quella scelta di percorso, quindi confronta il risultato della sfida. Se concorrono più referenti, semplificare il titolare del trattamento finché non si riesce a spiegare la sequenza delle richieste. Utilizza il riferimento API per gli esatti eventi supportati. Osservare una coda e una decisione alla volta fornisce la prova di una revisione senza affermare che si tratti di un controllore ottimale universale.
Suggerimenti e strategie per Elevator Saga
Seleziona un consiglio da provare nella prossima partita. Questo elenco non modifica il gioco né salva i progressi.
Domande e risposte sul modello Elevator Saga
In quale lingua scrivo?
Il controller utilizza JavaScript, con le funzioni init e update nell'editor di gioco.
Questo sistema fa funzionare un vero ascensore?
No. Si tratta di una simulazione di programmazione interamente all'interno del gioco per browser.
Posso usarlo per esercitarmi a programmare?
Sì, in particolare il controllo basato sugli eventi e la verifica di piccole modifiche. Il gioco è basato sul progetto Elevator Saga di magwo, rilasciato con licenza MIT; non si tratta di un corso di certificazione.
Perché i passeggeri aspettano anche se l’ascensore si muove?
Ripetere un percorso fisso non serve automaticamente tutti i piani richiesti. Gestisci floor_button_pressed e usa goToFloor per le destinazioni dei passeggeri. Confronta le code con l’obiettivo prima di aggiungere fermate. Se modifichi destinationQueue direttamente, chiama checkDestinationQueue per applicare il cambiamento; goToFloor gestisce già le richieste normali.