YuiFan 緊急避難用 掲示板

>物理エンジンを使用しているクローンでは、
>巣の出入りや曲がり角を最短距離で進むように
>実装されていることがあります

コイツ、明らかに内部のロジックでもピクセル単位で作られているな、と感じる野良パックマンを見かけることがありますが、それも物理エンジンが使用されているのかな。　(^u^*)

>奇数のばあい、アンチエイリアスでぼやけます

やはりそういうことになるのですね。
アンチエイリアスの処理はコンピューター（OS?）が勝手にやってくれるから面倒では無いか。

>細長い棒を回転して表示している様子を想像してください
>線が太ければ、水平・垂直のラインから端面の角がはみ出ます

これもプログラミングで実現しようと思ったら大変そうな処理ですね。
ちなみに、 "butt" の意味（と "square" との違い）が知りたくて、 "butt square" で検索したら以下のような画像がヒットしました。
https://storage.googleapis.com/flex-web-media-prod/content/images/wp-content/uploads/2023/12/check-out-the-different-butt-shapes.webp
近々 "Heart-Shaped" の実装もありそうですね。　(*´艸｀)

>ディグダグには迷路はなく、地中を自由に動けるように見えますが、
>曲がれるのはタイル単位の位置なので、

プレイ動画を見直してみました。
微妙な位置で止まることもできるように見えますが、方向を90度変えるときはタイル単位になっているのですね。
たしかに、そうしないと 銛や岩の処理 が複雑になってしまいますね。

>レイヤーという概念はなく、すでに描いた絵のうえに
>後から描いた絵を次々と重ねてゆくことしかできません

レイヤーという概念を持たせられそうなのに、なんかもったいない気がしますね。
そういう概念を持たせることのほうが、プログラミング的には厄介だったりするのかな。

>アトラクト画面やコーヒーブレイクでは、
>ＢＧ面のキャンバスはCSSによって非表示にされます

そういうときは簡単に背景の非表示ができて楽ですね。　(´∀｀*)

>（※タイトル画面からのコーヒーブレイク実行では、
>　下部のレベルカウンターは表示されない仕様です）

誰か（？）からそういう質問が来そうだったから事前に告知したのかな（笑）

>それも物理エンジンが使用されているのかな。

壁沿いに当たり判定をとって動かしているばあい、
角に引っかかってスムーズに動かないことがあります

初代パックマンに物理エンジンなんてものは不要です
決まった軌道の中心軸から外れないように敵を動かし、
曲がり角で直角に向きを変えるように補正すべきです

プレイヤーのパックマンは曲がり角のタイルで
向きが変わると斜め45度に進めるので、
これによって敵を少し引き離すことが可能です

このふるまいを正確に実装するには、
パックマンの中心点が曲がり角にあるかどうか、
中心軸を超えていないかどうかの判定が必要です

>以下のような画像がヒットしました

お尻とは関係がなくて、buttは棒の先端が突き当たるイメージ
すなわち端と端を平らに接合する、という意味です
ザンギエフがお得意のhead-butt(頭突き)はこの butt です
決してニコチャン星人を表しているのはありません

しかしながらbuttheadは罵り言葉で、BTTFではビフの口癖です
文字通りお尻頭で、まぬけ野郎といった意味合いです
こちらはまさしくニコチャン大王を侮辱しているようですね

squareはパスの両端に太さの半分を加えますが、
長さがゼロのパスでは、この点を中心として正方形が描かれます
ちなみにroundのばあいは円が描かれることになります

>レイヤーという概念を持たせられそうなのに

ゲーム用というより、図形を描くための最低限の機能しかないAPIです
HTML文書をツリー構造としてモデル化して、枝葉を弄れるように
キャンバスのなかでも描いたものがオブジェクトとして存在していれば
そのオブジェクトの重ね合わせ順を変えられたりして便利ですが、
残念ながらCanvas APIで出来ることは、ピクセルを描きだすことだけです

キャンバスの中にフォームを埋め込んでCSSが適用できたら便利ですが
それはできないので、ボタンなどはキャンバス外にタグづけしておき、
CSSで装飾＆レイアウトしてキャンバスの上に重ねるのが一般的です

>誰か（？）からそういう質問が来そうだったから事前に告知したのかな

コーヒーブレイクは本来、特定のレベルをクリアした後に始まる寸劇なので
タイトル画面からの閲覧では表示しないようにしています
たとえば、シーン２はレベル５(ひとつめのリンゴ)のあとに始まりますが、
チェリー１つだけだと、本来のレベルと対応してなくて違和感があります

アトラクトモードは、最後に遊んだプレイヤーが得られたスコアと
レベル表示が残る仕様なので、レベルカウンターを表示しています

>壁沿いに当たり判定をとって動かしているばあい、
>角に引っかかってスムーズに動かないことがあります

スクラッチでプログラミングされたパックマンでありそうな動きですね。　(^u^*)
https://www.youtube.com/watch?v=4ggU9CKv-_Q

>決まった軌道の中心軸から外れないように敵を動かし、
>曲がり角で直角に向きを変えるように補正すべきです

