2002-10-25 .. 2015-12-28

PC-Games

ゲーム計画、再び

(2009-10-17)

勇者ハニワの製作から既に 3 年が経った。結局その間、何の動きもなかった。勇者ハニワ自体は、いわゆるキャラクター系のアクションゲームなので、僕自身の本来の作ってみたいゲームの方向性とは全く違ったものだったせいもある。僕自身は基本的に、純 PC ゲーム的な、パラメーター系ゲーム(いわゆる戦略系ゲームや国取り系ゲーム)志向の人間である。RPG にしても、NetHack のような、ターン制のゲームにこだわる派で、リアルタイムなアクション系ゲームは過去にアーケードから DOOM に至るまで散々やりまくってきたものの、実はあまり好きではない、もしくは飽きてしまった。(これは好みだけの問題ではなく、論理的な考察によって優劣を判断した結果でもある。本来、抽象化度の高い物事の方がより知性的で、人間の精神により深く訴えるように出来ているのである。視覚面にしても時間の進行面にしても、より「リアルな」方が、実は文化的にはより「幼稚な」のである。つまり、高度に「理系的な人間」(技術的な充実に走る傾向のある人々)ほど、文系的な人間として(文化芸術的観点で)評価した場合には「低レベル」に陥いりやすいという罠がある)。

ところで、ここ 1 年ほど、一つのシミュレーション系ゲームのアイデアがあって、是非形にしていみたいと考えていて、またぞろゲーム製作に関心が戻ってきている。また、最近、Linux をいじっていて、どうしても自分でビデオカードのファンの制御用のドライバを書かなくてはならなくなり、ずっと避けてきた C 言語にも触れなくてはならなくなって、C 言語に手を染めてしまった(Perl を一通りマスターしている状況からすれば、C 言語はほとんどそのエッセンスは包含されているので、習得に何ら障害はないのだが、単に気分的な問題から長年避けていた)。C 言語を使うのに何の問題もなくなってしまったからには余計に、ゲーム製作に関する技術的な壁はほとんどなくなったと思う。

とはいえ、普通に Windows やら GNOME やらの GUI アプリケーションとしてのゲームを C/C++ で作るという定石を辿るのも、自分のような素人が今さらやったところで、何の面白味もないだろうから、あまりそのようなことをやるつもりはない。基本的に、

  1. Windows で開発しない。
  2. また、Java の場合はプラットフォームの問題以前の話になるが、プラットフォームに依存しなさ過ぎるのもゲームプログラミング的につまらない(ハードウェアをある程度意識しながらプログラミングしたい)ので、Java も外す。
  3. Mac OS-X 環境はそもそも所有自体していないので、結局 Linux で開発することが前提になる。
  4. Linux で GUI ゲームなら SDL ということになるが、別に Windows で作られているようなゲームをわざわざ Linux で作ることのメリットも感じないので、SDL は外す。
  5. 実は、自分が温めているゲームのアイデアは本当に、データ中心のパラメーター系ゲームなので、GUI は最小限で良く、ゲームのエンジン・アルゴリズムが胆なので、Perl/TK がおそらく最適の選択ということになる。

とはいえ、キャラクター系アクションゲームである勇者ハニワみたいなゲームもせっかくなので、C 言語などで移植してみたいとは思っている。こちらはこちらで、別に手がけてみたいのだが、Linux で開発する場合には、

  1. やはり、SDL は外したい。DOS で作ったようなシンプルなゲームはハードウェアの制御と直結しているようなプログラムになっているという特色があり、イベントドリブンな GUI 特有のプログラミングにするのは避けたい。敏感な人ならわかるが、GUI アプリケーションではどうやっても、DOS のようなダイレクトな反応性が得られにくくなるのである。
  2. 選択肢としては、DOS そのものの環境を Linux で使うということで、dosemu や DOSBox を使うという方法である。C 言語環境は DJGPP を、IDE の RHIDE と組合せて使うといったところである。
  3. または、DOS のように CUI 的な Linux ネイティブな環境としては、framebuffer を使ってプログラミングするという方法も考えられる。
  4. さらに、これは勇者ハニワの移植方法としては無理があるが、BASIC 的なゲームを製作する環境としては、(NetHack のように)ncurses を使った、ASCII グラフィックスのゲームを作るというのも、非常に魅力的な考えだ。

