週報7

パート採用された

パートの面接を受け、無事採用されました。良かった… 落ちていたら心が折れているところでした。これで当分は現状維持できるはずです。可処分時間は減りますが、金銭的なプレッシャーも減り、開発に集中できそうです。

面接

面接はマニュアルに沿って淡々と行われました。自己紹介や長所、短所などは聞かれれませんでした。空白期間については聞かれましたが、深堀りされませんでした。どちらかと言うと、業務に関する説明が大半でした。

筆記試験

ありました。聞いてないヨ… もっとも、電話した翌日に面接を受けたので、事前に知らされていたとしても、結果は変わらなかったと思いますが。詳細は伏せますが、内容は小学生レベルの計算と読み書きでした。ただし制限時間があり、私のような頭の回転が極めて遅い人間からすると、全問回答するのが困難な問題数でした。問題を一通り見て、引っ掛け問題っぽいのを発見しましたが、そこまでたどり着けませんでした。一方読み書きは簡単でした。PCの変換に頼りきりで、ほとんど漢字を忘れてしまった私ですら解ける問題なので、相当簡単です。

その他

面接や筆記試験は、よくある折りたたみ式の長机で行われました。下のスペースに書類を詰め込んだ段ボールが隙間なく並べてあり、ガニ股を強いられました。翌日お尻と腕が筋肉痛になりました。恐らくこれも試験の一環で、体力を測っていたのでしょうね(違)。

有料Unityアセットを非公開にした

詳細は伏せますが、見込まれるパートの収入とアセットの収入を合わせると、厄介なことになる可能性が高いので、非公開にしました。一部アセットについては、そのうち改修して無料公開する予定です。

車の挙動をリファクタリングした

名前空間を後から付けるのは大変でした。名前を変えるのは簡単なので、適当でもいいから構造化しておいた方が良さそうです。あと、リファクタリング中に大きめのバグをいくつか発見しました。その中でも酷いものを紹介します。

ジャンプ中の慣性モーメントが盛大に間違っていた

エンジン側から見たタイヤを回す際の慣性モーメントは、

エンジン慣性モーメント + タイヤの慣性モーメント合計 / ギア比^2

です。厳密に考えるとシャフトなどの慣性モーメントも考慮しなければいけないのですが、支配的なのはタイヤだと思うので省略しています。修正前は、

エンジン慣性モーメント * ギア比^2

となっていました。逆逆。これでジャンプ時のエンジンの吹き上がりが再現され、かっこよくなりました。

空気抵抗がでかすぎた

1/2の項を忘れていました。つまり空気抵抗2倍。通りで早々に最高速度が頭打ちになるわけです。アーケード挙動だから厳密さは不要と考え、速度2以外の係数をひとまとめにしてパラメーター化していました。しかし、現実の数値を使った方が調整が楽なので、投影面積 * CD * 空気密度を設定しました。1/2は定数なのでコード側に書いてあるものだと勘違いし、省略しました。そういう経緯で2倍になってしまいました。変なことはしないで、数式はそのまま実装した方がいい気がします。

来週

パートとして働き始めるまで、結構時間があります。今のうちに作り進めておきたいところ。来週は、UIなどを作り込もうと思います。あと、暗算や漢字の書き取りなどをして脳を鍛えようと思います。

週報6

今週は予定通りダラダラ過ごしました。途中から暇を持て余してBlackMagicGirlの手直しをしました。年が明けてから最初の週報です。

カードの効果を大幅に変更した

カードの効果を固定値にしました。レアリティごとに効果を用意し、固定値は下のレアリティの固定値*2にしました。例えば追加ダメージなら、コモン=3、アンコモン=6、レア=12といった感じです。

この変更により明らかな死に効果が消えました。発動しても効果が弱くてがっかりすることはなくなりました。相変わらずベースが運ゲーなので戦略も糞もないのですが。

