■ディレクトリ構成
まず、kyojinディレクトリとyamalibディレクトリがある。
kyojinディレクトリは、去人たちアプリケーション固有のプログラムがはいっている。
タイトル画面のプログラム、シナリオ画面のプログラム、エンディング画面の……。そしてそれらを構成する部品(クラス)のソースが収まっている。
yamalibディレクトリは、有用で使い回しができそうな部品。タイトル画面とかで表示するボタン、ダイアログボックス、テクスチャを効果付きで描画したりするユーティリティクラス、シナリオ描画を行う基幹クラス、Yanesdkのクラスをラッピングして機能追加したクラスなど。つまり、ライブラリになりそうなクラスである。まあ、あくまでも候補であって、テクスチャを効果付きで描画したりするユーティリティクラス系では、定数なんかが埋め込まれていてとても汎用的でもないのも入っているが、これはそのへんのアクセッサを用意すれば挙動も制御できる。
では、それぞれのディレクトリをもうちょっと詳しく見ていこう。
■kyojin/task
タスクは一つの処理単位で画面と対応している。たとえば、TitleTask.csであればタイトル画面の処理、 ScenarioScene.csであればシナリオ画面の処理という感じである。ソースではTaskとSceneが混在しているが、本当はSceneで統一すべきである。Taskは去人たちの過去のバージョンから移植してきたままだからで、TaskもSceneも同じ意味で使用している。ここでは、タスクと統一して記述していく。
タスクはYanesdkの肝の部分になる。詳細はやね本1を参照してほしい。
たとえば、去人たちのタイトル画面では、オプション画面や、シナリオ選択画面、音楽試聴画面などに遷移する。この遷移を制御するSceneControllerによって、どのタスク(画面)にでも簡単に行ったり来たりできる仕組みである。
kyojin/taskディレクトリにはこのように、それぞれの画面の処理を行うおおもとのクラスが入っている。
■kyojin/component
このディレクトリには、シナリオタスクやらエンディングタスクで使う部品となるクラスが入っている。
たとえば、PartialMenuItem.csではシナリオタスクの右下にでるメニューを処理するクラス、MusicRoomCmp.csでは音楽試聴タスクで再生パネルやら、プレイリストを処理する部品やらである。
そんなのシナリオタスクなり、音楽試聴タスクなりに処理を記述したらいいんじゃないか、というのは良くないアイディアである。わたしなんかは、昔なんでもかんでも*****Taskに処理を書いたために、タスクのクラスが長大になって、処理分岐の嵐になり、まともに処理が追えない状態になった。
これは、Yanesdkとは直接関係ないことだが、プログラミングの基礎的なことである。「Code Complete 完全なプログラミングを目指して」なんかの書籍をあたってみてほしいのだけど、わかりやすいプログラムのために必要なことだ。ひいては、よりカスタマイズしやすい、デバッグしやすい、保守しやすいプログラムになるのである。
話がそれたが、kyojin/componentにはそのような、画面を構成する部品クラスが入っている。
■kyojin/input
去人たちではInput.csしかないが、このディレクトリには、去人たち専用のインプットデバイスを定義したクラスがある。
インプットデバイスとは、キーボードやマウス、ジョイスティックなんかである。
もともとYanesdkにはMouseInputや、KeyBoardInput、Joystickなどのクラスがある。その他にVirtualKeyというクラスがあって、これはキーボードとジョイスティックなどのインプットデバイスを入力状態を一意に扱うためのクラスである。
たとえば、キーボードのエンターキーとジョイスティックのFireボタン(そんなのがあるなら)は「1番」と登録しておく。そこで、そのように登録されているVirtualKeyに対して「1番」のボタンは押されているか?と問い合わせることで、ジョイスティックのFireが押されているか、キーボードのエンターが押されているかは気にせずに、「1番」は押されているとか、押されていないとか判定出来る。
去人たちでは、「0番」にキーボードのエスケープキー、「5番」にはキーボードのzキー、スペースキー、ジョイスティックの4個目のボタンを登録している。それぞれのアプリケーションで使うだけのキーを登録しておけば、簡単にインプットデバイスのあるボタンが押されているかいないか判定できる。
■kyojin/model
去人たちでモデルと呼んでいるのは、単純にデータのことである。
BookmarkData.csはセーブデータを表している。去人たちではセーブデータは4つある。オートセーブと3つのユーザがセーブするデータである。
セーブデータは、セーブしたシナリオ番号や、セーブしたシナリオの位置、そのセーブ位置での文字列、セーブした時間、セーブしたシナリオで再生している音楽、背景画像の番号、表示しているキャラクターのID、位置などなどが想像できるだろう。
そのデータを単に表しているクラスである。簡単にいうと、それらのデータをGetとSetするだけのクラスである。
データを持っているだけなので、このBookmarkDataクラスのメソッドに画面に描画したりするメソッドはない。
もちろん、このクラスは描画するために必要な情報はもっているのだから描画メソッドを持たせることはできる。シナリオ番号を描画するメソッドをもたせれば、BookmarkDataクラスその何ページ目という情報をもっているのだが描画できる。
それをさせないのは、データをどのように描画するか、という問題はデータが解決することではないからだ。データはデータであって、それをどのように描画するかは、それを描画しようとするクラスまかせるべきだ。ページ番号をどの位置にどの大きさでどの色で描画するかを決めたとしても、あとあと、やっぱりこれはもっと大きな文字でとか、あるいは去人たちらしく、文字を単純に描画するのでなくて、ページ数をカバラ的暗号で表示させようとか、16進数で表示させようとか・・・ どのように描画するかなんて他の人にまかせておいて、データはデータとして独立しているほうがいいのである。
これは「モデル/ビュー/コントローラ」という一つの作法である。データはデータとして独立しておくといいよ、っていう指針である。この指針を実践しておいて損はないだろう。
というわけで、今回はkyojinディレクトリがどんな風になっているかを見てきた。
よく見ると、初心者は既に迷子で、中級者には退屈な内容にみえる。感想文でもないじゃないか。
まず、猫プロありきは失敗しとるんとちがうんかしら。