「アイディア」に関する日記(3)

<前 次>

CharaBox3

キャラボックス最近使ってないしそろそろ開発終了ってことにしようかと思って、じゃあ開発終了までにねじ込みたい機能って何かあるかと思ったら、簡単に実装できそうで役立ちそうなのがいくつか思い浮かんだので、GitHubの課題に入れておきました。
まず、開発終了するなら、キャラボックスを使わなくても管理できる形でデータを残したいということで、エクスポート機能。
そして、単に手抜きで今まで作っていなかった、データファイル追加・削除をソフト上で行う機能。
あとは、画像置き場が固定で不便なのを、可変にするのは大変なのでせめて負担が減るように、画像置き場へ画像をインポートする機能。
このあたりができればもう終わってよさそうに思います。

アンパンマンDB

右表を本文エリアに統合するためのアイディア。

現状の課題: スマホなど横幅が狭い環境で非常に窮屈になる。

解決法: テーブルの見出しを通常の文章と同じ行内に入れ、全体も通常のパラグラフと同じくする。

うーん、しかし…

ゲーム記

ゲーム記は、自分の持っているゲームについて書くコーナーであり、ゲームの進行状況も記載対象である。
当然ながら、ゲームの進行状況は、遊ぶ度に進む。
そうすると、しょっちゅうゲーム記の更新が必要になるが、現在それは大変な作業である。
コンテンツをHTMLで編集し、そのページの更新履歴を更新し、ゲーム記トップの更新履歴も更新し、FTPでアップロードし、サイトトップの更新履歴も更新する必要がある。
しっかりとコンテンツを作り込んでいるならまだしも、ちょっとゲームを進める度にこの工程を行うのは非現実的だし、実際多くのページで、進捗が過去のデータのままである。
また、ゲームを進めたという、ただそれだけのことを、更新履歴付きで大々的に主張するのもどうかと思っている。
そこで、ゲームの進行状況の記載は随時更新という扱いにしておいて、オンラインで進行状況本文だけ簡単に編集できるようにするのが良いのではないかと考えた。
これを実現するためのシステムは簡単に実装できそうだ。

アンパンマンDB

アンパンマンDBは、私が作っているWebサイトである。
故に、私の考えを最優先で記載しているが、それとは相異なる見解がコメントとして訪問者から示されることがある。
できれば尊重したいが、鵜呑みにするわけにもいかない。
そもそも人が複数いれば人数分異なる意見があるのは自然なことだし、却下して埋もれさせてしまうのも、採用して私の意見を上書きしてしまうのも、情報の喪失となってしまうのではないか。
単にコメントをコメントのまま残すというのも一つの手だけれど、コメントだとどうしても流れてしまう。
他者の意見と言う扱いで、コメントとも通常のコンテンツとも別枠で残すのがいいのかな。

funyak

ふにゃシリーズには、ふにゃとしては普通の動きの中にも、普通の物理法則から外れた動きがたびたび見られる。
バナナが当たり前に空中に浮かんでいるのはまあ置いとくとしても、ふにゃのジャンプは跳び上がり中、空気抵抗や風の影響を受けないし、しゃがむとその場でびたっと止まる。
それらは単純に当時物理法則の表現力が足りなくて実装できなかったというのもあるだろうが、ふにゃさんのときに一度見直しを行い、ほぼそのまま残すことに決めた。
funyakでは、これらの「わざと物理法則から外した仕様」以外について見直しを行い、ある程度物理法則に寄せた。
だが、あんまりふにゃとして面白い動きになっていないと感じている。
ということで出たのが先日の案なんだけど、それをふにゃ本人だけじゃなく、funyakの世界に全体的に適用して、ふにゃけー物理学的な感じで一種の物理エンジンにしちゃうのもいいんじゃないかなーとか、思い始めてます。

funyak

ふにゃの面白さって何だろう。
ふにゃに足りない面白さって何だろう。
と考えて思い当たったのは、キャラクター設定が遊びに活かされていないのではないかということ。
柔らかくふにゃふにゃしているという設定のわりに、動きがかっちりして固さを感じるんですよね。
もっとふわっとした動きを。
壁とか地面とかにぶつかってもガツンと止まらなくていい。めり込んでいい。
ただ加速度的に動くのはふにゃじゃない普通のキャラクターでも当たり前だ。加速感を強く感じられるように、加加速度を使うのはどうだろう。

アンパンマンDB

先日のアイディアのさらなる具体案。
次のような、集合知と、個人知の2本でやっていくことを考えています。

  • みんなのタグ(集合知)
  • あなたのメモ(個人知)

みんなのタグは、集合知。
今ある分類やシリーズとは別に、似たような一覧を作って、それに対してユーザー一人一人が、当てはまる・当てはまらないを選んでいきます。
これを集約(原則として多数決)して、情報として表示します。
一覧は、ユーザーが好き勝手に作ることはできず、管理人の判断で増やし、混乱を防ぎます。
「みんなの」というところを強調して、全体に公開される情報であること、管理人の意見ではないこと、ユーザー一人の一存で変わるものではないことを、示します。