あと、バーストしにくい数字の小さいカードの価値が高まりました。一方でそういったカードばかりを集めていると場に出したカードの枚数をトリガーにする効果が発動しにくくなります。あちらを立てればこちらが立たず。いい感じのバランスに落ち着いたと思います。

ただ、出現確率は改善の余地あり。似たような効果は抽選の重みを小さくするべきでした。同じような効果ばっかり付いてしまいます。

相性の悪い発動条件と効果の組み合わせを除外

効果をアルファベット1文字でカテゴリー分けしました。攻撃系ならA、防御系ならB、回復系ならHといった感じに。そして発動条件には組み合わせ可能なカテゴリーのフィルターを設定しました。例えば防御系と回復系とだけ組み合わせられる発動条件ならBHになります。そしてfilter.Contains(category)のようにして効果を抽出してから抽選します。これで相性の悪い組み合わせが発生しなくなりました。

ちなみにこれらの情報はCSVで管理しています。元々ソースコードにベタ書きでしたが管理が面倒なのでCSV化しました。エディタ拡張を作ってCSVからスクリプタブルオブジェクトにデータを流し込んでいます。バランス調整や説明文の修正が簡単になり、いい感じです。

アウトラインシェーダーを書いた

カードをマウスホバーした時に使うアウトラインシェーダーを作りました。Unity歴はそれなりに長いですが初挑戦でした。

アルゴリズムは非常に簡単でした。UVを上下左右にずらし、テクスチャをサンプリング。それらのアルファ値の最大を求めれば元の絵から少し膨らんだ絵が得られます。その絵をアウトラインの色で塗り、元の絵と合成すれば完成。この動画が役に立ちました。

ただ、枠線を太くした時の四隅の隙間が気になったので、斜めにも膨らませました。つまりアウトライン用に8回もテクスチャをサンプリングしています。パフォーマンスに難があるかもしれません。

あと、参考にした動画では絵に余白を設ければいいと言っていましたが、それだけでは不十分です。カードのように切り抜きやすい形状だとメッシュの形状が最適化されすぎてアウトラインを表示するスペースが無くなってしまいます。画像の設定のMesh TypeをFull Rectに変更する必要があります。

u1wで受けるゲームがわかった気がする

u1wの作品のプレイヤーは、初動ではu1wに参加した開発者が大多数だと思います。ここで伸びるかどうかが、後々開発者以外にリーチできるかどうかの分かれ目になりそうです。つまり、u1wの開発者に受けるゲームを作れば伸びる可能性が高いと考えられます。

そのようなゲームは多分こんな感じ

  1. ルールを一切説明されなくても遊べるくらい直感的
  2. 簡単だが極めようとすると奥が深い
  3. 短時間で遊べる

理由はu1wで疲労困憊だからです。そんな状態で、ルールが複雑で難易度が挑戦的でクリアするのに何時間もかかるようなゲームをやりたいとは思いません。説明やチュートリアルがなくても遊べるくらい直感的で難易度も緩めで数分で終わるゲームをやりたい。しかしそれだとすぐ飽きてしまうので、スキルが反映される作りになっているのが望ましい。クリアするだけなら超簡単。なれどスコアランキング上位を目指そうとすると地獄。そんな感じで指数関数的な難易度曲線を描くゲームが理想。いわゆるシンプルだけど奥深いゲームというやつでしょうね。

こうしたゲームは内輪でしか受けないかというと、そんなことはないと思います。むしろ、現代のブラウザゲームの理想系のような気がします。今は様々な娯楽があり、ブラウザゲームはその一つに過ぎません。娯楽一つあたりに使える可処分時間が減っているため、いかに短時間で濃密な体験を得られるかが重要です。濃密な体験を突き詰めたu1wのゲームは開発者以外にも魅力的に映ると思います。

u1wの結果

結果が出たので追記します。評価は以下の通りでした。

  • 楽しさ:3.424
  • 絵作り:3.424
  • サウンド:2.97
  • 操作性:3.758
  • 雰囲気:3.424
  • 斬新さ:3.303

