日記/2016-08-30

アイテムの一覧について†

あちこち調べて、一覧的な情報を見つけたので、それを元に csvファイル形式で作成。
必要な情報は、「アイテム名」「アイテムID」と「価格」。
アイテムには解説類や重量といった情報もありますが、それはサポートしない方向で。
つーか、それこそそんな「大量」の情報を扱いたくないです。

アイテムの価格情報、なにを基準にするか†

ROのアイテムには、実は大きく以下の3種類があります。

1. 普通のアイテム。
   「NPCからの購入価格」と「NPCへの売却価格」の両方が定義できる。
2. 販売の無いアイテム。
   「NPCへの売却価格」だけがある。
   
3. 販売禁止アイテム。 「NPCへの売却価格」がない。 当初「購入価格」基準で考えていたら、それが存在しないアイテムがあったので、どうしよう、となってるという話。

今回の意図は「NPCへの売却時にどれくらいになるか」っていう情報なんですね。
現地での重量オーバー時の破棄条件とか、ちょっとしたPTでの金銭清算のため。

# いまさら『代理購入』なんて商売は成り立たないですし。

そーすると、NPC売却価格基準でやっていいんじゃないかな、なんて考えてます。
まあその場合も「ない」ケースはあるんですが。

アイテム価格の調査・csvへの設定方法†

力技・人力でやることも考えたのですが、さすがに種類が万のオーダーなので、気乗りせず。
既存の Webサービスをうまく使おうと考えています。

候補は、Roween というサイト。
こちらでは アイテムのIDに基づいて Webページが作成されているので。

アプリでアイテム名からIDを引いて、必要なURLを構築して http通信してダウンロード。
取得したhtmlを解析して、価格情報を取り出す・・・という感じのことを考えています。 Roweenサーバに負荷をかけるわけにはいかないので、アクセス速度とかキャッシュとか、配慮は必要。
また、アイテム名⇔アイテムID の変換はアプリ責務なので、新しいアイテムが手に入ったときにはデータは別途追加が必要です。
そういうケースも含めて、友瀬側からもデータテーブル（含む価格）の提供メカニズムは必要そう。

アイテム名抽出について†

いろんなやり方がありますが、アイテム取得時にでる以下のようなメッセージを基準に判定しようと思います。

赤ポーション 1 個獲得

ただ、上記のような「簡単な」アイテムはいいのですが。
装備品の類は結構めんどくさいので、どこまでやろうか検討中。
めんどくさい理由は、以下のような様々なバリエーションが予想されるから。

• 『アイス ファルシオン [3] 1 個獲得』
  • 取得したいのは『ファルシオン [3]』。
    『アイス』はいらない。
  • 一応『スペースで区切られた文節』という解析基準はあるので、それは助かる。
    『アイスファルシオン（いわゆる宝剣）』と『アイス ファルシオン（マリナc刺しのファルシオン）』とは区別できる。
• 『ブラディウムブローチ オブ アンダー ア キャスト [1] 1個獲得』
  • 取得したいのは『ブラディウムブローチ [1]』。
    『オブ アンダー ア キャスト』はいらない。
    接尾文字列が『オブ』『アンダー』『ア』『キャスト』という複数文節になっている点に注意。
• 『+10 ダブル ブラッディ コンポジットボウ オブ バーサーカー ダブル [4] 1個獲得』
  • 取得したいのは『コンポジットボウ [4]』。
    上述の２つのパターンの復号で、わりと最悪のケース（笑）。
    
    • 接頭語も接尾語も、複数文節になりうるということ。
• 『エクスキャリバー <DEX+7> <DEX+5> [3] 1個獲得』。
  
  • エンチャント類ですね。これも削除対象。
    この場合のポイントは、<xxx> という書式で削除していいということ。
• 『回復の光 <int+1> 1個獲得』
  • スロット情報がないアイテムもあります。

つまり。アイテム文字列のデータ構造は
『（可変長接頭文字列 0〜任意数）（名称本体）（可変長接尾文字列 0〜任意数）（有無不明のスロット情報）』
・・・となっていることがわかります。

前述の通り、各文節はスペースで区切られているので、それなりに解析しやすい条件ではありますが。
接頭・接尾とも可変個数であるため、機械的な処理ではできません。
正規表現で削るしかなさそうですが、そーすると問題は、そのパターンが極端に多いってことですね。
極端な話、カードの種類と同じだけパターンが必要なわけで、消去パターン作るのが面倒（笑）
あと、それだけ条件が多いと、性能面がちょっと不安。