あなたのメモは、個人知。
各ページに、好きなようにメモを書くことができます。
このメモは他人には表示されず、自分で閲覧したり、検索したりできます。
他人には、もちろん管理人にも伝わらないので、完全に自分用のメモとして使えます。
ただのメモとは違い、アンパンマンDBの検索機能と組み合わせることができるので、うまく使うと強力なツールとなるでしょう。

アンパンマンタギング

アンパンマン情報を集合知によってまとめ上げようとする試みはかつて数多くなされてきた。
Wikipediaに始まり、放送まとめWiki、各種ブログやアンパンマンDBだってコメントから情報をまとめ上げたりしてきた。
しかし、Wiki類は悪意ある少人数にたやすく破壊され、ブログ類は最終的に管理者一人の一存に委ねられ、集合知を活かし辛い状況であった。
比較的成功していると言えるWikipediaも、サイトのコンセプトからして、詳細な情報には限度がある。

一方で、まとまってはいないものの集合知を活かしそれなりに成功しているコンテンツがある。
Anpanatorだ。

これはゲームという体裁をとっているが、実際のところ、情報収集の機能を有しており、集合知によってゲームとして成り立っている。
これの特長は、少人数の悪意によって、善意ある人に作られたデータが失われることがないこと。
そして、人によって異なる意見を、どれほど人によって異なっているかという指標も保持できる。

このやり方を、アンパンマンの情報をまとめるのにもっと使えないか。

funyak

動体同士の当たり判定は難しい。
Unityなどの本格的な物理演算でさえ、高速移動すれば簡単に当たり判定図形を突き抜けてしまう。
ふにゃさんでは、ウナギカズラでこの問題が顕在化した。
続投させるなら対策は必須だろう。
もし、片方が静止していると見なせるようにしたなら…?

funyak

共通当たり判定のための判定図形リストはマップ側にまとめて持つ。
マップはマップオブジェクトに対し、判定図形の登録削除インターフェースを提供する。
マップが当たり判定を行うと、マップオブジェクトが判定図形の情報を得る。
判定図形はマップオブジェクトの都合で追加の情報を持つことができ、例えば、ほっぺに当たったとか、おでこに当たったとかを判断して制御できる。
こんな感じか。

funyak

マップそのものもある種のマップオブジェクトでいいんじゃないかという発想。
いろんな細かい構想があるけどまとまってない。
雑にでもどんどん文章に残しておくべきか。

funyak

以前さらっと言っていた「属性」という概念だけど、これに関しても考えていることがあるのです。
ふにゃさんにもあった「火」や「氷」といった、これぞ属性!みたいな属性はもちろん続投するけど、ポケモンのタイプ相性みたいに使うわけじゃないから、もうちょっと広い意味を持たせようかな、と。
「属性」というのは、「属」する「性」質と書きます。
すなわち、ゲーム内の何かに付属する性質を表すものなら、何だって属性になりうるのです。
だったら、例えばギヤバネの出すばねに属する性質「弾き飛ばす」も属性でいいんじゃないか。
バナナが持つ「食べられる」という性質も属性でいいんじゃないか。
もちろんなんでも属性にしていったらきりがないので、共通当たり判定に使えるように、funyakにおける属性を定義してみます。

「面積を持つ領域に属する性質で、その領域内に入ったものに影響を及ぼしうるもの」

この定義だと、針と板は面積ゼロなので、属性を持ちません。
ふにゃは面積を持つので属性を持ちうるでしょう。

この方針で「属性」を連ねていったら、以下のようになりました。
括弧内は説明と代表種です。

  • 低温(ふにゃに氷エネルギーを与える/アイスゾーン弱)
  • 極低温(様々なものが凍り付く/アイスゾーン強)
  • 高温(ふにゃが弱体化する/ヒートゾーン弱)
  • 超高温(ふにゃが死ぬ/ヒートゾーン強)
  • 鋭利(さわるだけで物理的に痛いやつ/とげとげ)
  • 腐食(機械類を破壊する/ウナギカズラ)
  • 風(侵入者との速度差に応じた加速度を与える/風)
  • 弾き飛ばす(一度に速度を与える/ギヤバネ)
  • 食べられる(食べた数が1増える/バナナ)
  • 食べる(食べられるものを消す/ふにゃ)

キャラクターやステージのアイディア次第で増えたり減ったりはありそうです。
「風」と「弾き飛ばす」は速度の条件が必要になるわけですし、必ずしも単純なON/OFFで考えられるわけでもないのです。

funyak


キャラクター案。
・雲のキャラクター
・息を吐いて風を起こす
・いろんなものをすり抜けてくる
・ふわりふわりと近付いてくる
・自機以外も気まぐれに狙う
・属性攻撃を受けるとその属性に変わる
・ちょんまげ生えてる
・名前は「アトリ」

