前回の続きです。
どうも、のほほんとWin32 + Strawberry Perl環境で試した所為か、前回のスクリプトでアクションキャッシュが初回生成出来ない場合があることに気が付きました。
また、/css/*.cssなどのファイルを読めていないことも気が付きました。
さらに、$c->uri_forの問題もまだ追えていません。
なんだかもうちょっとArkの中身を見る必要がありそうですが、ともあれ、CGIで試すときの気をつける点などを合わせてどうぞ。
データをデータベースに格納しようとすると、主キーたるID（識別子）の仕組みを決めなければなりません。データを一意に識別するための道具ですね。
その場限りの仕組みならば、例えばScalar::Util::refaddrでメモリの番地を使う策も十分巧く回ります。しかし永続データとしてセッションを跨いで使用する場合には、UUID(GUID)をData::UUID辺りで見繕うか、或いはいわゆる「背番号」を付けるか、名前で一意に識別できるのならばそれを使うであるとか、色々な選択肢を採らざるを得ません。
これが業務でやっているようなシステムであれば、それはいわゆる「決めの問題」であるので、詳細要件で合意を得られれば完了です。
ところがこういう趣味の世界でファンが勝手に外野で作るようなシステムだと、勝手に決めてしまって良い物かどうか、いつも悩みます。
取り敢えずWorld（ゲームサーバー（群））であれば、FFXIの場合は00 : Bahamut, 01 : Shiva, ...といった具合に分かるので、それを使えばよいのです。
では逆にItem（装備とアイテム）では？ 名前が被ることは容易に想像出来るので、やはりIntなIDにしたいところです。しかし勝手なID（オレオレID）を付けたとすると、例えば外部データサイトとの連携をしたい場合に、外部データサイトA用のIDをデータとして持つとか、或いはオレオレIDと外部データサイトのIDとの変換テーブルを持つとか、そういった面倒なことになってしまいます。
EQであればクライアントに落ちてくるゲーム内部データを解析してデータサイトを構築・運営したサイトをいくらでも知っています。例えばAllakhazamです。内部IDはつまり公式なIDであるので、オレオレIDを作らなくて済むので、是非ともこれを採用したいところです。
さて、AllakhazamはFFXIにもありますしFFXIVもできそうですが、このFFXIのアイテムIDが内部データ由来の物なのかそうでないのかが分かりません。もしご存じの方がいらっしゃったら教えていただけると嬉しいです。
というようなことを考えると、予習の意味でFFXIを始めた方が良いのかも知れませんね。MMORPGに共通して必要になりそうなシステムは作れますし、実際に私の8年くらい昔のシステムを現代的に書き直している部分が少なからずありますが、やはり各ゲーム固有の要検討項目というものは出て来るわけですので。
最近のコメント