つまり、パラメーター系ゲームは Perl/TK、キャラクター系ゲームは dosemu か framebuffer か ncurses を使うという結論になる。

Web Games

(2002-11-01 .. 2004-05-08)

自分自身が Perl/CGI プログラマであり、ゲーム製作の夢があったりすることから、Web のフリーゲームは、自然と Perl/CGI 系のものを選んでしまう。

C/C++/Java 系の、要するにリアルタイム処理系のゲームになってしまうと、通常のスタンドアローンで楽しむコンシューマゲームとあまり大差はなく、実際上、それを Web ブラウザのアプレット上で走らせているだけという感じである。すると、所詮はアマチュアが作った無料ゲームであって、プロの会社組織が人材と資金を投入して製作したコンシューマもののチープな模造品にしかなり得えない。自分自身が作り手になるよりは、結局、プレイヤの立場に徹するに如かずということになる。

一方、Perl/CGI 系の Web ゲームには革命的な可能性が残されているように感じる。まず、多人数参加型のフリー Web ゲームの有力なタイトルの多くが Perl/CGI によるものだという事実。C/C++/Java ゲームだと、Web は所詮、プログラム本体をネットワークを通じてダウンロードするための伝送経路でしかない。しかし、Perl/CGI の場合は、Web という情報配信システムの特性と一体化したものとして機能している点に、これまでのスタンドアローンなゲームになかった長所が隠されているのである。

ビデオ機能が中心的な役割を果たしてきたこれまでのゲームの進化の歴史の常識から言うと、そもそも C/C++/Java 等のコンパイラ言語に比べて比較的低速な、インタプリタ言語である Perl を開発言語として採用すること自体、非実用的な話かもしれない。しかし、ハードウェア機能の十分な発達によって、もはやその差もあまり考慮しなくとも致命的ではならなくなりつつあり、これからももっと状況は改善することは間違いない。その一方で、Perl のコンパイラの開発も進んでいる(さらに先には Perl 6 と Parrot の可能性も控えている)。

商用ベースでないという理由であまりゲーム雑誌等のメディアには取り上げられずに無視されているが、実際に目にするとこれらの Perl/CGI ゲームの異様な人気に驚かされる。もちろん、商用ベースの多人数参加型のネットワークゲームも既に多数存在している。しかし、その盛り上がり方とはまったく異なる次元の熱狂がそこには存在するようである。
商用ベースのような、クローズド(閉鎖的)な世界ではない、オープンな世界特有の活況が、そこにはある。まさしく、ネットワークゲームのストリート・カルチャと言ってもいいかもしれない。

人気のある Web ゲームタイトル

Web ゲームを探すのにいいサイトとして WebGameCoJp という所がある。ランキングシステムによって様々なサイトが登録されているのを見ることができる。Perl/CGI 系のゲームで特に人気が高いのが、シムシティ系シミュレーションの『箱庭諸島』、ファンタジ系 RPG の『Spellbound』、ロボット系 RPG の『Endless Battle』など。このうち、『箱庭諸島』と『Spellbound』に共通するのは、プログラムが公開・配布されているという点である。そのため、数多くのサイト運営者が設置し、また、カスタマイズを施して、様々な変異体を生み出している。その点も人気の秘密だと言える。『箱庭諸島』は後にその人気を買われて商用にもなったようだし、『Spellbound』に関しては、ゲームプレイは無料でありながら、サイト運営者に対するプログラムの配布を有償にするという方針を採っているようである。しかしながら、いずれもプロがビジネスを最初から目論んでスタートさせたものではなく、純粋に面白いものを作ろうとしたのがきっかけで世に出てきたゲームであるというのが特徴である。

Spellbound