想像していたより高い評価でした。もっとボロクソこき下ろされるかと思っていたので意外でした。ランキングを見たところ結構やり込んでくださった方もいました。刺さる人には刺さるゲームだったのかもしれません。

それはさておき再び反省。↑で書いたu1wで受けるゲームの法則をもとに振り返ってみます。

どんなゲームかわからない

冷静に考えると、事前情報なしではどんなゲームかさっぱりわかりません。

まずタイトルが意味不明。魔法をテーマにしたブラックジャックなので、MagicとBlackJackとを組み合わせてBlackMagic(黒魔法)。BlackMagicだけだと語呂が悪いので、サンタナのBlackMagicWomanという曲になぞらえてGirlを付け、BlackMagicGirlというタイトルにしました。グレートなネーミングセンスだと思ったのですが、ゲーム内容はさっぱり伝わってきません

アイコンも意味不明。宇宙を背にした魔法使いのちびキャラ。ゲーム画面をキャプチャしただけなので制作時間は1秒です。

タイトルとアイコンから読み取れる情報は、魔法を使いそうということくらい。

ゲームを起動してもわかりにくい。トランプを使っていない上に、気取ってヒットやスタンドをオリジナル用語に置き換えているので、ブラックジャックを知っている人でも気が付かない可能性があります。

そもそもブラックジャック自体が日本ではマイナーな存在。名前は知っていてもルールまで理解している人は少数派でしょう。

以上により、法則1であるわかりやすさは皆無でした。ブラックジャックを全面に打ち出さなかったのが過ち。仮にブラックジャックを全面に打ち出してもブラックジャックという日本人にとってわかりにくいテーマを選んだこと自体が過ち。

運ゲー

なんか前も書いた気がしますが、とにかくこのゲームは運要素が強すぎます。ブラックジャックの仕様をそのまま実装したためできる操作がヒットとスタンドだけ。一応デッキを工夫することで運要素を抑えられますがやはり根本が運ゲーなので限界があります。

運ゲーでハイスコアを出すためには何より試行回数が大切になります。つまり時間がかかります。言うまでもなくプレイヤースキルが反映されにくいので奥深さもありません。なんと一気に法則を二つ破ってしまいました。

運要素は適度に入れるとリプレイ性を高めるいいスパイスになりますが、入れすぎるとゲームを破壊する毒になります。

いや、当たり前のことしか言っていない。作っている最中に気がつけよ俺…

来週

  • ラリーゲームの開発を再開する。まずは車関係の完成度を高める
  • アルバイトに応募する

2026年3月までの目標

あけおめことよろ。元日ということで、今年の3月までの目標を立てます。

なぜ3月なのか。期間が長いと目標が曖昧になります。目標は具体的でないと達成できません。なので3ヶ月ごとに目標を立てることにしました。

目標

開発中のラリーゲームを完成させて、unityroomとitchi.ioで公開する

なんとしてでも達成します。セガラリーのように3~4ステージ走ってその合計タイムを競うゲームにします。これなら余裕で完成させられるはず。

バイトを始める

これも何としてでも達成します。でないと野垂れ死にしてしまいます。

こんな感じ。今年は午年。馬のごとく駆け抜け、飛躍の年にしたい。

週報5

今週は予定通りunity1weekに参加しました。日曜日は最後の追い込みで忙しく、月曜日は燃え尽きていたので2日遅れの更新となります。ということで、今回の週報ではunity1weekの振り返りをしようと思います。

unityroom.com もしよろしければ遊んでみてください。

まだ評価期間は終わっていませんが、今回も失敗しました。前回同様、凝りに凝った面白いゲームを作ろうとして事故ってしまいました。原因は恐らく、せっかちな性格ゆえの思慮の浅さです。この記事を書いていて気が付きました。

