更新が遅れましたが、キチンと生存しております。
キチンと生存しております（大事なことなので二回！）
お詫び
さて、前回の設計で一つ謝らなければならないことがありました。
それは、Threadクラスの使用についてです。
前回作ったアレですが、ゲーム的にちょっと残念な仕様になっていた点がありました。
それは、プロセスが「ゲーム的に」宜しくなかったという点です。
ゲーム的な仕様の大切さ
まずゲームをプレイする人の視点に立ってみましょう。
ゲームをプレイしていると、
現実世界の訪問者によるインターフォンや、急にお花を摘みたくなったりと
きっとVRになっても割と起こるあるあるな横槍が入ることあるかと思います。
このとき、前回の設計（Threaクラス）で作成していた場合、どのようになるのでしょうか？
Threadの罠
端末をスマホにして動かしたと仮定しましょう。
あなたは心地よくゲームをしていました。
バトル中です。長いラストダンジョンのセーブ手前です。
しかしここで、友人の魔の手（？）により合コンの誘いの電話が来ます。
もちろん、電話にでますよね？デマスヨネ？
数分の会話の後、あなたは約束を取り付けて、意気揚々と電話を切ります。
そしてゲームのプロセスに戻してみたところ...
そこには、「おぉ、死んでしまうとは情けない」の文字が！？
そう、これこそがThreadクラスの罠なのです。
プロセスが異なるということ
Threadクラスは、簡単に言うと「平行世界を作って、面倒な処理をそっちでやってもらう」という処理です。
そのため、「メインプロセスがポーズ状態にあっても、関係なく動き続ける」ということになります。
ということは「描画しなくても戦闘は進行している」ということと同義なのです。
ハードがある程度固定化されていればこの辺の制御は難しくないのですが、
近年のスマホなどに対応する場合は、描画とプロセスの関係性をキチンと意識してあげないと後で厳しいことになるかもしれません。
ということで、Threadクラスでタイムテーブルを監視するとメインプロセスに依存しなくなるので却下します
別記：Threadクラスの使い道
通常に作っている分にはそうそうないところですが、企業なのでしっかりとサーバーを用意してあるオンラインゲームの場合に限って、
外部アセットや特定のスクリプトをサーバーからDLさせるように仕向けることもできます。
ただし、前回述べた通り、ThreadクラスではUnityEngineを使用することができません。
そのため、デフォルトのC#でダウンロードを管理する必要があります。
時間があったら個人でも今度作ってみようかと...
設計ミスによる現在の被害状況
この段階で気づけたことが幸いです。（あとで気づいたらほぼ作り直しになっていました...＾＾；）
※厳密に言うと、Threadクラスをそのまま使用しても作ることは可能です。
しかし、ちゃんとプロセス監視をしてゴニョゴニョするとできるのですが、Coroutineで管理したほうがUnity使ってる感じがしてわかりやすいのです。
タイムテーブル作り直し
ということで、タイムテーブル管理システムをUnityEngineで作り直しました。
ついでにuGUIのSliderを使用してゲージも作ってみました。
※時間がなくて動画が取れてないのですが、後日編集します。
味方4人はシーンの初期化完了時からタイムテーブルに「入力前処理」として待機時間を指定。
指定した時間をTime.deltaTimeで監視しつつ、累積時間が待機時間（Sec）を上回ったらコマンドウィンドウを表示させるようにしました。
なお、コマンドを入力したらコマンドウィンドウは随時非表示にしていきます。
※Time.deltaTimeで管理している理由は、Unityウィンドウが非アクティブ状態になった時にフレーム描画が停止するので、その間の時間軸の差し引きを計算しなくて良くなるからです。
Time.deltaTime：観測フレームからひとつ前のフレームを描画した経過時間。Updateメソッド内で使用することで、メインスレッドでの監視になる。