《花騎士》　アビリティ検索システム作成日誌【β版：0.1】

皆さま、こんばんは。
このような辺境まで、お越し頂き、ありがとうございます。

今回は、いつもの記事とは趣旨が違いまして、題名の通り、趣味で勝手に作ったシステムを試験的にご紹介しようと思います。

いや、正直、システムとかのたまう程、凄いものでもないのですが、折角そこそこ苦労して作ったので、何かの役に立てばなと思いまして。
ついでにほぼド素人な私ですから、しなくても良い所で散々苦労しました（情弱
苦労話も含めてそちらも記事にしておこうかなと筆をとった次第です。

そんな感じで、へっぽこなおっさんが錆び付いた頭で作った検索システムをご紹介です。

【注意】

これは遥か昔に少しだけプログラムを齧った程度のおっさんが、独学で適当に組んだものです。
本職の方が見たら、見るも無残な事になっているのですが、そこは笑って流してください。

また、アドバイスは歓迎ですが、対応するかは私の気分次第な事を、予めご承知おき下さい。
とりあえずバグってようが私が活用できれば良いので優先順位が低いです。
少し強い言葉になりますが、他の方の為に作ったものではないという一点をご理解いただいたうえで、活用いただければ幸いです。

そう言った経緯があるので拡散・宣伝は無しの方向でお願いします。
だって、恥ずかしいし（ぉ

あくまで、日頃こちらのブログを読んで下さる団長様向けのおすそ分けやお礼の意味が強いのです。

後ほど書いておりますが、もっと素敵なサイトがあります。
可能であれば、そちらを拡散・活用してくださいませ。

そうだ、検索システムを作ろう

nn先日、花騎士界隈では新たな試みとして、無限城なるものが実装されました。
団長の皆様は、もう楽しみましたでしょうか？

私はこの記事を書いている時点で、破級の登頂は厳しいと実感しております。
いやー、火力が足りない！
反撃中心の構成でズーっと楽しんできたので、そこを封じられると手も足も出ません。

そうなってくると新しい編成を試そうとは思うのですが、そこでネックになってくるのがアビリティの多さなのですよね。

実は、この状況はずっと前から懸念事項ではありました。
花騎士団長さんの皆さんの中には、アビリティで花騎士を絞り込んで検索したいと思った方もいらっしゃると思います。
私はそこまでガチの戦闘民族ではないのですが、それでも反撃を中心に調べたい時が出てきます。

私の場合は良くお世話になっております「しょくぶつずかん」さんで調べているのですが、時として複数のアビリティで同時に絞り込みたくなることがありました。

いつもお世話になっております！　ありがとうございます！

ただ今迄は、ある程度絞り込んでから、場当たり的に検索をかけていたのですが……
段々面倒になってきまして。
そこで昇華対応も多くなってきましたし、花騎士検索システムに手を付ける事にしたのが今回の経緯です。

しかし、作り始めてから気付いてしまったのです。
あるじゃん！　凄く便利なツールサイトが！！（情弱）

しかも、フォロワーさんなのに何で気が付かなかった自分！（迂闊
おかしいな、ＴＬで見掛けた記憶が全くない……口惜しい。
千代金丸さん、ありがたく使わせてもらいます！

まぁ、それはそれとして、作った途端、他の方にとっては全く無用の長物となりました（愚か
システム的には、上記サイトがとても良い物なので、そちらを使う事を強くお勧めします。

とりあえず作ったのがこちら

とりあえず私は自分の都合の良い形で使えるので、自分のシステムを愛用しております。
そんなへっぽこシステムを、ここの読者の皆様におすそ分けです。

こちらになりますが、多分、多くの人がいっぺんにアクセスすると落ちます（ぉ
花騎士　アビリティ検索システム【β0.1】

作成に関しては兎に角、どうでも良い事で苦労したのですが、その辺りの作成過程を記事にしつつ、シレっとご紹介しておきますね。

また注意にも書きましたが、趣味と勉強を兼ねて適当に作ったものなので、その点は留意して、ご自身の責任の元、お使いいただければ助かります。

使用言語やツール等の紹介

後ほどもう少し詳しく書くものもありますが、まずは簡単に今回の物を作るにあたって使用したものです。

・必須：Ｇｏｏｇｌｅアカウント（Ｇｍａｉｌ）

【使用言語】
・ＨＴＭＬ
・ＣＳＳ
・ＪａｖａＳｃｒｉｐｔ
・ＧＡＳ（Ｇｏｏｇｌｅ　Ａｐｐｓ　Ｓｃｒｉｐｔ）

