過去の挫折具合とゲーム作り

私は基本的に無能人であるから、何か作ろうと思い完成まで持って行けたことはあまりない。何本か書きかけのままで放置されている小説や、ゲームソフト、Webで連載していたはずの漫画、漫画の動画版・・・。DTMの成果物は満足のいくずっと手前だというところ以外は一応完成しているので、マシな方だったりする。しかし、どれをとっても半端物である。

続きを読む "過去の挫折具合とゲーム作り"

コードテスター

　コードを230個ほどMIDIデータにして聞けるようにした。が、個々のファイルをメディアプレーヤで再生すると、いちいち面倒で仕方がない。というわけで、さっさとプログラムを作ってみた。一覧からコードを選ぶとMIDIデータが再生される。気に入ったコードをドラッグで引っ張ると対象の場所にMIDIファイルをドロップしたのと同じ動作になる。フォルダにドロップするとMIDIファイルがコピーされる。下のボタンを押すとサウンドデバイスのプルパティを開くことができる。本当はプログラム内で出力先を選べたらよかったのだが、面倒そうなのでパス。

ダウンロード CodeTester.ZIP (190.6K)

プログラミング

1000文字小説へ投稿した記事の救済。

　どんなソフトウェアも技術者のプログラミングという作業によって制作される。未だに実用的な完全自動のソフトウェア開発というものは存在していない。ソフトウェアの開発とは、どのような作業なのだろうか。

　感覚的には積み木に近い。積み木は、様々な形のブロックを崩れないように積み重ね、最終的にオブジェを完成させる。近代的なプログラミングは、半完成品のソフトウェア部品を組み合わせてソフトウェアとして完成させる。同じである。積み木はブロックを、プログラミングはソフトウェア部品を使うというところだけが違う。積み木を積み始めるまでの手順まで同じだ。その手順は以下のような流れとなる。

　まず、完成したオブジェのイメージを思い描く。プロの積み木屋さんがいたとしたら、たぶん、完成図をきっちりと書くかもしれない。これはプログラミングにおいてソフトウェア設計という作業にあたる。素人ならば行き当たりばったりでもいい。しかし、プロの現場では行き当たりばったりは通用しない。仕様書と呼ばれるソフトウェアの設計図が作成される。

　次に積み木を積み始める。下手な積み方をしたら崩れてしまうことだろう。崩れたら崩れないように積み直す。発生した問題は修正されるべきだ。プログラミングでは問題点をバグという。バグは適当なタイミングで修正されることもあるし、様々な大人の事情で修正されないことも多い。

　積み木が積み上がったら、全体をよく眺めて最終確認を行う。今にも崩れそうな場所があるなら修正した方がいいだろう。もっとカッコよく積める箇所があるなら修正したっていい。プログラミングではソフトウェアのテストという作業にあたるだろう。

　そして、完成する!!

　積み木は遊びながら覚える。遊んでいるうちにいつの間にか複雑なオブジェを作れるようになる。プログラミングも同じだ。

　両者はまるでそっくりだ。しかし、プログラミングは遊べるまでにハードルがいろいろとある。プログラミングの抱える問題の一つは、まさにこの点だ。他に例えば、積み木は"形"のブロックを積み、プログラミングは"機能"のブロックを積むという違いからの難しさもある。

　様々な人々がふとした思いつきで、まるで積み木で遊ぶかのように自由気ままにソフトウェアを開発できたらどうなるだろう。もっとアイデアいっぱいでおもしろいゲームや、カユいところに手が届く実用プログラムが、もっともっと利用できるようにならないだろうか。専門知識がなくてもソフトウェアの開発ができて、それが携帯電話やパソコンの区別なく動作したら・・・。ワクワクしてこないだろうか。

　たぶん、そんな未来が遠からずやってくるだろうと、私は期待している。

軽量アプリケーションの基本部分実装完了

軽量アプリケーションの実装で書いたWebアプリケーションサーバの実装を暇な時にボチボチ作ってみた。とりあえず、基本的なWebサーバの機能とプラグイン方式によるアプリケーションの読み込みの実装が完了した。現在、SLランチャ V2を移植している。多少機能を追加する予定だが、メモリやCPUといったリソースの使用量を比較して個人用Webアプリケーションサーバの実用性を検証してみたい。

軽量アプリケーションの実装

