日記/2018-04-13

そもそも「何」を連携するのか†

ChatAnalyzerはもともと「チャットを解析して何かをする」アプリです。
そしてその機能の一部に、「/where→/savechat」の内容から『/whereされたマップはどこか』を取り出し。
そのマップ名から『今いるマップにある、ユーザ独自の座標メモ』を、RO地図に重ねて表示する。
そんな機能を持っています。

これ、元々はRO地図の不足・仕様に備えたものです。
現状のROのゲーム内ミニマップには「カプラさん」「店舗NPC」などがアイコン表示されていますが。
その網羅性に不足があり、例えば『イズルードにいる弾薬屋NPC』など、表示されないオブジェクトがあります。
また、ゲーム的にマップ表示したくない、例えば『クエスト用の隠蔽オブジェクト』もあります。
こういう『ROクライアントが表示してくれないオブジェクト』を独自登録・表示できるようにしたかった。
ただ、そのためには『プレイヤーキャラがいるマップ』をどうやって知るか、という問題があって。
検討した結果前述の『/where→/savechat』でいいじゃないか、ということで、『チャット解析アプリ』に組み込んだわけです。

で、上記機能を作った際に、すでにレジャーハントを想定してはいまして。
プレイヤーがROクライアント上で『123,39』というようにX,Y座標を発言して /savechatすると、 そのミニマップ上当該座標にアイコン表示するような仕組みは、すでに入っていました。

・・・ここまでくれば、もうわかりますよね？
トレジャーハントアプリは「暗号解読して、座標を取り出す」ことができます。
なら、『解読した座標を、ROのミニマップに重ねて表示する』という連携は、できそうですよね。

暫定方針：『アプリ自体を１つにする』ことはしない。†

現状、そういう感じで進めています。

あんまり深い理由はなくて。
CAは「チャットテキストを分析する」アプリであって、OCRするアプリじゃないよ、というだけです。
だからもしかすると、先々結合しちゃうかもですが。

連携の基本方針†

基本的には、単純です。
『まるでROクライアントから/savechatしたように』トレジャーハントアプリが『座標情報を書き込んだテキスト』を作ればいい。
そのために、トレジャーハントアプリに、『CAが読み取っている・期待しているチャットテキストファイル名』を登録できるようにする。
これだけで大体解決します。

ただ、ちょっと大き目の課題が２つほどあって、それの実現方法の検討中。
何が課題かというと・・・トレジャーハントが『通常２つのマップで行われる』ということ。

わかりますよね？
トレジャーハントが以前ラヘルで実施されたときは、オブジェクトは『ラヘルの街』と『ラヘル↑の神殿』の２つのマップのどちらかにありました。
現状のトレジャーハントアプリは『ぬふあうえ→12345』の変換はしますが、それが『ラヘル』か『神殿』かは判断できません。

課題１：マップの判断方法について†

今、方式は２つ考えているのですが、一長一短で。
とはいえ、案Bを選ぶと思います：実際他サイトのWebアプリでは、これに近い方法を取っていると思われる節があるので。

案A：台詞解析する。
今までのトレジャーハントでは、『ぬふあうえ』的ヒントを出している吹き出しに 『それがどのマップなのか』も併記されていました。
それを読み取れば、判断することは不可能ではないです。

案A問題点１：文字認識精度。
現状使っている Windows.Media.OCRは『細かい字』への精度はそれほど高くありません。
そのため、マップ名の読取判断がうまくできないおそれが結構高い。
これは現状でも実施・確認できます：RO内の適当な吹き出し台詞を「読取」してみてください。

RO の画面のスクリーンショットという時点で、文字の解像度がちょっと粗いのです。
実際、とりだしたままのスクリーンショットデータでは『ぬめあお』『つう』あたりの判断ミスが結構多く。
そのため現状内部動作として、画像認識の前処理として画像の拡大・補完処理をしています。
が、さすがに漢字が絡んでくると、これだけでは対処が厳しい。

案A問題点２：開発までの時間
『実際にトレジャーハントが始まる』まで、どういうヒント出力になるかわかりません。
マップ名までいれるとおそらく『複数行』を解析対象にしなければならず、またどこにどのように地図名が入るかわからない。

もちろん現状でも『新しい暗号パターン』がでてくれば開発は必要なのですが、それよりも面倒な気がしています。

案B：座標とマップの関連付けを行う。
例えば 12,34 はマップA、34,56 はマップB・・・というように、ヒントの出力パターンから決める、という方式。
実際、従来の他サイトのWebアプリでは『暗号文字列』からマップまで判断していることから、 おそらくこういう紐付けで対応していると思われる。

案B問題点１：紐付けが必要。
『12,34はマップA』、『34,56はマップB』というのは、実際にトレジャーハントが始まってからでないとわからない問題です。
この紐付けをどうにかして登録しないとならないのが、大変。

案B 問題点２：完全同一座標だったらどうするか。 『マップAの12,34』『マップBの12,34』という回答パターンが両方ある、という恐れ。
これがきたら、まああきらめましょう（笑）

課題２：『今のマップではない』ときの表示方法。†

課題１でのマップ判断の次の話。

『今回の解析結果が現在のマップにある』なら、簡単です。
CAの現状実装で十分対応できる。

ですが『隣のマップにある』と、ちょっと面倒。
隣のマップに移動するまではそのオブジェクトは表示してはならず、移動後、表示するようにしないとならない。
これを、ROTRとCA、どっちでどう意識するか、という話。
正直、この話になってくるとCAとROTRを1アプリに結合することも考えたい・・・

案A：ROTR側で意識。

ROTR側、判断の結果、『今のマップ』でよければ、普通にCAに通知。
『隣のマップ』なら通知を保留。キャラが隣マップに動いた後、ユーザが『ROTR上のボタンを押す』と、CAに通知。
その際に『対象座標』と『移動先のマップ名情報』：/whereしたのと同じようなデータとを作って吐き出せばいい。
CA側はどちらの場合においても、既存のメカニズムの中で『通知を受けたら表示』でOK。

案B：CA側で意識

ROTR側は判断したら、CA側に『座標』＋『対象マップ』を通知。
CA側は、受け取ったマップ名と現状マップを比較し、今のマップでよければ即表示、そうでないなら保留。
キャラが隣のマップに移動した後、ユーザがクライアント上で/where したトリガーで、CA側表示アップデート。
『移動先のマップ名』と『CA側から受けて保留しているマップ名』比較して、表示する。

利用者側の操作は、案Aのほうが多少楽：「ボタンを押す」だけでいいので、マウスから手を離さなくてよい。
案Bだと「/where」なので、ショートカットまで指を延ばす手間がやや大。
いずれにしても、ROTR側に「マップ名」を仕込む手間は必要・・・ここがCAとROTRを結合したい理由（笑）

ご意見などがあれば。