というのもこの記事を書くのに結構苦戦したからです。嘘つけこんな適当な文章書くのに苦戦するわけないだろ、とお思いでしょう。確かに文章を書くこと自体には全く苦戦していません。適当ですし。苦戦したのは、自分が何を考えていたのかをまとめることでした。

文章というのは何かを伝えるための手段であり、伝えたいことが明確でなければ書けません。ゲームを作っている最中は色々考えていた"つもり"でしたが、いざ文章に起こそうとすると、考えが曖昧すぎてまとめられませんでした。そもそも考えが固まっていなかったのだと思います。

なぜこんな事になってしまったのか。それは脳みそのできが悪いとういのもありますが、一番の原因はせっかちな性格でしょう。unity1weekのように時間が限られていると焦りから早々に結論を出して十分に考えないまま開発を始めてしまいます。仕様が曖昧なまま開発を進めて結果、ゲームデザインが破綻してつまらないゲームになってしまう。多分こういうことなのだと思います。

これからは、考えを具体的にしてから行動に移すようにしたいと思います。

運要素を減らすための工夫

ブラックジャックローグライクゲームを作ったのですが、ブラックジャックは運要素が強いゲームです。それだとゲームとして面白くないので、運要素を減らす工夫をしました。具体的には簡単にカウンティングできる環境を用意しました。

カウンティングとは場に出たカードを記憶しておいて山札のカードを予測する行為です。山札のカードが予測できれば有利にゲームを進められます。例えばカードの数字の合計が15で、山札に6以下のカードしかないことがわかっていたら、ヒットしても100%バーストしません。

で、まず山札を少なくしました。初期デッキは1~10+ランダムカード3枚の計13枚にしました。山札が少なければ予測が容易になります。特に山札が少なくなってくると次に引くカードの候補がかなり絞られます。このサイクルを素早く回せるので運要素を減らせるだろうと考えました。

考え方は間違っていなかったと思います。しかし勝利する度にカードを獲得する仕様のため、段々とこの恩恵が薄れていきます。少し考えれば分かることですが、開発中は全く気が付きませんでした(アホ)。カードを獲得するのではなく、既存のカードに特殊効果を付与していく仕様にした方が良かったように思えます。

他には、短い開発時間を割いて山札を確認するボタンを実装しました。これで記憶力に頼らずカウンティングできます。敵の山札も見ることができます。

ただ、いちいちボタンを押して確認するのが面倒でテストプレイ中ほとんど使いませんでした。人は便利でも面倒な機能は使いません。もっと手軽に確認できるようにするべきでした。例えばボタンを押している最中だけ表示するなど。

カードの効果は、発動条件と効果を分けた

短い開発機関で大量のカードを用意するのはどうあがいても不可能です。悩んだ末、発動条件と効果を分けるアイディアを思いつきました。この方式なら覚える要素を抑えつつカードのパターンを大幅に増やせます。例えば条件と効果がそれぞれ8種類あったとして、覚えなければならないのは8+8=16。一方で組み合わせは8*8=64通りにも上ります。カードの数字も絡めれば爆発的にパターンが増えます。これを思いついたときは天才かと思いました。優れたアイディアというのは複数の問題を一気に解決してしまうものだな。っと舞い上がっていましたが、冷静に考えると問題が多くあります。

まず、実用性の低い組み合わせが多数存在します。例えば、"マナを最大値まで溜める"と、"ブロックを増やす"は相性が最悪です。このゲームでは溜めたマナの量が相手より勝っている場合、その差分をダメージとして与えられます。つまりマナを最大値まで溜めた状態では必ず引き分け以上になるので、ダメージを軽減するブロックを増やしたところで何の意味もありません。こういう組み合わせは除外するべきでした。

また、カードの数字によって効果量が変わるのですが、数字の小さいカードが弱すぎて役に立ちません。その逆も然り。効果は固定値にした方が良かったように思えます。一方で数字大きさはバーストしやすさと比例しているので、リスクリターンの観点からは間違っていない気もします。難しい。