　アプリケーションといえば、ローカルなPCにプログラムとデータをインストールして利用するタイプとWebブラウザを使ってWebサーバ上にあるプログラムとデータを利用するタイプに大まかに分けられる。前者は動作するOSを選ぶが、使いやすく自然なインタフェースや制限が少なく高度な機能を搭載する。後者はWebブラウザさえあればどこからでも利用でき、OSを選ばない。その代わり、HTMLやJavaScriptなどWebブラウザでの表現を超えるインタフェースは実現できず、インターネットを介してデータをやりとりする構造上、様々な制限が存在する。インターネットのトラヒック状況によっては正常に動いてくれないこともある。最近ではRIAやAJAXといった言葉も登場し、両者の中間に位置する形態も登場している。

　RIAやAJAXはWebアプリケーションにつきまとうインタフェースの制限を専用のクライアントアプリケーションやFlashや表現力を強化したJavaScriptなどの技術を用いて取り払う。しかし、多くの場合、アプリケーションの本体はインターネット上に存在している。従来のWebアプリケーションのインタフェースの部分だけをローカルなアプリケーションなどに取り替えたわけだ。

　アプリケーションというのはどのようなものであっても、ユーザの入力を何らかのプログラムに渡し、その結果を再度画面に表示することによって成り立っている。プログラムの本体がどこにあるかは問題ではない。ローカルにあってもインターネット上のサーバにあっても、戻ってくる結果が妥当ならば、アプリケーションとして成り立つ。

　まとめると、インタフェースとプログラム(とデータ)が全部ローカルにあるのが通常のアプリケーション。利点はOSに依存している故の高機能。欠点はOSに依存すること。インタフェースがWebブラウザであり、メインのプログラムがインターネット上にあるのはWebアプリケーション。利点はクライアントを選ばない汎用性。欠点はインタフェースの表現やOSに依存する機能利用の限界、インターネットとの接続が切れたら利用できないなどなど。インタフェースと一部のプログラム(とデータ)がローカルにあり、メインのプログラム(とデータ)がインターネット上にあるのがRIAということだ。利点は通常のアプリケーションとWebアプリケーションのいいとこ取り。欠点は追加のランタイムなどを必要としたり、高機能なWebブラウザを必要とすることか。

　まあ、おおざっぱな分類はこんなものでいいと思う。

　ここでちょっと疑問に思った。インタフェースがWebブラウザであり、メインのプログラム(とデータ)がローカルにあるという形態はなぜないのだろうか。

続きを読む "軽量アプリケーションの実装"

ギャルゲー進捗

　さて、Javaアプリケーション版(ダブルバッファリングのコードが面倒なので、Swingを使用)が完成した。Javaアプリケーションだとキチッとスレッドを使い、キチキチした手順で作成してあげないと正常に動作しないことが判明。やはり、軽量化のためにアプリケーションが想定していない箇所で無限ループをかますのは危険だということか。MIDP版とiαppli版にも、多少サイズが大きくなってしまうが、Javaアプリケーション版の成果を取り込むことにした。まだ作業していないが、10分ぐらいで終わるかな・・・。

　今回の作業でDoCoMo(DoJa)、SoftBank(MIDP)、KDDI(MIDP)の各社携帯電話向けJava実行環境に加えて、WindowsやLinux、Mac、Solaris、FreeBSDといったJavaの実行環境が提供されるGUIを持ったOSすべてで動作するコードが手にはいった。どれでも同じスクリプトを実行可能だ。ただし、DoCoMo版は画像ファイルがGIFかJPEG限定、SoftBankとKDDIのMIDP版はPNGかJPEG限定。Javaアプリケーション版はJPEG/GIF/PNG総対応。画像のフォーマット変換を行いさえすればプラットフォームを選ばないノベルゲームが動くわけだ。JPEGで作っておけば全部対応可能なのだが、JPEGは小さな画像の場合、他のフォーマットに比べて非常にファイルサイズが巨大だ。悩ましいところである。

　Java Web Startでネット配信可能なJavaアプリケーションを作ることも考えたのだが、調べた感じでは何となくうさんくさい。結局、JREを入れてもらって、JARをダブルクリックしてもらうのが一番手軽で、開発者・ユーザ双方の負担も軽いという結論に至った。

シナリオ

作成中のシナリオの作成風景。選択肢の分岐の様子である。

ギャルゲー進捗

