ルーティング ポリシーを追加する前に 1 つのコントローラーの決定をテストする
ゲームの init と update 関数 の JavaScript から開始し、[開始] を押してシミュレーションを観察します。 idle イベント および goToFloor の正確な動作については、ゲーム内 API リファレンスを使用してください。最初の練習は、アイドル状態のエレベータが次のタスクをいつ受け取るかを理解することです。いくつかの条件を追加する前に、そのイベントとその結果の動きを観察して、コントローラーのどの部分がリクエストを発行したかを説明できるようにします。
次に、乗客の目的地を検査します。移動するだけでは乗客にサービスが提供されるわけではありません。リファレンス内の floor_button_pressed イベントを読み取り、リクエストを観察したルートと比較します。複数のエレベーターが同じルートを繰り返す場合、一部の待ち行列が依然として発生する可能性があります。複雑なポリシーをコピーして、それが現在の課題の乗客または待ち時間の目標を満たしていると仮定するのではなく、理解している小さなコントローラーから構築します。
コードの変更をチャレンジの実際の目標と比較する
シミュレーションを開始する前にクリア条件を確認し、アイドル時間、繰り返しの停止、特定のフロアで待っている乗客など、検査する動作を 1 つ選択します。決定を 1 つ変更して、もう一度実行します。エレベーターが頻繁に動いても、コントローラーが課題を達成できるとは限りません。動きを成功の唯一の兆候として使用するのではなく、目に見えるキューと表示された結果を目標と比較します。
destinationQueue を直接編集する場合は、参照の要件に従って checkDestinationQueue を呼び出し、変更されたキューが有効になるようにしてください。通常の goToFloor リクエストはキューに入れられた宛先をすでに処理しています。デバッグ中は、これらのアプローチを区別してください。このセンターでは、実際のエレベーターや生産安全システム用のソフトウェアではなく、ブラウザ プログラミング シミュレーションについて説明します。 1 つのコントローラーがすべてのチャレンジに合格することを保証するものではありません。ゲーム内の正確な API ドキュメントを使用して、実行した特定のテストを改善したイベントとルーティングの変更を記録します。
具体的なレビューとして、エレベーターがアイドル状態になっている間に行列ができているフロアを観察します。どのハンドラーが次の goToFloor リクエストを発行するか、またそのリクエストが待機中の乗客にサービスを提供するのか、それとも車両を別の場所に送るのかを特定します。その 1 つのルーティングの選択を変更し、チャレンジの結果を比較します。複数のハンドラーが競合する場合は、リクエストのシーケンスを説明できるまでコントローラーを単純化します。サポートされている正確なイベントについては、API リファレンスを使用してください。一度に 1 つのキューと 1 つの決定を観察すると、それが普遍的な最適コントローラーであると主張することなく、改訂の証拠が得られます。
Elevator Sagaのヒントと戦略
次のプレイで試したいヒントにチェックしてください。このリストはゲームを変更せず、ゲームの進行状況も保存しません。
Elevator Sagaに関する質問と回答
どの言語で書けばいいですか？
コントローラーはJavaScriptを使用し、ゲームエディタではinitとupdateの機能が割り当てられています。
これは実際にエレベーターを動かすものですか？
いいえ。これは完全にブラウザゲーム内で完結するプログラミングシミュレーションです。
プログラミングの練習に使えますか？
はい、特にイベント駆動型制御と小規模な変更のテストです。このゲームはmagwo氏のMITライセンスのElevator Sagaプロジェクトをベースにしており、資格取得コースではありません。
エレベーターが動いているのに乗客が待ち続けるのはなぜですか？
固定ルートの繰り返しでは、すべての希望階を扱えません。floor_button_pressed を処理し、goToFloor で乗客の行き先を指定します。停車階を増やす前に待ち行列と課題の目標を比較しましょう。destinationQueue を直接変更した場合は checkDestinationQueue が必要です。通常の追加は goToFloor が処理します。