物理エンジンが無かった（我々の）時代ではそうやって作ると思いますが、
それが身近に扱える現代では　利用できるものは利用しろ　って感じなんでしょうね。　(´∀｀*)
完成したものが面白ければどちらでもいいんですけどね。

>このふるまいを正確に実装するには、
>パックマンの中心点が曲がり角にあるかどうか、
>中心軸を超えていないかどうかの判定が必要です

物理エンジンがどういうものかさっぱりわからないのですが、そういう振舞いをさせることも可能なのかな。

>決してニコチャン星人を表しているのはありません

ザンギエフとヘッドバットはわかるけど、ニコチャン星人て・・・
あぁ、あいつか！
https://cdn.clipkit.co/tenants/1415/item_images/images/001/708/630/medium/ed6818c6-73b5-4b2d-9349-c677a9e77787.jpg?1468463246
よくこれを思い出しましたね（笑）

>しかしながらbuttheadは罵り言葉で、BTTFではビフの口癖です

まさかまた話が BTTF に繋がるとは思いもしませんでした（笑）

>長さがゼロのパスでは、この点を中心として正方形が描かれます

座標 X:200 Y:50 から 同じ座標の X:200 Y:50 までの 5px の太さの 線（点）の場合、
座標 X:198 Y:48 から 同じ座標の X:202 Y:52 までの 正方形が描かれるってこと？
間違ってはないけどなんか変ですね（笑）
5px の太さのマジックで線（点）を引くようなイメージか。

>ちなみにroundのばあいは円が描かれることになります

"Heart-Shaped"（未実装）の場合はどのように実現されるのか興味があります（笑）

>ゲーム用というより、図形を描くための最低限の機能しかないAPIです

ゲーム用でなくても、レイヤーが使えると利用範囲が広がりますよね。
まぁ、現段階では 最低限の機能 ということなんですね。　(´∀｀*)

>コーヒーブレイクは本来、特定のレベルをクリアした後に始まる寸劇なので
>タイトル画面からの閲覧では表示しないようにしています

さすがこだわりのアノ氏。　(*´艸｀)

§序論

　イジケは残り２秒以下になると点滅を始めて、
　２秒のときは５回点滅、１秒のときは３回点滅する仕様です
　
　プレイヤーがイジケの終了を予測できるように
　４体のゴーストの点滅はすべて同期している必要があります
　点滅がバラバラだったり、早すぎるクローンは不親切で、
　仕様を理解していないか、技術不足か、いい加減な人です

§しっかり調整したいのに何かがおかしい…

　残り１秒のときの振り分けでは、ミリ秒の“1000”で
　比較しないといけないのに“1”で比較していました
　白⇔青を繰り返すフレーム数も正しくありませんでした
　どうしたら正しいのか、メモを書き記します

§イジケタイムが２秒以上なら２秒前から点滅する

　残り２秒のときは14フレームに一回、白と青を交互に繰り返します
　白→青→白→青→白→青→白→青→白(９回切り替わる)

　(2000ms/9回)/16.66ms = 13.333 frames
　２秒を９分割すると13.333フレームとなり割り切れません
　13フレームごとだと10回目に差し掛かってしまいます
　なので切り上げて14フレームに一回、切り替えることになります

　２秒は120フレームなので、14で割ると
　8.5714... となり、均等に９分割するには少し足りません

　2000ms-((16.66ms*14フレーム)*8回) = 133.408ms
　８回切り替わったところで、残りは133.408ミリ秒になり、
　133.408ms / 16.66ms = 8 frames
　最後の白はフレーム数にすると８フレームだけになります

§イジケタイムが１秒のとき

　白→青→白→青→白の５回、切り替わるので
　(1000ms/5回)/16.66... = 12.00 となり、12フレームで割り切れます

>キャンバスから何かしらに変換するAPIがなければどうしようもない

そこは一般ユーザーが手を出せる部分じゃないのですね。　(^u^*;)

>番号を振ったりせずとも、周囲の状況から壁の種別を判定できれば
>壁であるかどうかだけで迷路が描けるので汎用性が高いと思います

隣の壁が何々ならここの壁はこの形にするとか、形の種別を指定する必要もなくなりそうですね。
そういえば、ランダム迷路でもそんな感じのことをやっていたような（記憶が曖昧；）

>この時代に使われていた縦画面の解像度では
>８×８マスで分割すると水方向の列数が28になるからです

めちゃくちゃ納得な回答。
なんでそんなことまで知ってるの？　(^口^*)
最近、Googleで検索するとAIが勝手に答えてくれるけど、先日試したときはAIでもこの質問には答えられませんでした（笑）
桜井さんがそういうテーマの動画を上げてそうだなという期待も少しはあったのですけどね。

>縦の解像度が足りないので迷路が縮小版にアレンジされていて
>そのせいでこの迷路では横の列数が奇数になっています

縦のマス数の謎まで知ってたんだ（笑）
解像度の問題でそうなっただけで、奇数でも偶数でも特に問題は無かったのですね。

