スクラッチでオンラインゲームを作る⑧ クローンを使おう

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

前回(ぜんかい)はクラウド変数(へんすう)を受信(じゅしん)して新規(しんき)プレイヤーなら入場(にゅうじょう)処理(しょり)とデータ更新(こうしん)を、既知(きち)プレイヤーならデータ更新(こうしん)のみを実行(じっこう)するようにプレイヤー管理(かんり)ができる仕組(しく)みを作(つく)ったぞ！でもまだまだリストのデータが更新(こうしん)されただけで、見(み)た目(め)は何(なに)も変(か)わってないんだよねぇ。っということでここから見(み)た目(め)も変(か)えていくぞ。これでオンラインゲーム感(かん)がグッと増(ま)してワクワクが大爆発(だいばくはつ)すること間違(まちが)いなしだ！

今回(こんかい)の目標(もくひょう)「クローンを作(つく)って別(べつ)プレイヤーを表示(ひょうじ)させる」

別(べつ)プレイヤーを表示(ひょうじ)させる一番(いちばん)いい方法(ほうほう)はクローンを使(つか)うことだよね。今回(こんかい)はクローンを使(つか)って別(べつ)プレイヤーを自分(じぶん)の画面(がめん)に表示(ひょうじ)させる。ただまぁクローンを使(つか)うと物事(ものごと)がより複雑(ふくざつ)になっていくんだよねぇ。仕方(しかた)ないけど。焦(あせ)らず急(いそ)がず、じっくり取(と)り組(く)めば大丈夫(だいじょうぶ)。それに実(じつ)は今(いま)までのコーディングはクローンを使(つか)うことを想定(そうてい)して作(つく)ってきているから、思(おも)ってるより複雑(ふくざつ)にならないかも。なにより僕(ぼく)も一緒(いっしょ)にいるから絶対(ぜったい)大丈夫(だいじょうぶ)だって！チラッと完成(かんせい)動画(どうが)を見(み)せちゃう↓

やってみよう！

クローンを作(つく)る

いきなりクローンを作(つく)っていくよ。最初(さいしょ)に作戦(さくせん)を伝(つた)える。各(かく)クローンには異(こと)なる変数(へんすう)「プレイヤー番(ばん)号(ごう)」を持(も)たせて管理(かんり)していくんだ。プレイヤー番(ばん)号(ごう)さえ分(わ)かれば「★プレイヤーUID一覧(いちらん)」と「★プレイヤーデータ一覧(いちらん)」のどこを見(み)ればいいか分(わ)かるから、これだけで他(た)プレイヤーとの区別(くべつ)が行(おこな)えるようになっているんだ。クローンを作(つく)るときによくある手法(しゅほう)として、スプライト自身(じしん)は非(ひ)表示(ひょうじ)のままにしてクローンだけ表示(ひょうじ)するっていう方法(ほうほう)をここでも採用(さいよう)するぞ。スプライト自身(じしん)の変数(へんすう)「プレイヤー番(ばん)号(ごう)」は空白(くうはく)のままにしておくことで、クローンかどうかを区別(くべつ)もできる。おいおい変数(へんすう)「プレイヤー番(ばん)号(ごう)」めっちゃ優秀(ゆうしゅう)じゃんか！？最高(さいこう)だね！

クローンブロックを置(お)く

変数(へんすう)「プレイヤー番(ばん)号(ごう)」をセットした直後(ちょくご)にクローンを作(つく)ろう。

こうすればクローンはプレイヤー番(ばん)号(ごう)を保持(ほじ)した状態(じょうたい)で生成(せいせい)されるね。そしてスプライト自身(じしん)はこのあとの処理(しょり)でプレイヤー番(ばん)号(ごう)を空白(くうはく)に戻(もど)してあるのでバッチリだ。

クラウド - ティックを受(う)け取(と)ったときの処理(しょり)を分(わ)ける

