スクラッチでオンラインゲームを作る⑤ バッファリングを実装する

スクラッチプログラミングに挑戦している皆さん、どうも！スクラッチコーチです。

前回(ぜんかい)はマイナス値(ち)に対応(たいおう)して一気(いっき)に動(うご)きの同期(どうき)確認(かくにん)まで進(すす)めたぞ！下記(かき)動画(どうが)が前回(ぜんかい)までの成果物(せいかぶつ)だ。改(あらた)めてチェックしてみてほしい。タブA（左(ひだり)）で更新(こうしん)されたクラウド変数(へんすう)１を、タブB（右(みぎ)）側(がわ)で受(う)け取(と)って座標(ざひょう)に割(わ)り当(あ)てることで動(うご)きの同期(どうき)が行(おこな)われている様子(ようす)だ。

かーなーり、スムーズに同期(どうき)されているけどまだ完璧(かんぺき)ではないんだ。なぜって？それはスクラッチの仕様(しよう)に原(げん)因(いん)があるんだ。そのあたりを明(あき)らかにして、この遅延(ちえん)の解決策(かいけつさく)を実装(じっそう)するというのが今回(こんかい)の流(なが)れだ。これによってますますスムーズな同期(どうき)が実現(じつげん)できる。いったいどこまでスムーズになってしまうんだ！

今回(こんかい)の目標(もくひょう)「バッファリング」

せっかくスムーズな同期(どうき)を作(つく)ったのになぜかまだカクカクしている……そんな頭痛(ずつう)の種(たね)を抱(かか)えている我々(われわれ)だが、大丈夫(だいじょうぶ)。頭痛(ずつう)といえばそう、頭痛(ずつう)にはバッファリングだ！（草(くさ)）スクラッチの仕様(しよう)による遅延(ちえん)をバッファリングという技(わざ)を使(つか)って解決(かいけつ)するぞ。必要(ひつよう)なのはスクラッチへの情熱(じょうねつ)と優(やさ)しさだ！なぜって？そりゃバッファリングの半分(はんぶん)は優(やさ)しさでできているからだ！（草(くさ)2回(かい)目(め)）このバッファリングを使(つか)えば真(しん)の意味(いみ)でクラウド変数(へんすう)たった１つだけで出来(でき)る同期(どうき)処理(しょり)が完成(かんせい)するんだ。よっしゃ、行(い)こう！

遅延(ちえん)の原因(げんいん)は何(なに)？

手(て)を動(うご)かす前(まえ)に何(なに)をするのか、大(おお)まかな全体像(ぜんたいぞう)を伝(つた)えておくね。前回(ぜんかい)X座標(ざひょう)とY座標(ざひょう)をエンコードして１つにまとめて、クラウド変数(へんすう)１つで同期(どうき)処理(しょり)を実現(じつげん)するところまで完成(かんせい)したよね。これによってクラウド変数(へんすう)を2つ使(つか)っていた方法(ほうほう)よりも倍(ばい)以上(いじょう)のスムーズさを実現(じつげん)できた。素晴(すば)らしい。これだけでもゲームの種類(しゅるい)によっては十分(じゅうぶん)だと思(おも)うけど、今回(こんかい)はトップクラスのスクラッチオンラインゲームの作(つく)り方(かた)を目指(めざ)しているので、もっと極(きわ)めて行(い)くぞ！問題(もんだい)が起(お)きたら原因(げんいん)を調(しら)べる、これがプログラミングのベストプラクティスだ。

「ずっと」ループは1秒間(びょうかん)に30回(かい)更新(こうしん)

さっそく原因(げんいん)究明(きゅうめい)するよ。次(つぎ)の画像(がぞう)をみてほしい。

スクラッチの「ずっと」ループでは基本的(きほんてき)に1秒間(びょうかん)に30フレーム更新(こうしん)されるっていう仕様(しよう)なんだ。専門的(せんもんてき)に言(い)うとfps30っていう状態(じょうたい)。つまりエンコードされたX座標(ざひょう)とY座標(ざひょう)の値(ね)が1秒間(びょうかん)に30回(かい)ほどクラウド変数(へんすう)1にセットされるわけだ。

そしてこれはクラウド変数(へんすう)なので、全員(ぜんいん)と共有(きょうゆう)されるわけだけど、ここに罠(わな)がある。

クラウド変数(へんすう)は1秒間(びょうかん)に10回(かい)更新(こうしん)

実(じつ)はクラウド変数(へんすう)は1秒間(びょうかん)に10回(かい)までしか同期(どうき)されないんだ。ずっとループでは1秒間(びょうかん)に30回(かい)更新(こうしん)しているのに、クラウド変数(へんすう)は1秒間(びょうかん)に10回(かい)しか同期(どうき)されないってことだ。つまり3分(ふん)の1しかデータが送(おく)れないわけだ……。どうにも嫌(いや)な予感(よかん)がするよね。次(つぎ)のイメージを見(み)てみよう。