>線はパスの中央に描かれるので、線の左半分は-2pxぶん
>キャンバスの外側に見切れてしまい、右半分の2pxだけ表示されます

あれ？　そういう仕様なんですね。
例えば、
座標 X:200 Y:50 から 座標 X:200 Y:150 まで 4px の太さの縦線を引こうと思ったら、
座標 X:198 Y:48 から 座標 X:202 Y:152 までの線が描かれるということかな。
私はプログラムで線を引くことが（おそらくBASIC時代以来）無かった、というか、
そもそも 2px以上の太線 を引いた記憶が無いかも（*笑*）

>だから、迷路の幅ぴったしのサイズにキャンバスを用意すると都合が悪くて
>キャンバスの内側に描こうとすると、あちこちで座標の補正が必要になります

だったら、キャンバスのサイズを最初から迷路の幅（と高さ）よりも2px以上大きくしておけば・・・
という簡単な問題では無かったですね。　(^u^*;)

>キャンバスで描かれた結果は単なるPNG画像ですから、
>それを拡縮してもキャンバスの描画には影響するわけがないのです

PNG画像にすることで、あとはブラウザがいつものように拡縮処理してくれるわけですね。
よくできたシステムだ。　(´∀｀*)

>フィットとか、そういう大衆受けのする車種に慣れてる人だと
>小物入れが少ないとか実用面でも不満をあげる人がいると思います

たまたま昨日、ホンダ車の設計に触れられた動画を見ました。
https://www.youtube.com/shorts/3pKYzqX17DE
コメント欄に、
『ホンダにはM・M(マンマキシマム・メカミニマム)思想という概念があって、限られた規格の中で乗員のスペースを最大限広くしようとしています。
なので、整備しにくいんですよねぇ(慣れると他社の整備がしにくくなります)』
という元ホンダディーラーの整備士の発言があって、会社によって様々な思想があるんだなと面白く感じました。　(´▽｀*)

私は小物入れは最低限でいいので全く問題無いのですが、（アクセラもそうですが）マツダ3は特に後席が狭くて窓も小さくて圧迫感がありそうですね；
運転席は乗り降り以外は十分快適なんですけどね。

>　４体のゴーストの点滅はすべて同期している必要があります
>　点滅がバラバラだったり、早すぎるクローンは不親切

逆になんでバラバラになるんでしょうね。
イジけながら巣から出てくる奴がズレるのかな。

>　残り１秒のときの振り分けでは、ミリ秒の“1000”で
>　比較しないといけないのに“1”で比較していました
>　白⇔青を繰り返すフレーム数も正しくありませんでした

点滅がバラバラなプログラマーたちもこんな おっちょこちょい なことをしているのかな。　(*´艸｀)

>　2000ms-((16.66ms*14フレーム)*8回) = 133.408ms
>　８回切り替わったところで、残りは133.408ミリ秒になり、
>　133.408ms / 16.66ms = 8 frames

久々の泊り明けの日にこの計算を理解するのに多少時間がかかりました。　(^口^*;)
私だったら、
14(切り替わるフレーム数) *16.66(1フレームのms)*9(切り替わる回数)　= 2099.16 ms
ということで、
§イジケタイムが２秒以上なら2.09916秒前から点滅する
というふうに仕様を変更してしまうと思います（*笑*）

>　(1000ms/5回)/16.66... = 12.00 となり、12フレームで割り切れます

12(切り替わるフレーム数) *16.66...(1フレームのms)*5(切り替わる回数)　= 999.99... ms
割り切れていませんね。　(^口^*)

>なんでそんなことまで知ってるの？

タイルが8×8マスであると知っていれば、28列36行なのだから
すなわち224×288ピクセルの画面であることは自明です
アクターやフルーツ類は16×16のスプライトになっています

通路のタイル自体は８ピクセルの幅ですが、
通路の両脇にある壁は半タイル内側に描かれているので、
見かけ上は16ピクセルの道幅があるように見えます
なので16×16のアクターが通り抜けられる通路にみえます

アクターの左上端をタイルの左上端に揃えると、
右下にずれてしまうので、半タイルぶん左上にオフセットします
スプライトの描画で中心同士で揃うようにしているなら
中心座標は左上端の座標から半タイル右下にオフセットになります

>奇数でも偶数でも特に問題は無かったのですね。

偶数列だと迷路のセンターが２つのタイル間にまたがります
ゴーストが巣に出入りする際にタイルの中心で揃えていると
13列目のタイルだと半タイル左寄りになり、
14列目のタイルだと半タイル右寄りの位置になってしまいます
なので、13と14の間を通す特別な処理が必要になります

奇数列だと迷路の中央に通路のタイルが並ぶので、
タイルの中心に揃えていれば巣のセンターから入れますから
むしろ奇数列だったほうが処理が簡単で都合が良いのです

アーケード版のクローンでは、面倒くさがりな人はしばしば
ドアを広めにして左寄りでも右寄りでも良くしてしまいます

>座標 X:198 Y:48 から 座標 X:202 Y:152 までの線が描かれるということかな。

太さの方向ではパスの中央に描かれますが、
デフォルトでは線の長さは太さに影響されることはありません

