僕が考えた最強のHTML5ゲームのプログラミング環境

「僕が考えた」って訳ではなく、人から色々聞いたりして得た情報を元に自分で実際に作って試してみて、最終的に安定したHTML5ゲームのプログラミング環境を紹介します。

以下が最強だと思う

ツール	用途
Visual Studio Code	ソースコード編集
Chrome	実行 + デバッグ
GitHub	ソース構成管理 + デプロイ

ソースコード編集（Visual Studio Code）
https://www.visualstudio.com/ja-jp/products/code-vs.aspx

Linux, OS X, Windowsで動くかなりシンプルなソースコード編集ツールで、フォルダを開けば、左側のツリーにフォルダ以下のファイルが一覧表示され、右側でソースコードが編集できるというもの。gitリポジトリのフォルダを開けば、差分内容が確認できて便利です。
「Webアプリケーション向け」と謳われてますが、最近はC言語のソースもこれを使って編集しています。IDEAでも良いんですけどね（しかし、IDEAは重すぎるのです...少し高いし）
ビルドはターミナル（WindowsならDOSプロンプト）でOKという人なら、どんな言語でもコレで大丈夫ではないでしょうか。HTML5(js)などのWebアプリケーションなら、ビルドが不要なので、多分これが一番最強だと思います。

実行＋デバッグ（Chrome）
https://www.google.co.jp/chrome/browser/desktop/index.html

右側に表示されているデベロッパーツール（option + command + I）が便利。
コンソール出力の確認、例外時のコールスタックの確認、ブレイクポイントを設定したりポーズしてからステップ実行など、デバッグに必要なツールが一通り揃っています。

ソース構成管理 + デプロイ（GitHub）
ソース構成管理だけならgitで十分ですが、GitHub Pagesを使えばデプロイまで出来てしまうので、GitHubを使うと便利です。

私の場合、リポジトリ作成後にGitHub Pagesを作ったら、gh-pagesブランチをデフォルトブランチにしてmasterブランチを削除しています（つまり、gh-pagesをマスター扱いで使っています）

こうすることで、ソースをコミット（git add -A; git commit）してから git push と叩けば、GitHub Pagesに内容が反映できてしまいます。

あとは、GitHub PagesのURL（http://suzukiplan.github.io/html5-60fps-stg-demo/とか）を公開するWebサイトやブログなどに iframe タグで埋め込んであげれば、デプロイ（公開）までできてしまいます。

<iframe height="480" name="game" seamless="" src="http://suzukiplan.github.io/html5-60fps-stg-demo/" width="480"></iframe>

BloggerをAdSense連携させておけば、万が一ゲームが大ヒットした時にお小遣いが入るかもしれないので、良さげかも。

恐ろしいのは、ここに紹介したすべてのツールが無料ってことですね。
すごい世の中になったものだ...

EnjoyableでMacでWindows用のゲームパッドを使う

家電量販店のPCゲームパッドコーナーに行くと、軒並みWindows用のゲームパッドしか売っていません。稀に「Mac OS X対応」を謳っているゲームパッドも置いてありますが、実際に動かしてみると妙に誤動作をして更にガッカリしたりとか（経験済み）。

色々と試してみたのですが、最終的にココの記事を読んで、Windows用のゲームパッドをキー割り当てして使う方法がベターだと悟りました。（確かSteam Controllerとかもそういう方向性だったような）

ただし、上記の記事では有料アプリしか紹介されていませんが、「流石にこれぐらいのものなら無料であるのでは？」と思って探してみたら、ほぼ同等機能のものが有りました。
https://yukkurigames.com/enjoyable/
何か、見たことのある饅頭がいるな...

そこで、近所の家電量販店で適当に買ってきたゲームパッドをつないでみて確認。
ちなみに、購入したのは ELECOM の JC-U3312SBK。
安かったし、「耐久性」の文言に惹かれました。

早速、JC-U3321SBKをMacのUSBポートに接続して enjoyable を起動。

ちゃんと認識してるみたいですね。
左側のタブに「Elecom Wired Gamepad #1」と表示されているので。

次に、パッドとキーボードのマッピングをします。

1. 左側のツリーから「Axis 1」の「Low」を選択
2. 右側のタブで「Press a key:」というラジオボタンを選択
3. キーボードの左カーソルを押す

と操作すれば、ゲームパッドの十字キーの左 に キーボードの左カーソルキー が割当たります。

少し分かり難いですが、JC-U3312SBKの場合、Axis 1 がカーソルキーのX軸、Axis 2がカーソルキーのY軸となっているようです。ボタンについてはゲームパッド（物理）に描かれている番号とenjoynable上の表示が一致しているので判り易い

それでは、上記の要領で以下のように割り当ててみましょう。
・Axis 1 - Low = 左カーソル (←)
・Axis 1 - High = 右カーソル (→)
・Axis 2 - Low = 上カーソル (↑)
・Axis 2 - High = 下カーソル (↓)
・Button 1 = Z
・Button 2 = X
・Button 3 = SHIFT