僕も実際に、試みに『Spellbound』をやってみた。運営サイトは、 WebGameCoJp でランキングトップだった一休システムの『カスタム版 Spellbound』だ。このカスタム版は、OKN氏の『Spellbound ~理想の果てに~』という改造スクリプトをベースにしているようだ。本家の花田圭介氏のオリジナル版と比べてみれば、その違いを見いだすことができる。オリジナルの優れたエンジンが核に存在してこそカスタムも可能だったのだろうと思うが、カスタムによってかなり華やかなものに飛躍的に向上しているように思われる。そのせいあってか、一休システムの『カスタム版 Spellbound』では、大変多くの女性プレイヤを見かける。おそらくティーンエージャが多いだろうが、ともするとマニアックに傾きがちのネットゲームにしては珍しい現象と言えるかもしれない。こういう所にも、 Web ゲームの潜在的な可能性を見出すことができる。
もちろん、一つ一つの機能を取り上げてみれば、スタンドアローンの従来の商用ゲーム製品にかなうべくもないものだろう。インターフェース的にも、まだまだ洗練されていない感じがする。同じコマンドを実行するのに、何度も遠回りな作業をプレイヤに要することがあったりする。しかし、そのような貧弱な面を抱えていても、全体として、掲示板機能やチャット機能などがトータルにパッケージングされたゲームとして展開されているのには、新しさを感じさせる。今まで、他のコンシューマーゲームや、商用のネットゲームでは体験したことのなかった、オープンなコミュニケーション空間が、そこには展開されているのだから。

Perl/CGI プログラムの技術的観点から『Spellbound』を実際にプレイしながら分析してみた限り、意外な点に気が付いて、驚いた。当初、多人数参加型のリアルタイム RPG をどうやって稼働させているのか、興味があった。1 ターンを 10 秒としても、10 秒毎にサーバ側の情報を更新するような、cron を利用するシステムが必要になる。cron を許可しているプロバイダは珍しいので、一体どのようにしているのかと思っていた。しかし、実際は、cron は使っていないらしいことに気が付いた。要するに、サーバプッシュ型のゲームシステムではなく、プレイヤ側からコマンド入力のリクエストがあった場合に、受動的にサーバ側のデータを更新してプレイヤ側に情報を返すようなクライアントプル型の仕組みになっているらしい。そのため、主に、ファイルの重複アクセスを排除するため flock だけが条件となっているようである。
実際にどうなっているかは、『Spellbound』からスクリプトを購入してみればはっきりすることではあるのだろうが、cron を要求しないということは、おそらくそのような仕組みになっていると見て間違いないと思う。
また一応、アクセス負荷の軽減を狙って、数秒毎に一度ずつしかコマンドを入力できない仕組みになっているが、これは、クライアントサイドまたはサーバサイド、もしくはその両方で、前回の入力との時間間隔が短い場合は、受け付けないような仕組みにしているのだと思われる。
つまり、てっきり、ローグ系のゲームと同じようなターン制の同期型ゲームシステムだとばかり思ってたが、実はターン制ではない非同期型ゲームシステムのようである。この非同期型というのは、実は、Web ゲームの特徴であり、可能性でもあるような気がする。これは商用のネットゲームの発想からはなかなか思い付きにくい盲点だと思うのである。

箱庭諸島

箱庭諸島』もプレイしてみた。このゲームも、ゲームシステムそのものとしては特に目新しいものではなく、一見したところはシムシティのちゃちなクローンといったところである。だが、にもかかわらず非常に人気が高いという事実は、『Spellbound』や『Endless Battle』同様に、商用ゲームのような単体のゲームシステムとしてのボリュームと複雑さに依存した面白さとは、全く別次元の場所にその醍醐味がある証拠だと言える。

システム的には、数時間ごとにターンが進む同期型のゲーム進行なのだが、数十ターン分のコマンドをあらかじめ予約しておけるというアイデアが特筆すべき点だと言える。こういう、24 時間休みなく進行し続けるネットゲームには、実はこういうシステムは非常に重要ではないかと思うのである。そうでない他の例えば『バトルロワイヤル』系のゲーム(『Endless Battle』を含む)だと、深夜・早朝の人が少ない時間帯に攻撃される不利さにはどうにも対抗できないという問題を常に抱えなくてはならなくなる。

