※ [ディレクターズ・カット版]と書かれたスライドが、この記事を公開するにあたり追加したものです。
※ この記事には多くの画像が貼れれているため、読み込みに時間がかかる可能性があります
ゲーム開発初心者が教えるブラウザゲームのつくり方
2015年末にSIerからフロントエンドエンジニアにジョブチェンジして、さくらインターネットに入社しました。
いまは、さくらのクラウドのネタ機能開発や、自社サービスのエゴサを主な業務としています。ですので、みなさんがツイートされた内容はすべて目を通しています！
また、弊社では「さぶりこ パラレルキャリア」という副業を推奨する制度があり、それを利用して今年の1月からスタートアップ企業でVue.jsをいじっています。
今日の勉強会を開催するきっかけとなった「さくらのINFRA WARS」では、主にゲームの企画・デザイン、プロトタイプ開発、サウンドデザインを担当いたしました。
[補足]
ネタ機能については、「遊び心を実現する技術」と「リリースする度胸」の記事を参照ください。
ゲーム開発初心者である私が、ブラウザゲームをつくるまでに学んだことや、ゲームの仕組みなどを具体的な実装例を交えて発表します。
最後に、「さくらのINFRA WARS」のサウンドデザインについても発表します。
私自身、ゲーム開発初心者ですので、バリバリのゲームエンジニアの方には物足りないかもしれません。そういう方は、次のtownewgokgokの発表（「さくらのINFRA WARS」で 利用されている技術）にご期待ください！
また、この発表を通じて、みなさんがゲームの基本的な仕組みを理解し、実際につくってみたくなることを目指しています。
あとは、さくらインターネットにも「フロントエンドエンジニア」がいることを知っていただき、私たちと一緒に働きたいと思ってもらえればと思います。
さくらのINFRA WARSの紹介
（半数くらいが挙手）
これが、さきほどから名前がでている、「さくらのINFRA WARS」というブラウザゲームです。
ジャンルは「インフラエンジニア育成型サーバー防衛シミュレーション」で、シンプルにいうと攻撃しない防衛特化型の逆シューティングみたいなゲームです。
プレイヤーがインフラエンジニアとなり、サイバー攻撃から身を挺してサーバーを守るという内容です。
このゲームのアイデアは、2017年9月ころに思いつきました。
さくらインターネットに入社して以来、さくらのクラウドのエイプリルフールのネタ機能の開発を担当してきました。
これは会社からいわれたものではなく、「自分のやってみたいこと」を「エイプリルフール」という口実を使ってやっているだけです。
そして、2018年はどうしようかと考えていたときに、ちょうどCanvasAPIを使った機能を実装しており、応用でインフラエンジニア向けのゲームは作れないかと思ったことがきっかけです。
ですが、前職からずっとアプリケーション開発がメインのため、インフラエンジニアの仕事についてよく知りません。
サイバー攻撃なんて、完全に攻殻機動隊の世界のイメージしかないので、たぶん「サイバー攻撃をされたらバリアを張って守っているんだろうなー」、「サーバーが攻撃を受けたら炎上して爆発するんだろうなー」という、私の中の雑なインフラエンジニア像をもとにゲームのアイデアを練っていきました。
ゲームのルールはこんな感じです。簡単なルールですので、実際に遊んでいただければすぐ理解していただけると思います。
そんな感じでプロトタイプを開発して、Slackのさくらのクラウドの企画チャンネルに投稿してみたところ…
なんか知らないうちにすっごい進化していましたｗ
どうやら弊社Slackには「何か」が住み着いているようですｗ
ただ、私はプロトタイプ版までしか作っていないので、それをベースにシンプルなブラウザゲームの開発方法についてこれから発表していきます。
シンプルなブラウザゲームのつくり方
ゲーム開発初心者である私が、ゲーム開発するまでにしたことや、ゲームの簡単なしくみを具体的な実装例も交えて説明していきます。
私の戦いはここからはじまりました。
ちなみにみなさんはゲーム開発についてどんなイメージをお持ちですか？
そこで出てきた、W3Schoolsのゲーム開発チュートリアルをやりました。CanvasAPIの使い方やコントローラ、衝突判定などの実装方法がかかれています。
次にCanvasについてもっと知りたかったのでMDNのCanvasチュートリアルを一通り読みました。有志により多くのページが日本語化されていますので、英語が苦手な方でもスラスラ読めると思います。
2つのチュートリアルが終わって早速ゲーム開発をしようと思ったのですが、複数オブジェクトの管理やタイムの管理方法がわからなかったので、既存のゲームエンジンをちょっとだけ流し読み参考にさせていただきました。
phina.jsとenchant.js、どちらも日本人が開発したライブラリですので、日本語情報が多く読みやすかったです。個人的にはphina.jsがオススメです。
ループの中で、ユーザーの入力を受け付けたり、座標を更新したり、衝突判定をしたり、レンダリング処理を行います。このあたりは順不同ですが、大まかにはこんな感じでゲームが動いています。
プロトタイプ開発をしたときは、このようなクラス設計にしました。
BaseItemクラスに座標やサイズ、衝突判定で使う位置を定義し、それを継承してPlayerクラスやBeamクラスをつくりました。それぞれのクラスでは、座標を更新するためのupdateメソッドや、オブジェクトを描画するためのdrawメソッド、衝突検知したときの処理をするhitメソッドをオーバーライドします。
それらのItemクラスをコアとなるGameクラスに集約し、ループやユーザー入力を受け付けます。
さきほどのクラス図を簡単にまとめるとこんな感じです。
ちょっと語弊はありますが、JavaScriptには一定間隔ごとに実行するためのメソッドが3種類あります。setTimeout、setInterval、requestAnimationFrameです。
このなかでゲーム開発にはrequestAnimationFrameがよく使われます。
理由としては、setTimeoutやsetIntervalは実行間隔を指定できるのですが、ブラウザの状況におかまいなく指定時間間隔で実行されてしまいます。そのため、ブラウザに負荷がかかって処理が遅延しだしたとき、前のループ処理が終わっていないのに次の処理が走ってしまい、バグや画面のチラツキなどの元になります。
対して、requestAnimationFrameは、ブラウザの状況に応じて実行間隔が自動調整されます。基本は60fpsですが、負荷がかかったり、ブラウザがバックグラウンドにいったりするとフレームレートを自動的に調整してくれます。
モダンブラウザはすべて対応していますので、好んでIE9対応をしたい方以外は、requestAnimationFrameを使うことをオススメします。
わかりにくいかもしれませんが、gifアニメーションをよく見てみてください。違いがわかりますか？
「フレームスキップしない」方は、オブジェクトが止まってから動きはじめるまでずっと同じ場所にいます。このように故意にブラウザに負荷をかけてオブジェクトを止めたり、ゆっくり動かすことができてしまいます。
その対策をしたのが、下の「フレームスキップする」です。
こちらは止まってから再度動き出すとき、止まった場所からではなく、先から動きだしています。何をしているかというと、
requestAnimationFrameのコールバックには、呼び出し時の高精度な時間が渡されます。60fpsの場合、その時間と前回実行した時間差は16.66ms（1000msec/60frame）であるべきなので、それより差が大きい場合は処理が遅延していることを意味します。処理が遅延したということは、座標の更新処理などが通常より少ない回数しか実行されていないということです。
そのため、16.66msの差を埋めるために溜まっていた座標更新などを行い、ゲーム内時間を進めています。これでrequestAnimationFrameの欠点が解消されました。
後編に続く
関連記事
以上
written by @bc_rikko
0 件のコメント :
コメントを投稿