本記事はHTML5 Japan Cup 2014で優秀賞を頂いたEnraged Fowlsというゲームについての技術解説後編です。前編はこちらです。

物理エンジン

前編ではスリングショットコントローラーについて説明しましたが、ゲーム本体の技術要素についてはほぼ触れていませんでした。Enraged Fowlsでは弾が飛んでいく動きや、弾がぶつかって崩れるブロックの動きなどを実現するために、物理エンジンを使用しています。物理エンジンは文字通り、物理的な運動をコンピューター上で模擬してくれるライブラリで、特に今回のアプリのような物体同士の衝突を処理する必要がある場合に有用です。Enraged Fowls技術解説後編では、この物理エンジンについて簡単に説明します。

cannon.js

cannon.jsについて

3次元を扱えるものに限っても、JavaScriptで実装された物理エンジンはいくつかあります。Enraged Fowlsではその中からcannon.jsという物理エンジンを採用しました。これは他の物理エンジンの多くが他言語製物理エンジンの移植で、インターフェースに違和感があったのに対して、cannon.jsはJavaScriptで新たに作成された物理エンジンなので、インターフェースが素直に見えたことと内部構造がシンプルだったためです。

なお、実際のEnraged Fowlsのコードは自作のライブラリを使っていて、物理エンジンの説明向きではなかったため、今回使用しているサンプルコードは、すべて説明用に単純化したEnraged Fowlsから抜き出したものになっています。単純化したコードの全文は以下にありますので、適宜参照してください。

簡易版Enraged Fowlsのコード全文

全体的な流れ

物理エンジンは、物体の位置や向きを計算してくれるだけで、物体の表示には関知しません。表示に関しては、three.jsをいつも通りに使うことになります。両者を組み合わせる場合の基本的な流れは、次のようになります。

1. 物理エンジンを初期化
2. three.jsを初期化
3. 物理エンジンに物体（形状・位置・向き・速度など）を登録
4. three.jsに物体（形状）を登録
5. 物理エンジンの物体とthree.jsの物体を関連付け
6. 以下を繰り返し
   1. 物理エンジンに登録された物体の次の位置と向きを計算
   2. three.jsの物体の位置と向きを、物理エンジンの関連する物体と同期
   3. three.jsの表示を更新

物理エンジンとthree.jsで、別個に物体を扱っているのが冗長に感じられるかもしれませんが、これには理由があります。両者を区別していることで、1つの物体に対して2種類のモデルを使用できるのです。例えばthree.js内で複雑な人型として扱われているオブジェクトを、物理エンジン内では単なる直方体として扱い、当たり判定を簡略化することができます。

上記のリストで重要なのは、5と6-2です。基本的にはオブジェクトの位置と向きは物理エンジンが管理し、オブジェクトの（表示される）形状はthree.jsが管理しますが、それぞれの情報の関連付けは開発者に委ねられます。5と6-2は、この情報の関連付けを処理しています。

本記事での解説は、上記の物理エンジンに関わる部分を抜き出す形で行います。

物理エンジンを初期化

AngryBirds.Game.prototype = {
  constructPhysicalWorld: function() {
    this.cannonWorld = new CANNON.World();
    this.cannonWorld.gravity.set(0,-9.82,0);
    this.cannonWorld.broadphase = new CANNON.NaiveBroadphase();
    // ...snip...
  },
}

cannon.jsでは、物理エンジンの実体はCANNON.Worldオブジェクトです。物理エンジン全体に関わる設定や処理は、このオブジェクトを通じて行います。設定しているプロパティはそれぞれ、gravityは名前の通り重力、broadphaseは「衝突している可能性のあるオブジェクトの組み合わせを見つけるアルゴリズム」です(注1)。設定できる値はほかにもありますが、とりあえずこの2つをこの通りに設定しておけば動作します。

注1: 通常、物理エンジンは衝突判定をBroad PhaseとNarrow Phaseの2段階に分け、はじめにBroad Phaseで衝突している可能性のあるオブジェクトの組み合わせをなるべく素早く見つけ出し、次にそれらのオブジェクトが実際に衝突しているかどうかを、Narrow Phaseで厳密に検査します。Broad Phaseのアルゴリズムは、物理エンジンのパフォーマンスに大きく影響を与えるため、cannon.jsではプロパティとして与える形でその変更を容易にしています。

物理エンジンに物体を登録

AngryBirds.Game.prototype = {
  constructPhysicalWorld: function() {
    // 地面
    var groundShape = new CANNON.Plane();
    var groundWeight = 0; // 固定
    this.cannonGround = new CANNON.RigidBody(groundWeight, groundShape); // ...(1)
    this.cannonGround.quaternion = new CANNON.Quaternion();
    this.cannonGround.quaternion.setFromAxisAngle(new CANNON.Vec3(1, 0, 0), -Math.PI / 2); // ...(2)

    // 鳥
    var birdShape = new CANNON.Sphere(0.5);
    var birdWeight = 10;
    this.cannonBird = new CANNON.RigidBody(birdWeight, birdShape); // ...(3)
    this.cannonBird.position.set(0, 2.5 + 2 + 0.1, 0);

    // CANNON.Worldに追加
    this.cannonWorld.add(this.cannonGround);
    this.cannonWorld.add(this.cannonBird);

    // ...snip...
  },
}

cannon.jsでは、物体はCANNON.RigidBodyオブジェクトとして表され、物体の位置や向きの設定などはこのオブジェクトを通じて行います。ただし、物体の形状はCANNON.RigidBodyオブジェクトからは分離されていて、その指定にはCANNON.Shapeオブジェクトのサブクラスを使用します。上記の例では、CANNON.Plane（平面）とCANNON.Sphere（球体）を利用していますが、それ以外にも以下のような形状が使用可能です。

