VGS-Zero版Battle Marineの開発状況をツイッター（X）で日々報告してみるようにしているところです。

ツイッター上で色々なクリエイターさんが実践されているヤツの真似事ですね。

ゲーム開発内容を短文で説明するのが大変なので、短い動画付きツイートをするようにしています。（別に動画縛りという訳ではないですが、今の所100%動画ツイートのみ）

動画ならSlack等のチャットでも齟齬が無く伝わり易いので、本業（※フルリモート）の方でもガリガリ活用していることもあり、macOSのQuickTimeの画面収録機能+iMovieで解説動画を撮影 & 編集することにはそこそこ慣れています。（macOSだとデスクトップ音声の収録が出来ないので音声付きの動画作成は結構面倒なのが難点ですが）

YouTubeでよく見られる解説動画のように字幕やゆっくり音声での解説はしません。編集がかなり大変ですし、Twitter、Slack、Discordならテキストと組み合わせれば良いので。

ツイッターのプレミアム会員（月額会員）ではないのですが、動画が短尺（1分以内）でしか投稿できない制限があるのも逆に良いです。（尺制限が無いと無駄に「大作化」しがちなので）

ツイッターでよく見られるクリエイターさんの進捗報告みたいなツイートは、ファンサービスを含むコミュニティーマネジメント的な文脈で実践されているものだろうと思って眺めていましたが、実際にやってみるとナメクジ程度のスピードでも毎日着実に進捗が出ているような気分になれたので、実は開発マネジメントの手法としても良いものなのかもしれません。

報告ツイートが形骸化・義務化すると多分生産性に悪影響があるので、実際の生産性に寄与しているのかは不明ですが。

今後も続けるかは分かりませんが、とりあえず5日連続で続けることができたので3日坊主は回避しました。

負担にならない範囲で続けていこうと思っているところです。

ただ、無理に毎日ツイートするつもりはなくて、進捗があった日限定 & 1日1ツイート以下が目標です。

また、ある程度の文量が溜まったらサマリーをnoteに纏めてみようと思っています。（これも続くかは分かりません）

1月1日 タイトル画面の実装

私はゲームを開発する時に最初にタイトルを決定してタイトル画面から作り始めます。

今回はVGS-Zero対応のゲーム第1弾ということで、VGS-ZeroのVDP（グラフィック）機能をフルに使った形にしてみました。

具体的には、BGを縦スクロールしながら横方向のラスタースクロールでうねうねさせ、タイトル画像（タイルパターン）とテキストをFGに描画し、スプライトで泡のようなものをランダム描画しています。

1月2日 トランジション実装

最大限に手抜きをしようと思えばタイトル→メイン画面へパッと一瞬で切り替えれば良いのですが、VGS-ZeroならFGを使って画面マスク方式でのトランジション実装が簡単にできるので無駄に頑張ってみました。

ゲーム開発というのはこういった合理的に考えれば「要らないんじゃない？」という無駄を、賽の河原の石積みのように（？）無限に積み重ねていくことが重要だというのが私見です。（経験上、合理的に作ってしまうとだいたいツマラナクなるので）

もちろん、「ハードの限界まで」という制約はありますが。

VGS-Zeroの場合、FGのレイヤーは1つしか無いので最初にFG（タイトル画像とテキスト）をラスタースクロール（MSX2+のBIOSブート画面風）で画面外に掃け、その後アニメーション付きのFGで画面全体をファードアウトしています。

フェードアウト後にメイン画面へのフェードインをしていますが、この時、本来FGに描画するスコアを一旦BGで表示して、フェードインが完了後（メイン画面に処理が移った後）BG→FGへ描画を移すという結構手間が掛かる実装をしています。

非合理な意思決定を実現するには合理的なパズルが必要です。

1月3日 プレイヤー移動 & ジャンプ

VGS-Zeroの解像度は 240x192 なので、座標系は8bitの符号なし整数（uint8_t）で管理できますが、整数座標系だと視覚効果が悪くなってしまうので少数点数で管理しています。

最近の普通のコンピュータなら浮動小数点数を使えば良いと思いますが、VGS-ZeroのCPU（16MHzのZ80）にはFPUが無いので16bitの固定小数点数を使っています。