タブAでは３０回(かい)分(ぶん)の座標(ざひょう)データがあっても、クラウド変数(へんすう)の仕様(しよう)でタブBには１０回(かい)分(ぶん)しか届(とど)かない。そのため上(じょう)のイメージだと②と③のデータは欠落(けつらく)してしまうことになる。これがカクカクが残(のこ)ってしまう原因(げんいん)になっているんだ。つまり、タブBでは①の次(つぎ)は④の座標(ざひょう)しか受(う)け取(と)ってないから、欠落(けつらく)した②と③の動(うご)きは再現(さいげん)できないということだね。よし、原因(げんいん)さえ分(わ)かればだいたい解決策(かいけつさく)も存在(そんざい)するものだ。

遅延(ちえん)の解決策(かいけつさく)はバッファリングにあり

問題(もんだい)をカンタンに言(い)うと「３回(かい)に１回(かい)しか送(おく)れない」こと。なら１回(かい)で３回(かい)分(ぶん)送(おく)ればいいじゃん？っていうのが解決策(かいけつさく)。くわしく書(か)くね。上(うえ)の画像(がぞう)だとさ、①も②も③も送(おく)ろうとするから結局(けっきょく)①しか送(おく)れてない、っていう状態(じょうたい)になってるんだ。だからいっそのこと全(ぜん)データを毎回(まいかい)送(おく)るのは諦(あきら)めて、①と②のデータもまとめて③の時(とき)に送(おく)るっていう作戦(さくせん)で行(い)きたい。

①と②ではエンコードしたデータを溜(た)めておいて、③になったら（または④になったら）データをクラウド変数(へんすう)1にセットするということだよ。そして、この溜(た)めてから送(おく)る手法(しゅほう)がバッファリングという技(わざ)なんだ！

手(て)を動(うご)かすぞ！

うっし、じゃあ手(て)を動(うご)かしていくぞ！

プロジェクトのコピーを保存(ほぞん)する

とりあえずプロジェクトのコピーを保存(ほぞん)しておこう。プロジェクトの名前(なまえ)はそうだね……ここまでは「オンラインゲームの作(つく)り方(かた)１」にしておいて、ここからは「オンラインゲームの作(つく)り方(かた)２」とかにしたらいいんじゃないかな。もちろん自分(じぶん)が分(わ)かりやすい名前(なまえ)で問題(もんだい)ないよ。

スプライト名(めい)を「自(より)プレイヤー」に変(か)える

いまあるスプライトの名前(なまえ)を「自(より)プレイヤー」にしようか。

スプライトを複製(ふくせい)する

右(みぎ)クリックでスプライトを複製(ふくせい)しよう。

スプライト名(めい)を「クラウドプレイヤー」に変(か)える

複製(ふくせい)したスプライト名(めい)は「クラウドプレイヤー」だ。これはクラウド変数(へんすう)を同期(どうき)して動(うご)く用(よう)のスプライトだ。今(いま)まで言(い)うところの数字(すうじ)キー２を押(お)したときの動(うご)きをする用(よう)のスプライトみたいなものなんだ。

自(より)プレイヤーを整理(せいり)する

まずはスプライトの選択(せんたく)を自(より)プレイヤーに戻(もど)そう。

不要(ふよう)なコードを削除(さくじょ)する

緑(みどり)の旗(はた)を押(お)した時(とき)のコード以外(いがい)は、ほぼすべて消(け)すよ。

「数字(すうじ)の２キーが押(お)されたとき」を消(け)す

エンコードを消(け)す

デコードを消(け)す

「緑(みどり)の旗(はた)がおされたとき」の一部(いちぶ)を消(け)す

これだけ残(のこ)す↓

めっちゃ減(へ)ったｗ

自(より)スプライトからメッセージを送(おく)る

イベント「クラウド - セットアップ」を作(つく)る

新(あたら)しいイベントを作(つく)るよ。イベントのメッセージのブロックから「新(あたら)しいメッセージ」を選(えら)んで、名前(なまえ)「クラウド - セットアップ」を指定(してい)しよう。

配置(はいち)する

最初(さいしょ)に送(おく)るようにするよ。送(おく)るではなくて、送(おく)って待(ま)つブロックを使(つか)うよ。

リスト「★送信(そうしん)用(よう)データ」を作(つく)る

リストを用意(ようい)しよう。これには座標(ざひょう)データを入(い)れる予定(よてい)だよ。

座標(ざひょう)を追加(ついか)してみる

X座標(ざひょう)とY座標(ざひょう)をリストに追加(ついか)してみよう。

テストする

これで動(うご)かすとどうなるかな？

