ミフミンのDQ10メモ、リニューアルを目指しています。縮小方面で。
というのも、大手攻略サイトがすごく充実していて、公式サイトも充実してきて、一方うちのサイトは増え続ける膨大なデータを追いきれなくなっており、情報サイトとしての価値をほとんど失っている状態なのです。
個人的コンテンツである写真置き場は他がどんなに頑張っていても存在価値を失いませんし、栽培のページなど一部のページは、自分で使うことがあるなど一定の価値を保っている部分があるので、コーナー自体を消すことはありません。
ただ、攻略に関する見解を述べるのは、本編を遊ぶことすらおろそかになっている私がやれば、マイナスになることのほうが大きいかなと。
あと、部分的に古い情報が残るのも何とかしたいんですね。
ページ自体の更新が最近でも、アイテムの価格が3年前の価格だったりするわけです。
この辺も、情報一つ一つに対して、いつ情報なのかを明示できたらいいなって思うのです。
画像の半自動整理実装。
タスク実行時に一時的に使うだけで他に使い道のない画像なんかがあって、そういうのはタスク実行後には基本的に不必要になるのですが、別のタスクにも使われている可能性も考慮して、自動では削除していませんでした。
タスクが幾度となく実行されて、不必要な画像が増えてきて、全自動で削除まではしなくていいから整理が必要になってきました。
ということで、セーブフォルダ内のファイル－タスク内で使用している画像という形で、未使用画像を列挙できるようにしました。
半自動削除機能も作るには作ったのですが、消しちゃいけないイレギュラーなファイルを完全に判定する手段はないので、削除はこれからも手動でやることでしょう。
Effective Bounds構想。
funyakの当たり判定の考え方は、ふにゃさんを継承していて、「自分が誰かにぶつかったら、相手の反応は相手に任せて、自分は自分の反応だけを行う」という考え方になっています。
具体例で言うと、ふにゃを弾き飛ばす効果のあるギヤバネは、ふにゃにぶつかるとバネを出し、一歩後ずさりしますが、ふにゃを弾き飛ばしはしません。ふにゃがギヤバネにぶつかって弾き飛ばされるのは、「弾き飛ばされる」という動作の主体たるふにゃの責任なのです。
と、なれば、自分が反応するためには、相手のことを知らなければならないわけです。逆に言えば、相手に反応してもらうためには、自分のことを教えなければいけないわけです。
自分の位置が、相手が「影響を及ぼしうる範囲」の外にあれば、自分は反応する必要がないのです。相手に反応してもらうためには、まず自分が相手に「影響を及ぼしうる範囲」を知らせなければいけないのです。
この、「影響を及ぼしうる範囲」を、「Effective Bounds(効果範囲)」と呼ぶことにしました。
Effective Boundsを共通的な仕組みの一つとして用意してやれば、厳密な当たり判定の前にまず影響がありうるかどうかを簡易的に調べることができるようになるわけです。
逆に、自分自身の「影響を受けうる範囲」、例えばやられ判定などについては、当たり判定処理の中で自分で考えればいいので、共通な仕組みを用意する必要はないでしょう。
自分が植わる位置を決定するための判定範囲を本体からかけ離れた位置に持つウナギカズラなんてのもいますからね。
板と針もそうでしたが、ふにゃシリーズの当たり判定は、当たる側と当たられる側で非対称な仕組みになっているのです。というか、します。
針と板思想、MapObjectと絡めた一般化はできていませんが、その基礎となる針と板に相当する概念は既に存在しています。
Segment2Dが針に当たり、CollidableSegmentが板として機能します。
地形関係の判定はこれでいいとして、やられ判定系も一般化したいところですね。
まあ、これは、矩形と点、円と点みたいな簡単な判定で事足りそうな気はします。
アンパンマンDBをよく見ている人は、アンパンマンDBには情報提供のコメントがしばしば来るということは知っていると思います。
そして、その反映には非常に時間がかかっていることもご存じだと思います。
そんなにみんなで作りたいなら、作れるようにしたらいいんじゃないか、と考えることがあります。
Wikiは一人で記事を全面改訂できる性質上、悪意ある少人数が暴れるだけで簡単に崩壊してしまいます。
他の人がやっていたこともありましたが、実際に崩壊しました。
間違いを書く労力が非常に少ない一方、間違いを見つけ出す手間や、それを正す手間は、非常に大きくかかります。
Wikipediaは強力な管理体制がありそこそこうまくやっているようですが、サイト自体がアンパンマン向けではないため、あまり充実させることが望まれません。
私がWikiを作るというのもなしです。
私の作ったコミュニティコンテンツは総て例外なく失敗して潰れました。
だいいち、アンパンマンDBだけでも管理が追い付いていないのに、追加でより大変なものを管理するなんてだめです。
あればいいなと私が思うのは、極力メンテフリーで、みんなの「総意」が自然に表れるような、そんなコンテンツなのです。
方向性は違いますが、Anpanatorなんかは、そういった「総意」ベースで動いていて、そこそこうまくいっているようです。
例えば、キャラクターの属性とかに対して、当てはまるか当てはまらないかをみんなで評価していって、その平均値でキャラクターの性質を表していけば、みんなで作るコンテンツっぽくなるのではないかなと考えています。
思えば、ふにゃシリーズはいつも、「平らな床」や「平らな壁」に向けて、キャラクターの範囲を示す「棒」を伸ばして、その交差を持って当たり判定としていた。
いわば、“板”に“針”を刺さるかどうかで、当たっているかどうかを判断していたのだ。
ふにゃは、体の中心線から四方に伸びた針で当たり判定を行った。
落ちるとげとげは上方向の針をオミットしており、横に動くとげとげは崖っぷち判定に変則的な位置に針を持っていた。
ギヤバネは四方に加えて崖っぷち判定用の針を持つ。
ウナギカズラは状態別に異なる針を持ち、本体上部には乗れる板も持っていた。
この“板と針”思想が、知らず知らずのうちに、ずっとふにゃシリーズを支えていたのだ。
それがまた、すり抜けバグという厄介な問題も生んだが、funyakにおいて、非対称に針を伸ばすという方法で解決を見た。
ふにゃらしい当たり判定を、統一的に、広範に適用するならば、“板と針”思想を意識していくことが必要になるだろう。
なんだかろくでもないアプリを思い付いた。
文章を入力すると、ひらがなカタカナ大文字小文字全角半角をごちゃ混ぜにして出力するやつ。
ついでに載せる機能を作り込むためにリリース時期が延びるのも何なので、改善だけでいったんリリースしました。
次に載せたい機能というのは、出合い頭の正面衝突を避けるために、とげとげの初期位置をふにゃの進行方向と逆位置にするというやつなんですね。
それ以後にやりたいのとしては、スコアを何らかの形で残すための機能ですね。スコアを保存したりランキングするのではなく、TwitterとかFacebookとかに共有する機能でもいいんじゃないかと思い始めています。
Twitterの障害時や反応が遅いときなどは、以前のAPIの結果を使って最低限何かを表示するように修正。
あと、GitHubとBitbucketの課題を一度に一覧する何かを作ろうとしてみたり。
まあ、どっちも私自身の個人プロジェクトですね。
アフィうぜーボタン実装。
実際には「商品リンク消すボタン」と表記するようにしました。
このボタンを押すと、商品リンクが消えて、その代わりに、下のほうの邪魔にならない場所に、「商品リンク復活ボタン」が出てきます。
ボタン一つで簡単に切り替えられるので、特に確認メッセージなどは出ず、すぐに反映されます。
んで、とりあえず、最近アクセスの多いページから商品リンクを付けてみました。
商品リンクとアフィうぜーボタンは、明日公開予定です。
ゲーム自体は特に進んでいないのですが、ゲーム記にユニークなカタチのことを追記したので、上記公開と同じタイミングで公開します。
というか、お役立ち情報に当たるこっちのほうをメインに据えます。
昨日のアレをfunyakにも参戦させるとしたらどうなるだろう、と考えて、今のfunyakはあまりにもそれぞれを個別実装しすぎていることを思い出したのでした。
当たり判定も個別対個別に行っているので、マップオブジェクトの種類がN種類あると、N^2オーダーで当たり判定のコードが増えてしまうことになります。
ふにゃさんのキャラクターはそれぞれがすごく独特な役割を果たしていたから、個別実装しかなかったんだけど、funyakでは、全く役割が被らないものしか作らないなんて制約は付けたくないんですよね。
部分的に役割が被る部分があっても、差別化可能であればいてもいい、と。
そうすればゲームとしての幅が広がる、と。
そのためには、よくあるパターンの組み合わせから成り立つキャラクターが必要ということになるのです。
せめて当たり判定だけでも、よくあるパターンの組み合わせに落とし込めれば…。
また変なコメントが増えてきたので、ちょっと制限を増やしましたよっと。
それだけなのも何なので、以前からちょくちょく言っていた差分検出について。
管理用に入力データの更新差分が必要な場合にはこれまでに実装した差分検出で充分なのですが、ユーザーに見せるための差分情報となると、必要なものが異なってきます。
ユーザーからすると、見えている情報がどう変わったのかが気になるわけで、見えない内部データよりも、自動生成されて表示されるデータのほうが重要なわけです。
今度はそこんとこを意識した差分検出を作っていこうかなっと。
Bomber丸Worldに登場させることを意識したキャラクター案。
爆弾使いとはとことんそりが合わない厄介者というイメージで。
考えただけで、本当に登場させるかは不明です。扱いにくいのは最初から確定だし。
メロディアトップス＆スーツの試着。
ショップのポイントが200ポイント余っているから、なにかと交換できないかなって思っているんですよね。
ちょっとほしかったシンプルＴシャツは300ポイント…ちょっと足りない。
タイトルバーに処理の進捗を表示するように改良。
UWPでも、Windows Formsほどわかりやすくはないけど、簡単にタイトルを変更することができるんですね。
タイトルにはちょっとした制約がありますが、それはまあ別にいいかな。
Amazonアフィリエイトリンクを設置できるようにしました。
データはこれから入れていくところです。
アンパンマンDBみたいに効率よく管理できるような仕組みを作ろうかとも思ったのですが、一度置いたらもう管理することもないだろうし、Amazonのサイト内から取ってきたHTMLをそのまま貼り付けることにしました。
で、ちょっと考えていることが。
こういうアフィリエイトリンクって、人によっては結構嫌悪感があると思うんですよね。
ましてやうちは売り上げを出す目的でサイト運営しているわけでもないので、非表示にされても別に構わない。
アンパンマンDBでも、商品情報を非表示にすることができたりするんです。
これを、ゲーム記にも取り入れられないかな、と。
「アフィうぜーボタン」を一発押したら消えますみたいな感じで。
いよいよ差分検出が完璧に。
こうなったら更新情報配信ももう一工夫してみたいところですね。
情報提供のコメントがある程度さばけてきたら、質問箱を再開してもいいかなーとか考えています。
昔のままのやり方だともちろん無理ですが、情報提供をあしらうみたいに気楽に答えるとか、手に負えない質問はコメントで他人に丸投げするとか、負担の少ないやり方はあると思うのです。
映像・音楽以外も充実させようかと考え中。
アンパンマンの原点と言える絵本情報や、主力商品となるぬいぐるみ・おもちゃ等の情報です。
あと、デフォルトの並び順も見直したいところですね。50音順が必ずしも正しいかどうか…。
情報提供の扱いについて考えています。
すごくたまっているので、使うか捨てるかしなきゃいけないんだけど、真偽の調査や、掲載にふさわしいかの検討に、一つ一つ時間がかかるんですよね。
本当に完全に問題外なのは初期チェックの時点で捨て去るのですが、それ以外にも見当外れなのはたくさんあって、それが邪魔になっているのです。
また、コメントで情報提供をする都合上、提供する側にとっても、情報提供は煩わしい作業となります。
そこで、コメント欄とは別に、情報提供のための記入しやすく確認しやすいフォームを設置することを考えています。
カテゴリ再編検討中。
ごった煮状態になっているキャラクターの性質や特徴などを、カテゴリーの種類ごとに分けて独立項目のように表示するというのを考えています。
昨日からの流れで、また今更ながら、モンスターシール始めました。シールを集めても特に何もないそうなので、あまり必死に追いかけるつもりはありませんが、まあ、時間が合えば会いに行こうかなと。
あんまりいろいろシステムを追加すると、作るのも使うのも大変になってしまうので、カテゴリの定義については、単に文字列として登録できるようにしようと思います。
そうすると、同じような文面がたくさん必要になるわけですが、「同じような文面をたくさん作ること」にこそ新システムを作ればいいのではないかと考えました。
これなら、使わないなら使わないでいいし、カテゴリ以外への応用も可能なのです。
日記にもAjaxによるカテゴリ提案実装。
んで、カテゴリが扱いやすくなったので、カテゴリを細分化して大幅に増やしてみました。
ゲームはシリーズごとに分けるのではなく、1作品1カテゴリで、自作ソフトも、開発中止を一つにまとめたりはせず、各々のソフトにカテゴリを設定。
細分化したのにはもう一つ野望があって、ゲーム記からプレイ日記にリンクしたいなって思ったんですね。例えば、「ドラクエ」でまとまっていたら、ドラクエ3の日記を見たいのにドラクエ10の話ばっかりしてる、なんてことになりかねないわけです。細分化すれば、そんな悩みともさらばです。
ただ、全部の日記に一気に細分化したカテゴリを付けるなんて無茶なわけです。
ということで、まだカテゴリを付け直していない日記を見つけるために、更新日の古い日記を探す機能を付けました。ありし日の日記へどうぞ。なお、普通の人が見て楽しくなる要素はないと思うので、上のナビメニューに入れていません。
それにしても、あの日の私は…懐かしくも痛々しい…。
もうひとつのカテゴリ案。
一致度は設けず、一致するか否かが明確になるよう定義と領域を設定する。
データ修正だけなので、プログラムの修正が必要なくなる。
とにかく、プログラムが複雑になり過ぎないように、データが膨大になり過ぎないように気を付ける必要がある。
アンパンマンDBのカテゴリに一致度という概念を取り入れようかと以前から考えていたが、一致度未記入をどうするか、データ量が膨れ上がらないようにするにはどうするかが課題だった。
カテゴリの一致度とは別に、可変長の記入進捗データを用意し、完全に記入完了したものは短い表現のデータに置き換える。一致度データなし、かつ、記入完了扱いされているカテゴリは、不一致とみなす。これでいいのではないか。
あと、管理メモに置いてある、ギミック付きのページを管理メモから独立させたい。なるべく楽に量産できるような仕組みで。
シンタックスハイライトについて検討中。
今まではSHJSを使っていたけど、古くて更新も途絶えたライブラリなので、代替になるものを。
サーバーサイドで色付けしてしまうGeSHiがひとつ。
クライアント側に負担をかけないというのが長所。
ただ、直接style指定していて、事実上色のパターンを選べないというのが欠点。
もう一つが、JavaScriptでハイライトするhighlight.js。
割と評判がよくて、今でも更新が続いているライブラリです。
言語は自動判定が可能(というよりそれがメイン)で、カスタムパッケージとして、必要な言語だけをインストールすることも可能。
スタイルも各種用意されています。
うん、特別な事情がない限りは今後はhighlight.jsがいいかな。