• CANNON.Sphere: 球体
• CANNON.Plane: 平面
• CANNON.Box: 直方体
• CANNON.ConvexPolyhedron: 凸型多面体
• CANNON.Compound: 上記の組み合わせ

なお平面はデフォルトではz軸に垂直ですが、cannon.jsでは重力はy軸に垂直なので、地面として使用するためにquaternionを設定して、x軸に対して90度回転させています。

物理エンジンの物体とthree.jsの物体を関連付け

物理エンジンの物体とthree.jsの物体を関連付けについては、特に決まったやり方はありません。管理する物体の数が少なければ、単純に1つの物体に対してcannon.js用とthree.js用、2種類のオブジェクトを用意すればいいでしょう。今回の単純化したコードでは、threeFooとcannonFooという2変数で管理しています。

AngryBirds.Game = function(opts) {
  // ...snip...
  this.threeGround = null;
  this.threeBlocks = null;
  this.threeBird = null;
  this.cannonGround = null;
  this.cannonBlocks = null;
  this.cannonBird = null;
};

実際のEnraged Fowlsでは、three.jsのオブジェクトとcannon.jsのオブジェクトを1つにまとめて使うためのc3.jsという簡単なライブラリを作成しましたが、まだ公開するような完成度ではないので、ここでは説明を省略します。

物理エンジンに登録された物体の次の位置と向きを計算

this.cannonWorld.step(1.0/24.0);

物体の位置を更新するには、CANNON.Worldオブジェクトのstepメソッドに経過時間を渡します。これだけで先にaddした物体間の衝突が処理され、位置や向きがそれぞれの運動状態に応じて更新されます。

three.jsの物体の位置と向きを、物理エンジンの関連する物体と同期

this.threeBird.position.copy(this.cannonBird.position);
this.threeBird.quaternion.copy(this.cannonBird.quaternion);

先ほどCANNON.Worldオブジェクトのstepメソッドを呼び出しましたが、このメソッドはCANNON.RigidBodyの位置と向きを更新するだけです。表示位置を更新するには、描画の前にthree.js側のオブジェクトとcannon.jsのオブジェクトの位置を同期する必要があります。cannon.jsはthree.jsと組み合わせて使うことが初めから想定されているため、これは非常に簡単です。three.jsのオブジェクトのpositionプロパティ（位置）とquaternionプロパティ（向き）に、cannon.jsのオブジェクトのそれらをcopyしてください。これだけで位置と向きの同期が実現されます。

ここまでの実装を行うと、次のように衝突がそれっぽく扱われるようになります。

物理エンジン前（貫通）

物理エンジン後（瓦解中）

まとめ

モデリングツールを覚えるような時間もモチベーションもなかったため、Enraged Fowlsはthree.jsに用意されている基本図形だけでできています。それでも物理エンジンを使用すれば、その動きで見た目をある程度はカバーできていると言っていいのではないでしょうか。

今回の記事から分かる通り、物理エンジンの利用は存外に簡単です。初期位置を登録してstepメソッドを呼び出し結果を表示に反映させる、これだけです。three.jsを使用して単なるビューアーに留まらないインタラクティブなアプリを作るのであれば、物理エンジンを採用しない理由はありません。本記事を参考に、ぜひいろいろと試してみてください。

本記事はHTML5 Japan Cup 2014で優秀賞を頂いたEnraged Fowlsというゲームに関する技術的な解説の前編です。

Enraged Fowlsとは

タイトルに使われているのは聞きなれない単語かもしれませんが、それぞれ類語辞典で調べたAngryとBirdの同義語です。「Angry Birds」については、おそらく皆さんご存知でしょう。全世界で累計15億ダウンロード（Wikipedia）されたアクションパズルゲームで、物理エンジンを使用してスリングショットで撃ち込まれた鳥と、それにより崩れ落ちるブロックのリアルな動きを実現していることが大きな特徴です。上のスクリーンショットからも分かる通り、「Enraged Fowls」はこの「Angry Birds」を3Dにすることを目指したものです。

　加えて、Enraged Fowlsならではの機能としてスマホをセットして使用できる、スリングショット型のお手製コントローラーがあります。当コントローラーを使用すれば、モニターの中の世界に対して、実際にスリングショットで鳥を撃ちこんでいるような感覚を得ることができます。

技術要素

Enraged Fowlsの技術的な見どころとしては大きく

1. スリングショットコントローラー
2. 3Dの表示と動き

の2つがあると考えています。具体的な技術要素を挙げると以下の様になるでしょうか。

• WebRTC（スリングショットコントローラー）
• Web Workers（スリングショットコントローラー）
• WebGL（three.js）
• 3D物理エンジン（cannon.js）

この中でthree.jsについては、今回の「HTML5 Japan Cup 2014」の優秀・最優秀作4作品のうち、Enraged Fowlsを含む3作品が使用していることもあり、おそらく別の記事で解説されると判断して、本記事では説明を省略します。HTML5 Experts.jpにもthree.jsの解説記事がありますので、そちらを参考にしてもいいでしょう。

初心者でも絶対わかる、WebGLプログラミング＜three.js最初の一歩＞

また（three.jsを除いても）上記すべてを一度に解説することができなかったため、今回はスリングショット部について解説します。物理エンジンに興味のある方は次回までお待ちください。なお、Enraged Fowlsのソースコードは以下で全て公開されています。必要に応じて参照してください。

