こんばんは。
今回は、戦闘におけるシーン管理の基礎について述べたいと思います。
これは戦闘に限らず、あらゆる場面で使える、非常に有用なテクニックです。
さて、皆さんが普通にプログラミングをしている限り、必ずと言っていいほどif-else構文を使うと思います。switch-case構文でも構いません。とにかく、条件によって処理を分岐させるということは、単純なバッチ処理やトイ・プログラムでない限り必要な手続きであります。
ことゲームにおいては、「シーン」は多種多様に渡ります。タイトル、移動、戦闘、売買……どこで大きなシーンを分けるかについては、仕様と個人の嗜好が大きく影響してくるので、とくに議論するつもりはありません。
このシーンというものを一つの処理のまとまりとして見た時、条件分岐によって処理を変えるという手法は、目的に合致していると思います。すなわち、いわゆるメインループにおいて、今どのシーンを実行しているかという変数の値に応じて、処理を分岐するということです。これはごく普通の考えで、皆さんも意識せずやっていると思います。
簡単なテクニックながら、「サブシーン」を導入するというのは非常に効果的です。変数が一つの場合に、0、1、2…のうち1と2の間に入れるのがリーズナブルなシーンが出てきた時、それが15や-1に入ってしまうという間抜けな問題を解決してくれます。法律でよくある～条の2、というやつです。シーンが1の1、1の2、のように分けられれば、今まで数直線上で管理されていたシーンが平面的な広がりを持って、柔軟に管理できることが分かると思います。
それとは別に、シーン管理の構造には要注意です。皆さんは各シーンをそれぞれクラスとして作りますか？関数に分けて書きますか？それとも、while(true)内に上から順に書いていきますか？
どの方法でも同じように実装できると思いますが、一つだけ異なる点があります。変数のスコープに関わる部分です。シーンそれぞれを関数に分ける方法は非常に有用で、私もこの方法を採用しています。しかし今ユーザーに「はい」と「いいえ」について入力を待つ場面だとして、その値を保持する変数は関数の中で宣言できません。その変数の寿命が1ループしかないからです。結局この方法では、関数の外にこの瑣末な変数を記述する必要があります（なぜ瑣末かと言えば、この選択の過程を表す変数は、過程を表す画面でしか必要とされないからです）。
このような変数は全体を通して30個にも満たない数でしょうが、構造として美しいとは言えないでしょう。とはいえ、この部分は他と違って後から修正することが容易ですし、機能的にはさしたる違いはありません。自分の意識として、「なぜこの構造が適しているか」を考えながらコーディング出来ればそれで十分だと思います。「自分が書きやすいから」というのも大きな利点なのです。