端面の設定はlineCapプロパティでおこないますが
規定値の "butt" は垂直に線を引くばあい、端面は水平に切り取られます
線分に太さの半分を追加したいばあいは "square" を指定します
そして、端面を丸くしたいばあいは "round" を指定します

>キャンバスのサイズを最初から迷路の幅（と高さ）よりも2px以上大きくしておけば

やはり、キャンバス左上端の角が原点になっているのが都合が良く、
できればオフセットはしたくありません

このゲームはピクセル単位の精度でアクターが移動できますが
内部のロジックではタイル座標に基づいています
正確な整列、方向転換にもタイル座標は重要になります

>PNG画像にすることで

毎フレーム、キャンバスの表示域全体をクリアして再描画する、
というパラパラアニメをリアルタイムに生成しているようなものです
だから解像度が上がるほど、処理の負担が大きくなるわけです
これは昨今のパソコンが高性能だからできることで
レトロゲームの時代からすると、とんでもないことをしています

CSSのtransformはGPUの処理でうまく拡縮してくれますが、
しかし欲を言えば、やはりキャンバスで描いた図形が
ベクターグラフィックとしてスケーリングしてくれたら嬉しい

>逆になんでバラバラになるんでしょうね。

ゴーストごとに変数を持たせると同期が面倒くさいので
４体共通のカウンターでフレームを数えるほうが万全でしょう

イジケがパックマンに捕まるとゴーストたちは静止しますが
更新処理の反復中に当たり判定を取ると同期がとれなくなります
１体目は進んだのに、２体目以降が静止したとかね

４体の更新処理を終えてから、当たり判定を取るべきですが
それ以外にも、正しく再現すれば巣へ戻る目玉は止まりません

>割り切れていませんね。　

200/(1000/60) は 200を16.6666... というパターンが永遠に続く
循環小数で割っているので、数学的には12と等しいことになります

JavaScriptでは倍精度浮動小数点数なので15桁まで精度があります
したがって 11.9999999999999996 は丸められて12と等しくなります

200/16.66666666666667 は 11.999999999999996 になりますが、
200/16.666666666666667は 12 になります

したがって 12 * (1000/60) * 5
もまた、計算上はぴったし1000になります

-----------

前述のばあいはキリよく丸められましたが、
0.1 + 0.2 は 0.30000000000000004 になってしまいます
なぜこうなるの？コンピュータは２進数でしか処理ができず、
10進数と２進数で表現できる小数が異なるからだそうです

Math.round((0.1+0.2)*10) / 10;　こうすると0.3にできます

>マツダ3は特に後席が狭くて窓も小さくて圧迫感がありそうですね

右ハンドル車はタイヤハウスのでっぱりで、
小型車はペダル位置が左へシフトしがちな欠点があります
軽自動車は鼻先が狭くキャビンを最大限に広げているので、
脚をまっすぐ伸ばした先にペダルが配置されていません

マツダは運転を楽しむことを最優先に考える設計思想であり、
デザイン性でも付加価値を高めるニッチ商売です
やはりボックスタイプの自動車はマツダらしくありませんし
ペダルの配置だったり運転姿勢だったり、運転の質に拘ります
なので前席の着座位置がやや後方になるパッケージングとなり
後席はどうしても他社の同セグメントほど余裕がありません

>タイルが8×8マスであると知っていれば、28列36行なのだから
>すなわち224×288ピクセルの画面であることは自明です

アノ様が言うとおり自明なんだよ、
わかったかAI！（*笑*）

>通路の両脇にある壁は半タイル内側に描かれているので、
>見かけ上は16ピクセルの道幅があるように見えます

そういえば、前にもその仕様を理解するのに頭を悩ませた記憶があります。　(^u^*;)

>アクターの左上端をタイルの左上端に揃えると、
>右下にずれてしまうので、半タイルぶん左上にオフセットします

アクター○は 16×16 で、
タイル●が 8×8 だから
○○○○○○○○○○○○○○○○
○○○○○○○○○○○○○○○○
○○○○○○○○○○○○○○○○
○○○○○○○○○○○○○○○○
○○○○●●●●●●●●○○○○
○○○○●●●●●●●●○○○○
○○○○●●●●●●●●○○○○
○○○○●●●●●●●●○○○○
○○○○●●●●●●●●○○○○
○○○○●●●●●●●●○○○○
○○○○●●●●●●●●○○○○
○○○○●●●●●●●●○○○○
○○○○○○○○○○○○○○○○
○○○○○○○○○○○○○○○○
○○○○○○○○○○○○○○○○
○○○○○○○○○○○○○○○○
こんな感じですね。

>13列目のタイルだと半タイル左寄りになり、
>14列目のタイルだと半タイル右寄りの位置になってしまいます
>なので、13と14の間を通す特別な処理が必要になります

アノが巣の出入りの処理で苦労してた記憶があるけどそういうことなんですね。

>アーケード版のクローンでは、面倒くさがりな人はしばしば
>ドアを広めにして左寄りでも右寄りでも良くしてしまいます

