型に嵌めよう

　飲食店で店員が「注文は以上でよろしかったですか？」と発する事があった。「注文は以上でよろしいですか？」が正しい。何故なら注文中だからだ。客が注文する品目を店員に伝え、 店員は品目と数量が正しい事を確認し、客が了承して注文が完了する。もし購入サイトで確認ボタンを押した後に「注文は以上でよろしかったですか？」などとメッセージを表示しよう ものなら、タコ扱いされるだろう。「注文を確定します。よろしいですか？」である。「注文を確定します。よろしかったですか？」ではない。

　敬語に詳しい同志社女子大学の森山由紀子教授によると「以上でよろしいでしょうか」が相手の判断を確認する表現なのに対して、「よろしかったでしょうか」は 「（あなたの判断はもう聞いたはずだが）私の認識はこれで間違いないか」と自分側の事柄を確認する表現で、この表現の背景には相手への配慮がある。 「よろしかったでしょうか」を「よろしいでしょうか」の誤りと断じることはできず、相手に直接ＹＥＳ・ＮＯを迫るのを避けるという意味で 「聞き手への気配りによって生じた表現」なのだという。

購入サイトで「注文を確定します。よろしかったですか？」と聞かれて「聞き手への気配りによって生じた表現」と感じる者がいるとは思えない。（あなたの判断はもう聞いたはずだが）は 暗黙的で恣意的なものだ。（あなたの判断はもう聞いたはずだが）を補完してまで正しいとする事には反対だ。対面での注文でも同様だ。
　何故こんな話を始めたかと言うと、言葉のおかしいプログラマーが結構いるからだ。「注文数量が間違っております。」と記述する者たちがいる。当人たちは利用者への配慮のつもりなん だろうが、裏を返せば「入力ミスしたお前が悪い」と利用者を責めている表現であるとも言える。システムは誰が入力したかは問わない。あくまで注文数量の間違いを問うのだ。この場合の メッセージは「注文数量が間違っています。」だろう。プログラマーは言語を扱う。自然言語では無いとは言え言葉を軽んじるプログラマーのコードは往々にして読みづらい。使用しない変数や 使用しない関数を放っておく、同様の処理をルーチン化しない。そのようなプログラマーはいつまでも仕様書が書けない。これは私の経験則だ。

　ソフトウェアはものである。一般的に企業においては、もの作りには生産性が要求される。ただし生産性が上がったからと言って全ての人が幸せになれるとは限らない。今まで８時間かかった ものが４時間ですむようになっても、ういた４時間分の仕事が与えられるだろう。それで社員の給料があがれば良いが、社員や世の中への貢献より利益のみしか頭にない会社のトップは結構いる。 過労死や過労自殺の報道が後を絶たない。
　そんな社会の暗部はあるにしても、生産性を上げる事は良いことだ。自作ゲームを作ると言う趣味の世界に生産性なんて関係あるのか？と思われる方もいるだろう。私は大いに関係があると 思っている。正確で簡潔なコードをサクサクと書きたい。これは全てのプログラマーの願いだと思う。サクサクと書くと言う事は、サクサクと、もの作りが出来る事であるから生産性の欲求に他 ならない。突き詰めれば楽がしたいのである。
  ソフトウェアフレームワーク と言うものがある。ソフトウェア開発を容易にすることを目指しているものだと言う。ならば楽をしたい私としては使わない手はない。フレームワークの使用有無に関わらず、フレーム化は 重要だ。これは型に嵌めると言う事である。パターン化とか記述ルールとかを連想して構わないだろう。似たような処理部分は似たような書き方をする事により一様化する。コードの可読性を高 めて解りやすくする。そうすれば楽なプログラミング・ライフをエンジョイできるだろう。

　オープンソースの会計ソフトや他のソフトの作りを見ていると、クライアントからの要求は一つのモジュールに送られるようになっている。仮にそのモジュールを index.php としよう。例えば トップ画面を表示する時も、何かのボタンを押した時も全て index.php に処理の依頼が行われる。index.php は処理に応じて、その処理を担当するモジュールを呼び出す。これは型嵌めが行われて いるなと直感した。ネットで検索した結果、Model View Controller(MVC)と言う デザインパターンである事を知った。C(Controller)さんが要求を受け付ける窓口である。CさんはM(Model)さんに要求を依頼する。Mさんは必要なデータ処理をしてV(View)さんに結果をクライアントに 送れと依頼する。Vさんは表現を生成しクライアントへ返す。index.php はCさんに相当するのだ。
　ここで疑問が生じる。１００種類の要求があった場合、index.php に、その数分の分岐コードを記述するのかと。ところが リフレクション と言う技を使えば簡潔になるのだ。私はC＃でリフレクションを多く記述したが、PHPでも可能だと知った。クライアントは複数いる Model の中から、どのMさんに処理して欲しいのかを指名する。 index.php は指名された Model を動的に生成し指定されたメソッドを呼び出すのだ。
　ネットでご注文はxxxですか？と言うフレーズを良く見かける。何かと思って検索すると ご注文はうさぎですか? と言う漫画とアニメ化された作品からきているらしい。保登心愛(ほとここあ)にコーヒーを頼む為のデータ構造とクライアント側のコードを具現化してみよう。