　さて、制作していたギャルゲーエンジンSyste=-)だが、DoJa 3.5からDoJa 2.1まで開発キットのヴァージョンを落とした。これによって、505iシリーズ以降の携帯電話でiαppliとして動作可能となった。同時にMIDPへの移植を完了。これによって、auの携帯電話で動作するオープンアプリとSoftBankの携帯電話で動作するS! Appliで動作が可能となった。DoCoMoはエミュレータと実機で動作検証を行い問題なく動作することを確認した。auはオープンアプリのエミュレータも実機もなかったため未検証。SoftBankはS! Appli MEXAのエミュレータで動作することを確認した。次の移植プラットフォームはパソコンである。Windowsに移植するのは赤子の手をひねる級の作業なのだが・・・。できるだけ動作プラットフォームを増やしたい。Javaアプリケーションで作成すればいいのだろうが、Javaのランタイムはもはや一般的とは言い難い。最近目にするAdobe AIRも時期尚早な感じ。ここはFlashで作るがいいのかもしれないが、デスクトップアプリケーションという訳ではない。Flashで作っておけば、AIRに路線変更はきわめてたやすい。しかし、やはりAIRはRIA(Rich Internet Applications)であることを前提としているので、微妙なことに変わりない。悩むところだ。MacとLinuxを無視してWindows開発だけで済ませるという選択肢もあるが、Linuxは兎も角Macがユーザが増えてるらしいから無視するのは惜しい。さてさて・・・。

　ゲームの内容部分はネチネチ作成中。

ギャルゲー進捗と・・・

　さて、いろいろ調整した結果、Release 1.2系列の最終的なクラスファイルサイズの合計は5859バイトとなった。なかなか小さいのではなかろうか。もっと小さくすることは可能だが、これ以上の軽量化を行うためには後々のメンテナンス性を犠牲にしなければならない。現在でもギリギリのところなので、これ以上の無理はしない予定。

　もっとも、初代のiアプリ対応DoCoMo携帯ではとてもじゃないが動かない。プログラムだけはロードできるだろうが、ゲームのデータを載せると制限サイズの10キロバイトを超えてしまうだろう。しかし、ターゲットとしているDoJa 4.0対応の携帯電話で、プログラムがこれだけのサイズならば多少大きな画像やデータのゲームを乗せても問題ないと思う。

　これで心置きなくゲームの本体に注力できるってもんだ。ストーリー部分は日々少しずつ追加中。絵はデータ量も作業量も多いので白黒のイラストをここぞというイベントとエンディングに一枚ずつぐらい予定。

続きを読む "ギャルゲー進捗と・・・"

ギャルゲー進捗

System=-) Release 1.2.2完成。細かいバグ修正とスクリプト仕様の変更、最低限のエラー処理の実装を実施。これで完成かな。現在、ストーリーの実装を行いながら実機での動作確認を実施中。よくわからないタイミングでNullPointerExceptionが発生していたが、これはpaint()が非同期にこちらの制御できないタイミングで呼ばれていたのが原因だった。まあ、よくあるパターンだ。

ギャルゲー進捗

　前回実装予定だった機能を昨晩すべて実装。これでSystem=-) Release 1.1が完成である。クラスファイルの合計サイズは6689バイト。圧縮後のJARファイルのサイズは3466バイト。もう少し、調整を行ってダイエットできるようならダイエットする。スクリプトの文法チェックなどのエラー処理は実装していない。スクリプトやプログラム内ではエラーが発生しないことを確認してからリリースを行うというのを前提にしている。ソフトウェア的には非常によろしくないのだが、デバッグを統合開発環境下でしっかり行うことで小規模のゲームなら(そして、仕様上の制限から小規模の開発しかあり得ない)何とでもなると思う。

追加。行末禁則処理を追加。"。"や"、"などが行頭にこないように制御を入れた。文字サイズを大きくしたり、Release 1.1で発見したバグの修正も含み、最終的にはクラスファイルの合計サイズが6662バイト。

ギャルゲー進捗

　FOMA向けギャルゲーエンジンSystem=-)だが、Release 1.0の開発を完了。可読性を損なわない程度に各種ダイエットを施し、コンパイル後のクラスサイズが全部あわせて5361バイト。JARに固めて3449バイトとなった。無理すればもっと小さくできるが、メンテナンスなどのことを考えれば、ほどほどに、である。これにゲームデータの容量が加算されたものが最終的なダウンロードサイズとなる。Release 1.0の機能は以下の通り。

• 画像表示: 画像を任意の座標に表示する。座標位置だけを更新することによって簡易のアニメーションを実現可能。アニメーションの間隔は「フレーム間の休眠時間指定」に依存する。
• 文字表示: 文字を一文字ずつ順次表示していく。文字スキップに対応。文字の開始位置の指定が可能。画面右端での自動折り返しが可能。折り返しの位置は設定可能。段落間の距離を指定可能。
• フレーム間の休眠時間指定: フレーム間の休眠時間をミリ秒単位で指定可能。
• 待機: フレーム数指定の時間待機とセレクトキー押下の待機に対応。
• 選択肢分岐: 文字キーで複数個の選択肢を選択する処理に対応。処理後はスクリプトが指定したものに切り替わる。
• スクリプトの切り替え: スクリプトを別のものに差し替えられる。