発動条件が厳しいほどレアな効果が付くようにした

リスクリターンの関係性を強化するナイスなアイディアだと思ったのですが、実際は違いました。成立の難しい条件=ただの使いにくい条件になってしまいました。狙ったカードを狙ったタイミングで出せないので当然と言えば当然です。さらにレアな効果も強力だけど使いにくいものばかりで、その傾向を加速させています。例えば現在のブロックを2倍にするとか。現在のブロックが0だとブロックは0のままです。アホです。順序が制御できないゲームでこの効果はアホ。

反省1: アイディアの検証をせず突っ走った

アイディアを思いついてからすぐに開発を始めました。この間わずか1時間。これが大きな間違いでした。もっと大量にアイディアを出して見込みのありそうなものについてはプロトタイプを作って面白さを検証するべきでした。一週間ゲームジャムでいくつもプロトタイプなんか作っていたら完成しねーよっと嘆きたくなりますが、そもそもそんな規模のゲームを作ろうとすること自体が間違いです。

反省2: 結局運ゲー

プレイヤーができる操作はチャージとフィニッシュだけ。カウンティングでいくらか勝率は上げられますが限界があります。その結果どうなったか。バーストしない程度にマナを溜めてチクチク削り合う地味なゲームになってしまいました。それで運悪くバーストするか、強力な効果を持つカードを引いて決着というパターンがほとんどです。結局、勝敗を分けるのは運です。麻雀だって運が勝敗を左右しますし、それ自体が悪というわけではありませんが、ローグライクを名乗るならもうちょっとプレイヤーのテクニックが反映されるようにするべきでした。例えば山札から引いたカードを場に出すか保留するか選べるようにして、保留したカードを好きなタイミングで出せるようにしただけでも、だいぶ違ったかもしれません。

まとめ

今回はうまくいきませんでしたが、収穫も多かったです。これからは自分がせっかちな性格であることを認識して、行動に移す前の準備により多くの時間を費やすように心がけようと思います。

来週

もう精魂尽き果てました。来週はお休みします。年末ですしお寿司。

週報4

週前半は好調でしたが、週後半は色々あって忙しかったり精神状態が悪化したりで、作業時間は少なめでした。それでも先週立てた目標は達成出来たので、結果としては悪くなかったのではないでしょうか。いや、リファクタリングは全くやっていませんが、まだ試行錯誤の段階なので良いのです(もっともらしい言い訳)。ということで第4回目の週報です。

テレイン自動生成

この手のアセットは無料でもありますが、将来的にアセットとして売っ飛ばすことを視野に入れているので、軽く自作してみました。fBm(ノイズ関数はMathf.Perlin)でハイトマップを作り、それを超簡素な侵食アルゴリズムで滑らかにしています。侵食アルゴリズムは、自身のマスを少し削り、隣接する一番低いマスに削った分を堆積させるというシンプルなものです(AI発案)。侵食の適用回数を増やすと、変な模様が浮き上がってきます。勾配に応じてアルファマップを塗り分ける処理も書きましたが、醜いので没にしました。ちゃんとした侵食アリゴリズムを実装して、堆積の量でアルファマップを塗り分けた方がリアルになる気がします。

テレインの青い木に悩まされた

テレインの機能を使って植えた木が、カメラから離れると青くなる症状に悩まされました。どうやらカメラから一定距離離れると、軽量化のためにビルボードに切り替わるようなのですが、そのビルボードの描写がおかしくなっているようです。確かに、インスペクターにはNature/Soft Occlusionシェーダーを使わないとビルボードのライティングがおかしくなるよ~と警告が出ます。しかしここで問題が。私はURPを使っているのですが、Nature/Soft OcclusionシェーダーのURP版が存在しません。試しにNature/Soft Occlusionシェーダーを使うとビルボードの色は正常になりますが、今度は近距離で表示される3Dモデルが、他のビルドインシェーダーを使った時と同様に、ショッキングピンクになってしまいます。結局のところ、Nature/Soft OcclusionシェーダーはURPでは使えないようです。じゃあどうすればいいかと言うと、3DモデルにLODを設定します。LODを設定すると距離に応じてモデルが切り替わるようになります。つまり、ビルボードは自分で用意しないといけないようです。今回は面倒だったの、でカリングされるようにしました。車視点では遠景が見えないので、カリングでもさほど気になりませんでした。

