作ったもの
達磨落としシンフォニー
右側からコード（和音）の指示が流れてくるので、それに合うようにだるま落としをするゲーム。
作りかけでもう少し作り込みたいと思いながらも、
他にやりたいことが出てくると放置してしまいがちなんだよなぁ。
収穫、良かったこと
新しい分野に挑戦してみたこと
CESA賞のお題が発表されたので、少し意識して音楽系のゲームをなにか作ろうと思い、その流れでリアルタイムの音声データ書き込みを手掛けることに。
音ゲーなので画面と音の同期を取るべしと公式サイトを探し、IAudioStreamの派生クラスを作ってデータを書き込むという方法にたどり着き、実際に作ったことで作れるアプリの幅が広がったのではないか。※公式のサンプルだけだと書き方は分かる一方で使い方が良くわからず、結果試行錯誤しながら作り進めることに
また、自分は作曲趣味はあるものの勘だけで作ってきたので、自分がコードや音楽理論の勉強もできるようなものができればいいということで、コードの種類を当てるようなゲームシステムにしてみたのも今まで作ったゲームの中では珍しい部類だった。
自分用のSiv3Dゲーム用テンプレートを作ったこと
これはお題の発表前に作ったもので、いくつかのシーン実装済みのシーンマネージャー、Iniファイルからのウィンドウサイズ設定読み込みとオプション画面での切り替え、Escキーでアプリ終了させずにタイトルに戻るなどの挙動にする、といった「ある程度ゲームとしての土台ができているもの」を作ったのだが、これは作った甲斐があったしスタートダッシュは非常に良好だった。多少作り慣れた人にはおすすめしたい。
Siv3Dの素のテンプレートのファイルはダウンロードしたての入門として、「これを書けば文字が描けるのか」とかすぐに分かって非常に良いと思う一方、「さあゲーム作ろう！」となった時にはもっとスラスラ作り進められるテンプレートがあるべきなような気がしている。でもこれはすごく汎用性のあるものは難しいので、自分で作るのが一番だろう。
ついにコードの勉強を始めた
「絶対わかる！ コード理論」買いました。
作曲スキルも多分上がるから一石二鳥だったな！
参加してみて思ったこと
モチベーションが爆上がりする
正直、昨年はアドベントカレンダーを書く以外にSiv3Dを触らなかったよう気がする程度にC++プログラミングから遠ざかっていたので今回のゲームジャムには参加しようかどうか迷ったのだが、結果的には参加することでプログラミングへのモチベーション自体が高まり、いい影響のあるイベントだった。
他の人の作品が刺激になる
昔参加していた1週間で作るSiv3Dゲームジャムのときとは違ってZoomでの中間発表があり（時代だなぁ）、他の人の進捗や苦戦の数々を見ることができたり、アイデアの説明を聞くことができたりして、これも自分のモチベーションになったように思う。
GitHub Copilotがとんでもなく強力
見出しの通り。htmlなどで多少使っていて勝手は分かっていたのだが、いざしっかりとコードを打つという時にコード補完機能の尋常じゃない強さには恐れ入った。
サラリーマンしている中では、一言でAI活用に目を向けてると、ぶっちゃけ「そこまでの費用対効果あるか？」と思う場面も多々あるのだが、正直なところコード生成AIは趣味であっても必須レベルに近いと思う。
なんというか、コンパイラや開発環境が無料ではなかった時代に（上達にはお金が必要だという意味で）近づいたような気がしている。今回のゲームジャムでは無料版でなんだかんだ間に合ったが、基本的には有償版が必要な印象だった。
GItHub Copilotは無料版で1000回くらいコード補完でき、VisualStudioも対応するようになっているので使ったことがない人は是非試したほうがいい。カルチャーショックを受けます本当に。
反省点
反省点というか次回の心がけというか。
反省点① ゲーム内に操作法の説明は入れておいたほうがいい
最終発表の後、遊べる作品は殆どの人のをDLして片っ端から遊んだのだが、痛感したのは
「ゲームの遊び方はゲーム内に記そう！」
ということだった。
これは審査された方もそうなんだろうなと思ったのだが、片っ端から遊ぼうとするとそもそもマウスで動かすのかキーボードで動かすのか、それすらも未知なので、アプリの画面に操作法がなければ、ウィンドウを一旦押しのけて作品紹介ページを再度開き、そのテキストを舐め回すように読んで操作法を調べることになる。
で、この作品ページを見るという行為がある種負担のようにも思えてしまったのだ。
タイパが求められる時代なんて寂しい世の中になったねえ、などとか言ったりする自分が、同じ口で作品紹介ページに戻るのはしんどいとか言いやがるのである。
こんな理不尽な事があっていいのだろうか。
……と、まあよくわからないテンションになってしまったが、要するにゲームへのモチベーションを下げさせたくなければ、極力ゲーム内に操作方法を出したりとか、「Hit Enter Key」とか次のアクションを記したりしてあげたほうがいい。PCは特に。
達磨落としシンフォニーはこれさえ気を付けていれば大賞間違いなしだっただろう。うん。
嘘です。
反省点② ミーハーを気取ってC++のmoduleに手を出すのはやめたほうがいい
C++23から、まあ数字が23だったかは今勘で書いているので間違っていても不思議はないのだが、#include に代わって import文が使えるようになっているので、じゃあ物は試しとimportを今回使ってみたりした。
しかし、ただ何となく時代の最先端を気取りたかった二シャスゆえに作品を提出し終わる頃にはmoduleを使うのはやめたほうが良いぞとなった。
これには理由がふたつある。
- Visual StudioのIntelliSenseの挙動がまだ怪しい
- #includeと混ぜて使うと怒られたりする
1.は字の通りである。なんかねぇ、他のファイルの警告表示が消えるのにmoduleだと時間がかかったりするし、IntelliSenseくんがファイルの中身をゆっくりと解釈して消化している間にCtrl+Sでモジュールファイルを上書き保存しようとすると、何故か名前をつけて保存のダイアログが出てきて保存させてくれなかったりしたんですよぉ。
まあこのへんは時代が進めば使いやすくなるんじゃないかと思う。今までみたいに宣言や定義と実装を別々のファイルに分けずに書けるのは嬉しいので将来の発展に期待したい。
2.については、自分が作ったものではないファイル、例えば標準ライブラリ関係は基本的にmodule化されているようで、#includeでもimportでも使えるのだが、#includeとimportはそれぞれ別のヘッダライブラリのように扱われているらしく、混在させると多重定義になってしまい、エラーの嵐になってしまうことがあるらしい、という話だ。
それを考えると、気を使わないといけないのが既存のライブラリとかを組み込んで使うときで、よっぽど新しいライブラリとかじゃないとガッツリmoduleを使っていく構成は無理があるのでは……と思ってしまった。
実際のところ達磨落としシンフォニーはエラーは酷くなくてmodule使った形で提出までやれたのだが、最近やったSiv3Dでない別のプログラムではmoduleをすべてhppとcppファイルに書き直すところまで追い詰められてしまったので、便利な面もあるがもう安易に手出しはしないと思う。
反省点③ 「駄目」の「駄」の字を間違えて覚えてた
楽をしようと筆で描いたのを実写取り込みしてたらこのザマだよ！
リアルで散々話のネタに擦りました（Ryoさんのご指摘に感謝である）。
結論
素晴らしいイベントでした。皆さんありがとうございました！
また参加したいね。