　Release 1.0で未対応ながら、Release 1.1として対応予定の機能は以下の通り。

• 変数操作: 整数変数の四則演算
• セーブ・ロード: ゲームデータのセーブとロード、ゲームの一時中断と復帰
• ジャンプ: 相対行ジャンプ、変数と組み合わせた条件ジャンプ

　ここまで実装できたら必要なものは揃う。クラスファイルのサイズは10キロバイトまでを予定。Release 2.0は不必要かもしれない。

　携帯電話アプリで一番大きな問題は絵だったりする。描ける描けないという問題ではなく、データサイズの問題。絵はプログラムの実行コードサイズなど目じゃないぐらい巨大なデータなのだ。240x240のJPEG画像で50キロバイトを超える。小さなアイコンでも10キロバイトだ。携帯電話アプリのごく初期の機種ではプログラムとデータ併せてZIP圧縮して10キロバイトまでという制限があった。いまでは1000キロバイトぐらいまでは許容してくれるが、それでも大きなデータはダウンロード時にお金がかかるため、小さければ小さいほどいい。

ギャルゲー進捗

　最近ギャルゲーがやりたくて仕方がないのだが、ギャルゲーのみならず、エロゲーにまで範囲を広げてもイマイチやりたいゲームが見つからない。

　とうわけで、製造してみることにした。iアプリというDoCoMoのFoma向けのソフトウェアとして開発している。現在プログラムの進捗は50%。後はスクリプトの切り替えと、選択肢の処理を作れば最低限の機能が実装できたことになる。まあ、やっぱり、セーブ機能とか音を出す機能は最終的には作らないとだめかな。

　絵は例によって後回し。ストーリーはちょっと作成。短いエピソードを10個ぐらいこなして終了ぐらいの小物を予定している。ストーリーのコンセプトは、ルームメイトの女性とその弟の間で揺れる心・・・。無論、主人公は女性。ヘヘヘ・・・。自分でこんなゲーム遊びたいなぁ、というのを考えてみたらこうなった。

　とりあえず、プログラムはサイズを考慮せずに可読性・メンテナンス性優先で実装。後でダイエットする。ダイエットの目標はプログラム本体を8KBぐらいまでに押さえること。プログラムが小さければ小さいほどゲームに使うデータをたくさん持つことができる。携帯電話ならではの世界である。これがまた楽しいのだが・・・。MIDP1.1に移植して他のキャリアでも実行できるようにもしたい。ちなみに、これは簡単だったりする。

DoJaで「サポートされていないエンコーディングです」

　iアプリのソフトウェア開発ツールであるDoJa 4.xや5.xで開発を行い、コンパイルを行うと「エラー:サポートされていないエンコーディングです: SJIS_i」というエラーが発生することがある。これは何かといえば、システムがDoJaの正式にサポートしていないJDKを使っていることに起因する。本日時点のJDKの最新版はJDK 6 Update7である。これを使いたい気持ちはわかるのだが、例えばDoJa 4.1指定のJDKは1.4.2である。これ以外では正常に動作しないということだ。しかし、DoJa開発を行っていないときは最新版のJDKを使いたい。古いヴァージョンを使う危険性もある。よって、6をアンインストールするのは気に入らない。ならばどうするか。JDKはきわめてシンプルなコマンドツール群で構成されている。よって、以下のようにコマンドプロンプトからプログラムパスを切り直せばいいのだ。

set JAVA_HOME=C:\j2sdk1.4.2_18
set CLASSPATH=.\;
set PATH=%JAVA_HOME%\bin;%PATH%

　その後、同じコマンドプロンプトからeclipseやiαppliToolの実行ファイルを直接起動すれば正常にコンパイルとエミュレータでの実行が可能となる。コマンドプロンプトの外はシステムに設定されているJDKが支配する世界なので何の問題もないのだ。

　多くのサイトでこの問題の解決策として、「sun.tools.javac.Mainを使用する」オプションを使えば動くとあるが、コンパイル時に「注: sun.tools.javac.Main は推奨されません。」という警告が出るはずだ。プロのソフトウェア開発者でなくても、警告はエラーと考えるべきだ。警告が出ているのは、ソフトウェアの問題点になり得るかもしれない場所だ。問題の元となるかもしれない場所をわざわざ残したままにして無視するというのは、ソフトウェア開発者としてあってはならない。修正できるものならば、修正しよう。

