ブラウザ上に音ゲーを作る構想2

試作してみました。
URLパラメータで飛べるブラウザ音ゲーです。
画面に書いてありますがDVNKを使います。

https://nekokan.dyndns.info/~cerebralmuddystream/GLBMS/index.html?asset=breakthemirror

https://nekokan.dyndns.info/~cerebralmuddystream/GLBMS/index.html?asset=seagreen

ゲーム的にはあまりに素直な「リズムに合わせて叩く」音ゲーです。
一応特色としては、キー音の過剰な強調と
それに合わせた可変長のエフェクトでしょうか。

で、実装に当たり

備忘録的な。

ゲームシステムそのものは何も問題なく実装したのですが。

まあ、なんというか、WebGLで色々ありましてね。
前回のogg問題もそうなんですけどね。

WebGL上だとAudioClipの波形を取得できない

R.I.P. bmsonシステム。
……と終わらせるわけにはいかず、対処法としては、
アセットバンドル化の時にaudioclipの切断処理を組み込んでしまう事。
アセットバンドルで１つのファイルにしている以上、
BMSで問題であったファイルアクセス負荷の問題は解決済み。
寧ろ、内部での切断処理を挟まない分ロードそのものは更に早くなる。
まあ……bmson2bmsみたいでちょっと抵抗はあったんだが……

ネックは、１ファイルにつき１譜面しか作れなくなってしまう事。
まあでも１回ロードすればキャッシュされるからユーザ側から
問題が視覚化される感じは薄いはずだとは思うが……

また、この問題につき、出来ればunity上でoggエンコードしたい。
が、きつい。 unityのnativeプラグインはx64にしか対応しておらず、
これのDLLがオフィシャルで存在しないので自力で作るしかない。
きつい。 まあ時間かけて上手く作るしかない……。

最終的に、
bmsないしはbmsonから音切断処理を実行
⇒oggフォーマットにエンコード
⇒アセットバンドルをビルド

という一連の処理をeditor拡張で自動化する必要がある。かなり重い。

ページ（サイト側）構想

SNS映えを意識するなら、twitterカードは使う必要があるだろう。
できれば、専用サイトの投稿時に作者がサムネ画像を登録できるべきか。
あれ、phpでtwtterカードって動的に変更できるのかな？調べてみよう。

webGLプレイヤーそのものにもSNS性を持たせたい。
SNS性というか、youtubeの関連動画みたいな。
いちいち別ページに飛ぶとwebGLのリロードが無駄なので、
ページはそのままでGL側で別曲を読む感じになると思うけど。

そんな感じの備忘録。

ブラウザ上に音ゲーを作る構想

かぜぎみなのがなおりません。

前回のつづきと思わせてBMSである。

BMSである。

BMSってなんぞやっていうと、ざっくり行ってしまうと
beatmaniaのクローンゲームです。
色々と音ゲー文化史に複雑に絡み過ぎて
ただのクローンゲームで片づけられはしない存在と化しているのですが、
それの云々は今回の主題ではないので割愛します。

https://www.youtube.com/watch?v=iA1-zTtgAGQ

年一回大型イベントがあり、今年のやつに自分も映像担当として出ています。
まあこれも主題ではないのでどうでもいい。

さてBMSですが、その形式ははっきりいってネット進化と照らし合わせると
極めて時代遅れのレガシーなものです。導入には専用本体をダウンロードし、
BMSデータをダウンロードし、PC上から起動しなければなりません。
いろいろなものがブラウザからそのまま出来るこの御時勢に。

こうさ！　WebGLで十分なスペックが出るこの時代には、
youtubeやニコ動みたいにURLにアクセスして出来る音ゲーは作れないか、と。
あとBemuseに触発された

というわけでunityでごにょごにょした備忘録。

WebGLで音ゲーシステム作成

何も障害は無い。

楽曲データとURLの繋ぎこみ

youtubeやニコ動のように、楽曲データとURLが１：１対応するのが理想的。
試したところ、unityのwebGLはApplication.absoluteURLで
問題なくURLパラメータも取れる（URLパラメータ込のアドレスが取れる）
ちょっとセキュリティ的には危ない気がするが実装は可能と言える。

楽曲データ

これが一番の問題であり、今回の主題。
BMSアーカイブを踏襲したもの（シャンシャンは音ゲーとして認めない） を
サーバ上にデータとして置き、それを読みこむのに最適な方法は何か。

１．AssetBundle化してサーバ上に置く
２．フォルダをそのままサーバ上に置く
３．zip圧縮したものをサーバ上に置く

結論から言うと、素直に１の方法しかないっぽい。最大の障害は、
zip圧縮の中にあるoggファイルをデコードするのが困難だったこと。
サーバ直置きならwwwwないしはwebrequestからのgetaudioclipで
問題なく取れるのだが、どうにもoggのデコード、
ファイルストリーム形式で行うのが前提らしく、
zip内に含まれるものをバイナリ配列として取得する所までは出来たのだが、
そこからデコードをかますのが困難だった。 Bemuseどうやってんの