/* 16bit固定小数点数型の宣言 */
typedef union {
    uint16_t value;
    uint8_t raw[2];
} Var16;

昨今のプログラムではあまり使われない union 型ですが、16bit固定小数点数を使う用途としてはかなり有用です。

具体的には、以下のように使うことが出来ます。

// 変数宣言 & 0初期化
Var16 x;
x.value = 0;

/* 少数点数を用いてX座標を動かす (整数は×256 & 256未満は少数) */
x.value -= 256 + 128; // 左に1.5ピクセル移動
x.value += 768 + 64;  // 右に3.25ピクセル移動

/* 整数だけ用いて高速にX座標を動かす (raw[1] = 整数, raw[0] = 少数) */
x.raw[1] -= 8; // 左に8.0ピクセル動かす
x.raw[1] += 15; // 右に15.0ピクセル動かす

ファミコンのCPU（6502）だとレジスタ数が少ないのでADC, SBCなどのキャリー演算を駆使する必要があり実装が面倒ですが、Z80ならペアレジスタを用いて（比較的）高速に256.0未満の固定小数点数を扱うことができて便利です。（C言語だとあまり便利さが実感できませんが）

固定小数点数が扱いにくいファミコンのソフトでも、大半のゲームのキャラクタ座標系は整数（8bit）ではなく16bit固定小数点数を用いていて、例えば、スーパーマリオブラザーズはもちろん、初代マリオブラザーズも固定小数点数を用いて慣性のある動きが実装されています。

VGS-Zero版Battle Marineでは座標系を小数点数で管理していることが微妙に分かりにくい程度の軽めの慣性を入れました。慣性が無い方が操作しやすいので。

ただ、慣性があることで脳が「画面が滑らかだ」と錯覚する視覚効果があるので、慣性処理の施されたゲーム（大半のゲーム）のプレイに慣れた後で慣性処理をしていないゲームをプレイすると動きがショボく（≒クオリティが低く）見えてしまいます。

CPUリソースが乏しいファミコンでも、大半のゲームでは頑張って座標系を固定小数点数にしていて、その体験に慣れたユーザはシンプルな整数座標系のゲームをプレイした時「マリオと違って操作性悪いな…」という残念な感想を抱くことになります。

一定のクオリティを保つことが死活問題になる市販ゲームでは、少数点数座標系による慣性処理の実装が（FPUが無かった or 貧弱だった8bit〜16bit世代の頃でも）事実上必須だったものと考えられます。

なお、VGS-Zeroの解像度は240x192ですが内部座標系は256x256になっていて、左右と上の8px、下の72pxは常時マスクという形になっているので、16bit固定小数点数による座標系の管理が最も扱いやすい仕様になっています。（このハードウェア設計は偶然ではないです）

1月4日 水しぶき演出の強化

細かい演出を1つ作るのも結構大変だったりしますが、こういったものを何百と作り込むことで、ゲームに良い感じにカオスな味が出てくることが稀によくあります。

そろそろゲームの骨格が見えて来たので、音関係に着手した方が良い頃合いです。

作曲が上手な人なら、後からゲームに合わせた音楽を狙って創れるかもしれませんが、如何せん私にはそれだけの器用さは無いので、まずは音楽を作り、その音楽に合わせてゲームを創っていくやり方にしています。

ただ、何のテーマもなく作曲することもできないので、ある程度の骨格が見えてくるこれぐらいのタイミングがベストです。（面倒くさいｗ）

1月5日 タイトルのBGMを作曲

作曲をする時に一番大変なのは動機（モチーフ）を考えることです。

良いモチーフさえ決まれば手癖だけで何となくそれっぽく纏めることができる気がするのですが、モチーフが微妙だと全く手が進まなくなります。

という訳で、今回はモチーフは自分で考えず、Battle Marine繋がり（？）で軍艦行進曲（軍艦マーチ）のイントロと第一主題の一部をパクってみました。

軍艦行進曲は1991年に著作権が切れているパブリックドメインな著作物なので、モチーフだけでなく楽曲をそのまま使っても法的には何も問題無いと思います。

ちなみに、軍艦行進曲はミャンマー国軍の公式軍歌としても採用されているようです。

軍艦行進曲がミャンマー国軍の軍歌になった経緯については、防衛省のウェブサイトに掲載されていたので引用しておきます。