漫画は平日午前更新

　この一週間、人型漫画を携帯電話の創作漫画の配信サービスマンガ★ゲットに投稿してきた。このサイトはベータ試験中だ。しかし、今後、ますます携帯電話でのインターネット利用が増えるらしいので、携帯電話にも拠点を持っておこうと登録してみた。SNS機能もついているので、ちょうどいい。

　で、登録してからすぐに人型漫画のオリジナルシリーズとうぇぶシリーズを毎日一つずつアップロードしていった。今日、手持ちの分を全部アップロードし終えたのだが、アクセス数をみていると土日になってからの伸びがまったくない。なるほど、携帯電話で漫画というのは通勤や通学の暇つぶしなんだろう。当然ながら、休日は家で別の娯楽を楽しむか、人と出かけるか・・・。そういう状態では、暇つぶしをする時間は減る。次回、うぇぶシリーズの作成後は平日の午前などのアクセス増加を望める時間帯に公開してみようと画策中。

　SNSの方はあんまり活気がないなぁ、といった感じ。正式にサービスインしたら賑やかになるのかもしれない。

　ちなみに、携帯電話アプリケーションの配信サイトであるアプリ★ゲットと同じ会社の運営だ。一時期、ここからライフゲームを配信していたのだが、ちょっと飽きてきたので放っておいたら、いつの間にか買収劇が繰り広げられたらしく、結果、アカウントが消えていた。もっと一般ウケするのを作って再登録してみるのもいいかもなぁ・・・。Javaだったら寝ててもコーディングできるし。まあ、優先順位では個人作成のシューティングゲームが上か。私以外のメンバーがまったく活動をしていないという段階で、別に好んでやりたいわけでもないゲームを完成させることに意味があるのか多少疑問を感じる今日この頃ではある。私の受け持ちであったゲーム本体の実装という目的のレベルには達してしまっている。これ以上、関わってもステップアップはない。設計やソースだけ引き継いで別のゲームでもいいんじゃないか、とか。まあ、楽器の練習とかで時間がとられて、開発は予定より遅れ気味。

続3・ゲームのサンプル実装を作成中

というわけで、続行中。ステージ1の敵の攻撃パターンを作成している。ステージ1は「手毬歌」という感じで作っている。まあ、基本的なところはできたのでアレンジを・・・。毬っていうぐらいだから跳ね返らないとな。もう少し弾を減らして、画面枠で反射するようにしていこう。反射機能は実装済み。敵のライフを全部削ると次へ、というよくあるパターンはやめて敵と味方どちらも10発当てたら次へという設計にしようと思っている。正直、すでに自分で作っておきながらクリアできない(汗)。

続2・ゲームのサンプル実装を作成中

ストーリー部分の画面はこんな感じに・・・。文字送りとかの演出は未実装。

続・ゲームのサンプル実装を作成中

ステージ1のストーリーと基本的なプログラム部分が完成。ソースへの修正は今のところ大規模なものは発生していない。とりあえず、音楽と絵は後回し。音楽は、もうね、自動作曲機能で無理矢理作る。絵は過去に作った同人誌でがんばった限界を踏まえつつ、何とかでっち上げる。ゲームはステージごとにオープニングとエンディングとして、それぞれ一画面程度の物語が挿入される。サークルでずっと以前に議論した内容では、シューティングゲームとしてはテンポや集中力を損なうということで、物語が入るとかはアウトらしいのだが・・・。まあ、シューティングゲームに特別こだわりがない私としては、こういうのもいいかな、と。テーマは夏に向けてってことで、怪談だ。リリースは一ステージごとに製造を終えて、その都度行う予定。リプレイなどの必須機能も順次リリースを繰り返しながら実装していこうと思っている。General Public License version 3.0でソースコードは公開予定。今回こそはリリースするぞー。

ちなみに、キャラクターのベースは美樹とうらはのペアに出張ってもらう予定。

ゲームのサンプル実装を作成中

シューティングゲーム制作サークルの方で作成したシステムを流用し、実際に小粒なシューティングゲームを一本製造してみることにした。できるだけ絵や音楽まで実装することも視野に入れて製造中。この製造過程で判明するであろう改善点は随時修正し、本体ソースにフィードバックする。実際に作ってみないとわからないこともあるだろう。ゲームは全3ステージ構成。ボス戦オンリー。ワンプレイ五分、長くて十分程度を見込んでいる。現在の進捗率は、たぶん10%程度。普段はシューティングゲームで遊ばないので、慣れていない人でもクリアできるようなものになると思われる。湖畔の家は目標を見失いつつあるので、とりあえず凍結。