仮にできたとしても、この方法の場合基本的にキャッシュはされない。
動画サイトのそれはともかく、BMS系のアーカイブは容量も結構あり、
毎回ダウンロードを挟むのははっきりいって非効率だし、
サーバ側の負荷も高いだろうと思われる。
（これに関してはBemuseも解決できていない模様）
となると、素直にBMSデータをアセットに置き換えるのがベストだろう。

AssetBundleは作る側に負担がかかるのがデメリット。
アセットバンドルのビルドはUnity本体が必要なので、
作る側にUnityの環境のインストールを強要する事になってしまう。
（ものすごく頑張ればサーバにビルダー置けるかもしれないけど……）

しかし逆に言えば、これは遊ぶ側には何も関係が無い話である。
そう考えると、やはりこれがベストなのだろう。

　総合的な企画プラン

・特定のサーバ（ また猫缶に負担を掛ける気だなお前） に専用サイトを用意
・WebGLとしてプレイヤーを用意。URLパラメータで楽曲データとの紐づけ
・専用サイトに楽曲データのアップローダを用意
　（↑無法地帯になる懸念はある。ファイルロダとしては使えなくする、
　　　作品登録は招待制にするなどの予防法があるくらいか？）
・みんなURLを共有してブラウザ上で気軽に音ゲーしよう！！

作者側は

・アーカイブを作る（bmsonベースかなあ）
・専用のunityプロジェクトからbundle化をかます
　（がんばればサーバにパイプかませそうだけど
　　サーバ詳しくないのでやり方わからん）
・専用サイトからAssetBundleをアップロード、紐づいたURLをもらう

うーん、一応できそうな気はする。

ところで

この話に関しては、BMS及びそれの基であるbeatmaniaの文脈は一度外す。
そもそも今BMSやってる人は、BMSやりつづければいいのである。
主旨としては、そもそもとして、
「インディーの音ゲーがそのままbeatmaniaの文脈に紐づくこと」が
果たして必然か、という疑問があるため。もっと直截に言えば、
BMS形式に縛られたままでいて、音ゲーで遊ぶ事に対しての実現手段として、
beatmaniaの文脈の知識を要求する事が前提になっている現状は
あるいは相当の機会損失が生じていないかと言う事にある。
先にも書いた通り、BMSの導入は今の時代から見ると
相当にレガシーなのだから……

もうちょっと書けることありそうだけどいったん切ろう。

【考察】個人による、中規模ゲーム制作講座かもしれないもの3

さて今回から「実践的製作工程」を踏まえて
書き連ねていきたいと思います。
「ステージが10くらいあるアクションゲーム」を想定します。

Ｘ軸が項目とそのボリューム、
Ｙ軸が作り込みとクオリティを表します。

必然的に、面積が作業量を表すわけですね。

まずシステムを作り上げます。システムが無いと動くわけないですから。

ここで第一の失敗者が現れます。

システムだけに夢中になってしまうパターンです。
最早リソース制作の存在は忘却の彼方であり、エタールートです。

システムは「最低限想定したもの」だけをさっさと作った後は、
リソースに着手しないとなりません。これはモチベーションの問題です。
「最初のシステム開発期間」は１週間が目安だと思います。

ではリソースに制作に移りましょう。
共用リソースは、プレイヤーの画像とかでしょうか。
これは小規模ゲームと何ら変わらないのでなんとでもなるでしょう。
なんなら自分の過去作から流用したっていいのですから。

そしていよいよステージデータ・リソースに着手します。
ここで第二の失敗者が現れます。

俺はクオリティを維持したい！　ステージひとつひとつ作りこむぞ！

物量リソースの縦を伸ばすと面積がどんどん肥大化するのです。
中規模はマラソンです。10kmのマラソンです。
最初の1kmに全力を注ぐと死にます。

死なない方法。
ひとつのステージをﾁｮｯﾄ作ります。
重要事項ではないですが、最初に手加減したステージ１を作るより、
開発した当初の作者の実力で楽しめる難易度を作る事を勧めます。
作者自身のゲーム力にもよりますが、だいたい前半の後半、
ステージ３くらいでしょうか。

さてステージ３ができあがりました。次にやる事は、
ステージ１～１０のデータをコピペして作ってしまう事です。
なんというかライフハックなのですが、「データを作る」が重要で、
データそのものが無いと他のステージを作るのが面倒臭く感じるのですが、
データそのものはあると割と腰を上げて着手しやすくなるんですよね。

あとはじりじりと全体の縦を伸ばしていきます。
ちょっと背景を変え、ステージ固有の敵を少しずつ用意し、
気が向いた時に思いついた地形を作って行ったり……

とまあこんな感じで作っていくと、不思議な事に「完成」が
現実的なレベルで見えてくるようになります。
まあ、まだ「ボリュームの担保」であり、「完成」には至ってませんが。