ペースノート生成アルゴリズムを改善した

曲率が閾値を超えたらコーナーと判定するよう変更しました。これにより、一つのコーナーが別々のコーナーとして判定されることがなくなりました。分類はかなり大雑把になりましたが、アーケードラリーゲームにはこれくらい粗めの粒度の方が合っている気がします。コーナーのきつさは、コーナー判定された区間の最大曲率から計算しました。平均曲率だと、コーナーの始まりと終わりの低い曲率に引っ張られてほとんどEasy/Midiumと判定されてしまい、うまくいきませんでした。本当はパーセンタイルなどを使ってノイズを排除した方がいいかもしれません。あと、ペースノートを表示するタイミングを早くしました。以前は完全に事後報告になっていたので(笑)

ガードレール生成スクリプトを書いた

ガードレールを生成するスクリプトも書きました。ガードレールがあると緊張感が生まれていい感じです。曲率の高いコーナーの外側と崖に生成されるようにしました。割と妥当な位置に生成されていると思います。Blenderで作ったメッシュをスクリプトで変形しました。Blenderで言うところの配列とカーブのような処理を行っています。メッシュの変形は意外と簡単でした。建物の配置など、色々と応用が利きそうです。

制御点の生成は難しい

高低差を考慮してA*でテレインをなぞればいい感じの道路が作れるのでは、と考え挑戦してみました。最初はグリッド状にノードを配置しました。当然ながらグリッド状だとコーナーの角度のバリエーションが少なく全然駄目でした。ノードの位置に乱数を加えても全然改善されず。そこで、ランダムに配置したノードをドロネー三角形で接続した有機的なグラフを作ってみました。かなり自然な道が生成されるようになりましたが、実際に使うにはまだまだ調整が必要そうです。

Catmull-Romの改良版に感動

恐らく使ったことのある方ならご存知と思われますが、Catmull-Romは制御点の配置によっては奇妙なループやとんがりが発生したりして、意外と使いにくいです。しかしすべての制御点を通り尚且つ計算が簡単なCatmull-Romは非常に魅力的です。どうにかならないものかと色々探していたら、素晴らしい記事を見つけました。要するに、制御点間の距離を考慮してtをいい感じに調節すると言う手法です(多分)。もうゲーム用途なら全部これで良いのではないかと思えるほど素晴らしい曲線が描けます。α=0.5が一番良いそうですが、道路用にはα=1の曲率が穏やかに変化する感じも捨てがたいです。

来週

来週は待ちに待ったunity1week。前回の雪辱を果たすため、前々回の栄光を取り戻すため、面白いゲームを作れるように頑張るぞい。

週報3

今週はよく頑張ったと思います(自分比) 予定していた車関係は完成。コースエディタも概ね完成。色々適当ですが、完璧よりまずは完成(馬鹿の一つ覚え) ゲームを完成させる上で、最も重要な考え方だと思っています。ということで第3回目の週報です。

3Dモデルを作った

やっぱりつれーわ。ただ、ようやくコツを掴めた気がします。

グリッド単位で編集

この機能を使い始めてから、モデリングが格段に楽になりました。狙い通りの形が作れるようになりました。もっと早く知りたかった。

ローポリ、デフォルメは難しいのかもしれない