（面倒くさがりな）私だったら13や14から斜め下に巣に戻らせるかも。
その処理のほうが難しいか（笑）

>デフォルトでは線の長さは太さに影響されることはありません

そこはちょっと気になっていました。
>座標 X:200 Y:50 から 座標 X:200 Y:150 まで 4px の太さの縦線を引こうと思ったら、
の例で言えば、
座標 X:198 Y:50 から 座標 X:202 Y:150 までの線が描かれるということかな。
というか、X:が198から202までだと 4px じゃなくて 5px になるか。
奇数の場合は中央はどうなるんだろ？（笑）

>規定値の "butt" は垂直に線を引くばあい、端面は水平に切り取られます

逆に水平に線を引くばあいは、端面は垂直に切り取られるのかな。
座標 X:200 Y:50 から 座標 X:400 Y:50 まで 5px の太さの水平線を引こうと思ったら、
座標 X:200 Y:48 から 座標 X:400 Y:52 までの線が描かれるということかな。
斜めの線の場合はどうなるんだろ？（笑）

>このゲームはピクセル単位の精度でアクターが移動できますが
>内部のロジックではタイル座標に基づいています

大昔のゲームなので（なんとなく）タイル単位で移動しているイメージがありましたが、
アーケードやファミコンの時代からピクセル単位で移動していたんですね。
インベーダーなんかは、ザコキャラは完全にタイル単位のイメージでした。　(´∀｀*)

>毎フレーム、キャンバスの表示域全体をクリアして再描画する、
>というパラパラアニメをリアルタイムに生成しているようなものです

PNG画像に変換（？）されるのは最初の一度だけ？
それともアクターの形が変化するたびに CANVASで再描画→PNG変換 を繰り返しているとか？
それだと無駄か。

>これは昨今のパソコンが高性能だからできることで
>レトロゲームの時代からすると、とんでもないことをしています

理屈ではわかっていても、それを実現できていることが信じられないですね。

>欲を言えば、やはりキャンバスで描いた図形が
>ベクターグラフィックとしてスケーリングしてくれたら嬉しい

そうやってみんなが考えることは、大体すでに実現されてたりしそうなものですけどね。
プログラムの世界では少し遅めか。
それでも計画はされてたりするのでしょうね。

>ゴーストごとに変数を持たせると同期が面倒くさいので
>４体共通のカウンターでフレームを数えるほうが万全でしょう

アノは４体それぞれに変数を持たせていたような気がしたけど、それも気のせいか（*笑*）

>循環小数で割っているので、数学的には12と等しいことになります

数学的に説明されると反論できませんね；
アノの足をすくおうとしたら逆にすくわれてしまいました。　(^口^*;)

>0.1 + 0.2 は 0.30000000000000004 になってしまいます

なんとなく言ってることはわかるけど、、、
https://qiita.com/higashi_nc/items/9a5ea00415a008f06843
よかった、私はエンジニアじゃなくて。　(^u^*;)

>右ハンドル車はタイヤハウスのでっぱりで、
>小型車はペダル位置が左へシフトしがちな欠点があります

マツダ車ではよく耳にする話ですが、ペダルの踏み間違い死傷事故が、旧型車の頃に比べて86％も減ったというのは驚きですね。
https://www.yomiuri.co.jp/fukayomi/20170502-OYT8T50139/3/

>やはりボックスタイプの自動車はマツダらしくありませんし

それもそうなのですが、
プレマシーのようなミニバンの復活を希望するマツダファンや、
ベリーサぐらいの室内空間があるコンパクトカーを希望するken4さんもいます（*笑*）
ベリーサが復活して、マツダ2とマツダ3の中間くらいの価格だったら即決買いするんですけどね。　(^口^*)

>0xProtoに和文のグリフが含まれていたら、良いのになあ

とても読みやすいフォントですね。
映画字幕でも使えそう。　(´∀｀*)

>保存はできません
>Base64によるエンコードでURLに変換する機能です

素人目には、画像で保存するよりもURLに変換するほうが難しそうに感じるのですけどね。　(^u^*)
この話からは脱線しますが、Windowsで印刷を行う際に PDFで保存 できるのが便利ですね。
あれこそ画像でも保存できてもよさそうなのに。

>SVGに変換するツールがないわけではないけど

あるんだ！？
私が考えるような程度のことは、すでに世の中にあることがほとんどですね（*笑*;）

>と煽られてる気がしたので、
>オリジナルのほうをプログラムで描きました

煽ってはいません。　行動を予測しただけです（笑）
てか、私が煽る、、予測する前にすでに作りはじめてたんじゃないの？　(*´艸｀)

>APIに慣れたので愚直に書けばいくらでも描けますが
>問題はどうしたら効率よく描けるのか、ということです

プログラミングに凝りだすと、そういうことに時間を費やすことが多くなりますね。
それが楽しかったりもするのだけど。

>マップチップの意味は以下のとおりです：

マップチップは以前からあったと思うけど、壁の描画用の英数字記号が増えた感じかな。
以前は パックマンの初期位置 とかも記されていた気がしたけど気のせいか。