ソフトの設計や実装をする人が私以外にいたら、実装過程に出る問題について意見を出し合って改善できるのだが・・・。たまに思い出したように作業をする人と、今のところ全く成果を出せてないどころか本当に何か貢献する気があるのかすら怪しくなってきた人と、私だけではソースについての議論など無理。開発中に有用で再利用可能な部分のソースをライブラリとしてスピンオフすることも当初は考えていたのだが・・・。このところサークルからソースを切り離してSourceForge.JPにでも引っ越して・・・なんて考えていたりもした。今月末ぐらいを目処にソースの整理をしていたところ、MLに反応があったので切り捨ては延期になっていたりする。

湖畔の家の改造計画

湖畔の家に3D処理を追加するべく、いろいろと試しているがなかなかに難しい。Quaternion関連クラスは何とか使えるようになってきた。ベクトルや力学の勉強もそれなりに進んでいると思う。しかし、それらの知識を利用し、スキーとかスケボーとかそういう感じの動きを実現できるようなコードを作成しようと思っても、上手に実装できない。難しいものである。今まで物理現象やそれに似た処理を実装することを想定していなかったので、何となくとっかかりで躓いてしまっている感じだ。

湖畔の家、大幅改造計画中

以前から少しずつ作成していた湖畔の家という謎ゲームだが、もう少し謎展開を追加するべく、改造に着手。ついに避けて通っていた3Dゲームへの道を歩むことにした。というわけで、3Dモデルの上にキャラクターを乗せるという一番の難関をクリアするべくテストコードを作成している。今回のテストコードは単にキャラクターをモデルの上に乗せるだけでなく、自由落下やジャンプなどその他3Dレースゲームっぽい物理法則の最低限それっぽく見える実装までを視野に入れてみることにした。ここ二週間ぐらい高校物理の力学を復習したので、何とか作れそうな気分になってきたのだ。例えば加速して斜面でジャンプして・・・とか、U字型の地形で宙返りとか・・・。もはや何のゲームが作りたいかわからなくなってきたけど、なんでもいいかな。湖畔の家は釣りゲームだから、釣り場探しとかをアクション性のある3Dフィールドでやってもいいのではないかというわけだ。釣り場に着いてから、今まで作ってたまま2Dの反射神経系ゲームになるってのもアレだが。まあ、気の向くまま進んでいく予定。湖畔の家に組み込む前のテストコードは満足のいくテストが完了したら公開。

部品によるゲームキャラクターの修飾

　さて、ゲーム制作サークル雅弾会だが、サーバ停止による開発環境の変化から、ようやく復帰。HamachiでVPNを構築し、Windowsのファイル共有機能を使ってネットワークドライブを作成し、Subversionと組み合わせてソースや資料のヴァージョン管理を行うようにした。結構使い勝手よく動いてくれているのではないだろうか。

　で、その間にもゲームのシステム面の開発は継続していた。我々が制作しているのは段幕シューティングなのだが、細かいソフトウェア部品を組み合わせ、複雑な動きを実現可能にする実装を行っている。デザインパターンのデコレータパターンを流用しているわけだが、部品の充実を図れば、楽しく遊べそうな感じになってきた。システム面はこのまま進めばなんとかなりそうな感じなのだが、ゲームのデザインが遅れている。

　今まではゲームのデザインにプログラムがあわせるというアプローチをとっていた。この場合、ゲームのデザインによってはプログラムの見直しやある特定の挙動のためだけに面倒なプログラムの作成が発生する。要件があって、それを満たすための仕様を作り、プログラミングをするというのは当たり前なのだが、今回の開発においてはプログラミングが常に先行している。そこで、現状のプログラムで実現可能なデザインを行ってもらって、プログラムの修正・作成作業を最低限に抑えようというアプローチを考えてみたのだ。そのための資料作成を行っているが、もし、このアプローチがうまくいけば開発速度が向上する・・・といいなぁ・・・。

　ゲームとしての演出面ではHLSLの調査を行ってもらっているが、こっちの作業者の応答がきわめて悪く、というか、無くなってしまっている。進捗がまったく把握できていない。どうなっているのだろうか。

　

イラストと音楽は相変わらず後回しだ。

LinuxとWindows分離完了