【使用環境】
・ネットにつながるＰＣ
・Ｇｏｏｇｌｅ　Ｄｒｉｖｅ
・Ｇｏｏｇｌｅ　スプレッドシート

【期間】
・約２か月ちょい（うちDB入力未完）

たったこれだけです。何よりお金かかってないのが素晴らしい。
やはり言語の知識がネックですが、やる気と折れない心があれば問題ありません。

プログラムを組んだことがある方はお分かりかと思いますが……
まず、新しい言語の場合、分からない事だらけの意味不明な状況が日常的に続きます。
解けない問題に延々とチャレンジしていくような感覚です。

それをひとつづつ、解きほぐすように解決していく気力と根性が必要です。
私の場合は、その時間もまた楽しいのですが、悩んでる間は、ムキーッってなる事もあります。

そう言う時間に向き合える精神力が必須ですので、その辺りは折れない覚悟をして取り組むことをお勧めします。

まぁ、本当であれば教えてくれる方が近くにいれば、そのストレスもかなり軽減されるんですけどね！

簡単な使い方とか

①　検索したい項目を選択するとチェックが入るよ！
②　一番下にある「検索ボタン」を押すと、検索が始まるよ！

以上（ぁ

ちなみに、検索はＡＮＤ検索なので、全ての項目が合致する花騎士のみがヒットする……筈です。
実際は、諸事情により面白い動きをする事も多いのですが、そこも含めて楽しんで下さい。

また一度選んだ項目を取り消すには、同じボタンを選択してください。
一括解除ボタンもありますが、こちらは全部いっぺんに解除されますので、ご注意を。

基本的には直感で何となく使える、あふんな仕様になってると思います。
とりあえず、触って楽しんで頂ければ嬉しいです。

さて、どんな仕様で作ろうかな？

最初に考えたのが、どういう仕様にするかという事です。

昔取った杵柄というほどでもないですが、一応、ちょろっとだけプログラミングもやってましたので、基本的な所だけは理解しているつもりです。

当時のＩＴ業界は当たり前の様にブラック一色でしたし、私の配属されたところは、割と緩かったのですがそれでも違った意味で精神力をゴリゴリと持って行かれる場所でした。
特に開発系で何が一番きつかったかって、数日かけて理解し、そして作ったものが仕様変更によってあっさりと消え去る事でした。

何と言うかまさに砂上の楼閣を地で行く仕事でしたね。
こう、自分で作った砂の城が、波が来るたびに灰燼と化す訳です。
やってらんねーよ！ってなります。普通の人なら。

そんな経験をしてきた私なので、仕様がコロコロ変わる事態だけは絶対に避けたかったのです。
そこで、骨子の部分は、早々に固めました。

①　検索は基本的にアビリティ主体。また選択は極力少ない方向で作る
②　メニューは動的に作成されるように組むこと
③　登録データは、原文まま　かつ　昇華など最終段階のみ

これは主に、私の使い勝手とメンテナンス性を一番に考えた結果、こうなりました。
いや、だってさっきも話した通り、作った後に仕様がコロコロ変わって、大部分作り直しとか絶対に嫌なので。

特にＨＰのベースやデザイン部分は、自分の手を入れて変更するとなると凄く面倒なことになるのは火を見るより明らかです。

なので、仕様的に絶対に妥協できない部分を決めた上で、作り始めてみました。

選択はラジオボタンとチェックボックスで！

検索するときに文字を打ち込みたい人もいるかもですが、私は面倒だと思うタイプです。
なのでマウス、またはタッチで選択できるこの２つの入力系統で検索できる形にする事にしました。

これだと感覚的にチェックを外したりつけたりするだけで良いので、分かりやすいでしょうし、何より動きが小気味よいので触ってて楽しいのですよね。

問題はむしろシステム的にどうやって検索語句を繋げていくかという所だったのですが、そこは、基本的に項目で分ける事にしました。
基本は各大項目をＡＮＤ検索でつなぐ形にしたのです。

アビリティなどは基本的にＡＮＤで検索すると思うのですが、その中に追加項目で発動値の「１０％」だったりとか、対象人数の「２人」とかを付け足していける形にしました。

まぁ、チマチマと触りながら徐々に絞り込んでいくという使い方を想定してしています。
私なんかが結構適当に、ああでもない、こうでもないと頻繁に検索項目を変えるタイプの人なので、このような形が私にとっては理想だったというのもあります。