>タイル内で左寄り、右寄り、上寄り、下寄りがあり、
>ここをどうすべきか悩みました

すべてがすんなりと解決すればいいのですが、なかなかそうは行きませんね。
腕の見せ所ですね。　(^u^*)
プレイした感じ違和感は全くありません。
ウィンドウを拡縮させても問題ありません。

-----

昨日、アクセラスポーツの3回目（7年目）の車検の打ち合せがあったのですが、
今だと90万円で下取りできるので MAZDA3 に買い換えませんかと言われました。
実は4日ほど前にリアドアをコスってしまって、それがなければもう少しプラスだったらしいんですけどね；
買い換えは全く考えていなかったのですが、想像していたよりも下取り額が良かったので悩み初めてしまいました。
MAZDA3 は庶民には高すぎるんだよなぁ。　(^口^*;)

>画像で保存するよりも

canvasで描かれた内容を保存したい場合、２つの方法があります：

１．ユーザがキャンバス上でコンテクトメニューを開いて保存する
２．文書の著者がURLに変換してそれをA要素でリンクとして提供する

最近のHTMLではA要素にdownload属性を指定すると、
ブラウザの保存ダイアログが自動的に立ち上がるようになっています

Base64にエンコードするとデータ量が増えるので、
もっと良いほうがないのかと思いますが、
CSSで画像として読み込ませるにはURLに変換するしかない

>煽ってはいません。　行動を予測しただけです（笑）
>予測する前にすでに作りはじめてたんじゃないの？

冗談を言いました　いいえ、まったく着手してませんでした
他人から言われるとやりたくなるもので、
やってみたら出来ました　少しだけ技術力が上がったようです

>そういうことに時間を費やすことが多くなりますね。

少なくとも元の画像よりデータ量が小さくならなければ、
プログラミングで描く必然性がありません

>以前は パックマンの初期位置 とかも記されていた気がしたけど気のせいか。

アーケード版のタイル行は28列で割り切れてしまうため、
真ん中に配置するオブジェクトは２つのタイル間を跨ることになり、
どうせ座標を補正しなければならいので、やめました

マップチップを使わず、各クラスのコンストラクタに
デフォルト値として迷路上のタイル座標を指定しています

アクターの中心がタイルの中心に揃うように配置してるので
水平方向のセンターは13.5タイルの位置になります
これにタイルサイズを掛ければピクセル単位で中央になります

>プレイした感じ違和感は全くありません。

これまでキャンバスのサイズを実際の縦横比で指定してましたが、
Canvas APIで引いた線は中央に描かるため、
両端の縦線が半分だけキャンバス外に出てしまう誤算がありました

左右に１列ずつ追加するのは座標がずれるので解決策として却下
仕方がないので全体の描画を2px右へオフセットして
ずらしたぶんキャンバスの横幅を4pxだけ拡張することにしました

オフセットして広げたぶん、グリッドの水平線を延長したり、
画面をクリアしたさいに左端にゴミが残らないように
始点を-2pxからにする必要があり、少々面倒なことになりました

>ウィンドウを拡縮させても問題ありません。

ゲーム本編は、スプライト一覧と違ってラスター画像として
CSSでスケーリングしてるので描画が崩れることはありません
うまいことスケーリングしてくれます

canvas上で任意のサイズにスケーリングすると
浮動小数点の丸め込みによっておそらく線が乱れます

<html lang="ja" style="--tile-size:26px;">
ページの読み込み時にこのカスタム・プロパティの値に
基づいて描かれますが、いまは26px平方に指定しています

これは縦のサイズが1080pxのときおよそ等倍になるサイズで、
それ以上大きくならないようになっています
なので4Kの画面をお使いのかたは小さく表示される筈です

タイルサイズに比例して再描画の負担が高まりますので
これくらいが丁度よいのではないでしょうか

>MAZDA3 は庶民には高すぎるんだよなぁ。

新型のプリウスもMAZDA3のハッチバックは恰好が良いんだけど、
後方視界が悪いとか、SKYACTIV-Xが中途半端とかで
国内では思いのほか人気がないみたいなんですよね
こっちのガソリンはオクタン価が低いからマツダには不利

今の魂動デザインには角ばったプレスラインがなく、
光の当たり方で見え方が変わるうねりがとても好きです
付け足すのではなく、そぎ落としの美学なんですよ

>もっと良いほうがないのかと思いますが、
>CSSで画像として読み込ませるにはURLに変換するしかない

もちろんそれすら出来ないよりはいいのでしょうが、もっと良い方法はありそうですね。
（それが可能なのかわからないですが）アノが自作メソッドを作ったらいいんじゃない。　(^u^*)

>他人から言われるとやりたくなるもので、
>やってみたら出来ました　少しだけ技術力が上がったようです

アノの技術力向上のために今後も煽り続けていきたいと思います（笑）

>少なくとも元の画像よりデータ量が小さくならなければ、
>プログラミングで描く必然性がありません

データ量が多少増えたとしても、画像よりも拡張性が高くなるならプログラミングもいいかもしれませんね。

