ブログ

現在、検索画面のほとんどは文字のみで構成されている。作りこむのに一番簡単だったからだが、PCで使う時ならまだしも、やはりスマホから使うにはちょっと問題があると思わざるを得ない。レイアウトだけで回避しようと思って色々考えてみたが、やはりアイコン使った方が簡単だし、スッキリするだろうと考えた。

さて、ではアイコンを使うとなると、どのようなアイコンにするのが良いのだろうか？ざっと調べてみたが、グラブルでWeb開発キットのようなものは配布されている様子は無い。FF14には各種アイコンセットなどが無償配布されており、出典さえ明記すればそれらアイコンは自由に使う事ができた。

無いのであれば作るしかないのだが、まぁ絵心も無いし、大したものは作れないだろう。そこでダメモトでCygames運営にアイコンなどの使用許諾について問い合わせをしてみた。結果を公表できるかどうかは不明だが、もし使っていいという事になればラッキー。NGという事であれば０から作るしかないかな。取り合えず返答を待とう。

色々とモチベーションを喪失してしまっていたけれど、そろそろ再開しよう。休止している間も、いくつかアイデアも浮かんできた。データ入力を最優先にしないといけないのは間違いないけれど、デザイン的にも(特にスマホ向け)アイデアが浮かんできたから、それもやりたい。

そう思えてきたから、しばらく頑張るつもり。

とはいっても、まだようやく30％くらい。
中々進まないけれど、それでも全く進んでないわけでもなく、データが増えた事によって見えてきた事もあるし、限定公開したお陰で得たものも多い。

今後はもう少しデータ入力のペースもあげて、早い所意見集約の場を広げたいところ。

予定よりも大幅にズレこんでしまったけれど、とりあえず公開した。
これで後戻りもできないから、後は頑張るだけだなｗ

そして、このエントリが先頭に表示されるようになれば、「最新リリース」表示の完成だ。

今日は本当に色々と進捗があった。まずスマホのアビリティ表示で、縦書きにチャレンジしていた部分が解決した。一時はテーブル形式を自前で作ろうかとも覚悟したのだが、どうも縦書き(writing-mode: vertical-rl)の指定を、<TD>にしていたのがまずかったようだ。<td>タグはブロック要素で、かつテーブルの要素という事もあって、特殊な動きをしているようだ。また、TDに直接指定するという事は、文字の向きというより、セルの向きに影響するという感じだった。その証拠に、<div>でテーブルの外に作ったブロック内では、意図通りの縦書き表示が行えていた。

そのあたりで、ブロック要素とインライン要素という概念があった事を思い出す。(今はその区分は使われなくなったようだが)

TDはブロック要素であり、かつテーブルの要素なのでうまくいかないのであれば、TDの中に更に要素を入れ込んで、その要素に対して縦書きを指定してはどうなのか？と閃いた。実際には<span>を入れてみることにした。

CSSではTD用のスタイルのほかに、spanに対して使うスタイルもクラス定義し、それぞれにわけて指定するようにしてみた。結果…。

できた！

後は細かい調整だが、PCとスマホでは表示のされ方が異なり、幅の調整も昨日知ったViewportWidthだけではうまくできなかった。そこでCSSの@mediaを使い、幅が480以下の場合にのみ、縦書きのCSSを使うように記述してみた。そして、これも思うとおりに実現できた。

これで懸案事項は全て解決した(と思っていた)ので、モジュールわけやデバッグ情報の削除などに取り掛かった。

最初に固定ページを作った時は、ショートコードなどはfunctions.phpに入れろとなっていたので、それに従っていたが、複数の固定ページを作っている場合、functions.phpより、page-XXX.phpの方が適切ではないだろうかと思い、アビ画面、キャラ画面はそのようにしてある。しかし、検索画面のショートコードはfunctions.php(子テーマ用)に入れっぱなしだったので、一斉にpage-XXX.phpに移動してみた。

ら、動かなくなった。どうやらAjaxで呼び出す関数は、page-XXX.phpにあっても参照されないご様子。要するに、page-XXX.phpは画面表示までに使うものは入っていても良くて、画面表示された後にはpage-XXX.phpは一切参照されなくなる。以前表示時と、Ajax時でプロセスが異なりデータが共有できなかったという話をしているが、この辺りがまさにそういう話なのだろう。

functions.phpはページ表示後も繰り返し参照される可能性があり、プロセスが常駐していたりするのかもしれない。page-XXX.phpは画面表示時のみに作られる、インスタンスのようなものなのだろう。

という事で、画面表示までで役目を終えるショートコードはpage-XXX.phpに、Ajaxなどで呼び出される関数はfunctions.phpにというモジュール分けを実施した。JavaScriptは現状固定ページのソース上に直持ちしているが、これも本来なら別モジュール化して、表示時に読み込むような対応をすべき。だが、開発のし易さを今は優先して、しばらく現状のままにする。