インターフェースは、ほぼ自動生成にしたい

過去……と言っても２０年前位ですけど、何度かWeb系のプログラミングはした事があるのですが、一番苦労したのがデザイン周りの管理です。

昔はタグ打ちで積み上げて作っていく感じでしたが、これがまた酷かった。
どこか仕様変更が入って、例えばテーブルの段を一つ増やすと言う作業が発生するとそれでコーディングに影響が出る様なやり方でした。

なので今の技術を見て、原始人な私としてはびっくりです。
今はＪＳ（JavaScript）を使用すれば、ほぼ動的にＨＰを作成する事が可能になってます。
これは生かさない手はないでしょう。
ほぼ、ＨＴＭＬ側には手を加えず、パラメータや管理表の変更でインターフェースが自動生成されるようにできるのですから。

特に、アビリティと言う変化の激しい値を扱うので、その様な仕様にしておかないと後々、泣きを見るのは目に見えてます。

そんな訳で、管理表を読み込み、動的にインターフェースを作成する機能は必須でした。

データの殆どは表形式で管理したい

さて、そうすると最後は、データベースをどうするかと言う話になります。

当初はＣＳＶから読み込む形を考えていました。
ですが、これ、地味に管理が面倒なんですよね。

ＣＳＶ自体は、今は様々なアプリで簡単に管理・作成できるのですが……
わざわざレコードをＣＳＶファイルに変換して更新するという作業が嫌だなと思っていたのです。

何とか、Ｅｘｃｅｌの様に、そのままいじれる形で更新かけられないかなーと考えていたのです。

いやぁ、時代の進化って本当に凄いですね。
ありましたわ。私のそんな怠惰な願いを叶えるものが。

日頃私は、オフィスベースのファイル管理はExcelとほとんど変わらないGoogle系を使っていました。

ドキュメントとスプレッドシート、それをGoogleDriveで管理しておけば、どこにいてもすぐに作業が出来るんですよね。
しかも、基本的に無料で使えるので、貧乏な私は重宝している訳です。

そんな中、Excelと変わらない感覚で使えるスプレッドシートはやはり便利です。
これでデータ管理できれば何の問題も無いと思っていたのですが……できちゃうんですよね。

Google Apps Script(GAS)って何？

流石、世界を牛耳る天下のＧｏｏｇｌｅさんです。
スプレッドシートを使ってＷｅｂプログラムを作成できる仕様がありました。

それをＧｏｏｇｌｅ　Ａｐｐｓ　Ｓｃｒｉｐｔ（ＧＡＳ）と言います。

まぁ、Ｏｆｆｉｃｅで言うマクロの事なんですけど、こちらはＷｅｂアプリ準拠になっております。
つまりＨＰ上で動作するアプリを構築できるんですよ。これが求めていたものに合致しました。

しかも無料で開発環境も含め全て利用可能とあれば、言う事はありません。
こうして、手探りながらアビリティ検索システムの構築を開始した訳です……が、勿論、凄い苦労しました。なんせド素人なもんで。

ド素人すぎてどん詰まりした事

もう本当に、どうでも良い事で凄く悩みました。
ド素人だから仕方ないね！

そんな中でも、印象に残っていることを少しまとめておきます。

頼むから快適な開発環境を下さい　デバックしたいの！

私がコーディングをしていた時は、世にＪＡＶＡが登場したばかりで、オブジェクト指向が広がり始めたころです。
そんなカビの生えた知識しかないので、最初、ＧＡＳを触った時、コーディングのあまりの単純さにびっくりしました。

え？　何、インスタンス化は？　いらない？
え？　変数宣言、それだけで良いの？うそでしょ？

みたいな、カルチャーショックの連続です。

その割に、そもそも開発環境が終わってるとか、色々と別の意味で苦労しました。
開発環境に関しては今も、意味不明な状況でやってます。

デバックって、連結してできるのが普通じゃないんだろうか？
私の知識が古いのか、使い方が間違っているのか、探しても出てこない。解せぬ。

関数内のデバックは普通にできるのに、複数の関数を渡る処理が出来ない。
って言うか、アプリの挙動全てを監視できない。何で？
誰かやり方教えて！！

そんな状況で、とりあえず「Logger.log」を駆使して、ログを追いながら、何とか管理してます。
いや、面倒すぎる。変数の値変化が追えないのが致命的すぎる！！