当たり前ですが、ローポリは少ないポリゴンでそれらしい形を作るセンスが問われます。形を愚直に追っていけば大きくは外さない、ハイポリの方が初心者向きかもしれません。さらにデフォルメの場合、参考にする三面図が存在しません。よって感覚を頼りに形を作る必要があり、センスが問われます。つまり、ローポリ*デフォルメはセンスがかなり要求される組み合わせということです。簡単そうだからこのスタイルを選んだのですが、茨の道だったかもしれません。

UI作った

慣れないInkscapeに悪戦苦闘しました。どうもInkscapeの円整列にはバグがあるように思えてならないのですが、気のせいでしょうか?

路面によって摩擦力やエフェクトが変わる仕組みを作った

以前作ったアセットを流用しました。旋回用のμを変更すると操作感が変わりすぎてしまうので、横力用のμだけ変更するようにしました。雪道のμは0.5に設定したのですが、このくらい低いほうが派手にドリフト出来て、ゲーム的には面白いかもしれません。

コースエディターを大まかに作った

横着するために、一本のスプライン曲線からコースを生成するエディターを作りました。以下のような機能があります。

  • 道路メッシュ生成
  • 道路コライダー生成
  • 道路コライダーに合わせてテレイン変形
  • ペースノート生成
  • セクション生成

スプラインはB-スプラインを採用

当初、UnityのSplinesを使う予定でしたが、制御点を編集すると高確率でPCがフリーズして使い物にならないのでやめました。Unityエディターがフリーズするだけならまだしも、PC自体がフリーズしてしまうのは流石にちょっと… 名誉のために言っておきますが、恐らく私のPCのスペックの問題だと思われます。

以前作った、Catmul-Romスプライン曲線を使うことも考えましたが、Catmull-Romは結構ピーキーで思い通りの曲線を引くのが難しいため、思い切ってB-スプラインで作り直しました。正直、実装が正しいのか自信がありませんが、分類的には、3次一様ノットベクトルB-スプラインになると思います。B-スプラインは、一つの制御点が、曲線の形状に影響を及ぼす範囲が限定的で使いやすいです。逆に滑らかすぎてややメリハリに欠けますが…

テレイン変形は、生成した道路コライダーのポリゴンを元に行っている

xz軸でポリゴンと当たり判定を取り、ポリゴンの頂点から平面方程式を作ってyを求め、その値でテレインを変形させています。数学的なコードはChat GPTが大いに役に立ちました。こういったコードは、自分で0から書くと厄介なバグを埋め込みがちで、正しく動作する状態に持って行くまでに結構な時間を要します。AIを使い始めてから一番AIの威力を感じた気がします。どんどん使って効率化していきたいです。

ペースノートは曲率を元に生成

想像よりずっと難しかったです。というか、現時点ではポンコツです。曲率を元に適当に分類すれば万事OKと考えていましたが、間違いでした。特に、どこからどこまでをコーナーとするのか、が難しい。現状では、カテゴリー化した曲率が連続している区間をコーナーと定義していますが、コーナーの中にコーナーができてしまうなど、課題山積です。

sfc /scannowでPCが快調に

PCの起動時に、Windowsセキュリティセンターサービスが無効になっていますというメッセージが表示されるようになりました。ウイルス感染も疑いましたが、無効化された痕跡はないので、システムファイルが損傷しているのだろうと考え、スキャンディスク(sfc /scannow)を行いました。すると、破損したファイルが見つかり修正したというメッセージが。やはりシステムファイルが損傷していたようです。変なメッセージは消え去り、PCも軽快に動作するようになりました。考えても見れば、OSのような巨大なシステムが特段問題なく動いているのは、奇跡に近いかもしれません。これからは、定期的にスキャンディスクしようと思います。

来週

  • 引き続きコースエディターを作り進める
  • 雑すぎるコードをリファクタリング
  • 地形生成機能を作る
  • オブジェクト配置機能を作る
  • ペースノート生成アルゴリズムを改善
  • 再来週はunity1weekなので、桜井政博氏のYouTubeチャンネルを見て、面白いゲームの作り方を学ぶ