Perl/CGI プログラムの技術的観点からは、JavaScript を上手く応用して、ユーザインタフェースの点でそれなりに快適に作り上げられている点も特筆すべき点だろう。
一方、この『箱庭諸島』と後述する『Endless Battle』の場合は共にスクリプトが配布されていたので、目にする機会があったのだが、純粋な Perl プログラマとしての僕の観点からすれば、かなり癖のある、元々 Perl 以外の言語(C 言語等)を得意とするプログラマが書いたコードだという感じがした。純 Perl 的なオブジェクト志向モジュールで構成すれば、もっとすっきりした再利用可能なものになるのになあとも思ってしまう。

Endless Battle

Endless Battle』は元々作者のサイトのみで運用されていたものだが、一時配布がされたこともあり、多くのサイトで運用されるようになった。それで僕もプレイしてみる機会ができた。
『箱庭諸島』と同様、単体のゲームシステムとして見たら、商用と比べてチープきわまりない代物である。だが、やはり『箱庭諸島』と同様、異常な人気がある。

システム的には、単純な 1 対 1 のカードバトル系の戦闘システムである。特にゲームに頭を使うわけでもないし、ただひたすら回数を重ねて、経験値・お金稼ぎとレア・アイテムを探す程度のものである。要するに、ゲームシステムに特にこれといったアイデア的な秀逸性は全くない。
一方、そのような戦闘システムと並行して、参加数多人数のプレイヤーが、派閥を形成するようになっている。そして、その派閥は、ちょっとした派閥内のみのメッセージ交流空間(簡単に言えば掲示板)を共有するという点でつながっているのである。この派閥ごとのメッセージ交流空間が、他の派閥との戦闘によって破壊の危機にさらされていることになる。そのため、極めて単純な戦闘システムにも関わらず、戦いに熱がこもるわけである。むしろ掲示板というネット特有のシステムに、戦闘システムをオマケに付けたと考えた方が正解かもしれない。一種の、「花いちもんめ」系の遊びだと考えればいいだろう。この掲示板を巡る「花いちもんめ」系のゲームは、実は、アイデア的には『Endless Battle』が最初ではなく、『バトルロワイヤル』というフリーのネットゲームが先に存在しており(このゲームより先にこのタイプの原型となるものが存在したのかどうかは僕には定かでない)、『Endless Battle』は、そのアイデアを「ロボットもの」という形で実現した形になる。

Perl/CGI プログラムの技術的観点からは、『箱庭諸島』と同様に、やはり、JavaScript の応用の点が挙げられる。『箱庭諸島』の場合は、純粋にユーザインタフェースのために JavaScript を使っていたが、『Endless Battle』の場合はユーザインタフェース向上の要請というよりはむしろ、「演出的効果」を狙った面が目立つのが特徴である。すなわちどちらかと言うと、「動的な視覚効果」を得るために虚飾的に JavaScript が用いられている気がする。僕自身の主義からすると、JavaScript は基本的には最低限必要なユーザインタフェースのために用いるべきだと思っているが、一方でゲームはエンタティメントのものであるから、「演出効果」のために JavaScript を活用するというのもアリなのかなとも思っている。

結論:Web ゲームの核心的機能

結局のところ Web ゲームというものは、技術論で評価できるものではないと思う。冒頭で述べたように、ゲームの「モノ」としての良し悪しは枝葉末節の二次的な問題に過ぎず、それが閉鎖的クローズドな場ではなく、開放的オープンな場であるという、ストリート・カルチャゆえの利点が、他のコンシューマゲームや会員制のネットワークゲームにない、独自の特性なのである。だから、その特性を活かすか活かさないかにかかっているのではないかと思う。つまり、大胆に言ってしまえば、Web ゲームは、ゲームエンジン自体はオマケに過ぎないのだと。掲示板機能やチャット機能というこの開放的オープンな場ゆえに成立するコミュニケーション機能こそが、Web ゲームの核心的機能であると、ズバリ言い切ってしまっていいような気がする。例えば、キャラクタのカスタマイズ機能も何もかも、そのコミュニケーションの「ダシ」として存在する要素に過ぎないのだ。


<mihr.net>