そんな終わってる状況なので、まぁ、凄く苦労しました。多分、昔のＪＡＶＡより。
Eclipseをください。デバックだけでなく、コーディング支援も欲しいです。

字下げをいちいち自分でやらなきゃいけないとか、もう一周回って新鮮すぎます。
こんなにスペースキーを連打した日々は無かったかもしれない（遠い目

おぶじぇくと？　何それどう使うの？

そんな死んでる状況下だったので、オブジェクト型の意味が、最近まで全く理解できませんでした。

いや、正確に言えば使い方が本当にわからんかった。
配列なら二次元だろうが三次元だろうがこんがらがるものの、仕組み自体は単純なので分かりやすいのですが、オブジェクト型の存在意義が不明すぎた。

結果から言えば、配列の変換方法とかは調べるとすぐ出てくるのですが、直接オブジェクト内にある値を参照するというやり方が何故か上手くヒットせず、そこがネックになりました。

まぁ、分かってしまえば凄い単純な話なんですよね。

配列の場合は、配列番号で指定するんですけど、それをKeyに置き換えれば良いだけだった（ぁ
これがまたややこしい事に、番号でも指定できてるように見えるところがまた罠なんですよね。
値は取れるのに、思ったところに指定できなくて、なんでー？ってなってました。

今は理解しているのですが、最初期の頃にそれで分からなくて、結局配列に入れなおして処理したりしてるので、完全に冗長構成となっており、今では手を入れるのが怖いので放置です（ダメパターン

アプリなんて動けばいいのよ、動けば。

判定でnull、undefined　何でうまくいかないの！？

よく条件分岐で使う判定に、nullやundefinedがあるのですが、局所で指定しても何故か上手く拾ってくれませんでした。
まぁ、それもこれも、変数の中身が分からんと言うのが致命的すぎるんですが。

調べてみると、何やら小難しい仕様があるようです。

型じゃなくてstring文字で拾ってるのかなーとか、色々考えたんですけどそうではなかったです。
とりあえず「！」で代用が一番楽でスマートなので、それで良いかなと。
数値やその辺りは、今のところ判定に絡まない仕様なのでそれもあります。

lengthでエラー出まくり　無いものは計れません

かの有名なlengthは、長さをとってくるのですが、まぁ、長さが無い場合、エラーを吐きます。
for文を回すときに、必須と言っていい物なのですが、これがまた罠だったり。

本当はエラー処理もちゃんと作ればいいんですけど、変数が追えない関係でイマイチ組み方がわからんのですよね。
とりあえず、「何がどうしてエラー出てるの！？」的な感じで調べると、大抵はここで、詰まってます。

検索結果によっては結構な頻度で、中身がないこともあったりと、処理が難しいです。
一つずつ潰しつつ、一応、多分、それなりに発生元をつぶしきったと思うのですが、そこからが勝負なのがデバックなんですよね。
大抵、予期しない所で面白い挙動しまくりますし。

私の戦いはまだ始まったばかりだ（完

公開したけど反映されない？　なんで？

これは凄く単純な話で、ＧＡＳの仕様を理解してませんでした。
そもそも、Ｗｅｂアプリなんて公開したことないし！

で、調べてみたら単純な話で……バージョン管理に失敗してました（基本中の基本）

この記事がとても参考になりましたのでご紹介です。

まぁ、つまるところ公開設定でずっとＶｅｒ１で更新し続けていたので、結果として反映されてなかったって言う。

とりあえず、ある程度出来上がってきたので、暫定公開でバージョン上げるのは良いですよね？
仕事で触ってた時は、本当にコーディングだけしかやってなかったので、この辺り、意味不明なんですよね。

そもそも、本渡されて「これ参考に組んで。明日までね」みたいな世界だったんで。
今思い返すと、良く生き抜いた自分。

現状での課題とかと何とか

そんなやらなくても良さそうな苦労をした結果、何とか動くものが出来てます。
多分。きっと。一応、私の使ってる範囲内では動いてる、はず。

ですが、そんなド素人が作ったものなので、まだまだ多くの課題が山積している訳で。

デザインが致命的に死んでる件

幼少期より実感しているのですが、自分には美的センスっていうものが致命的に欠けてるんですよね。
いや、綺麗なモノを見て感動したり、綺麗だと思う感性はあるのですが、それを作る能力は無いと言いますか。

頭の中でそういう物が映像として浮かんでこないんですよね。
なので、見てもらった通り、デザインに関しては後回しにしております。
とりあえず分かれば良いよね？　と言う感じで止めてます。
そこに時間を費やすより、やる事があるのです。です。