昔、「ジュンクラウド」という名前で見せてたことがあるかもしれません。
ちょっとfunyak自体の内部構造の一部刷新を考えていて、これをうまくやると、どんなキャラクターでもエリア環境を搭載して、属性とか風とか重力とかの機能を持てるようになるので、見境なく属性をまき散らすキャラクターとしてリメイクしてみました。
名前は、属性を意味するattributeから。
あくまでも現段階では一つの案に過ぎないので、いろいろ変わる可能性はあります。

アンパンマンDB

アンパンマン大図鑑の収録ページ情報とか入れてみるのもいいかなーとか思ってたり。
しかし問題は分量ですね…。
今の私に記入しきれる量とは思えない。

アンパンマン質問箱

質問箱復活に向けて、新しい仕様を考えています。

  • ユーザーに課すルールは緩くする。
  • 質問時にユーザーからのコメントを受け付けるか選択可能にする。
  • 管理人からの回答は「現時点」での「個人的見解」であると断ったうえで、なるべく「断言」する。
  • 「わからない」という回答は避け、想像でもいいから回答を出す。
  • 調査に時間をかけず、時間がかかりそうなら、現段階でわかる範囲で答える。
  • コメント受付可能な場合、ユーザーは質問に回答したり、回答に意見したりできる。

ミフミンのDQ10メモ

ミフミンのDQ10メモ、リニューアルを目指しています。縮小方面で。
というのも、大手攻略サイトがすごく充実していて、公式サイトも充実してきて、一方うちのサイトは増え続ける膨大なデータを追いきれなくなっており、情報サイトとしての価値をほとんど失っている状態なのです。

個人的コンテンツである写真置き場は他がどんなに頑張っていても存在価値を失いませんし、栽培のページなど一部のページは、自分で使うことがあるなど一定の価値を保っている部分があるので、コーナー自体を消すことはありません。
ただ、攻略に関する見解を述べるのは、本編を遊ぶことすらおろそかになっている私がやれば、マイナスになることのほうが大きいかなと。

あと、部分的に古い情報が残るのも何とかしたいんですね。
ページ自体の更新が最近でも、アイテムの価格が3年前の価格だったりするわけです。
この辺も、情報一つ一つに対して、いつ情報なのかを明示できたらいいなって思うのです。

TGWSAdminとfunyak

TGWSAdmin

画像の半自動整理実装。
タスク実行時に一時的に使うだけで他に使い道のない画像なんかがあって、そういうのはタスク実行後には基本的に不必要になるのですが、別のタスクにも使われている可能性も考慮して、自動では削除していませんでした。
タスクが幾度となく実行されて、不必要な画像が増えてきて、全自動で削除まではしなくていいから整理が必要になってきました。
ということで、セーブフォルダ内のファイル-タスク内で使用している画像という形で、未使用画像を列挙できるようにしました。
半自動削除機能も作るには作ったのですが、消しちゃいけないイレギュラーなファイルを完全に判定する手段はないので、削除はこれからも手動でやることでしょう。

funyak

Effective Bounds構想。

funyakの当たり判定の考え方は、ふにゃさんを継承していて、「自分が誰かにぶつかったら、相手の反応は相手に任せて、自分は自分の反応だけを行う」という考え方になっています。
具体例で言うと、ふにゃを弾き飛ばす効果のあるギヤバネは、ふにゃにぶつかるとバネを出し、一歩後ずさりしますが、ふにゃを弾き飛ばしはしません。ふにゃがギヤバネにぶつかって弾き飛ばされるのは、「弾き飛ばされる」という動作の主体たるふにゃの責任なのです。

と、なれば、自分が反応するためには、相手のことを知らなければならないわけです。逆に言えば、相手に反応してもらうためには、自分のことを教えなければいけないわけです。
自分の位置が、相手が「影響を及ぼしうる範囲」の外にあれば、自分は反応する必要がないのです。相手に反応してもらうためには、まず自分が相手に「影響を及ぼしうる範囲」を知らせなければいけないのです。
この、「影響を及ぼしうる範囲」を、「Effective Bounds(効果範囲)」と呼ぶことにしました。
Effective Boundsを共通的な仕組みの一つとして用意してやれば、厳密な当たり判定の前にまず影響がありうるかどうかを簡易的に調べることができるようになるわけです。

逆に、自分自身の「影響を受けうる範囲」、例えばやられ判定などについては、当たり判定処理の中で自分で考えればいいので、共通な仕組みを用意する必要はないでしょう。
自分が植わる位置を決定するための判定範囲を本体からかけ離れた位置に持つウナギカズラなんてのもいますからね。

板と針もそうでしたが、ふにゃシリーズの当たり判定は、当たる側と当たられる側で非対称な仕組みになっているのです。というか、します。

funyak

針と板思想、MapObjectと絡めた一般化はできていませんが、その基礎となる針と板に相当する概念は既に存在しています。
Segment2Dが針に当たり、CollidableSegmentが板として機能します。
地形関係の判定はこれでいいとして、やられ判定系も一般化したいところですね。
まあ、これは、矩形と点、円と点みたいな簡単な判定で事足りそうな気はします。

<前 次>