上記のキーマッピングは、東方Projectをプレイする想定でJC-U3312SBKのベストだと思われるキー割り当てをしてみた感じのものです。

そして、一通り割り当てたら、画面右上の「＞」というボタンをクリックすれば、マッピングが有効な状態になります。

マッピングの 有効化 / 無効化 の操作は、スクリーン上部のツールバー（下図のアイコン）でもできます。（便利）

実は、GamePad Companionという1000円ぐらいする有料アプリも買って試してみたのですが、そちらには常駐機能が無いのでやや不便です。

下記の記事で実験中のHTML5製STGのデモが、これで遊べることを確認しました。
http://suzukiplan.blogspot.com/2016/03/html560fpsstg.html

HTML5で60fpsで動くSTGが作れる限界を探る

HTML5（JavaScript）で60fpsのSTGが作れる限界点を探ろうという趣旨の記事です。
以下のデモを随時更新していきます。（更新状況はコメントに記載）

（備考）
・PCブラウザ専用（Chrome推奨）
・カーソルキーで8方向に移動
・[Z] キーでショット発射
・[SHIFT] キーで低速移動

（PCブラウザ別の動作状況）
・Chrome: ◯ 正常に動作します
・Safari: △ 音が鳴りません（何らかのプラグインが必要？）
・IE: △ 音が鳴りません（何らかのプラグインが必要？）
・Edge: × 動きません（ロード途中で止まります）
・スマホ全般: × 動きません（ロード途中で止まります）

（ホスティング）
上記のデモははGitHubを使ってホスティングしています。
最初は suzukiplan.com でホスティングしていましたが、HTML5（静的ページ）ならGitHub Pagesでホスティングできてしまいますね。（しかも、修正をgh-pagesブランチへcommit後は git push だけでデプロイまで出来てしまうという手軽さ）
https://github.com/suzukiplan/html5-60fps-stg-demo

Invader Block を HTML5 で作ってみた

ゲームはC言語で作る派のシーラカンス・プログラマな私ですが、一応Web系の企業に勤めているのでJSも書けますよというアピール的な意味で、Invader BlockをHTML5に移植してみました。

・PCブラウザ専用（Chrome推奨）
・カーソルキーで左右に移動
・ブロック崩しの要領で敵を倒す
・メダルを取るとスコアの基点が上がる
・連続してインヴェーダーを倒すと獲得スコアに倍率が掛かる（最大16倍）
・メダルを一定数取ると味方からの援護射撃（レーザー）が来る
・このレーザーはリアルでハードコアなものなので、当たるとプレイヤーも撃破される 

ソースコードを（9leapからもDLできるようにしていますが）GitHubでも公開しています。
https://github.com/suzukiplan/invader-block-5

ターミナルで以下のような感じでコマンドを叩けばローカルで遊べます。

$ git clone https://github.com/suzukiplan/invader-block-5.git
$ cd invader-block-5
$ open local-index.html

※ローカルプレイの場合はリプレイ時はブラウザリロードしてください

今回は、ソースだけでなく、画像や音声（全部自作）もリベラル・ライセンス（CC4）になっていますので、alt Invader Block を誰でも作れるというかなり誰得仕様にしてきました。

ひとつ注意点として、Chrome以外のブラウザでの動作は不完全です。
・Firefox: 音が鳴らない（プレイはできる）
・Safari: 音が鳴らない（プレイはできる）
・IE: 音が鳴らない（プレイはできる）
・Edge: プレイできない（ロード中に止まる）
・スマホ: プレイできない

HTML5の普及がイマイチな原因のひとつがブラウザ依存ですね。性能的な面ならPCブラウザで十分ゲームが作れるけど、結局特定のブラウザでしか完全に動かないのであれば、（ゲームデベロッパ脳で考えると）ネイティブで作った方が性能が良いからネイティブで作るという結論になる。（スマホのWebViewは重すぎるし）

プログラミング環境としては、JavaScriptならC言語とだいたい同じノリで作れるから結構良い感じかもしれません。ゲーム本体のコードは下記で公開していますが、Cプログラマな方にとっては結構とっつき易い感じではないでしょうか。
https://github.com/suzukiplan/invader-block-5/blob/master/game.js
JavaScriptは、データ型と宣言の概念さえあれば、もっと普及した言語だったかも（そこら辺がバグ作り込みリスクがかなり高い）。宣言については use strict で解消できるけど、データ型の件はどうにもならない（だからtype scriptがそこそこ流行っている）という感じか。

【更新】一部iOSアプリがiOS9.2で起動できない件について

久々にSUZUKI PLAN製アプリを（iPod touch 5で）動かしてみたら、起動時に落ちてしまう問題が発覚しました。確認してみたところ、以下のアプリで同件の現象が顕在化します。
・Battle Marine
・Lunatic Clay
・Canon Sniper
・NOKOGI Rider（製品版）
・Invader Block 3

最新のXCODEでリビルドするだけで動くようになったため、iOS側のアップデートで過去のバージョンとの互換性を失う何らかのデグレードがあったものと考えられます。