さて、クローンを使(つか)う時(とき)の問題点(もんだいてん)として、本体(ほんたい)側(がわ)で実行(じっこう)されているループ処理(しょり)をクローンも実行(じっこう)してしまうというのは有名(ゆうめい)だよね。問題(もんだい)ないケースもあるんだけど、例(たと)えば今回(こんかい)のメッセージ「クラウド - ティック」をうけとった時(とき)の処理(しょり)は本体(ほんたい)だけしか実行(じっこう)してほしくない。いや、もっと正確(せいかく)に言(い)うと、本体(ほんたい)のティック処理(しょり)とクローンのティック処理(しょり)は別々(べつべつ)にしたいと思(おも)ってる。

本体(ほんたい)とクローンを区別(くべつ)する

ここで再(ふたた)び役立(やくだ)つのが変数(へんすう)「プレイヤー番(ばん)号(ごう)」だったね！条件(じょうけん)分岐(ぶんき)させてみよう！

条件(じょうけん)ブロックを置(お)く

とりあえずクラウドティックを受(う)け取(と)るところに「もし」ブロックを置(お)こう。

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

変数(へんすう)「プレイヤー番(ばん)号(ごう)」が空白(くうはく)でなければクローンだね。この作(つく)り方(かた)は何(なに)通(どお)りかあるけど今回(こんかい)は下記(かき)のような方法(ほうほう)でOKだ。

否定(ひてい)ブロックを使(つか)う方法(ほうほう)もあるけど、こっちのほうがシンプルじゃない？これを条件(じょうけん)式(しき)として使(つか)うとこうなる↓

うん、いいね。この中(なか)の条件(じょうけん)ブロックの中(なか)にはクローンしか来(こ)れない状態(じょうたい)ができたね。では中身(なかみ)も作(つく)り込(こ)んでいこう！

ブロック定義(ていぎ)「クローンティック」を用意(ようい)する

クローン専用(せんよう)のティック処理(しょり)をブロック定義(ていぎ)にまとめておくよ。

使(つか)う

条件(じょうけん)ブロック内(ない)に置(お)いて、さらにそれ以降(いこう)の処理(しょり)は実行(じっこう)されないように「このスクリプトを止(と)める」ブロックも置(お)こう。

これで「もし」ブロック内(ない)はクローンだけが実行(じっこう)できて、「もし」ブロック以降(いこう)は本体(ほんたい)だけが実行(じっこう)できるようになったね！

クローンティックを作(つく)る

よし、じゃあココからはクローンだけが実行(じっこう)するティック処理(しょり)を作(つく)るよ。ちなみに、ココに至(いた)るまでにすでにブロック定義(ていぎ)「順番(じゅんばん)にデコードする」を１回(かい)実行(じっこう)してるのは覚(おぼ)えてる？そう、プレイヤーUIDをエンコード文字列(もじれつ)から取得(しゅとく)するときに１回(かい)実行(じっこう)したんだよね。じゃあ次(つぎ)にデコード処理(しょり)を実行(じっこう)したら何(なに)が取(と)れるか覚(おぼ)えてるかな？そう、X座標(ざひょう)だね！ではさらにもう１回(かい)実行(じっこう)したら？うん、Y座標(ざひょう)だよね。じゃあさ、続(つづ)けてもう１回(かい)実行(じっこう)したら何(なに)が取(と)れるっけ？答(こた)えは次(つぎ)のイメージを見(み)てみてね。

うん、取(と)れるのは次(つぎ)のX座標(ざひょう)だね。この図(ず)を参考(さんこう)にどんどん順番(じゅんばん)にデコードしていって、そのたびに座標(ざひょう)データを割(わ)り当(あ)ててみよう。

デコードしてX座標(ざひょう)を割(わ)り当(あ)てる

ブロック定義(ていぎ)「順番(じゅんばん)にデコードする」を実行(じっこう)しよう。