今回はこのくらいで。次回、「完成」に持ち込むまでの手法論を書いてみます。

【考察】個人による、中規模ゲーム制作講座かもしれないもの2

台風がやばいらしいですが、わたしは気温の変化で風邪気味です。
早期に薬飲んだからか極めて症状軽い状態で持ち直しましたが。

さて、前回からのつづきー。
中規模以上の制作を開始する前に確認しておく心構えなど。

「全てできる」のが大前提

基本的に、「やろうとおもっている事は全てやり方がわかっている」
が大前提です。
「あーいうのがやりたいけど試したことは無い」ものがあるなら、
それの中規模制作はまだ早いです。ミニゲームを作り、
「わからないことは無い」状態に持っていく必要があります。

開発期間は想定の数倍かかる

インタビュー記事、ありますよね、個人開発した人の。
記事内でこういう風に書かれることがあるでしょう。
「このゲームの開発には１年ほどかかった」。
これらは、一年の予定で制作して一年かかった　のではなく、
数ヶ月に予定で制作して一年かかった　のです。

なので、こういう記事の年数をそのままとって、
１年の目途で開発しようと思ってはいけません。３年かかります。

１か月で作りきってやる！　くらいの勢いで望んでも間違いじゃないです。
それでも３か月はかかるのだから。

チーム制作は無理、複数人なら自分＋お助け程度

ここまで個人前提で書いていますが、
絶対に最後まで一人で作り続けなければならない、という訳ではないです。
要所要所で他の方の手を借りるのはアリです。しかし、同時に言えるのが、

・誰一人欠けてはいけない複数人体制は死

ということです。自分以外のメンバーがいるのしても、
基本的には「自分一人でも完成させられる」体制が望ましいです。
雑魚敵枠や、曲関係は製作途中でメンバーが崩れてもなんとかなる部類です。

トータルボリュームは常に意識する

例えば中規模のアクションゲームを作るとしましょう。
この時、肝要なのは「何ステージのボリューム」か常に定める事です。
「やれるだけいっぱいステージ作ろう」は駄目です。３ステージで止まります。
「これは10ステージあるゲーム」と最初からゴールを見据える必要があります。

ただし、このゴールを最初に決めた量から変えてはいけない訳ではありません。
「10ステージは多すぎたから８ステージに減らす」は全然問題ないです。

まとめ

ここに書いてあるのは「個人開発」がベースですが、実際のところ
企業での開発でもある程度通底することです。
企業開発の場合、「工数」やら「予算」やらそういうガチ概念が出てきますが。
あと企業の場合はこれらはプロデューサーとディレクターの仕事です。
勿論プログラマーも、各々のタスクにどの程度の工数がかかるかは
ディレクターと示し合せるわけですが。

今回はこんな所で。次から実際の制作光景あたりに視点を移しましょう。

【考察】個人による、中規模ゲーム制作講座かもしれないもの

世の中に、「ゲーム制作講座」はいっぱいあります。
そして、その講座を見ると、８割はこう書いてあるだろう。

「大作を考えるな。小さなゲームから作れ」

その通りです。　
そしてそれを実行して、小さなゲームを作る。完成させる。公開する。
何も問題はない。

さて、ゲーム作りも慣れてきた。
いよいよミニゲームじゃない、がっつりとしたボリュームのゲームを作ろう！

それでは、「がっつりとしたボリュームのゲーム」はどう作るのだろう？
これがちっとも資料が見つからない。
大抵のゲーム講座は「小さな作品を完成させた！　おめでとう！」
で完結するのである。　そこから先の面倒は見てくれないのである！

というわけで、なんとはなしに徒然と書き連ねてみようと思う。
それなりに書けることあるので複数回にわたるかと。

ていぎ

そもそも中規模とは、具体的にどの程度の規模なのだろう？　個人論ですが、

　・中途セーブが必要なくらい（ジャンルにもよるけど）
　・エンディングまで１時間以上、全要素遊びつくすのに５時間以上

くらいのイメージでしょうか。
まあジャンルにもよるので一概にどう、とはいいきれませんが。
あるいは、

　・個人で開発できる限界ライン（制作お化け除く）

かもしれません。有名タイトルならマリオ１＆２あたりが中規模か。
３は「大規模」だと思います。

中規模の特徴

厳密には「小規模」とは違う所、ですね。大規模以上は考えない。
ぶっちゃけたところ、「システム」は大差ないと思います。
小規模だろうが中規模だろうが大規模だろうが。
データ管理部分くらいでしょうか、中規模以上で新しく要求されるの。

では何が違うかと言うと、やはりリソースの物量でしょう。
グラフィック然り、キャラデータ然り、ステージデータ然り。
そして「中規模ゲーム開発」に挑む際の最大の壁こそが、この物量です。
物量制作において、如何にモチベーションを維持するかが鍵です。

つづく。つづけ。