また、調べきれていないのですが、「アイテム名と合致する接頭・接尾後」がないかも心配。

チャット文字列の改行問題†

テストしていたログを見ていて気づいたのですが、たまにこんなログもあるんですよ。

ブラディウムブローチ オブ アンダー ア キャスト [1] 1個獲

得

わかりますかね。行が長くなりすぎて、途中で改行しちゃうケース。
この場合『xxx n 個獲得』というパターンを外れてしまうので、うまく検出できない。
次の行を先読みマージするっていうやり方もありますが、それはそれで副作用生みそうだし。
どうするか検討中。

ただ、これは普通のアイテムではなく『いろいろ付与された長い名前』でおきやすい現象。
今回の趣旨の『NPC売りしたらいくらか』というケースを前提にすると、 こういう『いろいろ付与された』モノを対象にするとは思えない。
そういう意味で、何もせずに結果的に無視、というのもアリかもしれない。

さらに、チャット窓の幅を狭く設定している場合におきやすい。
これも使用条件として明示しておく必要はあるだろう。

ちなみに、この改行問題にはもうちょっと別のパターンもある。
極端に書くとこんなケース。

ブラディウムブローチ オブ アンダー ア

キャスト [1] 1個獲得

この場合「2行目」が問題。
まるで『キャスト [1]』というアイテムを取得したかのように見える。
このケースはたぶん打開しようがないので、
『アイテムっぽくて切り出したけど、そんな名前ないから無視』というスタンスで考えている。

xxxxxxxブラディウム

ブローチ [1] 1個獲得

とかいうケースもあるだろうけど、そこまでは面倒見れない（笑）

処理フローまわり。†

今回想定している処理フローは、以下のような流れです。

• RO クライアント上で /savechat する。
• アプリがチャットテキストを読取、解析。アイテム名を抽出。
• アプリ内部処理、抽出したアイテムを知っているか？
  • ここで「知らない」なら、前述の「変な改行」問題もあるので、あきらめる方針。
• アプリ内部処理、抽出したアイテムの価格情報を知っているか。
  • ここで「知っている」なら、難しいことは何も無い。
• 知らなかった場合、Roweenに問い合わせして情報取得を試みる。
  • ここで非同期動作になるのが１つの課題。
    取得処理をしている最中に『次の savechat』がきたらどうする？
  • Roweenとの通信に失敗する可能性もある。
    とはいえ、これはあきらめればいいか。
  • ともあれ非同期通信中にユーザ放置するわけにはいかないので、 アプリとしては「調査中」表示して待機状態にするのが妥当か。
• Roweenからのhtml取得成功したら、その内容の解析開始。
  解析完了したら、その値を「保存してあるアイテムリストcsv」と「現在のチャット表示」とに反映。

・・・こんな感じ？

ただ、Roween通信を考えると上述の通り非同期処理とか面倒な話が出てくるので、正直やりたくない。
Roween のhtml書式変更だってありうる話ですし。
なので、それはやらずに済ます方針も考えています。
具体的には、Roweenとの通信は『友瀬の開発環境で実施』して。
リリースするアプリには『価格情報が全部載った csv』を同梱して、Roween通信しない、というやり方。
先々のアイテム追加については、あきらめて友瀬側で csv改訂〜配布するメカニズムを作り。
加えて、利用者が独自編集できるような仕組みも作ることになります。

こっちのほうがいろいろ問題を起こさないと思うので、自然かも。

ちなみに、アイテム種類がざっくり1万として。
Roweenサーバに負荷をかけないために『1分に1種類』の取得を行うとして。
1時間で60個、1日で 1440個。1週間くらいあれば1万個は全部探れる計算。
どうせ動作確認も必要なので、こっそり進めておくのがいいかもしれない。

画面デザインと表示詳細について†

とりあえずプロトなので「えいや」で作ってるところ。

どこかでてきとーに開示して、意見をもらおうかと思ってます。

その他。†

『チャットテキストを取り込んで解析してｘｘｘする』というメカニズム。
結局 ROCALFOと根っこは同じなんですね。

なので、１つのアプリで実現できるように考えています。

これについても画面デザインが絡むので、今後の課題。

こんな感じかな。

---

ご意見などがあれば。

お名前: