最初は、以前から作りたいと思っていた2Dローグライク風のゲームを提案しました。ポケモン不思議のダンジョン、Minecraft、勇者のくせに生意気だ。などを参考にしながら、制作開始から1ヶ月ほどはゲーム内容について話し合いました。

テーマとして「冒険」を置き、プレイヤーが「この行動をしたらどうなるのか」という好奇心から仮説を立て、試してみることで予想通り・予想外の結果を見つけられる体験を目指しました。

Rolling Snow の経験から UI は直感的に分かりやすいものを強く意識しました。イラスト担当の一人が UI を作りたいと言ってくれたため、参考資料やリソースの探し方を共有しながら調整し、かなり良い UI にできたと思います。

初期はマップタイルを用いて地面を表現していましたが、自然な地面の模様を作ることが難しく、規則的なパターンになりすぎました。手作業でマスクを描く方法も考えましたが、工数が大きくなりすぎるため別の方法を探しました。

そこで Minecraft の地形生成のようにパーリンノイズを使い、0から255の2次元値を生成し、その値の区間に応じてシェーダーで色を置き換えることで地面の模様を作りました。

この方法により自然な模様を自動生成でき、イラスト担当の負担も減らせました。ダンジョン内の床模様も同様に自動生成し、単調さを減らしました。

また、ダンジョンの暗さや視野を変数で調整できるようにし、たいまつの明かりのようなシェーダーも実装しました。これにより、ゲームらしい雰囲気を出せるようになりました。

ストーリーモードの街マップに移動する際、読み込みが終わるまで画面が固まってしまう問題がありました。そのため、読み込み完了までローディング画面を表示する処理を追加しました。

後から、忘れ物などで隣接マップへ戻るたびに毎回ロードが入るとUXが悪いと考え、直前に遷移したマップの情報をキャッシュしておくことで、隣接した移動では読み込みを挟まないようにしました。

旧サイトでは「記載中...」としていた項目です。

競技で使うサッカーボールを認識する必要があったため、最初はPCとWebカメラを用いて YOLOv5 で画像認識を行いました。学習画像を用意し、PC上ではかなり高い精度で検出できました。

しかし、実際にロボットに載せるカメラは Raspberry Pi カメラモジュールであり、Raspberry Pi 上では YOLO の fps が要求を満たしませんでした。必要だったのは、限られた計算資源の中で 4から6fps 程度、かつ 80%以上の精度で認識することでした。

軽量な YOLO のバリエーションなども試しましたが、最終的には TensorFlow Lite を用いました。既存のサンプルを参考にモデルやコードを変更し、量子化も行うことで、Raspberry Pi 上で約4fps、80%以上の精度を達成しました。

その後、チームとして 10fps 以上、90%以上の精度、より高い安定性が欲しいという要望が出たため、認識用モジュールは Raspberry Pi から Jetson に変更されました。結果的にこの作業はそのまま使われませんでしたが、限られた環境で機械学習モデルを動かす良い経験になりました。

別のソフトウェア班メンバーが競技用シミュレーターを必要としていたため、ROS を用いてシミュレーターを作りました。ロボット工学の知識はあまりなく、Linux や WSL の環境構築にも苦労しましたが、rviz や Gazebo に触れながら制作しました。

青い扇形の部分はカメラの検出範囲を表しており、仮想的な箱型ロボットに対してルート設計を試せるようにしました。rostopic で操舵を制御でき、別ターミナルからコマンドを送って動かせるようにしていました。

当時所属していた部活動で、外部コンテストへの参加文化が少ないと感じていました。挑戦する文化を作りたいと思い、メンバーを集め、先生にも相談して参加に向けて動きました。

開発はプログラム、プロジェクター側(Raspberry Pi など)、サーバー側に分かれて進めました。私はプログラム班のリーダーとして React Native と Expo を初めて本格的に触り、C言語やJavaとは違う開発に苦労しながらも、深夜までデバッグして学びました。

この経験から、必要な技術は必要になった時に学んで身につければよい、技術はあくまで目的のための手段である、という感覚を得ました。

チームリーダーとして、各メンバーがやりたいことや得意なこと、モチベーションを聞きながら作業を割り振り、困った時にすぐ相談できる雰囲気を作ることを意識しました。

BPM解析の部分は難しく苦労しましたが、最終的には実装でき、社員の方から「チャレンジングなところを攻めるな」と言っていただきました。最終発表も上手くいき、社員の方や人事の方からも評価していただきました。

毎日の終わりに KPT(Keep / Problem / Try) をホワイトボードに書いて振り返り、進捗や問題を話し合ったことが特に印象に残っています。リーダーとして責任を持つこと、コミュニケーションを取ること、難しい部分を自分が引き受けてチームを支えることの大切さを学びました。

雪玉が大きくなるほど操作が難しくなる面白さを狙って設計しました。Unity インターハイでは一次審査を通過しましたが、最終審査には進めませんでした。審査員の方からは、操作が難しく、楽しさや爽快感が足りないというコメントをいただきました。

この経験から、自分が設計した面白さがそのまま良いUXになるとは限らないことを学びました。

その後、学祭で販売するために、ゲームが得意な人・苦手な人の両方にテストしてもらいました。最初のステージを苦手な人でもクリアしやすいように調整し、説明書を読まなくても遊べるよう UI も改善しました。結果として、「操作が楽しい」「スピード感が爽快」といった感想ももらえました。

高専1年の頃に作った簡単な弾幕ゲームです。Processing を用いて、Java の class の使い方を練習しました。弾の計算を通じて三角関数や円の当たり判定も練習しました。

高専1年の頃、先輩から「プロ生ちゃん」を使ったゲームコンテストの話を聞き、練習として参加しました。キャラクターを選択して上にジャンプしていくシンプルなゲームで、キャラクターごとに二段ジャンプやロングジャンプなどの性能差を付けました。

Processing ではなく Java で一から作ったため、ライブラリなしでのゲーム制作に苦労しました。継承やオーバーライドの練習にもなりました。

高専1年の頃に作った、アイテムをキャラクターに渡すと別のアイテムと交換してもらえるゲームです。昔遊んだ「クター」のミニゲームをもとに作りました。

この頃は、なるべく綺麗なコードを書くこと、マジックナンバーを減らすこと、名前を分かりやすくすることを意識していました。後に Processing 版も作り、UI を改善しました。

高専2年頃に C++ で行った実験です。場所ごとのベクトルが時間で変化していれば、ゲーム内の動きなどを簡単に作れるのではないかと考えて作りました。研究で扱うベクトル場に近い概念を、自分なりに思いついて試していたことが印象に残っています。

高専3年の頃、友人と学校で遊ぶために作った「刹那の見斬り」のような居合ゲームです。友人に絵を描いてもらい、Processing で1日ほどで作りました。マウスの左クリックと右クリックで2人対戦できます。

旧サイトでは「記載中...」としていた項目です。