あと、週報を書く時間を短縮するために、やったことをその日のうちにメモっておこうと思います。記憶を頼りに書き起こすのは時間がかかりますし、本当に書きたかったことを忘れてしまいがちなので。

週報2

うわあああもう一週間経ってしもうた。歳を重ねるごとに時の流れが早くなっていく。ということで2回目の週報です。

今週は本格的に寒くなってきたせいか体調をやや崩しました。Unityも風を引いたのか(謎)クラッシュ頻発。ただでさえ低い集中力を何度もぶった切られて作業量は少なめ。しかし先週立てた新しいゲームのプロトタイプを作るという目標は達成できたのでよしとしましょう。

ラリーゲームのプロトタイプを作った

セ○ラリーのようなシンプルなラリーゲームを作ることに決めました。それで早速車の挙動作りに取り掛かったのですが改めてその難しさを痛感しました。過去に散々苦しんできたテーマなのに時が経つと苦痛は忘れてしまうようです。でもそのおかげで何度失敗しても立ち上がることができます(^q^)

大量の毛根の犠牲を払いながら試行錯誤を重ね、最終的に以下のような構成で落ち着きました。

摩擦力は二輪モデルで計算

正直これはそんなに重要ではありません。物理に基づいたモデルなら何でもいいと思います。今回は実装が簡単な二輪モデルを採用しました。極端にホイールベースが短いチョロQ風の3Dモデルを使う予定なのでトルク計算用と横力計算用とで摩擦係数を分けました。トルク計算用は通常のホイールベースの車と同程度の摩擦力が発揮されるように大きめに、横力計算用はドリフトできるように小さめにしました。

RigidbodyのangularDragを3~5程度と極端に大きくする(超重要)

これが最も重要です。angularDragを大きくすることで挙動がマイルドになり操作性が劇的に向上します。雑なステアリング操作をしても一切スピンしなくなります。逆にオーバーステアで前輪が内側に巻き込まれるような挙動も消えてしまいますが、これこそが操作を困難にしている原因なので仕方ないね。何かを得るためには何かを捨てなければならない。世の中はトレードオフな関係で溢れかえっている。辛いね。

正直angularDragを大きくすると車体を直接回転させる方式と似たような挙動になります。じゃあ車体を直接回転させる方式でいいんじゃないかとお思いでしょう。とんでもない。散々挙動を作ってきた私から言わせてもらうと挙動の説得力が段違いです。文章で説明するのは難しいですが車体を直接回転させる方式では決して出せない車っぽさがあります。恐らくスリップ角によってヨーレートが細かく変化するからだと思います。

加速度を捻じ曲げる(超重要)

これもアーケード挙動を作る上では重要です。速度が乗った状態だとキツめのコーナーを曲がりきれずガードレールとお友達になります。物理的には正しのですが、アーケードゲームとしては爽快感が損なわれるので望ましくありません。そこでlinearVelocityをtransform.forward方向に捻じ曲げる処理を書きました。イメージとしてはnewVelocity = slerp(velocity, forward * velocityMagnitude, bendFactor * dt)みたいな感じです。

Unity Recorder使ってみた

最近進捗を動画としてXに投稿するようにしたのですが、ありがたいことに多くの方に見てもらえています。そこで画質にこだわろうと思いUnity Recorderを導入しました。しかし想像以上に録画の負荷が大きくフレームレートを出すためにゲーム側の画質を落としたので結局画質はプラマイ0といった感じ。ちなみに今まではSnipping Toolで録画していました。

Unity6.3にアップデート

6.2からアップデートしました。まだ1日しか使っていませんが明らかに速い。私は古い低スペPCを使っているのでバージョンアップでいつかUnityが動かなくなるのではないかと危惧していましたが、むしろ逆。かつてないほど軽快に動作しています。最高だぜー

来週

来週はコース以外の要素を完成させたい。車の3Dモデル作ったり計器UI作ったり。いつも後回しにしている効果音も付けようと思います。