X座標(ざひょう)に割(わ)り当(あ)てる

これで変数(へんすう)「値(ね)」にはX座標(ざひょう)が入(はい)ったから、これを割(わ)り当(あ)てよう。

デコードしてY座標(ざひょう)を割(わ)り当(あ)てる

２回(かい)デコードしたから下記(かき)のようになってるわけだ。

じゃあ続(つづ)けてY座標(ざひょう)も取(と)り出(だ)して割(わ)り当(あ)てよう。

カンタンだね！

カラになったかどうか調(しら)べる

これでXとYが取(と)り出(だ)されたからエンコード文字列(もじれつ)は下記(かき)のようになったね。

ティック処理(しょり)はどんどん実行(じっこう)されるから、次回(じかい)もまたX座標(ざひょう)とY座標(ざひょう)を割(わ)り当(あ)てる処理(しょり)が実行(じっこう)されるよね！そしてこのティック処理(しょり)は変数(へんすう)「エンコード文字列(もじれつ)」がカラになる（=デコードできなくなる）まで続(つづ)くわけだ。

カラになったらどうしようか？大丈夫(だいじょうぶ)、安心(あんしん)して！その頃(ころ)にはきっと本体(ほんたい)側(がわ)のクラウドティック処理(しょり)で次(つぎ)のクラウド変数(へんすう)を受信(じゅしん)してるだろうから、またリスト「★プレイヤーデータ一覧(いちらん)」にデータが届(とど)いてるはずだよ。データをまたエンコード文字列(もじれつ)にセットすれば、連続(れんぞく)してデコード処理(しょり)が実行(じっこう)していけるね。

これでエンコード文字(もじ)の順番(じゅんばん)を2にセットしてから余分(よぶん)なデータ（プレイヤーUID）をスキップするために１回(かい)デコードしておけば……そう、またXとYを取(と)りたい放題(ほうだい)だね！めっちゃスムーズに動(うご)きが再現(さいげん)できそうな予感(よかん)がしてきた……ワクワクっ！

条件(じょうけん)ブロックを置(お)こう

じゃあエンコード文字列(もじれつ)がカラかどうか調(しら)べよう。

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

カラかどうか、どうやって調(しら)べる？気(き)を付(つ)けてほしいのは、実際(じっさい)には変数(へんすう)「エンコード文字列(もじれつ)」の中身(なかみ)はデータが入(はい)ったままってこと。だからエンコード文字列(もじれつ)が空白(くうはく)かどうか、という条件(じょうけん)式(しき)は使(つか)えない。そこで変数(へんすう)「エンコード文字(もじ)の順番(じゅんばん)」を使(つか)って次(つぎ)のような演算(えんざん)を作(つく)ってみよう。

現状(げんじょう)だと、変数(へんすう)「エンコード文字(もじ)の順番(じゅんばん)」は変数(へんすう)「エンコード文字列(もじれつ)」の長(なが)さより１つ大(おお)きい値(ね)になっているよね！そこを利用(りよう)すればエンコード文字列(もじれつ)がカラ（＝全部(ぜんぶ)デコード済(す)み）かどうかが分(わ)かるっていう算段(さんだん)だよ。

次(つぎ)のプレイヤーデータをエンコード文字列(もじれつ)に移(うつ)そう

この中(なか)ではプレイヤーデータをエンコード文字列(もじれつ)に移(うつ)す処理(しょり)を作(つく)っていくよ。

ブロック定義(ていぎ)を用意(ようい)する

ブロック定義(ていぎ)「次(つぎ)のプレイヤーデータを移(うつ)す → エンコード文字列(もじれつ)」に処理(しょり)をまとめておこう。

使(つか)う

とりあえず置(お)いてみよう。

プレイヤーデータを取得(しゅとく)する

各(かく)クローンが持(も)っている変数(へんすう)「プレイヤー番(ばん)号(ごう)」を使(つか)って、自分(じぶん)のプレイヤーデータを取得(しゅとく)しよう。