検索画面からデバッグ情報を除去していくうちに、そういえば機能の説明が一切存在していない事に気がついた。いわゆる「マニュアル」が無いwという事で、検索画面(プルダウン)の上に、説明文を書き入れた。そうすると当然邪魔になるので、トグルで開閉できるようにした。さらに、開いた中も長くなりそうなので開閉できるようにしてみた。トグルボタンのデザインも、いつか「＋」みたいなのに変えたいが、今はいいだろう。

機能の説明を書いていたら、プルダウンが２つあるのに、どっちがどっちかわからなくなりそうだったので、ラベルを置いてみた。普通にラベルを置くと、これまたPCとスマホで綺麗に表示できそうになかったので、display: flexをうまいこと活用して自動的にデザインが切り替わるようにしてみた。こっちは@mediaとかは使わず、単純に実現できた。

ただ、ブラウザ幅広くして使ってる自分はいいけど、狭くして使ってる人の事考えてなかったな…。それも考慮しないとアカンか…。ブラウザ対応の１項目として考えよう。

そう、IE11で動かしてみたら、ちょいちょいおかしかったので、IEやEdge、Safari、FireFoxあたりのブラウザもちゃんと対応しないとならないだろう。IEやFireFoxは入手可能だからなんとかなるにしても、EdgeやSafariはどうしよう。SafariはWindows版はあるだろうけど、MacやiPhoneなどと挙動含め全部同じなのだろうか？ここら辺は、テストしてくれる人を募集していくしかないかな…。

そんなこんなで、とりあえずリリースに向けての画面の開発や、モジュールなどの整理は完了した。次は公開テスト用のサイトを構築してリリースするだけだ。当初はドメインもキチンと取得してリリースしようと思っていたのだが、テスト版とリリース版ではドメイン分けた方がいいような気もしているので、まず無料版のドメインでテスト公開し、並行してドメイン取得して正式リリースの準備をしようと思う。どのくらいの負荷がかかるのか、そもそも使って貰わないとそのあたりもわからないのだけれどｗ

全然ニーズが無いとは思わないけど、そんなに頻繁に使うものでも無いのだよな…。英語版までできたらまた違うのだろうけれど。ま、まずは公開に向けて着々と準備をしていこう。

今日は良くがんばったｗ

グラブルでは、アビリティの効果が複数の効果を持つものがある。

例えば「回避」というアビリティは「ダメージ無効」と「弱体無効」が合わさったような効果となる。ダメージ無効は弱体を喰らうし、弱体無効はダメージを喰らう。回避と似ているけれど「幻影」はダメージは回避するけれど、全体攻撃は喰らう(弱体も当然喰らう)。

さて、検索するときの事を考えてみる。

ユーザーが「ダメージをくらいたくない」と考えた時、「回避」で検索するのか「ダメージ無効」で検索するのか、どっちなのだろう？

「回避」が「ダメージ無効」と「弱体無効」を内包するのであれば、「ダメージ無効」で検索した場合、「回避」も検索結果にでてしかるべきなのではないだろうか？

「弱体無効」で検索した場合も同じ。弱体無効と共に、回避も検索結果に出て欲しいのではないだろうか？

例えば「攻撃UP」。今は「攻撃UP」「攻撃UP(別枠)」「攻撃UP(HP依存)」「攻撃UP(状況依存)」などと細かく分けているのだが、これは本当に必要なのだろうか？

単に「攻撃UP」で検索し、結果に全て含まれていて、詳細を見ると「HP依存」だったり「状況依存」だとわかった方がいい場合があるだろうか？

攻撃UPや防御UPに関しては、まだピンとくるかもしれないので、現状通りとしても、弱体や強化に関しては、アビの効果名称から実際の効果を想像できない場合もあるから、検索条件で「ダメージ無効」で検索し、「回避」が検索結果から除外されてしまうのはいかがなものなのだろう？

「アビリティ検索」を謳うのであれば、この辺りもカバーできなければいけないのではないだろうか？

「回避」以外、複数の効果を持つアビリティ効果はどれくらい存在するのか、ちゃんと把握しておく必要があるかもしれない。

ざっと思いつくのは、回避以外だと「活性」(再生とゲージUP)くらいか…。

逆に、「カウンター(回避)」は、「回避」と異なり、全体攻撃も弱体も無効にならないんだよな…。

検索条件に「単体攻撃をくらわない」「全体攻撃をくらわない」「弱体をくらわない」とか、そういう項目、要するに目的別の検索があるべきか。そうだとすると、検索条件のリストの出し方を工夫する事でこの部分はカバーできるかもしれないな…。下手に「回避」に「ダメ無効」「弱体無効」を両方持たせようとすると、ただでさえ多いデータ量が更に増える事になって、際限がなくなる。

目的別検索リストを作って、「単体攻撃をくらわない」を選ぶと、中分類に「回避」「ダメージ無効」「かばう」「回避カウンター」などの候補がでてくる方がいいような気がしてきた。当然、その為にはそれらを紐付けるテーブルなりを用意しなくてはならないが、利便性と開発、データ精査、維持を考えるとこっちの方が良さそうだ。