うわ！リストの長(なが)さがどんどん増(ふ)えていく！これはバグる予感(よかん)がヒシヒシするね！赤(あか)いボタンを押(お)して止(と)めておこう。でも安心(あんしん)してほしい！この座標(ざひょう)データはずっと保持(ほじ)しておく必要(ひつよう)はなくて、クラウド変数(へんすう)に渡(わた)したら過去(かこ)データは不要(ふよう)になるわけだから、その都度(つど)消(け)すようにすれば大丈夫(だいじょうぶ)。やってみよう。

イベント「クラウド - ティック」を作(つく)る

今度(こんど)はループ内(ない)で１フレームごとに送信(そうしん)されるメッセージ「クラウド - ティック」を作(つく)ろう。

配置(はいち)する

よし、このままでは何(なに)も変(か)わらないけど、とりあえず次(つぎ)に「クラウドプレイヤー」側(がわ)を整(ととの)えよう。

• ティックってなに？

  u003cpu003e日本語(にほんご)だとあまり適切(てきせつ)な訳(わけ)がないんだけど、tickティックは「秒針(びょうしん)が１つ進(すす)む(む)」みたいな意味合(いみあ)いで使(つか)われる。ここでは「ずっとループ」内(うち)でフレームが１つ進(すす)む(む)っていうイメージだね。u003c/pu003eu003cpu003e「tick-tockチクタク」っていう擬音語(ぎおんご)なら有名(ゆうめい)だよね。あれのtickなんだ。u003c/pu003e

クラウドプレイヤー側(がわ)を整(ととの)える

ではスプライトを切(き)り替(か)えよう。

不要(ふよう)なコードを削除(さくじょ)する

こっちも不要(ふよう)なコードは消(け)していくぞ。

緑(みどり)の旗(はた)がおされたときを消(け)す

数字(すうじ)キー２が押(お)されたときも消(け)す

エンコードとデコードだけ残(のこ)す

この２つは残(のこ)しておこう！

メッセージ「クラウド - セットアップ」を受(う)け取(と)る

続(つづ)けてコーディングしていこう！まずは「クラウド - セットアップ」の方(ほう)から行(い)くぞ。

初期化(しょきか)処理(しょり)を作(つく)る

ここで最初(さいしょ)に行(おこな)われる初期化(しょきか)処理(しょり)を作(つく)っていくよ。

まず隠(かく)す

とりあえずスプライトを隠(かく)しておこう。

過去(かこ)データを消(け)す

さっそくだけど過去(かこ)データを空(そら)にしておこう。セットアップし直(なお)すから過去(かこ)データは一切(いっさい)不要(ふよう)だ。

よし、とりあえずこれでOKだ。

メッセージ「クラウド - ティック」を受(う)け取(と)る

次(つぎ)にクラウド - ティックの受(う)け取(と)り処理(しょり)も作(つく)ろう。これはスプライト「自(より)プレイヤー」のループ内(ない)で実行(じっこう)されるから、１秒間(びょうかん)にだいたい３０回(かい)くらい飛(と)んでくるメッセージだね。でも僕(ぼく)らの作戦(さくせん)としてはこのメッセージは３回(かい)または４回(かい)に１度(ど)だけクラウド変数(へんすう)にセットして、それ以外(いがい)のときはデータをためるバッファリングを行(おこな)うってことだったね。そのあたりをここで実装(じっそう)していくよ。

変数(へんすう)「クラウドティック」を作(つく)る

何回目(なんかいめ)のメッセージ「クラウド - ティック」を受(う)け取(と)ったのかを管理(かんり)するために同名(どうめい)の変数(へんすう)を作(つく)っておくよ。

初期(しょき)化(か)する

メッセージ「クラウド - セットアップ」のところに初期化(しょきか)処理(しょり)を追加(ついか)しておこう。

加算(かさん)処理(しょり)をする

メッセージ「クラウド - ティック」のところでは１ずつ加算(かさん)するようにしよう。

ブロック定義(ていぎ)「同期(どうき)する」を作(つく)る

３回(かい)か４回(かい)送(おく)ったら同期(どうき)するっていう処理(しょり)をブロック定義(ていぎ)にしてまとめていくよ。

条件(じょうけん)分岐(ぶんき)ブロックを追加(ついか)する

もしも変数(へんすう)「クラウドティック」が指定(してい)した回数(かいすう)に達(たっ)していたら、っていう条件(じょうけん)を作(つく)りたい。そんなときも「もしも」ブロックだね。

条件(じょうけん)式(しき)を作(つく)る

さて、演算(えんざん)はどうしようか。やり方(かた)はいろいろあるけど今回(こんかい)は剰余(じょうよ)演算子(えんざんし)を使(つか)っていこう。「割(わ)った余(あま)り」を調(しら)べる演算子(えんざんし)のことだよ。

