「funyak」に関する日記(6)

マップオブジェクトの一番の基底はインターフェースにしてあるけど、どのマップオブジェクトでも同じ実装で構わないものや、むしろ同じ実装でなくてはならないものもある。
すると、実装がなく型のみのインターフェースは不適切になりそうだ。
となれば、抽象クラスか。
細分化の方針も一度見直しが必要かもしれない。

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

共通当たり判定と独自の当たり判定の共存を効率的に行うための仕組みに向けてちょっとずつ軌道修正中。

構想ばかりじゃ何も進まないから、とにかく細かいことでも実装を進行。

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

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

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

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

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

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

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

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

TGWSAdmin

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

funyak

Effective Bounds構想。

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

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

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

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

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

思えば、ふにゃシリーズはいつも、「平らな床」や「平らな壁」に向けて、キャラクターの範囲を示す「棒」を伸ばして、その交差を持って当たり判定としていた。
いわば、“板”に“針”を刺さるかどうかで、当たっているかどうかを判断していたのだ。
ふにゃは、体の中心線から四方に伸びた針で当たり判定を行った。
落ちるとげとげは上方向の針をオミットしており、横に動くとげとげは崖っぷち判定に変則的な位置に針を持っていた。
ギヤバネは四方に加えて崖っぷち判定用の針を持つ。
ウナギカズラは状態別に異なる針を持ち、本体上部には乗れる板も持っていた。
この“板と針”思想が、知らず知らずのうちに、ずっとふにゃシリーズを支えていたのだ。
それがまた、すり抜けバグという厄介な問題も生んだが、funyakにおいて、非対称に針を伸ばすという方法で解決を見た。
ふにゃらしい当たり判定を、統一的に、広範に適用するならば、“板と針”思想を意識していくことが必要になるだろう。

funyak Demo 1公開してみました。
funyak自体はゲームではないので、あくまでも、「デモ」という形ですが、とりあえずゲームっぽくゴールを付けてみました。
TGWS内にはfunyakのページ自体がないし、将来的にも「funyak」としては作る気はないので、GitHubでひっそりリリースです。

ゲーム記

アフィうぜーボタン実装。
実際には「商品リンク消すボタン」と表記するようにしました。
このボタンを押すと、商品リンクが消えて、その代わりに、下のほうの邪魔にならない場所に、「商品リンク復活ボタン」が出てきます。
ボタン一つで簡単に切り替えられるので、特に確認メッセージなどは出ず、すぐに反映されます。
んで、とりあえず、最近アクセスの多いページから商品リンクを付けてみました。
商品リンクとアフィうぜーボタンは、明日公開予定です。

いっしょにチョキッとスニッパーズ

ゲーム自体は特に進んでいないのですが、ゲーム記にユニークなカタチのことを追記したので、上記公開と同じタイミングで公開します。
というか、お役立ち情報に当たるこっちのほうをメインに据えます。

funyak

昨日のアレをfunyakにも参戦させるとしたらどうなるだろう、と考えて、今のfunyakはあまりにもそれぞれを個別実装しすぎていることを思い出したのでした。
当たり判定も個別対個別に行っているので、マップオブジェクトの種類がN種類あると、N^2オーダーで当たり判定のコードが増えてしまうことになります。
ふにゃさんのキャラクターはそれぞれがすごく独特な役割を果たしていたから、個別実装しかなかったんだけど、funyakでは、全く役割が被らないものしか作らないなんて制約は付けたくないんですよね。
部分的に役割が被る部分があっても、差別化可能であればいてもいい、と。
そうすればゲームとしての幅が広がる、と。
そのためには、よくあるパターンの組み合わせから成り立つキャラクターが必要ということになるのです。
せめて当たり判定だけでも、よくあるパターンの組み合わせに落とし込めれば…。

アンパンマンDB

また変なコメントが増えてきたので、ちょっと制限を増やしましたよっと。
それだけなのも何なので、以前からちょくちょく言っていた差分検出について。
管理用に入力データの更新差分が必要な場合にはこれまでに実装した差分検出で充分なのですが、ユーザーに見せるための差分情報となると、必要なものが異なってきます。
ユーザーからすると、見えている情報がどう変わったのかが気になるわけで、見えない内部データよりも、自動生成されて表示されるデータのほうが重要なわけです。
今度はそこんとこを意識した差分検出を作っていこうかなっと。

Visual Studio Code

PHPの整形は、いろいろある中で、php cs fixer(小文字のほう)がうまく使えました。
PSR-2に従って整形してくれるらしいのですが、命名規則までは直してはくれないようです。
コーディング規則の最終確認にはSideCIを使っているのですが、ここでチェックすると、警告はある程度までは減っても、ある程度は残ってしまうんですね。
SideCIは本当に最終確認で、気軽にここで調整というわけにはいかないので、できるだけ手元でさっと確かめたいのですが、そのあたりの環境はまだ構築できていません。

VPS