よし、この方向で考えてみるか。

データ入力は紆余曲折もあり、テーブル見直したり、分類見直したりと色々あったが、それも昨日まで。今日はほぼ確定した条件での入力だったけれど、かなりスムーズにいったのではないだろうか。

とは言え、１人分あたり約１時間かかっている。残りは１８０人分である事を考えると、それらの入力を待っていてはいつまでたっても公開テストに移れないｗ

という事で、十天衆のデータである程度テストは可能になっているので、プログラム的な話だったり、デザインやモジュール構成などの積み残ししてある項目について片付けていきたいと思う。

最初に検索結果テーブルのスクロールを何とかして終わらせ、その後にモジュールについて見直しと確認をしていこう。

トップ画像どうしようかなぁｗ今のルナール先生丁度いいんだけど、さすがにこれを使うわけにもいかないだろう。とりま、ゲームのキャプチャ画面とかから、適当に作り上げるしかないなぁ。(まぁ無しで行くという手がないわけでもない)

それにしても、十天衆分のデータを、ざっと検索したり表示させてみたけれど、結構悪く無い(自画自賛)気がする。ただ、アビリティの種類がある程度想像できていないと選択肢から選べないという気もする。大・中分類の文字列の工夫で何とかなるのであればいいが、自由検索とかはさせたくないし、キャラクター検索は本意では無い。

全キャラが持っている「奥義ダメージ」あたりと絞込み条件を組み合わせると、キャラクター検索ができなくも無いと思ったが…、コルワとか奥義ダメ無いキャラいるからダメだね。全キャラに共通のアビデータを仕込めばいいか…。末尾999とかで…。う、やれそうｗ

まずデータのIDの振りなおしから実施(桁を増やして分類し直した)し、その後データ上のIDを更新、そしてプルダウンリストの表示調整を実施した。そこまでで結構かかったけど、まぁ仕方ない。

その後、やっぱり分類し直してもプルダウンの量が多くなりすぎている感があったので、ラジオボタンを設けて大分類ごとに絞り込む処理を追加してみた。きづいたら４時間近く経過していたwこんなに集中できたの久々かもしれないｗ

何はともあれ、これで必要なデータの形が定まった…と思いたいｗ

後はひたすらデータ入力をしていこう。用語の統一とか検索結果のスクロール表示とか色々気になる部分はあるけれど、ともかく今はデータが必要。今日はフュンフまで入力し終えているから、明日はシスからエッセルまで終えてしまいたい。色々悩みながら入力する事にはなるだろうけど、今日のカトルとフュンフの入力の進捗度合いを見ると、随分こなれてきている実感がある。多少分類に悩むアビリティもあるだろうけれど、それでも何となくいけそうな気はする。

今日は夕方眠くて一時休憩したが、昨日、今日と結構体調も良かったので、明日も同等くらいには動いて欲しいなｗ

データ入力をしていて、アビリティの効果一覧がどんどん増えて行く。もうこれはこのまま無秩序に追加していってはどうにもならなくなるのが目に見えているので、一旦整理する。

• 条件が細かすぎるかも？
• 分類が曖昧な気がする
• そもそも数が多い
• プルダウンだけで絞り込むのは困難

などなど。IDの体系をし直したい気もあるのだが、そこはどうしようかな。全置換をうまくやれば漏れなくはできるか…(「1111」を一旦「A1111」に置換し、後で先頭を取る。部分一致とか使わなければこれで問題ないはず)

選択数が多すぎて、プルダウンだけで絞り込むのは難しいので、ラジオボタンかチェックボックスでそもそも一覧に出すものを絞り込む必要もありそう。はぁ、中々思うように進まないものだｗ

モードチェンジがあって、それぞれ奥義が変わるようなケースは、サラーサやナルメア、ユイシスなどが該当する。さらに言うとサーヴァンツに至ってはそれぞれと合体時で奥義が分かれているため、３種類存在し、最終想定すると全部で６種類の奥義がでてくる可能性がある。

最終済みかつモードのあるサラーサの表示がうまくいけば、後のキャラも問題ないだろう、という事で入力してみたが、昨日対応した注釈を活用して入力したところ、さほど問題なく表示できた。HTMLが奥義４個までしか対応させてなかったので、６個まで拡張したというのはあるけれどｗ

後、データ入力時(というよりインポート時)に、キー重複になってしまったので、その辺りを工夫して対応した。ただ、同じような問題がアニラの１アビ時にも必要になりそうな気配がする。ID分けておけばいいだろうか。

また、今回で検索結果がようやく10を越えるようになったので、検索結果のスクロールについて検討ができるようになった。ざっくり試してみたが、まだちょっと不可解な部分もあるし、綺麗に揃えるのができていなかったりして、簡単ではなさそうだったので、後回しにすることにした。

また、プルダウンリストが大・中項目だけでも結構な量になってきてしまった…。もう少しこの辺りは絞ったほうがいいのかもしれないなぁ…。要検討。