Project MMO: 2005年10月アーカイブ

　DBD-Pgの組み込みが終わってサーバーサイドの環境はこれで大丈夫だろう。
実際にPerlから利用できるのかソケットサーバーのプログラムを更新した。とりあえずOK。

　次にXML::Parserをどうやって使うのか検索したらCMAGAZINE2000/12に載っていると…。運よくその号のみ持っていた！(当時C言語でメールクライアント作ろうとしていたのでソケット通信プログラムの参考に買った)

　まさかPerlの記事があるなんてずっと気がつかなかった…。その記事を参考にパース部分の設計をまとめて今日は終了。この先はDBに実データいれないとテストできないためクライアント開発の方に移行する事にします。

　それと、アカウント登録用に別プログラムが必要になった。さすがにメインと共用は設計上好ましくないと思ったのでこれだけは分離。但し運用サーバーにApacheは使用しない為こちらもソケットサーバーにして新規アカウント登録専用にします。FLASHクライアントは共通で利用(シーン分けか分割のどちらかで利用)

　残り、マップデータとクライアントのキャラ移動関係を組み込めばチャットアバターの基礎は完了する。11月下旬にはキャラデザも終了する段階まで来ていればいいけどな…。12月はBGMと追加機能のみであまりプレッシャーが掛からないようにしたい予定。

　先週はDBIやXML Parserに関して組み込みを行ったので今日は実際にソケットサーバーから利用してみる予定でしたが、PostgreSQLを利用するにはDBIだけでは足りなかった模様。そこでPgライブラリを組み込んだ。

　Active Perlでppmを使用したときのコマンドは以下の通り。Perl5.8より古い場合はURLが異なります。

ppm> install http://crazyinsomniac.perlmonk.org/perl/ppm/5.8/DBD-Pg.ppd

コマンド結果は続きを読んでください。

　今日も殆ど出来なかった、テーブルの作成とCGIにDBIを宣言しただけ。テーブルの作成にはpgAdminを使ってみたが主キーはどこで設定すればいいのか分からなかった。中途半端にツール使うより直接SQL文を書くほうが楽だな。MySQLと用語が違うところがあり戸惑い。

　仕事が遅くなってしまったので今日はプロジェクトお休み、PostgreSQLとDBIの組み込みは完了したのでDBの設計を行う予定。PCでの実作業ができなくてもZaurusにメモとかでやってみる。

現在必要と分かっているカラムは

ユーザーテーブル：
pid プライマリID(SQL文では不使用) Auto number
uid ユーザーID 文字列(英数)
name ユーザーハンドル名(ゲーム上に表示する名前) 文字列
type キャラクタータイプ 数値
x 現在地x座標 数値
y 現在地y座標 数値
online オンラインどうか 数値

マップテーブル：
pid プライマリID(SQL文では不使用) Auto number
x 座標x 数値
y 座標y 数値
stat 移動の可否 0…OK, 1…NG(他プレイヤー), 2…NG(障害物)

特にマップに関してはロールバックが発生しやすいと思うのでDB使用を前提で考えてみました。
selectで処理しているのでメモリ読み込みのみでも壊れたりしないと思いますが、何れfork版が必要になったときのために設計します。

　本当は目先にある問題(クライアントのバグ)を解決しないといけないのですが、プログラミングをする時間も無かったので電車の中とか、昼食中とかに無駄パケットのフィルタリングについてアルゴリズムを検討していました。

　もちろん、仕様書なしの仕様です。(自分1人だからいいけど)ココに書いておけば忘れても大丈夫だろう。

　サーバー側が1プロセスで動いているselect方式であるため、アルゴリズムとしては理解しやすかった。(私は再帰とかすごく苦手なのでforkだとパニックになってるかもです。)
　因みに処理効率はどちらが良いのかは分からないです。1CPUだと分散してもあまり意味がないようにも思います。