まぁ、今の世の中は本当に便利な事にＣＳＳと言う神言語があるので、デザインなんていつでも変更できます。
そう、後で良いのよ後で。

と言う訳で、使う分に私は気にならないので多分、このまましばらく放置です（ぉ

検索精度がガバガバすぎる件

これはまぁ仕様的に仕方ない部分があるんですが、このシステム、意図しないヒットの仕方をします。

例えば、検索項目で「デバフ：攻撃力・命中率・２０％以上」を選んで検索をかけます。
仕様上、攻撃力２０％・命中率２０％のデバフを両方持つ花騎士を検索します。
ですが実際、その様な花騎士はいないはずなのですが……何故かアプリコット（クリスマス）がヒットします。

何故そうなるかと言うと、それはアビリティを見てみると納得なのです。

攻撃力デバフはそのままなのですが、問題は攻撃ミスの方です。
１２％となっているのですが……何故かヒットします。
それはその文章内を見て頂ければわかる通り、回避やミスの最大数値が入ってしまっていることが原因です。

この辺りは検索語句を精査する事で、精度を上げる事は可能なのですが、まぁ、現状、あまり問題がないので放置しています。

これを解決しようとすると、仕様を変更する事になるので、なるべくしたくありません。
というか、ぶっちゃけそこまでの精度は、私には必要無かったりしますので。

なので数値を絡む検索の際は、そういう所も含めて、ご注意下されば幸いです。

データー入力が面倒臭いでござる

まぁ、検索システムと名打っているので、検索できなきゃ話にならないのですが……。
その検索する元データを入力するのが本当に面倒です。面倒です。めんどうなんｄ（大事な事なので

そうならないように、なるべく入力するデータ自体は少なくしました。

・名前
・国家
・属性
・レアリティ
・スキル
・アビリティ×４

これだけです。９項目だけなんですけどね。
ですが、これだけでもやはりＷｉｋｉから引っ張ってきて入力するのがかなりの手間です。
あ、ちなみにデータは基本的にこちらのＷｉｋｉを参照させて頂いております。

いつもお世話になっております！　ありがとうございます！

最初は、自動取得とか出来るんじゃなかろうかと、試してみたのですが、あれですね。
ページの作り方が各花騎士ごとで微妙に違うせいなのか、上手く値が取得できませんでした。
結局、試行錯誤した結果、手動でもってくる以外に方法が無かった。って言うか現在進行形です。

なお、このＷｉｋｉには用意されたＣＳＶデータがありまして、そちらを使う事も検討しました。
ですがこれ、アビリティの効果を再構築したものはあるのですが、原文が無いのですよね。

個人的には、参照する以上、原文を使いたいという謎のこだわりがあるので、早々に諦めました。
あと、スキルごとに区分けすると情報量（と言うか使用セル）が多くなるというのもネックでした。
私の組んだ仕様の場合は、一定範囲のセルを複数語句で一発検索できるので、セルの範囲は小さい方が良いのです。

そんな訳で、作り始めてから並行してDB入力もしているのですが、これがまた曲者です。

ご存知の通り、花騎士はアビリティの更新が結構頻繁に行われるのですよね。
その為、数値や文言が変わって行くんです。なので既に入力した後に更新されてたりする子もいたり。
ただそれを更新するの面倒なので、放置してます（ぉ

この辺りは気が向いたらやる位の、フワッとした運用で良いかなと。
検索自体の存在意義として、大体の編成に対する方向性が分かれば良いので。

仮に使って下さる方達の中で、有志の方が勝手に更新するよというなら、それはそれでありなのですが、仮に不特定多数の方が触れるようになると、いずれ変な事が起こるのは火を見るよりも明らかなんですよね。

アカウントを絞って、選ばれた民（掲示板常連の方とか？）に任せるのもありと言えばありですが……
その辺りに人間関係的なモノが絡んでくると、もめた時に超面倒なのでやりたくないでござる。ござる。
そんな感じで、暫くは適当な運用で行くつもりです。

なお重ねて申し上げますが……
要望や修正願等はありがたく頂戴いたします。これは嬉しいのです。
ですが、対応するかは私のその時の気分で決まりますので、重ねてご容赦ください。

今回の記事は以上になります。
お読み頂き、ありがとうございました。

 
☆注意！　リンク先は音が出ます！

『フラワーナイトガール』(C) DMMゲームズ