>真ん中に配置するオブジェクトは２つのタイル間を跨ることになり、
>どうせ座標を補正しなければならいので、やめました

やはり以前はそうしていたのですね。
時間が経つと自分の記憶に自身が持てなくなります。　(^口^*;)

>水平方向のセンターは13.5タイルの位置になります

なんでアーケード版のタイル行は偶数にしたんでしょうね。
私なら奇数で作ると思うのですが、コレ系のゲームは偶数が主流なのかな。
コンピューターにはそのほうが都合がいいか。

>Canvas APIで引いた線は中央に描かるため、
>両端の縦線が半分だけキャンバス外に出てしまう誤算がありました

Canvas APIを理解できていない（＆アノのこれまでの説明の記憶が消えた？）のでまたトンチンカンなことを言うかもしれませんが、
座標（的なもの）を指定して線を描いているんじゃないということかな？
タイルで指定？

>ゲーム本編は、スプライト一覧と違ってラスター画像として
>CSSでスケーリングしてるので描画が崩れることはありません

グリグリサイズを変更しまくっても、動いているアクターもズレることなく表示されるのが凄いなといつも思います。

>これは縦のサイズが1080pxのときおよそ等倍になるサイズで、
>それ以上大きくならないようになっています

それならウチは問題無いですね。　(^u^*)
1080px以下の場合はスケーリングされるから問題無いということか。
それなら、最初から8K（8000px）にしておいてもよさそうだけど。
しないということは、それだと何かの問題が出てくるのでしょうね（笑）

>タイルサイズに比例して再描画の負担が高まりますので

8K（8000px）は負担が大きすぎるということですね（笑）

>新型のプリウスもMAZDA3のハッチバックは恰好が良いんだけど、
>後方視界が悪いとか、SKYACTIV-Xが中途半端とかで

後方視界は、デジタルインナミラーがあれば特に不安に感じることも無いですけどね。
MAZDA3も標準搭載にすればいいのに。
マツダの営業の人も（何に乗っているかは聞きませんでしたが）自分の車に付けていると言っていました（笑）

エンジンに関しては正直よくわかりません（*笑*）
乗り心地にしても、足回りが硬いとか言われますが、私はマツダ車にしか乗っていないので、正直よくわかりません（*笑*）
ひとつ言えることは、今まで不満に感じたことは無く、運転は楽しいということぐらいです。　(´▽｀*)

>光の当たり方で見え方が変わるうねりがとても好きです
>付け足すのではなく、そぎ落としの美学なんですよ

私はデザインには（にも）疎いので、うまく言語化できないのですが、アノが言うそういう部分に惹かれているのだと思います。　(´∀｀*)

>操作ではなくて、迷路の通路から脱線しないように
>座標を補正する処理のやりかたが全く異なります

ということは、今回の改変によって（バグがあれば）脱線する可能性があるということですね。
気をつけて確認します。　(^u^*)

>フルーツ類もCanvasで描くことにしました
>そのせいで、少し容量をくわれました

画像よりもソースコードのほうが容量を食うの？

>オリジナルの迷路はひとつなので、プログラムで描く必要がありません

ランダム迷路のプログラムが流用できないなら面倒ですね。

>この方です：

以前紹介してくれたあの人ですね。。
この人のパックマンの見た目はオリジナルに忠実に作られていますね。

>円は border-radius で描けますが、線を引くには向いてない

単純な円や線なら簡単に描けそうなんですけどね。

>アカベエが左へ進むごとに、被膜を後ろへ引き伸ばして変形しています

そんなとぼけたシーンに高度な線形補間が使われているのが面白いですね。　(^u^*)
ファミコン時代にも（もちろん現在でも）、プログラマーのこだわりによって、どうでもいいシーンに高度な技術が使われていることはよくあるのでしょうね。

>リファクタリングして簡潔になるとスッキリします

日本風に言うなら、再設計したということですね。

>あれだけの機能だとソースが長くていぢる気がしません

出来るけど、その時間がもったいないということですね（笑）

>そもそもこのようなフォームをどのように表現するのかは
>User-Agentや環境によって様々ですから、
>標準仕様として定められているワケではありません

また環境の問題ですか；
環境を気にする必要が無ければ、プログラマーも（無駄に）頭を悩ませる必要が無くなるのですけどね。　(^口^*;)

>ベクターグラフィックで描いているのだから
>やっぱり拡大して観たいよね、っていうことで

ベクター画像って、SVGのようなものを言うのかと思っていたのですが、Canvas APIで描いたものもそう呼ぶのですね。
円や直線などの集まりという意味ではたしかに同じか。
ということは、SVG画像 を Canvas API の形式に変換できたりしないのかな。　(^u^*)

>キャンバスの表示面を画像として拡縮するのではなく、
>サイズを切り替えるたびに新たに描き直してます

描き直しているとは思えないほどスムーズですね。
それこそカクカクしてもおかしくなさそうですよね。
BASICの時代とは違うか（笑）

>脱線する可能性があるということですね。

ランダム版で散々テストしてるので脱線はしませんが、
ゴーストのパターンに影響します