これを変数(へんすう)「エンコード文字列(もじれつ)」に反映(はんえい)するよ。

元(もと)のプレイヤーデータは消(け)す

なにかのはずみで２回(かい)同(おな)じデータを取得(しゅとく)してしまわないように、元(もと)の場所(ばしょ)は空白(くうはく)にしておこう。

プレイヤーUIDをスキップしておく

この段階(だんかい)ではプレイヤーUIDは不要(ふよう)なので一度(いちど)デコードを行(い)ってしまおう。もちろん直前(ちょくぜん)で変数(へんすう)「エンコード文字(もじ)の順番(じゅんばん)」を2にセットすることも忘(わす)れずに。

この処理(しょり)はとりあえずこれでOK！

仕上(しあ)げる

ところで、★プレイヤーデータ一覧(いちらん)にデータが届(とど)いてなかったらどうなるだろうか。その場合(ばあい)はエンコード文字列(もじれつ)に空白(くうはく)がセットされることになるんだ。このことを利用(りよう)してブロック定義(ていぎ)「クローンティック」にストップ処理(しょり)を追加(ついか)しておこう。

条件(じょうけん)ブロックを置(お)こう

プレイヤーデータを移(うつ)した直後(ちょくご)に条件(じょうけん)分岐(ぶんき)を作(つく)ろう。

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

エンコード文字列(もじれつ)が空白(くうはく)かどうかを調(しら)べよう。

処理(しょり)を止(と)めよう

何(なに)も取(と)れなかったら今回(こんかい)のティックではなにもしない、っということだね。

表示(ひょうじ)も忘(わす)れずに

おっとこのままだと本体(ほんたい)と同(おな)じくクローンが隠(かく)れたままだね。しっかり表示(ひょうじ)させよう。表示(ひょうじ)させるタイミングはここかな。

テストターイム！

ここまで一気(いっき)通貫(つうかん)で作(つく)ってきたから、もうテストしたくてウズウズしてたんじゃないかな？！よしよし、またタブを２つ開(ひら)いてテストしてみませう！

た・の・し・いーーーーーぃ！動(うご)いた？動(うご)いた？ちょっと感動(かんどう)じゃない！？これはやばいよね！

次回(じかい)へ

今回(こんかい)は別(べつ)プレイヤーを自分(じぶん)の画面(がめん)に表示(ひょうじ)させて動(うご)きを同期(どうき)させるためにクローンを使(つか)ったね！クローンを使(つか)うと一気(いっき)に複雑(ふくざつ)になる……と心配(しんぱい)したけど、元々(もともと)クローンを想定(そうてい)して作(つく)っておいたから思(おも)いの外(ほか)スッキリした構造(こうぞう)を保(たも)てたと思(おも)わない？大(だい)改造(かいぞう)したっていうよりは、ちょっと追加(ついか)しただけ、みたいな印象(いんしょう)だったんじゃないかな。さてさて、まだ終(お)わらないよ。もっと高(たか)みへ行(い)こう！現状(げんじょう)だとタブを３つとか４つとか開(ひら)くとカクカクしちゃうときがあるよね。そう、ラグいんだよ。次回(じかい)はこのラグをスケールアップという技(わざ)で直(なお)す！あとプレイヤーを追加(ついか)する入場(にゅうじょう)処理(しょり)ができているけど、次回(じかい)か次(つぎ)次回(じかい)でオフラインになったプレイヤーを除去(じょきょ)する退場(たいじょう)処理(しょり)も実装(じっそう)しようと思(おも)う！こうすることで入(い)れ代(か)わり立(た)ち代(か)わり遊(あそ)ぶ人(ひと)が途切(とぎ)れないオンラインゲームになるってことよ。近日(きんじつ)中(ちゅう)に更新(こうしん)するので待(ま)っててね～。