これだね。空欄(くうらん)にブロックをはめていこう。こんな感(かん)じ↓

これの解(かい)が0より大(おお)きいときはまだデータを溜(た)める段階(だんかい)ってこと。

たとえば「回数(かいすう)」が４なら、クラウドティックが１なら１÷４の余(あま)りは１だからゼロより大(おお)きい。２，３も余(あま)りがでる。４÷４のときに余(あま)りがゼロになるね。これを条件(じょうけん)式(しき)として使(つか)おう。

処理(しょり)を止(と)めておく

とりあえず処理(しょり)を止(と)めておけばOK。

リストを消(け)す

そして色々(いろいろ)上手(うま)く行(い)った後(あと)は改(あらた)めてリストを消(け)すようにしておくぞ。これはテスト用(よう)だからすぐ修正(しゅうせい)するけどね。

ブロック定義(ていぎ)を呼(よ)び出(だ)す

ではメッセージを受(う)け取(と)った時(とき)にこのブロック定義(ていぎ)を呼(よ)び出(だ)そう。引数(ひきすう)には４を指定(してい)しておくよ。

テストする

リストの長(なが)さに注目(ちゅうもく)！

よし、だいたいいいね！精度(せいど)としては十分(じゅうぶん)だ。

エンコードする

もちろん座標(ざひょう)をエンコードして渡(わた)していくのが目的(もくてき)だから、このままでは終(お)われないね。こっからが本番(ほんばん)だ。

テスト用(よう)のブロックを消(け)す

リストデータを消(け)すところはいったん消(け)してOK。

変数(へんすう)「エンコード文字列(もじれつ)」を初期(しょき)化(か)する

消(け)した場所(ばしょ)に変数(へんすう)「エンコード文字列(もじれつ)」の初期化(しょきか)処理(しょり)を置(お)こう。空白(くうはく)で初期(しょき)化(か)するよ。

リストの中身(なかみ)を全部(ぜんぶ)エンコードするループを作(つく)る

リストの長(なが)さを使(つか)ってループブロックを作(つく)ろう。

ループにはめる↓

これを追加(ついか)するぞ。

リストの先頭(せんとう)をエンコードしていく

このループ内(ない)でブロック定義(ていぎ)「エンコードする」を呼(よ)び出(だ)そう。

引数(ひきすう)にはリストの１つ目(め)をハメる。

これを入(い)れよう。

先頭(せんとう)を消(け)す

直後(ちょくご)に１つ目(め)のデータを消(け)してしまおう！

ちょっとトリッキーだけど、これでどんどん先頭(せんとう)がエンコードされていくんだ。リストの１つ目(め)をエンコードした後(あと)にリストの１つ目(め)を消(け)したら、自然(しぜん)と２つ目(め)のデータが先頭(せんとう)に来(く)るからね！

クラウド変数(へんすう)1を更新(こうしん)する

最後(さいご)にクラウド変数(へんすう)を更新(こうしん)しよう！

テストする

さぁどうなるかな。

よぉし！クラウド変数(へんすう)が次々(つぎつぎ)と更新(こうしん)されているね！さっきまでよりも長(なが)くなっているのがバッファリングした分(ぶん)を一気(いっき)にエンコードしている証(あかし)だね。

次回(じかい)へ

今回(こんかい)はここまでにしておこう！バッファリングという難(むずか)しい仕様(しよう)を実装(じっそう)することに成功(せいこう)したね。今回(こんかい)やったことをまとめると次(つぎ)のようになるよ。

• スプライトを２つに分(わ)けて
• 自(より)プレイヤー側(がわ)からは「ずっとループ」が１フレーム進(すす)む(む)ごとに、「★送信(そうしん)用(よう)データ」に座標(ざひょう)データを追加(ついか)して「クラウド - ティック」というメッセージを送(おく)った
• クラウドプレイヤー側(がわ)では「クラウド - ティック」を受(う)け取(と)って、４フレームごとに「★送信(そうしん)用(よう)データ」をエンコードしてクラウド変数(へんすう)1にセットした

よしよし、順調(じゅんちょう)だ。次回(じかい)は別(べつ)のタブでも同(おな)じプロジェクトを動(うご)かしてみよう。タブA側(がわ)でタブBがクラウド変数(へんすう)を更新(こうしん)したことを検知(けんち)して、新(あたら)しいプレイヤーの追加(ついか)処理(しょり)を実現(じつげん)してみるぞ。それだけ聞(き)くと前(まえ)のチュートリアルで実現(じつげん)したことと同(おな)じだけど、今回(こんかい)はバッファリングされたバージョンだからね！かつてあったカクカクは極限(きょくげん)まで少(すく)なくなっているはずだ！次回(じかい)もすぐ更新(こうしん)予定(よてい)だから待(ま)っててね！