マストドンをちょっとやってみたくてVPS始めたんですが、うまくいかなかったので、もう一個やりたかったこと、.NETのWebアプリケーションをLinux上のサーバーで動かすというのに挑戦しています。
今あるサイトをここのサーバーに置き換えるのではなく、新しいことを始めたい、というところです。
もちろん、軌道に乗ればサーバー移転も考えますが。
先日学習していたdotnetコマンドの件は、これの準備段階ということで、とりあえずハローワールドですが成果が出ました。

例えば、C#で作っているfunyakのステージデータが正当なものであるかどうかを検証するには、同じC#で作ったプログラムを使うほうが簡単だったり仕様の不一致が防げたりして都合がいいわけです。

まだFTPを入れていなくて、手元で作ったWebアプリケーションを向こうで試せないので、ちょっとFTPも入れておこうと思います。

CocosSharpとか使えるかなーとか思ったり。
サンプルがビルドできないけど。
funyakのフロントエンド開発には何を使うかいまだに決まってないんですよね。
一応WPFでそれっぽいものは作っているけれど。

各コンテンツで使っているマークアップ言語についても検討中。
アンパンマンDBははてな記法に似せて作ったTGWS_Wiki構文を使っているけど、手早く自作したものだから、機能不足なんですよね。
Markdownが最近ははやっているらしいけど、あまり私の理想には合わないような…。
段落を自動で入れてくれて、テーブルを簡単に作れて、柔軟なリンク指定ができて、普通の文章でマークアップが誤爆しにくく、カスタマイズ性が高い、というのが欲しいんですよね。
やっぱりTGWS_Wikiを改良するかな…。

WordPressのアカウントを管理者アカウントと投稿用アカウントに分割。
管理者アカウントは表に見せたくないものでね…。
いざWordPressを設置してみると、他のサイトで間に合うことが多くてなかなか最初の記事作成に着手できないですね…。

恐らく私以外誰も見ていないであろうアクセス統計のページを微修正。
ランク外に出たものは統計の対象外になってしまうために、再びランクインしたときに、ランクアップしてきたのか、全く新規の項目なのか区別がつきませんでした。
ランク外に出て見えなくなってしまった項目も、内部的には記録するようにして、正確なランク変動がわかるようになりました。

Anpanatorの実装のMifuminator、Packagistに公開しました。
mifumi323/mifuminator - Packagist
使い方とか全然書いてないし、requireしただけでは何も動かないので、まだ一般には使い物にはならないとか思いますが、Packagistの練習も兼ねて。

テスト環境のスタイルをかなり露骨にしてみました。
テスト環境であることを検出すると、背景にTestという単語がうっすら浮かび上がります。
明るい背景でも暗い背景でも対応できるように、白と黒の文字を両方入れています。

VS2017で追加されたファイルに個人情報が！
プロジェクトの構成情報の保存にproject.jsonが使われているのですが、そのキャッシュ情報にあたるproject.lock.jsonに個人フォルダのパスが保存されるようです。
自分一人で使う分には特に問題はありませんが、オープンソースとかでソースを公開しているときは、project.jsonは公開してproject.lock.jsonは非公開にしておく必要がありそうです。

タイルマップの読み込み作成中。
…と言いたいところだけど、リソースの読み込みとどう折り合いをつけるか決まり切っておらず…。

当たり判定実装。
死亡を実装していないのでとげの当たり判定はありませんが。

タイルマップの表示実装。
一応これもWPFの仕組みで表示しています。
ふにゃと同じく大きさは可変にしてあります。
表示だけなので、まださわっても何も起きません。
また、データの読み込みを実装したわけではなく、プログラムで無理やりマップに突っ込んでいます。
ここから先は、まだまだこれからというところです。

タイルマップ実装中。
当たり判定周りの実装の構想はあるのですが、リソース管理とどう絡めていくかが結構悩みどころです。
当たり判定は、線分の当たり判定がすでにできている以上、マップ内の「当たる場所」に線を引けば、すでにできている当たり判定の仕組みに乗せていくことができるのです。
しかし、リソースに関しては、主人公の絵とは違ってマップ作者がどの画像を選ぶか決められるので、ここに自由度が必要なのです。
しかも、ゲームのコア部分では、「リソース管理に一切関知しない」というルールを守っているので、画像に触れずに、どの画像が来ても大丈夫な仕組みが必要なのです。
まだしっかりしためどはたっていませんが、もうちょっと固めていけば何とかなるだろうとは思っています。

地面との摩擦やらしゃがんで当たり判定が小さくなるのやらを実装。
タイルマップを実装するために、当たり判定関係の基礎を後回しにできなくなってきたためです。
あとついでに、大きさを変える機能も実装しました。
巨大化して何かするようなゲームにするつもりは別にないのですが、特定の大きさを前提とした実装にする意味も感じなかったので、変数化したという形です。

今後作りやすくなるようにソースコードをちょっと調整。
そろそろ第1作や3作にあったようなタイル状のマップを実装したいので、その前に動きやすくなるように。