順次アップデートをしていきますが、最新のXCODEでビルドすると、動作できるiOSのバージョンが4.3以降から6.0以降に変わります。

[追記]
上記ですが、原因が分かりました。ストアからダウンロードせずにXCODEでビルドしたものを使っていて、プロビジョニング・プロファイルの期限が切れていたことが原因でした。という訳で、ストアからダウンロードして動かす分には問題無いことを確認したので、アップデートはしません。

無駄な手順は誰も踏みたがらない

先日、英雄伝説4の原曲集をiTunesで買ってから、ファルコムのFM音源アルバムをiTunesで色々と買い揃えてみました。いや、全部CDで持っているんですけどね。（CDを再生する機械が手元にないから仕方がない）

イース4と風の伝説ザナドゥは、パソコン（PC-98）ではなくPCエンジンが原作なので、原曲 = 波形メモリ音源 or CD-DAですが、PC-98のFM音源（YM2608）で作られた原曲の原曲版です。

98のFM音源で原曲を作ってから波形メモリ音源なり生楽器なりでアレンジしたものをゲームで使っていたようです。チップチューンの頃は、機種毎に音源仕様が全く異なるので、音楽を作る人が最も得意な環境で最初に作ってから、ターゲット機種向けにアレンジするということは割とよくあったのではないかと思います。

こういうのは最近無いですね。

世界樹の迷宮（任天堂DS）など、PC-8801のサンプリング音を使ってBGMを作ったFM音源原曲（？）の比較的新しいゲームとかならあったりしますが。去年YAMAHAがDX refaceという最新のFM音源をリリースしたりした（恐らく現代でもかなり戦力になる音源だと思う）ので、FM音源で作られたゲーム音楽は今後もチラホラ出てくるのではないだろうかと思っています。サンプリング音や生楽器よりも音的にゲームに向いていると思うので。

ただ、私の言う「こういうの」というのは、そういうことではなく、原曲の原案を敢えて8bit機、16bit機のチップチューン音源で作ってから、最新のサンプリング音源で曲を作り直すということ。一見すると無駄手間のように見えます...というか、無駄以外の何物でも無いかもしれません。

いや、もしかすると私が知らないだけで、作曲の最初期の段階では MSX + FB-01（※操作にMSXが必要なオーパーツ的なFM音源）で作り、それを基に最新の機材でアレンジしたものを最終納品物にしているプロが今でも居るのかもしれません。

それなら、原案版のサントラも出した方が売り上げ的な意味でも良いと思うのですが、そういうのが無いということは、やっぱりそういう人は居ないのだろうか。俄には信じ難いのですが。少なくとも私は一見すると無駄手間のように見えるその手順を踏まないと作れないので。

何故か？

うまく説明できないのですが、ノリとしてはこんな感じだろうか。

KOBUSHI mode

前回の記事で書いたFM音源の仕組みを使って、東方VGSにKOBUSHIモードという機能を入れてみました。KOBUSHIというのは演歌のこぶし（小節）から付けた名前ですが、厳密には演歌のこぶしとは若干違います。（単に音をビブラートさせているだけです）

ついでに、Google Play とかで「KOBUSHI」で検索すると何故か太極拳関連のアプリがよくヒットするのですが、太極拳のシンボルマークによく陰陽マーク（？）が見られるので、東方とも相性が良かろうと。

コレとか
（陰陽マークって太極拳のシンボルマークなんですかね）

KOBUSHIモードを入れたAndroid版の東方VGSは昨日リリース済みで、iOS版は昨夜未明に審査に出したところです。（追記: 2016.02.25 released）

KOBUSHIモードで与えているモジュレータのパラメタは、vgs-bgm-decoderのソースコードを参照。
https://github.com/suzukiplan/vgs-bgm-decoder/blob/master/src/vgsdec.c
※VGSDEC_REG_KOBUSHI という名称のレジスタでON/OFF可能な仕様

若干意図した通りの時間経過による波形加工ができていなかったりしますが、お遊び機能なのでまぁ良いかなと。（後でも直すかも）

モジュレータに与えるパラメタを変えることでもっと色々なパターンのKOBUSHIが作れたりします。（KOBUSHIパラメタをお好みに調整できる機能は後で入れるかもしれません）

このKOBUSHIパラメタの調整というのは、要するにFM音源に与える音色パラメタを調整することとだいたい同義です。実際のFM音源とKOBUSHI音源の違いとしては、KOBUSHIの場合、音を揺らす装置（モジュレータ）が１機しか付いていない点かな。つまり、KOBUSHI音源は2オペレータ（1キャリア, 1モジュレータ）のFM音源ということになります。

有名どころのFM音源のオペレータ数としては、DX7が6オペレータ（１キャリア+5モジュレータ）、YM-2203が4オペレータ（1キャリア+3オペレータ）とかだったと思います。オペレータが3機以上あれば、オペレータの並び順（FM音源の世界ではアルゴリズムと呼ばれている）を変えることができたりします。

本格的なFM音源にすると、東方VGSの元データを弄らずに加工することが難しくなるので、再アレンジが必要になりそうな感じですが、それもまた一興かなと。