Enraged Fowlsのソースコード

スリングショットコントローラー

スリングショットコントローラーは、本物のスリングショットのようにコントローラを移動して狙いをつけます。そして、ゴム紐を引いて手を離し弾を撃つという操作を、ウェブカメラとスマートフォンの加速度センサーを利用して実現したものです。

（もちろん上記のような工作をしなくてもスマートフォンさえあれば、ウェブカムの前にかざして画面をタップするか端末の裏面を指で弾けば動作を確認することができるので、よかったら試してみてください）

ウェブカムによるスマートフォンの位置の特定

ウェブカメラに写るスマートフォンの位置を取得する方法は、正直かなり手を抜いていて、スマートフォンの画面を真っ赤にし、ウェブカムの「赤い部分」の平均値をスマートフォンの位置と見なしています。スリングショットコントローラーは、締め切りの一週間ほど前に、ふと思いついて追加した機能です。まず簡単な方法で実装して動作や使用感を検証し、精度が足りないようなら後できちんとしたやり方にしようと考えて実装しましたが、ちょっと遊ぶ分には大して問題もなかったため、結局そのまま今に至っています。まぁよくあることです。

（右側の画像の緑のドットが”赤”と認識された箇所です）

ソースコードの該当部分を以下に抜粋します。

Detector.prototype.startCamera = function() {
  // ウェブカムの映像取り込み
  navigator.getUserMedia({video: true}, // ... (1)
    function(localMediaStream) {
      // ウェブカムの映像をvideo要素で表示
      this.video.src = window.URL.createObjectURL(localMediaStream); // ... (2)
      this.video.play();
    }.bind(this),
    function(err) { ... }.bind(this)
  );
};

Detector.prototype.startWorker = function() { // ... (3)
  // 画像解析用WebWorker開始
  this.worker = new Worker('js/detector_worker.js');
  this.worker.addEventListener('message', function(event) {
    // WebWorkerから返された解析結果を処理
    this.detectHandlers.forEach(function(handler) {
      handler(event.data, this.gc);
    }.bind(this));
    if (this.isDetecting) setTimeout(this.detect.bind(this), 10);
  }.bind(this));
};

Detector.prototype.detect = function() { // ... (4)
  // video要素の内容を取り込んでWebWorkerで処理
  this.gc.drawImage(this.video, 0, 0, this.video.width, this.video.height);
  this.worker.postMessage(this.gc.getImageData(0, 0, this.video.width, this.video.height));
};

スマートフォンの位置の特定は、Detectorオブジェクトで行います。Detectorオブジェクトはdetector.jsとdetector_worker.jsの2つからなっていて、detector.jsではnavigator.getUserMedia関数を使用してウェブカムの画像をvideo要素に取り込み(1)(2)、画像解析用のWebWorkerを開始し(3)、定期的にvideo要素の内容をWebWorkerに送ります(4)。現在のところdetector_worker.jsでは非常に単純な解析しか行っておらず、WebWorkerを使わなくてもそれほど問題にはならないかもしれませんが、将来的に複雑な解析を行うことを可能にするために、バックグラウンドで処理しています。

// 直近10回の解析結果を保持
var centers = [];

addEventListener('message', function(event) {
  var imageData = event.data;
  var data = imageData.data;
  var redPoints = [];

  // 画像データを走査して赤い部分（isRed）の位置を記録
  for (var x = 0; x < imageData.width; x+=5) {
    for (var y = 0; y < imageData.height; y+=5) {
      var base = x * 4 + y * imageData.width * 4;
      if (isRed(data[base], data[base+1], data[base+2], data[base+3])) { // ... (5)
        redPoints.push({x:x, y:y});
      }
    }
  }

  // 直近10回の赤い部分の中心位置を記録
  var center = getCenter(redPoints);
  while (10 <= centers.length) centers.shift();
  centers.push(center);

  // 直近10回の平均位置を取得
  var centerAverage = getCenterAverage(centers); // ... (6)
  
  // WebWorker呼び出し元に結果を返却
  postMessage({
    redPoints:{points:redPoints, center:center, 
      centerAverage:centerAverage, size:redPoints.length}
  });
});

function isRed(r, b, g, a) {
  // なんとなく赤っぽい色を判定
  return 250 < a && 100 < r && g < r/2.0 && b < r/2.0;
}

先に書いた通り、detector_woker.jsの中心的な処理はImageDataオブジェクト内の赤い部分を抜き出して、その中心位置を返すことです。基本的にはImageDataの画素の色をチェックしているだけですが(5)、特に厳密な解析も不要なので全画素をチェックするのではなくある程度間引いた値をチェックし、それにより発生するチラツキを直近10回の解析結果の平均を返すことで防いでいるのが(6)、工夫といえば工夫です。

ちなみに、「赤い部分の位置の平均を取るだけだと服や部屋が赤かったりすると問題が起きるんじゃないか？」と思う人もいるでしょうが、おっしゃる通り、割と大変なことになります。

解決策はいろいろあると思うので、まぁ読者の皆さんへの宿題というか、pullreqは随時受付中です。

Detectorオブジェクトの利用