　さて、Windows側のソフト整備なども完了して、いよいよWindowsはゲームとゲーム開発、Photoshop、DTMだけの環境となった。Linux側も日常的な作業をすべて行える状態だ。CDやDVDも焼けるし、デュアルディスプレイもOK、WebもメールもメッセもIRCもOKだ。辞書ソフトもJava開発もオフィスアプリも録画したテレビも映画やアニメのDVDも見られる。DTMや画像編集もPhotoshopほどではないが、OK。できないのはDirectXゲームだけだ。無料で手に入れることができる仮想PCソフトがDirectXに対応してくれると非常に助かるのだが・・・。

　湖畔の家はXNAを捨てて、Javaで再実装することにした。試しにUMLモデリングツールで作ってみている。環境依存部分を切り出して作成し今後の方向転換に対して柔軟な対応が出きるように設計中。この辺をしっかりとデザインしておけば他の環境や言語に移植する作業が楽になる。

　ゲーム製作サークルの雅弾会は基盤となるサーバを失ったので、代替手段を実験中。実験が成功したら再びソースコードのヴァージョン管理とWikiが使えるようになるだろう。

　ディスクの割り振りはgpartedで調整しながら色々と試した結果、全体が100GBのHDDをWindowsに65GB(残30GB)、Linuxのシステム領域に12GB(残8GB)、Linuxのユーザデータに20GB(残6GB)、Linuxのスワップに2GBに切り分けることになった(全部、おおよその値)。フルボイスのギャルゲー/エロゲー用にWindowsの空き領域を多めに確保。Linuxのユーザデータ領域が不足した場合は、gpartedでパーティションを切り直してLinuxのシステム領域から充当する。

　来週頭ぐらいからマビノギに復帰できそうだ。でもWindows起動したくないなぁ・・・。

AIRはダサい!?

　自作ゲームは迷走中・・・で書いたAdobe AIRだがJavaというよりはJavaScriptっぽい。そして・・・なんだかダサい。新しい言語にしては、何となくイケてない。実用かつ実戦に堪えるプログラム言語としてはやっぱりJava(5.0以降)かC#がいいのかなぁ・・・。しかし、JavaもC#もオブジェクト指向的理想とは遠い。オブジェクト指向的理想というのならば、RubyやSmalltalkとか?両方を同時には満たせないというのが、私の思うところなのでどこかで妥協が必要だ。AIRで作るならJavaアプリケーションで作っても・・・。AIRのサポートするマルチメディアのサポートがJavaにあったらなぁ・・・。

湖畔の家・ベータ版 バグ情報

mixiの方でゆーじからバグ情報が入った。

まず、第一報。「エラーが出て立ち上がらない」との書き込みがあった。ランタイムの欠落だと思い、Microsoft .NET Framework Version 2.0 再頒布可能パッケージ (x86)とMicrosoft XNA Framework Redistributable 2.0のインストールを行ってくれるように提案。しかし、それらのインストール後に別のエラーが発生したという「 入れたら違うエラーが出てマイクロソフトにエラー送信する？見たいなのがでた・・・。」という書き込みが。ゆーじのPCはXPだったはずなので、ここで私は日本語フォルダ名が原因でSQLiteが誤動作しているのではないかと推測した。湖畔の家はXNAベースのゲームである。XNAはセーブデータを、XPではユーザの「マイドキュメント」 フォルダ以下、Vistaでは「ドキュメント」フォルダ以下に保存する。Vistaではエクスプローラからは日本語に見えるのだが、プログラムからは英語でDocumentsとして取得される。XPではそのまま日本語フォルダ名である。推測だけでは、原因はこれしか考えられなかった。
しかし、実機で調査していると原因はそうではないことが判明した。
私手持ちのXPマシンでもゆーじが遭遇したと思われる現象を再現できたのだが、開発キットを入れたとたん動作する状態になってしまった。ということは、この問題に関して、私の作ったプログラムが原因ではないということになる。詳しく調べてみたところ、どうやら、XNA 2.0ベースのゲームの動作には以下の三つが必要らしいことが判明。

• Microsoft .NET Framework Version 2.0 再頒布可能パッケージ (x86)
  
• DirectX End-User Runtimes (November 2007) - 日本語
  
• Microsoft XNA Framework Redistributable 2.0

