てごわいです。。。

■今週のゲーム制作：ボタンUI！！！

ここ２週間ずっとボタンUIと戦ってます。てごわい。。。( ;∀;)

ボタンUIといいながら入力ソースの管理やメインループとシーンの構造、イベントをボタン→シーン→メインループに送信する仕組みなどなども作っていました。

※

・ボタンUI→「スタートボタン」「終了ボタン」「攻撃・防御・魔法・逃げるボタン」などを押したときの挙動、デザインや配置場所を考えること

・入力ソース→キーボードやマウス等の「どのボタンが押されているのか」という情報

・メインループ→「ソフトを起動してから終了するまで表示されている画面」

・シーン→「タイトル画面」「セーブ画面」「会話画面」

続きでプログラムの大まかな構造について！

「明日、初めて彼女と❤」とはかなり構造を変えていたんですが、ようやくベースのプログラムが整ってきました。

あしかののプログラムと今回の「怪物に至るエモーション（略して怪エモ）」のプログラムのイメージはこんな感じです。

あしかのの場合、メインループが持っているシーンは一つだけです。例えば「シーンA」から「シーンB」に移るときは「シーンA」が「シーンB」を生み出して「シーンB」が「シーンA」のポジションに収まります。

利点としてはメインループが単純なことと画面内の処理がシーンの中に全てまとまっていることです（これはデザイン面での利点であり、プログラムの面では悪い部分です）。

欠点はシーン移動の際にシーン間に結びつきがあることや複数のシーンを同時に処理できないので一つのシーンが膨らんでしまうという問題がありました。

実際、シーンの上にメニューを表示させるときなんかは特にプログラムの行数が膨らんでいます。

今回怪エモで目指しているのは右図のような「シーン同士が干渉しない」プログラムです。

メインループがシーンを積んでおけるコンテナを持っていて、必要なシーンを生産（push）して不要なシーンを削除（pop）します。

シーンやいろんなメニューを同時に表示できる設計です。

メインループがシーンとやり取りを行う部分のプログラムが膨らんでしまうんですが、その分シーンの処理は単純になります。

前に比べると処理速度が低下し（ポインタの参照回数が増え）ますが

シーン内部の機能面でやりたいことがたくさんあるのでプログラムの管理をしやすくするためにもこういう設計にしました。

体感できるレベルで処理が重くなるというようなことはないようにしたいです。（汗

どれくらいの粒度でシーンに処理をさせるのかは手探りですが時間をかけて正解を見つけていきたいです。

ここのところ平日（水曜日以外）は9時間くらいpixivSketchとYouTubeで配信していたりもするのでいつでもしんきの作業を監視しに来てください～～！