this.detector = new Detector();
this.detector.addDetectHandler(function(data, gc) {
  // ウェブカム画像内のスマートフォンの位置を正規化
  var center = data.redPoints.centerAverage;
  var dx = center.x / Detector.DEFAULT_WIDTH - 0.5;
  var dy = center.y / Detector.DEFAULT_HEIGHT - 0.5;

  this.cameraDirection = new THREE.Vector3(0, 0, 5);

  // y軸方向の位置を射出の縦方向に変換
  var yAxis = new THREE.Vector3(0, 1, 0);
  var yawAngle = -dx * Math.PI/2;
  var yawMatrix = new THREE.Matrix4().makeRotationAxis(yAxis, yawAngle);
  this.cameraDirection.applyMatrix4(yawMatrix);

  // x軸方向の位置を射出の横方向に変換
  var xAxis = new THREE.Vector3(1, 0, 0);
  var pitchAngle = -dy * Math.PI/4 - Math.PI/8;
  var pitchMatrix = new THREE.Matrix4().makeRotationAxis(xAxis, pitchAngle);
  this.cameraDirection.applyMatrix4(pitchMatrix);

  // 視点とカメラの向きを射出方向に合わせて変更
  this.world.threeCamera.position.copy(new THREE.Vector3().copy(
    this.bird.threeMesh.position).sub(this.cameraDirection));
  this.world.threeCamera.lookAt(this.bird.threeMesh.position);
}.bind(this));
this.detector.start();

Detectorを利用する側のコードは、上記のようになります。Detectorオブジェクト自体はなるべく汎用的にしたかったので、Enraged Fowls独自の処理はaddDetectHandler関数で、利用側がハンドラ登録するようにしています。

一見複雑な処理にみえるかもしれませんが、要は下の図のように、目の前に固定されたスリングショットがあるイメージで、ウェブカム映像内でスマートフォンが写っている位置に応じて、撃ち出す方向や視点を変更しているだけです。具体的な座標変換についてはコードが全てですし、説明を省略します。

加速度センサーによるゴム紐リリースの検知

スリングショットで狙いを付けることができるようになったので、次にゴム紐を伸ばして離すことで、狙いをつけた方向に鳥（弾）を撃てるようにします。正直なところ、これも非常に手を抜いたやり方で実装しています。

window.addEventListener('devicemotion', function(event) {
  var threshold = 5;
  if (threshold < Math.abs(event.acceleration.z)) {
    toggleMarkerColor();
  }
});

windowオブジェクトのdevicemotionイベントで、端末にかかる加速度を取得できます。スマートフォンの画面に対して垂直な方向はz軸方向なので、event.acceleration.zの値がある閾値を超えたときに、スマートフォンの裏側に何かしらの衝撃があったと判断できます。その衝撃を検知したことをアプリ本体に伝えられればいいわけですが、ここでも先ほどのDetectorオブジェクトを使用します。つまり衝撃を検知したときにスマートフォンの画面の色を赤から青に変更し、その色の変化を先のDetectorオブジェクトで検知してアプリに伝え、鳥（弾）を発射します。

«»

勘のよい方はお気づきかと思いますが、z軸方向の加速度センサの値を見ているだけなので、例えば急にスマートフォンを裏返したり倒したりするだけで弾が暴発します。時間があればなんとかしようとも思っていたのですが、ちょっと遊ぶ分には大して問題もなかったため、結局そのまま今に至っています。まぁよくあることです。

加速度センサの値の履歴から特定のパターンの場合にだけ反応するなど解決策はいろいろあると思うので、読者の皆さんへの宿題というか、pullreq随時受付中です。

まとめ

スリングショットコントローラーに使用されている個々の技術は、非常に基本的で、特に難しいことも行っていません。ただそれらの組み合わせでスリングショットを実現したところは、ほんの少しだけ新しいのではないかと自負しています。

次回は、アプリ本体で使用している物理エンジンについて解説する予定です。

「コトバツナギ」というWebコンテンツを作成し、HTML5 Japan Cup 2014で最優秀賞を頂きました。コトバツナギは、SpeechRecognitionとWebRTCを軸にしたマルチユーザーコンテンツです。このコンテンツで使っている主な技術の解説をしたいと思います。

概要

コトバツナギは、声に出して声で遊ぶマルチユーザーコトバアソビゲームです。

PCサイトを開き、スマートフォンを皆で持って集まって遊ぶゲームになっています。スマートフォンの代わりにマイク機能付きのノートPCでも可です。

WebRTCとwebkitSpeechRecognitionを使っているため、2014年8月の時点ではPC・スマホともにChromeブラウザのみ対応です。iOSのChromeはWebRTCとwebkitSpeechRecognitionに非対応のため不可ですが、MacのChromeは動作します。一人でも遊べます。

動作環境が限られるので遊べないユーザーがいる場合もあると思い、デモ動画も用意しました。