前回の記事と変わっている点はDirectX End-User Runtimes (November 2007) - 日本語が追加されたことだ。ゆーじの環境で発生した問題は(推測だが)DirectXが最新ではなかったために発生したのではないか。開発キットのインストールで私のXPにDirectXの新しいファイルが導入された可能性は十分にある。これで動作しなかったら次はエラーログを回収する仕組みを組み込んだベータ版を提供するしかない・・・。ちょっと面倒なのでDirectXの更新で動いてくれたらいいなぁ・・・。
DirectXのインストーラは適当な場所を指定してそこにファイルを展開した後、DXSETUP.EXEを実行することでインストールを開始する。この辺もきわめて不親切。
ちなみにDriectXはWindowsUpdate経由やゲームのインストール時にインストールされるケースが大半である。が、同じDirectX 9.0cでも実はその内容が違っている。開発者の間では知られているのだが、DirectXの開発キットは二ヶ月に一度更新される。と、同時にDirectXの実行環境も同じペースで更新されている。しかし、この更新はWindowsUpdateから提供されていないのだ。これは非常に開発者泣かせである・・・。ManagedDirectX 1.1の時もまったく同じ問題に悩まされてきた。XNAになってランタイムをサクッと入れたら動作するようになってくれたものとばかり思っていたのだが、私はM$を未だに過大評価していたようだ。XNAが重要な企業戦略の一環であるならばXNAゲームを確実に動作させるためにM$はDirectXの更新をWindowsUpdateで提供するべきである。XNAが重要でないプロジェクトだというならば、C#からDirectXアプリを開発する確実な手段を開発者に提供するべきだ。わざわざXNAを選んでやっているのに、馬鹿にするな。

追加調査
XNA 2.0はどうやらC:WindowsSystem32d3dx9_31.dllがないと動作しない模様。

追加調査2, 3
三つのランタイムを入れていても、DirectXのd3dx9???.dllがそろっていても、XPだとまだ動かないらしい。 システムログを出力して調査する機能を追加したヴァージョンを公開。実行後、いつまでたっても起動してこなかったらエラーが出ている。その場合、実行ファイルと同じ場所にerror.logというファイルができるのでその中身を教えてほしい。

(危険物指定になったので公開停止)

ラグナロクがPerlの起動を制限

　ラグナロククライアントがPerlの実行を制限するというニュースが流れた。一見意味不明だが、多くのBOTのプログラムがPerlを使っていることに対する対応策らしい。しかし、この対策、すぐに意味が無くなるような気がする。Perlを他の言語に置き換えるのはたやすい。おそらくBOTで必要なPerlの機能はごく一部。バリバリのオブジェクト指向とか使わないだろう。上から下へ素直に流れて、フラグを操作しつつ、if文が並んでいる的なコードではないだろうか。もしそうなら、Perlから他の処理系へコードを変換するのは一瞬だ。自動変換すら可能かもしれない。ところで、Perlのスクリプトが実行中であるという判断を行う手法はどうなっているのだろう。プロセスの一覧からPerlインタプリタの実行を検索するのが一番簡単だが、これではPerlインタプリタの名前を変更されたら一発で回避されてしまう。乱数使って名前を毎回変えたり・・・各プロセス空間のメモリダンプをとって、その内容を検証するか?これはチェックにかなりの時間を必要とするだろう。それにPerlのソースをいじって何も実行しないような命令を追加したりすれば、バイナリがメモリに展開された場合の特徴を変更できる。そうでなくても、ソースが公開されているPerlインタプリタならばあらゆる修正が可能である。ラグナロククライアントと同じPCでPerlスクリプトが動いている場合には実行の制限は一時的には有効かもしれない。しかし、サーバ・クライアント型のBOTを用意すればまったくクライアントでは検知できないに違いない。おまけに別に二台パソコンを用意する必要もない。PC仮想化製品はWindowsで動作する有名なソフトが三つある。ラグナロクサーバのふりをしてラグナロククライアントをだましたり、プロキシのような動作を行うBOTクライアントならばシステム的な対策ではいかんともしがたいのではないか。こんな手法で駆除できるのはスクリプトを拾ってきて実行するのがやっとの無知な層だけだろう。
それではどうすればいいのだろうか。ゲーム内での取り締まりを強化して、徹底的にBOTのアカウントを特定・廃止させるのが、人件費はかかるが近道かもしれない。ユーザからの通報を常時監視して、全サーバ取り締まり目的に必要人数の人間を待機させる。ユーザからの通報でBOTを追跡して、切断・アカウントの停止を繰り返す。はっきり言って、かなり金がかかりそうだ。しかし、ネットワークサーバを管理して、サービスを提供している会社である。サービスの提供を停止することなく行ってこそ、ネットワーク商売というものだ。ガンホーは少々ネットワーク商売をなめているのではなかろうか。私が思うに現状のサービス料金でサービスの質を改善する手間賃が出ないならば、多少上げても仕方がないのではないだろうか。不正行為を行う者のせいでゲームにならないようなゲームでは、ゲームを遊んでもらうという行為すら成り立たなくなってしまう。とにかく、誠意のある対策をお願いしたい。