　方法は、パケット送信するクライアントを選択したとき(この時点ではハンドルしか分からない)、サーバー側に保存している位置情報を取り出して今度は送信パケットと解析し、座標が範囲外のものは送信しないようにする。実は単にこれだけ。

　その際にサーバー側でクライアントの状態を取得するためにDBもしくはファイル、保存しないのであればメモリ内だけのDBサーバーを制作する必要がある。あとクライアントをハンドルのみで処理していると、ログインするたびにクライアント数が増えてヤバイ事に気づく。やっぱりID発行しないとダメかな。

　そんなところで今日はDBのインストールで終わり。とりあえずMySQLとPostgreSQLに対応させますが、MSSQLは開発環境があるものの運用時にサーバーと予算が限定されるので移植に向かないと判断。あとすごく興味があるのは、このブログでも使用しているBerkeley DBはファイルベースで移植性も良くてLinux等には標準で搭載されているみたいなのでライブラリがあればこちらも検討。(多分パフォーマンスはあまり期待できないかも)

　チャット機能を搭載したFLASHクライアントにEnterキーによるメッセージの送信ができるようにイベントを追加。チャットのみのアプリではないのでフォーカスに関係なくメッセージ入力と送信を行おうと最初にEnterの処理を追加したところで想定外！

　IMEの漢字決定Enterでメッセージを送信してしまう。

いくらフォーカスに関係なくと言ってもそれはやり過ぎだろう…orz
キーボード入力が在ったらフォーカスをメッセージボックスに移すだけにして、Enterはメッセージボックス内のイベントに設定してみるかな。

　昨日は単純だと言っておきながら、罠にハマった。XML Socketは簡単なのだが、FLASH XMLオブジェクトのメソッド・プロパティが生産性の低いものばかりだった。 orz

　送信用データの作成については、まだ目を瞑るとして、受信データの抽出の仕様には呆れてしまった。
何で上から順番に辿って取得しなきゃいけないんだ？しかも親→子で辿る分は気にしないが、記述順にずっと辿っていくのは情けない。(つまり親子関係の無いタグも辿っていく)折角タグに名前をつけることが出来るのに何故ダイレクトにデータを持って来れないのか。XMLの構造通りにデータ取得ルーチン書くなんてアホすぎ。まだ今日はチャット機能のみなのでまだ綺麗だが、全ての機能を実装した日にはとてつもなく費用対効果のないコードが出来る悪寒。こんな状態では仕様変更時のデバッグもやってられない事態に発展するので、書籍やネット調べました。

　…が、どこも苦労しているようです。裏技でダイレクトアクセスできる方法が載っていましたがMXでは使えなかった(バグ技は保証なしってことです)。ゲームの仕様上、キーボード入力のなデータはチャットメッセージのみでそのほかは全てイベントメッセージなのでデータ用のタグにメッセージを入れ、それ以外のデータはタグの属性に突っ込みました。摂りあえずこれで処理コードの量は1/100位になったと思う。おまけに構造を気にする必要もなくなったので、生産性の低いコードと無駄パケットの嵐の２つを天秤に掛ける必要もなくなった。

　これでMMOチャットは完成。ただキーボードイベントが変だったのでその処理を行って次はマウスイベントの方を実装します。キャラデザとBGMは11月後半かな。それまでにシステムだけは完成させよう。

　予算と時間に余裕があれば11月末にSTUDIO 8を準備してエフェクターの恩恵を受けたいなぁ。

　ソケット通信関係のプログラミングが一段落したので、本日よりプロジェクト開始とします。
今まで語る人も利用例も少ないFLASH XML Socketはかなり難解なものと思っていたら、関数も一桁の数しかないし、思いっきり単純でした。これで直ぐにチャット機能は完成しそうなんで実装して複数接続のテストを行います。

　因みに今回制作するコンテンツの詳細については、仕様を含め全ての詳細が決定しましたが、投稿作品として制作している理由上、作品そのものは発表時まで非公開になります。