　解説文字無しの動画はこちら → [http://youtu.be/G6HGNISv4mo]

コトバツナギの主な技術をまとめると、

• SSL
• WebRTC（getUserMedia）
• WebRTC（PeerJS）
• SpeechRecognition
• SpeechSynthesis
• Web Audio
• テキスト解析
• 画像検索

で、できてます。

次章より詳しく説明していきます。

getUserMediaとSSL

WebRTCでカメラ・マイク入力を利用可能にするgetUserMediaは、使用する度にブラウザに許可を得るダイアログが出てしまいます。このままだとゲームとして遊ぶには問題がありますが、httpsでアクセスできるようにすると回避できるため、SSLを導入しました。httpsの場合、アクセスしているドメインに対して最初に1回だけ許可すると、その後の許可は不要になります。（ブラウザを閉じても、設定をクリアするまで有効）

コトバツナギでは、カメラ・マイクでそれぞれ許可ダイアログが出るので、最初に計2回の許可が必要になります。getUserMediaのvideo・audioを一度に扱えば一回で済みますが、マイク入力は使えるけどカメラが使えない（またはカメラの利用が嫌だ）という場合にも対応するため、このコンテンツではそれぞれの許可を分けました。

PeerJS

PCとスマートフォン間でWebRTCによる通信を実現するためにPeerJSを利用しています。PeerJSは無料で使えるPeerServer Cloud serviceを用意してくれていますがSSLに対応していません。今回は、レンタルしているVPSにPeerServerをインストールして、下記のサーバーサイドjavascriptをnode.jsのforeverコマンドで起動し、PeerServerを立てました。

var fs = require('fs');
var PeerServer = require('peer').PeerServer;
var server = new PeerServer({
	port: [ポート番号を指定します],
	path: '[パスを指定したい場合は記述します]',
	ssl: {
		key: fs.readFileSync('[sslのkeyファイルのパスが入ります]'),
		certificate: fs.readFileSync('[sslのcrtファイルのパスが入ります]')
	}
});

アイコトバでハジメル

PCとスマートフォンを接続する際に、数字入力や文字入力をするコンテンツがよくありますが、その方法はあまり味気ないと以前より思っていたので、このコンテンツでは別の方法を検討しました。タップと声だけで遊べるコンテンツにしたかったので、アイコトバを声に出して言ってから始める仕組みにしています。

コトバツナギではアイコトバやゲーム本編での音声認識に、webkitSpeechRecognitionを使ってます。アイコトバは予めいくつか用意しておいて、認識した音声を対応する数字に変換するという仕組みをとっています。

var recognition = new webkitSpeechRecognition();
recognition.maxAlternatives=1; //webkitSpeechRecognitionは複数の解析候補を出力してくれる場合があるが、このコンテンツでは一つだけに絞って使用。
recognition.onresult = function(event) {
	//音声認識の解析結果のテキスト
	var resultText=event.results[0][0].transcript;

	//resultTextを予め用意してあるリストに照合して、マッチしたら該当の数字に変換
}
recognition.start();

なお、webkitSpeechRecognitionは、onresult以外に、onstart、onend、onaudiostart、onsoundstart、onspeechstart、onspeechend、onsoundend、onaudioend、onnomatch、onerrorという多くのイベントがあり、必要に応じて使い分けることが重要になります。

解析結果（上記resultText）を数字に変換したら、WebRTCのDataChannel（PeerJSのDataConnection）を利用してPC側のゲーム本体と通信します。

var peer = new Peer('[自分のID番号]', {host: '[PeerServerのhost]', port: ['ポート番号'], path: '[パスを指定してPeerServerを立ち上げた場合は記述]'});

var connect = peer.connect('[接続先のゲーム本体のID番号。このコンテンツでは、resultTextのテキストを数字に変換]');
connect.on('open', function(){
	//接続成功
}
connect.on('data', function(data){
	//接続先から送られてきたdataを処理
}

数字入力や文字入力を使った方が動作は安定するのですが、あえてアイコトバを使うようにしたのは、声に出して遊ぶゲームであることをゲーム本編の前にユーザーに体験してもらい、確認・練習してもらうという意図があります。また、ゲーム本編の前にマイク入力の許可をさせておきたいという狙いもあります。

ゲームモードの選択

ゲームは「シリトリでアソブ」「レンソウでアソブ」の2つのモードで遊べるようにしています。

ゲームモードを選択する際、スマートフォンの場合にはタップ操作以外に端末を右か左に傾けることでも選べるようにしました。参加者みんなが体を傾けて選択している絵が作れたら面白いと思い、こういう機能をつけてます。

端末側の傾き検知は、以下のようになっています。 必要に応じて、傾き検知を開始・停止できるようにしておくと便利です。

var peer = new Peer([自身のID番号],[PeerServer情報]);
var connect = peer.connect([ゲーム本体のID番号]);

//傾き検知が必要になったらstartDeviceMotion()を呼んでaddEventListenerする
var startDeviceMotion=function(){
	window.addEventListener('devicemotion',onDevicemotion);
};

//必要ない時に止められるようにしておく
var stopDeviceMotion=function(){
	window.removeEventListener('devicemotion',onDevicemotion);
};

//端末が傾くと呼ばれる。実際にはaddEventListnerしていると常に呼ばれ続ける。
var onDevicemotion=function(e){
	var gravity = e.accelerationIncludingGravity;
	var data={mode:"gravity",gx:gravity.x,gy:gravity.y};
	connect.send(data);
};

ユーザーの端末傾き情報をゲーム側で受け取って、ゲームモード決定するところは以下のようになっています。 このコンテンツのように一対多で接続する場合は、WebRTCのDataChannel（PeerJSのDataConnection）を接続毎に保持して、各端末からの通信を処理します。

var users=new Array();
var peer = new Peer([ゲーム本体のID番号],[PeerServer情報]);

peer.on('connection', function(connect) {
	//一対多の接続の場合は端末から接続がある毎に呼ばれるので、connectを保持しておく。
	//今回はUserクラスを用意してconnectを保持
	var user=new User(connect);
	users.push(user)
});

//各ユーザーがシリトリを選んでいるかレンソウを選んでいるか調べる
var cnt=0;
setInterval(function(){
	var siritoriSelected=0;
	var rensouSelected=0;

	for(var i=0;i<users.length;i++){
		var selectmode=users[i].getSelectedMode();
		if(selectmode=="siritori"){
			siritoriSelected++;
		}else if(selectmode=="rensou"){
			rensouSelected++;
		}
	}
	
	//一定カウント後にどちらが多いかによってモード決定
	//（実際のゲームでは、全員の選択が落ち着くのを待ってからカウントしている）
	cnt++;
	if(cnt>3){
		if(siritoriSelected>=rensouSelected){
			//シリトリをはじめる
		}else{
			//レンソウをはじめる
		}
	}

},500);

//Userクラス
var User=function(connect){

	connect.on('data', function(data){
		//接続先の端末からいろいろな通信情報がここに送られるので、処理分岐できるようにしておく
		if(data.mode=="gravity"){
			onGravity(data);
		}
	});

	var onGravity=function(data){
		//data.gx、data.gyを元にアイコンを移動させる。
	};
	
	//画面右の方にいるか左の方にいるか調べてシリトリかレンソウを返す
	this.getSelectedMode=function(){
		var selectMode;
		if([左の方にいる場合]){
			selectMode= "siritori";
		} else{
			selectMode= "rensou";
		}
		return selectMode;
	}
}

ゲームモード決定時には「シリトリでアソブ」か「レンソウでアソブ」と、ゲーム本体から声が出ますが、これは音声合成で発話しています。

var speech=new SpeechSynthesisUtterance();
speech.text="しりとりであそぶ";
speech.lang = "ja-JP";
speech.volume = 1;
speechSynthesis.speak(speech);//speechSynthesisはwindowが持っているオブジェクト

ゲーム本番

シリトリゲーム、または連想ゲームでコトバをつないで遊びます。

「シリトリでアソブ」のゲームの処理の流れを、利用している技術要素とともに図にしました。おおまかには、①～⑧の流れでコトバをつないでいきます。

カメラの利用が許可されている場合、回答する度に毎回操作端末側のカメラでユーザーを撮影して、ゲーム本体に画像を送信しています（フロー②）。

また、ユーザーの操作端末がノートPCの場合は、回答の音声を端末側で録音し、blobデータとしてゲーム本体に送信しています。（フロー②、③）録音にはrecorder.jsを利用しました。recorder.jsはrecorderWorker.jsがセットになっており、Web Workerとして使う仕組みになっているようです。

var mediaStream;
var rec;
var audioContext=new AudioContext();

navigator.getUserMedia({audio:true}, 
	function(stream) {
		mediaStream=stream;
		var source = audioContext.createMediaStreamSource(stream);
		rec=new Recorder(source,{workerPath:[recorderWorker.jsまでのパス]"});
		rec.record();
	},
	function(err){
		//エラーの場合は何もしない。
		//スマホの場合はwebkitSpeechRecognitionと同時併用できないのでエラーになる。
	}
);

//録音終了したいタイミングで呼び出す
var recStop=function(){
	rec.stop();
	mediaStream.stop();

	//wav形式に変換したらonRecExportedを呼び出す
	rec.exportWAV(onRecExported);
};

//wav形式変換が完了するとblobデータが取得できる
var onRecExported=function(blob){
	//blobをWebRTCでゲーム本体に送信
};

スマートフォンの場合、2014年8月現在ではSpeechRecognitionとgetUserMediaのaudioを同時に使えない仕様になっていたので、残念ながらスマートフォンの場合は録音を諦めました。（SpeechRecognitionを同時に使わなければ、スマートフォンでも録音することができます）

なお、ここで録音撮影した音声・画像は、ゲーム終了時に使います。

ゲーム終了

ゲーム終了すると、これまでつないだコトバが連続して再生されます。

getUserMediaのvideoが使える場合、終了時に流れる各コトバに表示されているユーザー画像は、ゲーム中に回答した時に、毎回撮影したものを表示しています。（ゲーム本番のフロー②で撮影）それぞれのコトバを発声した時に、どんな顔をしていたかがわかるようになっています。（ページ上部のデモ動画参照）

また、ノートPCを使って回答したユーザーのコトバの場合、ゲーム中に回答した時に、録音した音声を再生します。（ゲーム本番のフロー①②で録音）上述の通りスマートフォンでは音声録音がSpeechRecognitionと併用できないので、スマートフォンを使って回答したユーザーのコトバの場合は、音声合成で代用します。

var audioContext=new AudioContext();

//audioBlobはゲーム時に保存していたblobデータ
if(audioBlob){
	//audioContextはコンテンツ内でnewできる数に上限があるため、何度も同じ処理をする場合は、毎回newするのはなるべく避ける。
	//このコンテンツのように同時発音する可能性がなければ、AudioContextは再利用した方がnew上限エラーにならないので良いと思われる。
	if(!audioContext){
		audioContext=new AudioContext();
	}
	var source = audioContext.createBufferSource();

	audioContext.decodeAudioData(audioBlob,function(buffer){
		source.buffer = buffer;
		source.connect(audioContext.destination);
		source.start(0);
	});

//audioblobがない場合は合成音声で発話。recognitionTextはゲーム時に保存していた音声解析のテキスト。
}else{
	var speech=new SpeechSynthesisUtterance();
	speech.text=recognitionText;
	speech.lang = "ja-JP";
	speech.volume = 1;
	speechSynthesis.speak(speech);
}

最後に

コトバツナギの主な仕組みは上記のようになっています。ゲーム本編だけでなく、ゲーム終了後にも参加者みんなで結果を振り返って楽しんでもらえるように作っています。音声解析がなかなかうまくいかないことも多いですが、思わぬ解析結果になることも含めて楽しんでもらえれば幸いです。
よかったら遊んでみてください。

■コトバツナギ
https://kotoba.tsukuenoue.com/

html5j主催により開催された、WebデザイナーやWebエンジニアのためのクリエイティブ・アワード「HTML5 Japan Cup（5jCup）」。応募期間4月23日～6月30日の約2カ月で集まった作品数は、なんと289作品でした。

この数あるHTML5を使ったアプリの中から最優秀賞・優秀賞作品や審査員特別賞などを受賞した作品たちを、5jCupの審査員も務めた池澤あやかさんと一緒に紹介していきたいと思います。

　▲Rubyが得意な「GEEK系アイドル」池澤あやかさん

優秀賞4作品と審査員特別賞3作品が選抜されるまで

7月26日に開催された「HTML5 Japan Cup 2014 The Final」まで、実は2回の審査会を行っています。1回目はhtml5j＆5jCupスタッフ有志約30名による審査基準チェック。作品にWeb技術を使っているか、5jcup開催期間中に制作・更新されたものであるか、モバイルアプリは端末で操作できるかといった基本的な確認に加え、「独創性」「完成度」「表現力」「技術力」の観点から審査を行い、20作品に絞り込まれました。

　▲PC画面やモバイル端末、Leap Motionなどの実機を使って検証、審査するスタッフの皆さん

その20作品に対して、5jCUp審査員による二次審査会を行いました。審査員全員が半日に渡り議論を重ねながら選ばれたのが、優秀賞の4作品と審査員特別賞の3作品です。

　▲審査員の池澤あやかさん、及川卓也さん、羽田野太巳さん、Daniel Davisさん、藤村厚夫さん、秋葉秀樹さん、吉川徹さん

「HTML5 Japan Cup 2014 The Final」では優秀賞に選ばれた4組がプレゼンを行い、会場の参加者全員で10円玉で投票するというやり方で最優秀賞が決定しました。

　▲審査員も来場者と同じ一票（10円玉）を投じました

最優秀賞・優秀賞・審査員特別賞に選ばれた作品たち

＜最優秀賞＞コトバツナギ

会場の票を集め、最優秀賞に選ばれた作品は、藤岡宏和さんの「コトバツナギ」。PCやスマートフォンで「声に出して声で遊ぶ」ゲームです。シリトリもしくは連想ゲームを選択し、WebRTCと音声解析を使ってコトバをつないでいきます。コトバは文字だけでなくネット上から画像を検索して表示させる機能もあり、どんな画像が現れるのか予測できないという楽しみもあります。

　▲参加者がスマートフォンに向かってアイコトバ（合言葉）を伝えるとゲームがスタートします

デモ動画（解説文字付きデモ動画／文字なしデモ動画）が公開されていますので、ぜひこちらもご覧ください。詳しい技術解説は後日藤岡さんのレポートで！

＜優秀賞＞Enraged Fowls

優秀賞1作品目は、「Angry」と「Bird」でおなじみのゲームをThree.js（WebGLライブラリ）とCannon.js（物理エンジン）を組み合わせて3Dゲームに仕立てた「Enraged Fowls」。制作者のあんどうやすしさんいわく、WebGLと3次元の物理エンジンを一緒に使っている作品はEnraged Fowlsだけという自信作。デモ動画とソースコードも公開中です。

　▲Google I/Oで配布されたProject Cardboardをヒントに100円ショップで自作したスリングショットコントローラー

さらに利用したHTML5技術として、WebWorker（画像解析）、navigator.getUserMedia (WebRTC：ウェブカメラ画像取込）、navigator.vibrate (Vibration API：タップ通知）、window.localStorage（ハイスコア保存）、devicemotionイベント（スマートフォンの裏面タップ検知）があるのだとか。最優秀賞で賞金100万円を獲得したら、電子書籍でWebGL+物理エンジンの技術について執筆するとアツく語っていましたが、今回はHTML5 Experts.jpで授賞作品の技術解説を書いていただくことになりました。お楽しみに！

＜優秀賞＞YouTubeそっくりなWebGLプレーヤー

カメラのアングルを動かせる「YouTubeそっくりなWebGLプレーヤー」で優秀賞を受賞したのは、jThree合同会社の松田光秀さん。一見動画に見えるデモ画面の中で踊るキャラクターたちは3DCGモデルで、マウスで動かすことができる。

　▲「jThree」で世界のWebをたぎらせたいとアツく語る松田さん

プレゼンで最も強調して語られたのは、松田さんが開発したjQueryの記法で作るWebGLライブラリ「jThree」の有用性について。このプラグインを使えば、デモ1本のコーディングがたったの3KBで書け、デザイナーやプログラミング初心者でも簡単にWebコンテンツを作ることが可能だという。

Oculus Riftモードやカメラコントロールは、設定不要の標準搭載。表彰後の懇親会では、池澤あやかさんもLeap MotionやOculus Riftで体験。池澤さんの感想は「ブラウザで3Dレンダリングできて、しかもLeap Motionからの入力でそのモデルが動くなんて、すごく時代は進んだなと思いました」。

　▲Leap Motionで3DCGモデルを動かす体験を試みる池澤あやかさん

＜優秀賞＞JS Racing

優秀賞4作品目は、西田慎吾（株式会社アイエムジェイ・TSUKURITE）さんのWebGLとWebSocketを使用した3Dオンラインレースゲーム「JS Racing」。審査員である羽田野太巳さんが、時間を忘れるほどはまってしまったというシンプルながらもゲーム性の高い作品です。

　▲PCだけでなく、スマートフォンからも操作ができ、複数人で同時走行やオンライン対戦も可能

その他に使ったHTL5技術はSVG、Canvas、WebFont、CSS3。クライアント技術としてTypeScript、jQuery、Three.js、Box2DJS。サーバサイド技術としては、Node.js（Socket.IO、Express、Jade）、MongoDBを活用しているとのこと。元々Flasherだったという西田さんは、TypeScriptがとても使いやすかったそうです。

＜審査員特別賞＞PACPAC

当初予定されていなかったものの審査会で優秀賞と甲乙つけがたいと評価された3作品に、審査員特別賞が授与されました。その一つがCanvasとCSS3を組み合わせて立体の面にペイントできるようにした作品「PACPAC」（いしかわさん）。

　▲池澤さんが描いた3Dの牛乳パック。拡大して見たい方はこちらから

その他に使ったHTL5技術はアニメーションにjQuery、Ajaxをページ遷移を少なくするために用い、画像の保存はクライアント側でcanvasをdataURLにして、サーバー側でファイルに保存しているとのこと。池澤あやかさんいわく 「divで牛乳パックが構成されてることに驚きが隠せなかった」のだそう。ちなみに最も応募数の多かった、html5jエンタメ技術部の「エンタメアプリ・コンテンツ賞」もダブル受賞でした。

＜審査員特別賞＞花王カタログカルタ

node.jsを利用した多人数での同時対戦が可能な花王製品カルタゲーム「花王カタログカルタ」（博報堂アイ・スタジオ）。各画像はsvg、カルタの拡大画像などのアニメーションは主にCSS3で実装することによって、パフォーマンスやクオリティの向上を図っています。

　▲製品にまつわる利用シーンなどのあるあるネタをカルタ化している

技術力に加え、インタラクティブコンテンツの制作会社である強みである最大限に活かしたマーケティング力とクリエティブ性の高い作品です。

＜審査員特別賞＞TouchBloomy

オブジェクトの連鎖点を予想して、ブラウザ上でタップしてつなげるパズルゲーム「TouchBloomy」で受賞したのは、チームアルクリットの吉村智志さん、小澤駿さん。1ステージ約30秒、ワンタップでできるシンプルなゲームで、ステージ投稿機能なども面白い仕掛けとなっています。

　▲画像を使用せずに処理速度を維持。enchant.js、canvas、DOMなどの技術を使って制作している

上記で紹介した最優秀賞・優秀賞・審査員特別賞の受賞作品について、池澤あやかさんに感想を聞いてみました。
「受賞作品はWebRTCで参加型のWebに仕上げたものが多く、印象に残りました。意外と今までは参加型のWebが少なかったので、Webの近未来を感じました。WebRTC、私も今度いじってみようと思います」

池澤あやかさんの言うとおり、今回の5jCupはWebRTCを使った応募作品が最も多く、41作品。そして、WebGLの30作品、Monaca/Onsen UIが20作品と、Webの先端技術を駆使した作品が多数応募されました。受賞作品の講評、審査員コメントは以下で紹介されていますので、合わせてご覧ください。

• 【HTML5 Japan Cup 2014】最優秀賞・優秀賞・審査員特別賞の受賞作品と審査員講評
• 【HTML5 Japan Cup 2014】テーマ賞の受賞作品と受賞理由
• geechsマガジン独占！豪華審査員インタビュー

テーマ賞作品LTで、池澤あやかさんが印象に残った2作品

「HTML5 Japan Cup 2014 The Final」表彰式終了後の懇親会では、各テーマ賞受賞者の方々によるLT大会が行われました。飲食OK、ただし全員着席で全力でLTを聞くのをルールとしたこともあり、歓声と拍手で大盛り上がり。どれも大変面白い作品ばかりなのですが、今回は池澤あやかさんが印象に残ったという2作品に絞って紹介したいと思います。

!CheerZ!　乾杯可視化システム

まず1作品目は「!CheerZ!　乾杯可視化システム」（0101室サーバ担当チーム）。センサー付きのグラスを使って乾杯を可視化し、遠方にいる人とも乾杯ができるというもの。「スマートフォンの次を狙え！生活を快適にするデバイス×Webアプリ」受賞作品。

　▲WebGLを使って表示、 Socket.IOで画像を飛ばしている

　▲乾杯するとグラスに付けている加速度センサーが認識して、地図上に表示される

UFO-Escape

もう1作品は小学6年生のプログラマ・シュン君の「UFO-Escape」。Webプラットフォーム賞の審査基準は「最低でも二つ以上のプラットフォームで、同様の挙動をすること」だったが、応募したWindowsストアアプリ、Firefox OS、Chrome Apps、Android (4以上)すべてのプラットフォームできちんと動くことが確認できた唯一の作品だったのだとか。

　▲トップバッターにも関わらず、堂々と発表するシュン君

　▲enchant.jsで作ったゲームを、Windowsストアアプリ、Firefox OS、Chrome Apps、Androidなどのプラットフォームに移植

• シュン君が挑戦した「enchant.jsでHTML5ゲームを作り、プラットフォームに移植してみよう！」
• 【HTML5 Japan Cup 2014 The Final】LT＆懇親会レポート！

＜池澤あやかさんの感想＞
カンパイ楽しかったです。この作品はジョッキの下にマイコンがとりつけてあったのですが、この作品のようにマイコンを使って現実世界と繋がるWebも今後発展していくのではないかと思います！

そしてまだ小学生の男の子が堂々とLTしていたのを見て、今後の日本は安泰だと思いました。しかもゲームもよくできてたので、本当にすごいなと。

HTML5 Experts.jpではこの後も「HTML5 Japan Cup 2014」特集を組んで、最優秀賞・優秀賞受賞者の皆さんによる技術解説レポートも掲載予定です。ご期待ください！

　▲61団体,延べ参加人数1449名（htmlday含）で日本のWebをたぎらせた「HTML5 Japan Cup 2014 The Final」にカンパイ！