項目	内容
className	処理を依頼する相手、リフレクションで動的生成が可能なクラス名、例えば mdlHotChocolate
actionName	要求名、className で指定したクラスが認識するもの。例えば getCoffee
mid	処理対象のメンバ、当自作ゲームで認識するプレイヤー
引数群	処理に必要な引数、例えば品目や数量など。

<form action="./index.php?className=mdlHotChocolate&actionName=getCoffee&mid=1" method="post">
<input type="text" name="arg1" id="Item" />
<input type="text" name="arg2" id="Quantity" />
<input type="submit" />
</form>

これで「ここあちゃん。モカコーヒーをひとつ」と言うシーンが表現できるな(^^)v

　前節で掲げた <form action="./index.php?className=mdlHotChocolate&actionName=getCoffee&mid=1" method="post"> の mid=1 の部分の番号は可変で無ければ ならない。何故なら、この番号はプレイヤーの識別番号なのでログインしたプレイヤーの番号に置き換えなければ、誰かを認識できない。つまり動的な HTML 生成が必要だ。楽に できる方法を探したら見つかった。 テンプレートエンジン を使おうと思う。どうやら Smarty なるものが有名で使い易いみたいだ。テストコードを書いて試し て見ると、なかなか「うい奴じゃ」(^^) 名前も可愛いではないか。これを使うと保登心愛にコーヒーを頼む為のテンプレートはこうなる。

<form action="./index.php?className=mdlHotChocolate&actionName=getCoffee&mid={$mid}" method="post">
<input type="text" name="arg1" id="Item" />
<input type="text" name="arg2" id="Quantity" />
<input type="submit" />
</form>

上記のテンプレートを「cocoa.tpl」と言うファイルに保存したとする。PHP 側のコードは下記のような記述になる。

$smarty = new Smarty();
$smarty->template_dir = dirname(__FILE__).'/tpl';
$smarty->compile_dir  = dirname(__FILE__).'/tpl_c';
$smarty->assign('mid', $this->GetPlayer());
$smarty->display('cocoa.tpl');

　ソフトウェアの世界はエンジンブームらしい。末尾にエンジンと付いた名前のソフトウェアが溢れている。何を燃料として動くのか解らないがプログラマーの執念を燃やすのかも知れない(^^) ゲームエンジン も当然のようにある。結局のところ「共通して用いられる主要な処理を代行し効率化するソフトウェアの総称である」と。わかんねぇ(__!) ゲームフレームワーク じゃダメなのか。ソフトウェア開発を容易にすることを目指しているものではないのか。とかく新しい名前を作りだすのが好きな者たちがいる世界である。 とぼやいても仕方がない。「html5 ゲームエンジン」のワードで検索してサイトを見てみよう。

a) HTML5でゲーム開発。JavaScriptゲームフレームワークまとめ
b) ブラウザゲーム開発で使えそうなゲームエンジンまとめ - Qiita
c) ゲーム向けJSライブラリ雑感

　ゲームエンジンってこんなにあるのだな。Qiita の要件としてオープンソースであることを加えても、結構な数だ。実際に動くものを置いてあるサイトで感触を試してみた。enchantjs は 動くと言いながら動かないものが多数ある。こんな実験をしてみた。google で「enchantjs デモ」と検索する。ヒットしたサイトへ行く。ゲームをやる。何回かやった後にブラウザの戻るボタン を押す。一回では戻らない。何回も押すと戻る。Cocos2d-js のデモはサクと戻る。しかし２Ｄである。３Ｄを使えた方が表現に深みがでるだろう。WebGLだ３Ｄの時代だと語られるご時世だ。 切り捨てるには勿体ない。ゲームエンジンを使わないゲームのデモを掲載しているサイトもある。

d) こんなのも作れる！HTML5で作られた最高に面白いゲーム10選
e) 初めてのHTML5ゲーム作成

これらのサイトを見ると、ゲームエンジンを使わずともゲームは作れる事がわかる。これらは、ゲームエンジンが処理している部分を、全部ではないにしろ自前で処理していると言う事だ。 ３Ｄ表現ができるライブラリ「Three.js」を紹介しているサイトもある。

f) 多彩な表現力のWebGLを扱いやすくする「Three.js」

さて結論を出すとしよう。当節で掲げたサイト以外も多数調べた結果、ゲームエンジンは自作する事にした。どのような機能があれば良いのか？それは次節に譲る。

ゲームエンジンが提供する機能は何だろうか。下記に列挙する。

以上の機能があれば、少なくとも私の自作ゲームは実現できると思う。ゲームエンジン自体が自作なので不足分は後からでも補える。