連載：マルチユースなライブラリの開発手法【C#／.NETでiOS／Android開発も】
iPhone／Android／Windows／Linux向けマルチターゲット化のシナリオとは？
C#を活用してマルチプラットフォームを実現する方法を解説する連載がスタート。今回は、ゲームを題材に、その「共通して使いたい部分」に関するシナリオを紹介する。
言葉としてはすたれてしまった感もあるが、ここ数年のソフトウェア開発のトレンドを一文で言い表すと、「Devices and a Cloud」である。単一デバイスで完結しないのが今の開発の実情だ。
といっても、「今の世の中、分業するものだろう？ どうせ違う開発者が担当するのだから、サーバーとクライアントは違う言語・違う環境で、それぞれ得意なものを使う方がいいのではないか？」と考える人も少なくないだろう。
もちろんそれぞれの環境に特有の部分に関してはそのとおりだろう。しかし、どんな環境でも共通して使いたい部分というものもある。
今回は、ゲームを題材に、その「共通して使いたい部分」に関するシナリオを紹介しよう。すなわち、図1に示すような、ゲーム・ロジックの共通利用だ。
こういう要件は、これから、業界を問わずますます重要になってくるだろう。
筆者はこれをC#を使って実現している。個人的には、今のところ、C#（というよりも、Visual BasicやF#も含む、いわゆる.NET言語）を使うのが一番楽だと感じている。何が一番になるかは人によりけりだとは思うが、これから説明するような要件を踏まえたうえで検討してみてほしい。
それでは、具体的なシナリオを見ていこう。
クライアントの選択
ゲームといっても、今回題材にするのはスマートフォン向けのゲームである。今、スマートフォン向けゲームを作るなら、iPhoneをターゲットにするのが一番だろう。Androidもターゲットに含めたいが、Android単体で出したいほどではない。できることなら、iPhoneとAndroidのクロス開発をしたい。
スマートフォン向けのクロス開発ができるフレームワークはいくつかあるが、C#が使えるものとしてはUnityゲーム・エンジンが有名である。クロス開発には特有の苦労も多いものの、Unityゲーム・エンジンの場合は、「用途がゲームに限られている」「スマートフォンなら、ある程度マシン・スペックがそろう」などの理由で、意外と苦労少なくクロス開発ができる。
クライアントのオフライン動作
日本では、電車の中でゲームをプレイすることも多い。電車の中ではどうしても電波が不安定になりがちで、ネットワークの寸断、あるいは、状況によっては全くつながらないことも多い。ゲームは、そんな不安定な通信状況でもプレイできなくてはいけない（ほんの少し「やりたいけどできない」という状況が発生するだけで、ゲームへの熱はあっさりと冷めてしまうものである）。
ネットワークのない状態、つまり、クライアント単体で動かすためには、当然、ゲームのロジックがクライアント上で動いていなければならない。一方で、プレイ結果や、結果に応じたアイテム獲得、ランキングなどの情報はサーバー側で管理することになる。クライアントから送られてくるプレイ結果の自己申告を信用するという手もあるにはあるが、完全に信用すると、いわゆるチート（＝非正規のクライアントを使って通常ではあり得ないプレイ結果を作ってサーバーに送る）の温床となる。
●クライアントとサーバーでのコード共有
結局、同じゲーム・ロジックをクライアントとサーバーの両側に持つ必要がある。また、プレイヤーの操作を記録して、サーバーに送信し、その操作をサーバー側で再現実行する仕組みが欲しい（チート検証は、プレイ時間などの行動ログからだけでもある程度判別可能ではあるが、一番確実なのはやはり、完全に再現実行することである）。
最悪、異なる開発言語・環境、異なる開発チームで二重に同じロジックを実装するということもできなくはないが、完全に動作を一致させるのは至難の業である。できれば、コードそのものを共有したい。
C#なら、それが簡単にできてしまう。iPhoneやAndroid向けの開発でUnityゲーム・エンジンを使うメリットの1つだろう。
●Linux上での実行
ただし、「そのためだけにWindowsサーバーを用意するのか」という問題がある。現状、日本において、サーバー上でのコード資産はLinux環境で動くもの、特にPerlやPHPコードが多いだろう。
全てを置き替えるような開発はお勧めしない。ゲーム・ロジックだけを単独でC#実行するのが現実的だろう。Monoを使って、Linux上で（すなわち、PerlやPHPなどが動いている同一サーバー上で）C#を動かすこともできる。
マイクロソフト実装の.NET Frameworkとオープンソース実装のMonoの間には、細かい挙動の差がないわけではない。しかし、基礎的な部分で問題が起こることはあまりなく、ゲーム・ロジック部分をしっかり切り出していれば（GUI、通信、データベース・アクセスなどの層と分離されていれば）、互換性問題で苦労することは少ない。
バランス調整ツール
ゲームを面白くするためには、いわゆる「バランス調整」という工程が非常に重要である。同じゲーム・ロジック、同じゲーム画面であっても、キャラクターやアイテムの強さのバランス次第で面白みに大きな差が生まれる。
要するに、「データを入力してみて、実際にプレイして確かめる」という作業が必要になる。ゲーム開発を迅速に進めるためには、このバランス調整工程をいかにして早く回すかも重要である。
スマートフォンのサイズのデバイスはどうしても「見る」「遊ぶ」専用で、通常、データ入力はPC上で行う。デスクトップPC上で動くバランス調整ツールがあれば、調整作業もはかどるだろう。
あるいは、最初は、Excelなどで入力したデータを受け取って、単にテキスト形式で結果を出力するだけの簡易なツールを用意するだけでもいい。ゲーム・ロジックが完成した時点で、ゲーム画面の開発と並行してバランス調整を行えれば、開発期間の短縮につながる。
ものによっては、明らかにおかしい部分を自動検出することもできるだろう。
そしてC#
ここで挙げた要件をまとめると、以下のような実行環境への対応が必要になる。
- iPhone、Android、Linuxサーバー、Windowsデスクトップ、（UIなしの）単体実行
意外かもしれないが、今、C#であればこの全てに対応できる。
もっとも、それを実現しているのは「CLI（Common Language Infrastructure： 共通言語基盤）」という規格（＝.NET Frameworkの基礎部分を標準化したもの）であって、（C#でなくても）CLI規格に対応する言語であれば（Visual BasicであれF#であれ）何でもよい。
上記のような広い用途・広い環境での利用を実現するためには、基礎からしっかり作られている必要がある。短期的に見てはやっていても、上物ばかりがよくて地盤の緩い技術では、利用の幅を広げる際に無理が生じる。C#を広い用途で使えるのも、CLI規格という強固な地盤のたまものである。
最後に
余談となるが、ゲームといえば、昨年からの話題はパズドラだろう。もはや、プレイ人口・売上規模ともに、ゲーム史上最もプレイされたゲームといっていい。しかし、それを作ったのは、家庭用（専用ハードウェア）ゲーム会社でも、フィーチャーフォン向けのゲームで大成した会社でもなかった。
そういった成功していた従来の会社が、市場の移り変わりについていけなかった理由はいろいろある。もちろん、家庭用やフィーチャーフォン向けと、スマートフォン向けでは、配信形態も客層も異なり、企画・運用面でのノウハウも違う。それでも、開発がネックにならなかったといえばうそになるだろう。
特定の環境に特化するあまり、変化に対応できなくなってはいけない。スタンドアロンのゲームしか作れないとか、サーバー側しか書けないとかでは時代の荒波を乗り越えることはできない。
技術は変化が激しくてすぐに陳腐化するといいたいわけではない。変化が激しい中でもずっと変わらず重要な「強固な地盤」は確かにあり、それをしっかりと押さえる必要がある。
1. 【現在、表示中】≫ iPhone／Android／Windows／Linux向けマルチターゲット化のシナリオとは？
C#を活用してマルチプラットフォームを実現する方法を解説する連載がスタート。今回は、ゲームを題材に、その「共通して使いたい部分」に関するシナリオを紹介する。
