少し前に Nintendo Switch で発売になった「7 Billion Humans」を遊んでいる。
購入直後は「あれ？ 思ってたのと違う…」という感じだったので特に日記ネタにしなかったのだが、ステージが進むにつれて期待通りの内容になってきた。
しかし、このゲーム、遊んでみるまで内容がわからない。
事前に紹介ムービーとか作成者インタビューを読んでいても、どんなゲームかさっぱりわからなかったのだ。
そんなわけで、僕と同じように迷っている人のために、どんなゲームか書いてみようと思う。
一応、Human Resource Machineの続編ではある。
どちらも「プログラムゲーム」だし、インターフェイスや画面構成もほぼ同じだ。
だから、同じようなゲームかというと、全く違う。
プログラム言語が違うのだ。
プログラムを中心とするゲームなので、「言語が違う」というのは、かなり違うものだと思っていい。
前作、Human Resource Machine では、「アセンブラ」を使ってフィルタを作るゲームだった、と考えていい。
部屋の入口・出口にベルトコンベアがある。
入口からは「データ」が次々入ってくる。
これを、アセンブラプログラムで「加工」して、出口のベルトコンベアに乗せる。
結果が課題通りであれば、ステージクリア。
こういう、次々と入ってくるデータを適切な形に加工し、出力するプログラムを「フィルタ」と呼ぶ。
だから、Human Resource Machine は「フィルタを作るゲーム」だったんだ。
たとえば、次々入ってくる数値データを、0 を区切りと考えてそれぞれの合計を出し、出力する、という課題があったとする。
そのプログラムを、非常に低機能なアセンブラで作成する。
できた、と思っても、結構入力データが意地悪だ。
0 が2連続する部分があったりする。
0 が区切りなのだから、2連続ということはデータが空っぽ。
この時、合計を出力するのだから「0」を出さないといけない。
でも、うっかりしているとおかしなデータを出力して、上司に怒られたりする。
そう、このゲームの主人公は「おじさん」で、上司が課題を出す。
おじさんは、アセンブラに従って、ちょこまかと移動して働き、正しければ上司に褒められるし、間違えていたら怒られる。
このおじさん、あくまでも CPU の動作を「面白く表現」しているだけで、ゲームの主体はプログラムのほうにある。
おじさんの動きはかわいいが、おじさんを動かすゲームではない。
さて、今作 7 Billion Humans の話に入ろう。
タイトルは「70億の人々」という意味だな。全世界人口。
このゲームは、人をプログラムして動かし、課題をクリアしていくゲームだ。
前作のように、おじさんの動きは飾りではなくなった。おじさんの動きのほうが主体で、それを動かすためのプログラムを組むのだ。
8方向のどちらに進むか、命令パネルを並べ、おじさんが行った先で pickup で置いてあるものを拾う。
そして、指示されたところに移動して、drop で持っているものを置く…
最初のほうの課題は、そんなのばかり。
あ、これ、ダメな奴かもしれない。プログラム教育の悪い例だ。
…そう思ったから、購入してもすぐに日記ネタにしなかったのだ。
Hour of Code という活動がある。
子供にプログラムを教えよう、と頑張っている組織だ。
子供に人気のキャラクターが、そのキャラクターに合わせた「課題」でプログラムを教えてくれる。
たとえば、「アナと雪の女王」を使ったチュートリアルがある。
ここで、「前に n ピクセル動く」とか「右に n 度曲がる」などを駆使して、スケートの跡で綺麗な模様を描いてみよう、という「プログラム学習」が行える。
たしかに、わかりやすい。そのわかりやすさは「与えられたとおりにすればいい」からだ。
結果として、課題はクリアしていくのだけど、プログラムを理解できないまま終わってしまう。
一応、順次実行や繰り返しなどの、プログラムの基礎は学べることになっているのだけど、プログラムってそういうことではない。
「どうすればいいんだろう」って悩んで、解決方法を自分で組み立てていくのがプログラムだ。
まぁ、Hour of Code のすべてがこういう課題だというわけではない。
（以前はすべてだったのだけど、今見に行ったら、現在は「上級課題」としてもっとまともなものが用意されているようだ）
悩むにしても、知識ベースがないと解決方法がわからない。
その知識ベースを与えるために、こういう学習方法もありだとは思うのだけど、これだけで終わってしまうのは面白くないというか、もったいない。
で、7 Billion Humans もそういうゲームなのか、がっかり…と思いながらも先に進めたら、途中からどんどん変わってきた。
今作では、「おじさん」が一人ではない。多数の人々が協力して課題を解かないといけないようになっている。
でも、ここで大切なのは「プログラムは１つだけ」ということなんだ。
多数の人がいて、協調動作を求められているにもかかわらず、その指示を行うプログラムは１つしか作れない。
だから、工夫しないといけない。
プリンタから出てくる書類を、人々が順次閲覧して、最終的にシュレッダーにかける問題がある。
このプログラムで真っ先にやらないといけないのは、「自分の位置を認識させる」ことなんだ。
プリンタの前にいる人は、プリンタからの書類を受け取らないといけない。
シュレッダー前の人は、書類を受け取ったらシュレッダーに入れないといけない。
でも、それ以外の人は、「隣の人から書類をもらう」という動作以外をやってはいけない。
自分が何をすべきか、周囲の環境から判断し、処理を振り分けるプログラムを作らないといけない。
UNIX などの OS では、fork を使って並列動作ができる。
その際、プログラムは同じものになるのだけど、自分が「親」か「子」かを判断して違う動作をさせる必要がある。
このゲームでは、そういう高度なプログラムと同じものを求められるんだ。
さらには、途中の課題から「メモリ」が使えたりもする。
前作では、「入力」されたデータを床に置いたりすることができ、それがメモリだった。
今作では、一人の人は、4つのことを覚えられる。これがメモリだ。
覚えられるのは、データの値だったり、その値を計算した結果だったり、部屋の中の「位置」だったり、文脈によって自由に変わる。
さらには、「最寄りの社員の位置」とかを瞬時に見つけ出して、その位置をメモリに入れたりもできるようになる。
位置は、「その位置まで移動」という形で使える。
８方向に１マスづつ異動ではなく、一気にその位置まで移動できる。
メモリが出てくると、ゲーム内容が一変する感じすらある。
ただし、メモリはあくまでも「個人の記憶」であって、共有メモリのようなものはない。
だから、協調動作の際に、共有メモリを使って指示、みたいなことはできない。
（これ、並列プログラミングでは結構やるのだけど）
だから、個々人はそれぞれ独立にプログラムを実行しているだけで、協調動作などのようなことはできない。
…この時点までは、まだ。
さらに後の課題で、listen と tell というコマンドが増える。
listen した人は、tell されるまで動作を止めてしまう。
これを使って、やっとタイミングを合わせて協調動作させることが可能になる。
tell するときは、「全員に」聞こえるように大声を出すこともできるし「隣の人に」話しかけることもできる。
これも、他の人の動きを待とうとして、全員一斉に listen したりしてはならない。
何らかの周辺環境を判断して、最初に動く人を決め、その人以外が listen するようにプログラムを組む。
たとえば、床一面に広げられた「数値データ」の平均を取る課題がある。
７×７にデータが並び、その下に７人の人がいる。
それぞれを上に進めながらデータを合計していくのだけど、これだと「各列の合計」しかわからない。
一番上まで行き、列の合計が出た後が問題だ。
人々のスタート位置は異なっていて、わざと一番端の人のスタート位置を下げてある。
逆に言えば、端の人は最後に上まで到達するように作ってある。
そこで、端の人以外は、上に到達したら listen して待つ。
端の人は、到達したらそこのパネルに合計値を書き込んで、隣の人に tell する。
tell された人は、隣のパネルの値を自分の覚えている合計値に足し、パネルに書き込み、隣の人に tell する。
以下繰り返し。
これで、最後の人は「全体合計」を知ることができる。
49 で割れば平均値になる。
課題としてはこの平均値を「答える」ための操作でまたいろいろあるのだけど、大体目標は達成できる。
一応、この後「周囲の８マスを順に」という、ループ命令が出てくる。
このゲーム、前作に比べて課題が多く、まだ最後まで終わらせていない。
まだまだ新しいコマンドが登場するのかもしれない。
しかし、全体としては４つの段階に分かれているので、これで最後かも。
1段階目で基本命令、2段階目でメモリ、3段階目で listen と tell 、4段階目でループだ。
一つ不満を書いておくと、課題ごとに、不要と思われる命令は使えないようになっている。
多分迷いなく答えにたどり着くための「やさしさ」なのだろうけど、それまでに出てきた命令は自由に使わせてくれたいいのに、と思う。
課題が多いと書いたが、１個づつの課題の難易度は低めだ。
そりゃそうだ。「アセンブラで書け」と、「Scratch で書け」っていうのくらいの違いがあるのだ。
Scratch は子供向け言語だけど、並列プログラムも可能だし、今回のゲームの言語と似ているように思う。
今回のほうが、明らかに高級言語。その時点で難易度が低くなるのは当然。
そして、その分課題を増やしてある。だから、ゲームとしてのボリュームは同じくらい。
どのくらい難易度が低いかというと、前作のアセンブラは子供には理解しづらかったようで、中学２年の長男も少しやって投げ出してしまった。
今作は、小学校３年生の次女が「面白い」と言って楽しんでいる。それくらい難易度が下がった。
あ、もう一つ不満点あった。
まずは課題をクリアすること。プログラムが汚くても、力業でも構わない。
クリアすれば、次の課題が遊べるようになる。
だけど、課題ごとに「短さ」「速さ」で基準値がある。
もし楽しみたければ、それらを目指してもいい。場合によっては、基準値を超えたものも作れる。
ここで、前作なら短さを目指すと、それなりに「美しい」プログラムになった。
美しいっていうのは個人のセンスによるものなのだけど、少なくとも短くするために無駄がそぎ落とされている、という意味合いだ。
これが、今作では短さを目指すと、エラー処理を無視することが多い。
たとえば、一歩歩くごとに、とにかく「ものを拾う」ように作る。
そこに何もなければ「なにもありません」とおじさんが立ち止まる。つまりは、エラーが出る。
でも、「何かあったら拾う」と条件判断をするより、１行少ない。
短いとしても、エラーが出まくるのは美しくないように思う。
でも、それをしないと課題をクリアできないこともある。
速さに関しては、前作はループ展開したりすることもあったが、今回はどれだけ並列度を上げられるかが勝負だ。
エラーが出ると「立ち止まった」分だけ遅くなるというペナルティがあるので、１ステップ増えてもエラー処理は必須。
こちらのほうが、むしろ「美しい」かもしれない。
その一方で、条件判断していると速度が落ちるので、大胆な「決め打ち」をすることもある。
データはランダムに変更され、速度は「何回か実行した平均値」で測られるので、データに依存した決め打ちはできない。
でも、条件判断が省略できるところを探して、汎用性がない「決め打ち」のプログラムを入れ込む。
これがまた、美しいプログラムではない。
今回のゲーム、短さを目指しても、速さを目指しても、美しくないプログラムになることが多いのだ。
しかし、最適化が難しくて、後回しにしている課題も多い。
後回しにしている、というのも、簡単に思いつかないほど奥が深いということではある。
まだしばらく楽しめそうなゲームだ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |