１１月１１日　へらぶな釣り、段差

突貫工事、大きな山を超えました。

釣り介（１０年前のWebゲーム）の仕掛けのデータを読みこめるようにしました。これで、仕掛けのエディット機能を移植しなくても、色々な仕掛けでテストできます。サビキ仕掛けなどは複雑で、物理演算で破綻しやすいんですよね。

地面、水面の高さはポリゴンやボクセルデータからではなく、高さマップ（テクスチャ）から取得しています。水面はほぼ水平で重ならないので、縦横の座標だけで簡単に取得できます。水の流れはシミュレーションの結果があれば、それを利用しようかな。

釣り具の物理演算用なので、地面の法線とかは省いています。

改良も少ししました。釣り具をローカル座標で計算していたのですが、グローバル座標（スケール除外）に変更。プレイヤーが移動しながら釣りをしたり、向きを変えたときに、考慮する必要が無く楽なので。スケールを除外したのは、物理演算で単位が長くなったり短くなったりするのは面倒なので。変則的ですが、プログラムはスッキリしています。

現在の釣り仕掛けのプログラムは、キャスティングから魚がかかってからのファイト、釣り上げまで同じ物理演算で、かなり無理しています。補正や例外処理がぐじゃぐじゃ。今思うと、物理演算でなるべく自然な動きを再現しようと、こだわって失敗しています。かえってラインの動きなど不自然になっていたり。

いったん整理する予定です。

見せ方、操作が問題です。

キャスティングは斜め上視点。

着水したらこんな感じかな？仕掛けが沈んでいく様子や、ルアーのリーリングでアクションを見ることができます。

魚がよってきたら、ズームでフッキングの緊張感を高め。

魚が掛かったら、魚が画面の半分ほどまでになるまでズームして、ファイト。 

問題はキャスティングから着水横画面の切り替えです。キャスティングはプレイヤーが自由に視点を変えられるようにして、横画面でキャスティングしていれば問題ないですが、後上方からの視点でキャスティングした場合、操作方法に工夫が必要そうです。

操作を画面の向きと合わせると問題が発生します。前後に振りかぶってキャスティングして、横画面になると左右が振りかぶりに変わってしまう。通常操作。

操作方法を画面と関係なく、前後で振りかぶり、左右で横振りに固定してしまえば問題ないが、横画面の時、画面とリンクしないので直感的ではなくなります。ラジコン操作。

「通常操作」と「ラジコン操作」を切り替えられるようにしても、通常操作で画面が切り替わると意図せず竿を動かすことになってしまいます。

着水したら横画面にするのがダメなのか。ズームはプログラムで制御して、視点はプレイヤー任せで自由に変えられるようにすれば問題ない？ 

ルアーで遠投すれば、横画面で断面図でも、前画面で断面図でも同じようなものです。

どうしよう。色々試してみます。

１１月１０日　Copilotすげー

建築パース屋の友人にAI利用を相談されて、画像生成はあまり使っていなかったので、「本格的には課金が必要、おこちゃまレベルだろうけど、Copilotで試したら」とアドバイスしました。

それで、建築パースでは無いけどリスの下絵で試して見ました。

おこちゃまレベルなんて失礼いたしました。すげー。

微妙にプロポーションもポーズも良い方に修正していて悔しい・・・

１１月１０日　牛歩の日々

先日の回転バグ（プログラムのミス）は解決しました。回転自体は仕掛けの回転を適用していただけでした。ワールド座標にしていた訳ではありませんでした。

原因はQuaternion（クォータニオン回転）の演算順序でした。

A＊B　と　B＊A で普通の掛け算だと同じですが、

上を向く＊右を向く　と　右を向く ＊ 上を向く では結果が違います。A * B は「B を適用してから A を適用」となっていて、ややこしい。

それとは別にStackOverflowExceptionで悩まされました。釣り具のテーブルの初期化で発生していました。GPT（AI）の助けを借り、色々試すも解決せず、もしかしたらとテーブルのファイルを分割したら解決しました。

テーブルが膨大すぎて本当にスタックオーバーフローしていたみたいです。GPTは賢すぎて、無限再帰を疑っていました。

今動いている状態を崩したくないので、一歩一歩進めていて牛歩状態です。元のプログラムにもプレイヤーと地面が含まれているので、それを１つ１つ今のプレイヤーと地面に移しています。 

１１月４日　１０年越しにバグ発見

ウキ釣り、ルアー、フライフィッシング、良い感じです。仕掛けのグラフィックが無いので、とりあえず赤い直方体で表示。

ルアーが真っ直ぐ下がらないので、不思議に思い調べてみたら、バグ（プログラムのミス）でした。釣り介（１０年前に作成したWebゲーム）の時は疑似３Dで表示していたのであまり気になりませんでした。なんか傾いているなと気にはしていたのです。

ロッド、ライン、仕掛けの位置計算はプレイヤー正面がZ方向になるように（ローカル座標）計算しているのですが、仕掛けの回転だけワールド座標（マップ上での位置）で計算していたようです。まだ検証はこれからですが、ルアーの回転から修正してみます。

仕掛けがプルプル震える現象に悩まされていたので、もしかしたら解決するかもしれません。

いやー、それにしても酷いバグだ。なぜ気が付かなかったか。自己嫌悪。

追記

原因はQuaternion（クォータニオン回転）の演算順序でした。

１１月２日　キャスティング

一日かかって、キャスティングできました。ロッド、ライン、結び目、ハリ、餌の基本的な釣り具です。動作するようにしただけで、コードは無修正です。

この感じだと、リールロッドのキャスティングなどは試していませんが、ほぼそのまま動きそうです。

処理速度は微々たるもので問題なさそうです。１０年前にSilverlightで作成した当時はギリギリだったのに不思議です。描画で遅くなっていたのかな。

仕掛けはXAMLのグラフィックで作成していたので、Unityでは使用できません。２D画像ですし、テスト用にテクスチャとして利用するぐらいでしょう。

ウキ・ハリ・オモリなどをラインでつなぐなどして仕掛けをエディットする処理が、膨大にありますが、これはグラフィックが無い段階では移植しにくいので後回しにすることにします。

ロッドやラインの挙動はだいぶ不自然です。「釣り介」の当時は、疑似３D表示で動作がもっさりしていたので、それほど気にならなかったのでしょう。ロッドとラインの物理演算の見直しから始めます。 これが肝です。 

１１月１日　釣り介移植、竿デバッグ表示

なんとか竿を表示するところまで出来ました。手に持っているロッドではなく、水色のデバッグ表示ですが。マウスの動きに合わせてしなります。

昔作ったWeb用の釣りゲーム「釣り介」のコードを移植することにしました。Silverlightと言うブラウザ用プラグインのコードなのですが、３D用ではないので、変数は自前のVector3（３D変数）やQuaternion（回転）を使用しています。

それをUnityのVector3に修正するのに一苦労。XYZの各要素に大文字を使用していたので、それをUnityのVector3用に小文字のxyzに変更したり、などなど。各メソッドも微妙に違うし大変でした。角度の単位が度とラジアンで違ったり。

半日ほどグチャグチャに表示される状態でしたが、やっと動きました。絵が出るとデバッグが格段にやりやすくなります。