>画像よりもソースコードのほうが容量を食うの？

レベル選択の項目にあるフルーツ類のために
結局はスプライトシートが別途必要かと思いましたが、
キャンバスの内容をdata:スキームのURLに変換できるので
それをHTMLの属性に書き込もことで対応しました

cf. HTMLCanvasElement: toDataURL() メソッド - Web API | MDN
https://developer.mozilla.org/ja/docs/Web/API/HTMLCanvasElement/toDataURL

しかし、それでも若干大きいと思います
結局のところ6KBくらい増えました

頂点を削って形をシンプルにしたり、
可読性を無視してソースコードを最小化すれば
もうちょっと減るとは思いますが…

>ランダム迷路のプログラムが流用できないなら面倒ですね。

本物はタイル間をまたがって壁が描かれていますが、
あれは１タイルのなかに壁を描いています
それに、塗りつぶしでテキトーに描いているだけなので
オリジナルのように中抜きの壁にはできません

>この人のパックマンの見た目はオリジナルに忠実に作られていますね。

ドット絵と滑らかな絵の中間って感じです
目は四角でも成立しますが、あのベルはベルに見えません
カギも原作となんか違うような気がします

オレンジのヘタが左にズレてるのも違和感があるので直しました
ドット絵の都合に合せる必要はないと思います

ギャラクシアンの羽を原作どおり原色の青にすると
黒い背景に沈み込んで形がぼやけるので、私は水色にしました
同様にイジケも濃紺だと暗すぎるので明るめにしています

>単純な円や線なら簡単に描けそうなんですけどね。

CSSの整形モデルはボックスの入れ子構造として表現するので、
無作為に２点間の線を結ぶ、というのは無理があります
要するにそんなこと文書でやるこっちゃないでしょ、って話です

>高度な線形補間が使われているのが面白いですね。

別に高度でも何でもなくて
0～1の数値を任意の範囲に変換するための式です

>その時間がもったいないということですね

時間があっても面倒くさい

>Canvas APIで描いたものもそう呼ぶのですね。

正しくは疑似的なベクターグラフィックですね

絵の描き方はベクターグラフィックに似ていますが
ラスター画像を出力してるので厳密には違います
でも工夫しだいでスケーラブルに絵を更新できます

canvasのサイズを変更してもラスター画像が拡縮されるだけですが
出力したいサイズに合せて描画スケールを変更して
その都度、絵を消しては絵を描きでアニメーションすれば、
スムーズに劣化なく拡縮しているように見せることができます

真のベクターグラフィックになってたら、
もっと使い勝手が良いのですがね、拡縮が面倒くさい…

>ランダム版で散々テストしてるので脱線はしません

その部分はランダム版を流用しているなら問題は無さそうですね。
ゴーストのパターンに関しては、異変があっても（プレイ中は必死なので）私は気づけないかも。　(^u^*;)

>キャンバスの内容をdata:スキームのURLに変換できるので
>それをHTMLの属性に書き込もことで対応しました

ムツカシイことはよくわかりませんが、対応できてよかったです（笑）
canvasで描いたものをPNG画像などに保存できるということかな。
どういう場面で活かせるのかパッとは浮かびませんが、想像力が膨らむメソッドですね。　(^口^*)

>頂点を削って形をシンプルにしたり、
>可読性を無視してソースコードを最小化すれば
>もうちょっと減るとは思いますが…

容量を減らす（強引な）手段はあるのでしょうが、ゲームに支障が無いなら（無駄に）そうする必要も無いですね。

>オリジナルのように中抜きの壁にはできません

あの「ランダム迷路も中抜きの壁にしたくなってきた」
とか言い出しそう。　(*´艸｀)

>ドット絵と滑らかな絵の中間って感じです

そういえばオリジナルはドット絵でしたね。
忠実に、とか適当なことを言ってしまいました（*笑*）

>オレンジのヘタが左にズレてるのも違和感があるので直しました
>ドット絵の都合に合せる必要はないと思います

ナムコが作りそう、というのが重要なポイントですね。　(´∀｀*)

>ギャラクシアンの羽を原作どおり原色の青にすると
>黒い背景に沈み込んで形がぼやけるので、私は水色にしました
>同様にイジケも濃紺だと暗すぎるので明るめにしています

自分がイメージするものを作る、というのが重要なポイントですね（笑）

>要するにそんなこと文書でやるこっちゃないでしょ、って話です

要するにEXCELでゲームを作るようなもんでしょ、って話ですかね（笑）
グラフィックを描くのに適したツール（Canvas）があるならそれを使うべきですね。

>別に高度でも何でもなくて

そこはツッコまれると予想していました（*笑*）

>正しくは疑似的なベクターグラフィックですね

そういえば、先程のtoDataURLで作成できる画像にベクターグラフィックは無いのですね。
元々似たようなものだから作成できそうだけど。

>真のベクターグラフィックになってたら、
>もっと使い勝手が良いのですがね、

toDataURLでベクターグラフィックが作成できるようになれば使い勝手がよくなるのかな。