北海道の下川町で行ったゲーム開発体験イベントの話

こんにちは。技術部平山です。

今回は、2024年1月15日から2日間、北海道の下川町にて行った「ゲーム開発体験」というイベントのことと、それに関連して「プログラミングの教育」のことについて書きます。

イベントのこと

小学1年生から中学2年生までの20人以上の人に参加してもらえました。本当は高校生にも参加してもらえたら良かったのですが、高校生はすでに冬休みが終わってしまっていたそうです。もっと早く開催できると良かったかもしれません。

参加してくださった方の満足度は、それぞれ聞いてみないとわかりませんが、 2日目も参加してくださった方が半分くらいはいましたし、 Scratchのアカウントを作って自分の作品を持ち帰ってくれた人もいました。たぶん、結構楽しんでもらえたのではないかと思います。

なお、この文章を書いているのは平山ですが、実際にやったのはかなりの部分がトモぞヴPです。感謝してもしきれませんし、子供を楽しませることに対する彼の真剣さには、本当に驚くべきものがありました。

内容

内容として用意していったプログラミング環境は、 viscuit、 Scratch、そして手前味噌ですがSunaba、の3つです。結局前2つでSunabaは使いませんでした。 viscuitが8人くらい、あとはScratchです。年齢を尋ねてはいないのですが、viscuitは低学年のお子さんに選ばれていた印象があります。

作っていった資料はgoogle drive に置いてあるので公開しておきます。ただし、全てを使ったわけではありませんし、その場のノリに合わせて飛ばした所や、補った所もあります。

viscuitを選んだ理由

viscuitがどんなものなのかは、公式サイトからご自分で体験されるのが良いと思いますので、ここでは使った理由を述べます。

まず、キーボードがいりません。

参加者の募集は事前に行われ、小学校低学年のお子さんがかなり含まれていることがわかっていました。となるとキーボードを使うのは困難です。 viscuitは絵を描くことでオブジェクトのクラス的なものを生成し、それをスクリーンにドラッグすることでインスタンスを生成します。

また、「手順を明らかにする」という面倒を後回しにできます。普通のプログラミングでは、起こることを分解して順番に並べる必要があり、朝起きて、着替えて、歯を磨いて、といった感じになります。しかしそれは結構難しいことであり、子供にとってはなおさらです。

viscuitの場合、入力と出力を定義する「メガネ」というものを定義しておくと、スクリーン内のインスタンス状態がメガネの入力にマッチした時に、出力に変換されます。「こういう状態になったら→こうなる」をバラバラに書けば良いので、順番を意識せずに済むわけです。これは本当に新しい体験なので、是非触ってみることをおすすめします。

例えば、卵と鳥を描いて、卵が入力、鳥が出力のメガネを定義すれば、スクリーンに卵が存在すれば、それだけでマッチするので、鳥に変換されます。

ライオンと兎を入力に指定し、出力にライオンだけを指定すれば、「ライオンと兎が接近した」という状態にマッチしますから、「ライオンが兎を食べちゃった」的なことを表現できますし、逆に数を増やすこともできます。

移動回転もメガネであり、メガネの入力にはタップも入れられるので、「タップしたら卵が生成される」といったこともできます。これによって、「とりあえず絵を描いてしまってから、それがどうなるかを考える」という自然な流れでのプログラミングが可能になっています。

以上のような理由から、低学年のお子さんが楽しみながら、キーボードのような怖い機械に触らずに「こうなると、こうなる」という変換の手順を作ることに慣れることができます。とりわけインスタンスが増えるようなメガネを定義すると、予想外に物が増えるので楽しいですね。

さて、プログラミングを教える方にとって、「これが本当にC#やJSのようなプロ言語の開発力につながるのか?」という疑問は当然のように湧いてくると思うのですが、それは私にもわかりません。そもそもお子さんがviscuitの体験と、キーボードでコードを書く行為を同じカテゴリだと思ってくれるか、ということすらわかりません。

ただ、楽しいのは確かで、小学校1年生でも作品が作れます。今回に関しては、それで十分に目的を達すると考えました。

Scratchを選んだ理由

実はScratchを選んだのは、かなり寸前でした。最初はUnityを予定していたのです。

トモぞヴPがこれまでUnityで作ってきた作品をいじって遊んでもらうとか、スーパーマリオ風の簡単なサンプルを作っていって絵を差し変えたりパラメータをいじったりして自分の作品を作ってもらうとか、そういったことを予定していました。

平山はScratchの経験がそれほどなく自信がありませんでしたし、トモぞヴPは触ったこともありませんでした。 Unityの場合まともにゲームを作ろうと思うと「C#でコードを書く」という今回はどうやっても無理な行為が必要となりますが、エディタ上で触れる部分をたくさん用意していけば楽しめるでしょうし、実際に公開されてたくさんの人が遊んでいるものに触れる方が盛り上がるだろうと思ったわけです。中学生であればコードを書けそうな感じの人もいるでしょうけれども、そういう人はSunabaに誘導すればいいと思っていました。

しかし、いよいよとなった時に、はたと気づいたのです。

「あれ?そもそもこれってタダで使えるんだっけ?」と。

正直よくわからない上に確認する時間もありませんでしたし、加えて「PC25台にインストールする手間がとても許容できない」という問題も浮上しました。 PCはレンタルなのですが、現地に直接送られています。前日に9時間かけて北海道に移動しますから、前日の準備時間は限られます。当日も13時からですから、準備にかけられる時間は3時間が限度です。インストールよりは段取りや資料の準備をする方がよほど重要と考えると、 Unityはないなということになりました。マリオ風のサンプルはできていたのですが捨てて、慌てて二人でScratchに挑んだわけです。

さてここでScratchが浮上した理由は、これまた「キーボードがほぼいらないから」です。

これほどまでにスマホとタブレットが普及した現在において、キーボードを使う必要性は相当に減っています。私が子供だった30-40年前は、キーボードを使えることがちょっとかっこよかった感じがありますが、今はたぶんそうではないでしょう。スマホで本を書いている方もいると聞きますし、 10年後にキーボードが絶滅するとしても驚きません。そういうわけで、キーボードはナシです。

Scratchはコードの部品をマウスでドラッグしてつなげることでコードが書けるので、キーボードを使うのは数字を入れる時くらいです。それなら許容できます。

入力がマウスなだけで、やっていることは文字で書くコードと大差なく難しいのですが、ScratchもUnity同様、コードがわからなくても既存のプロジェクトをいじれる余地があります。絵を差し換えることはできますし、インスタンスの位置を動かすこともできますし、コード中にある数字をいじることもできます。残念ながらUnityの方がいじれる余地は大きく、インスタンスを増やすこともできないし、設定値は実質「コード中のリテラルをいじる感じ」になってしまうのでやりにくかったりはしますが、 Unityのインストール関連問題を考えるとやむを得ません。

また、scratchは簡単に他の人が作った作品にアクセスでき、その中身が見られて編集もできるので、「自分でゼロから書くのがキツい人でもやれることが多い」という利点があります。我々も5つほどサンプルを持っていきましたが、それ以外にも多数の触れるプロジェクトがあるのはありがたいことです。

ただ、「コードを書かなくても遊べてしまう」ことは長所ばかりとも言えません。平山としては「コードが書ける人にはコードを書いてほしい」という思いがあり、Scratchで他人の製品をいじって遊ぶことで時間が過ごせすぎてしまうのは少々残念な感じはありました。しかし、今回に関してはそれはやむをえないし、楽しむことが優先で良かったのだと思います。

使わなかった選択肢Sunaba

元々は上記のように、Scratchの代わりにUnityを予定していました。 Unityでコードを書くのは年齢層と時間を考えると無理ですから、コードを書けそうなお子さんには別の何かを用意したくなります。平山としてはできればプログラムを書いてほしいわけですしね。そのためのSunabaでした。 Sunabaは平山が作った言語と実行環境のセットで、とにかくできることが少ない代わりに覚えることも少なく、短時間でコードを学ぶことに集中させるためのものです。

しかし、Scratchを使うことになったことで、コードを書くことの難度がかなり下がりました。キーボードを触れる必要がなくなり、「キャラが出てきて、歩く」くらいなら低学年でも書けます。 Sunabaだと描いた絵を入れることすら容易でなく、「楽しいことが起こるまでが遠すぎる」ので、仮にキーボードが使えたとしても小学生には辛すぎます。

一応用意はしていきましたが、選んでくれるお子さんはおらず、ナシにしました。それで良かったと思います。そもそもviscuitとScratchの2ツールでもサポートが手いっぱいで、私の家族(妻、中1、小4、小2)を全員動員してなおギリギリだった印象です。もう一個ツールが増えたら完全に破綻でした。

データの共有方法について

今回は25台のPCをレンタルして直接現地に送り、前日と当日にセットアップをする、という作業手順となりました。ここで問題になるのが、「データをどうやって渡すか」です。 viscuitもScratchもwebアプリなのでURLがあれば十分ですが、 URLを渡す方法がありません。こちらで作ったスライドを後で見ようと思う場合にもURLが必要ですし、 Scratchのサンプルも同様です。

そこで、それらのリンクを一つのスライドにまとめ、そのスライドをPDF化したものをUSBメモリで各PCに入れて回ることにしました。

資料の更新に備えて、ドライブ上のリンク集のURLをQRコードにして貼ったりもしましたが、実際使われたかはわかりません。 slackのようなものが使えると良いのでしょうが、単発のイベントではそこまで用意するのは困難でしょう。

もっと良くしたい

今回は20人以上にviscuitやScratchといったものがあることを知ってもらい、実際に触って作品を作ったり、動いているゲームの中身を覗いてもらったりできたわけで、たぶん相当にうまく行ったと思います。

しかし、満足してしまえば、それで終わりです。平山は「誰かが何かをできるようにするのを手伝う」ことを人生の課題だと思っていますから、「もし次があったらどうするか」をつい考えてしまいます。別の形も模索したいですし、今回の形であったとしても、何かしら工夫する余地はあるでしょう。

viscuitについて

viscuitは素晴らしいツールです。支援級に所属するうちの末っ子でも小1に時にはメガネを使って動くものを作れていました。今でも自発的に、しかも頻繁に遊んでいます。レゴに知育玩具としての効用があるのだとしたら、 viscuitにも間違いなく同じような効用があることでしょう。タブレットスマホ世代にとっては、レゴよりもタブレットでできるviscuitの方が手軽、ということも見逃せません。無料ですしね。

ただ、今回イベントで使ってみて、少々使いにくい点はありました。

まず、PCのスタンドアロン版がありません。過去にはあったようなのですが、今はどうも見当たりません。そのためネット接続が必要で、間違ってブラウザを閉じたりリロードしたりすると作品が消えます。子供は誤操作が多いので、この頻度はかなり高くなります。

会場のwifiが十分な性能だったのでネット接続必須なのは問題になりませんでしたが、もしwifiに制限がある環境なら、スタンドアロン版が欲しくなるでしょう。

次に、保存の操作性に難があります。サーバにアップロードすることはできますが、名前をつけることもできず、他人の作品と一緒のリストに入るので自分のものを探すのが手間です。さらに、アップロードすると編集画面から出てしまうので、「とりあえず一旦保存」といった使い方には適しません。作ったもののjsonデータを表示することはできますが、子供が自分で保存するのは難しいでしょう。これらの制約はブラウザで動いているためだと思うので、その意味でもスタンドアロン版があると楽だなと感じました。それならオートセーブも可能でしょう。

最後に、範囲を限定した公開ができません。アップロードは可能ですが、おそらく世界中の人の作品が混ざってしまうので、「今このイベントにいる人達の作品のリストが作りたい」という用途には適しません。イベントで作ったものを共有するには、リアルで見せるしかない感じです。作品が一人一つである限りはリアルで見せれば済むのですが、複数作って取っておきたい場合もあるでしょう。

また、これはイベントと直接の関係はありませんが、「成長過程の記録にしたい」という場合もあります。自分の子が6歳の時に作っていたものはこんな感じで、 7歳で作ったものはこんな感じ、といった履歴があることはうれしいですし、教育の計画を立てるのに使おうと思う親もいるでしょう。今回のイベントにおいても、お子さんが作ったものを持って帰れないので、親御さんは自分の子が何を作ったのかがわからないままになります。自分用のリストにアップロードできるような機能があると、このあたりの使い勝手が良くなると思われます。

もっともScratchのように大々的なサーバを置けないことによる制限でしょうから、リストの共有のようなものは難しいかもしれませんが、スタンドアロン版があれば軽減する問題は多いように思います。

あとは機能的な面でも、スクロールの使い勝手が若干良くないとか、メガネやオブジェクトを消す方法がわかりにくいとか、「割れたメガネ」という隠し機能が意図せずにできてしまってよくわからなくなってしまうとか、そういった点もあります。

今後もこういったイベントがあればviscuitを使うでしょうし、末っ子のために保存機能の強化はしたいので、思想を受け継いだアプリをUnity上で実装することを考えていたりはします。Unityで作ればweb版、PC版、タブレット版を同時に作れるでしょう。

Scratchについて

Scratchも優れたツールです。世界的に使われていてドキュメントも多数ありますし、作品公開サーバも立派なものですから、参考にする作品が無限に得られ、自分の作品を簡単に公開できます。

キーボードなしでコードを書ける、ということの利点は今の時代には非常に大きく、今後はさらに大きくなるでしょう。「やっていることは文字で書くコードと大差ない」ということは、文字で書くコードへの移行も容易いということです。私も5個ほどゲームを作ってみましたが、「これで書けるならC#で書いても大差なく書けるだろう」と思ってしまいました。プログラミングの本質的な難しさはほとんどそのままそこにあるからです。

しかし、それだけに、対象が小学校低学年となると少々難しすぎます。低年齢向けのScratchJrもありますが、こちらはスマートフォン/タブレットのアプリのみで、 web版がなく、先にPCを手配してしまった関係で使えませんでした。

Scratchの難しさは、まずは機能の多さに現れています。分類は適切ですし、色や形でも種類がわかるように工夫されていますが、やっぱり多い気がします。「2000年からの日数」とか「ユーザー名」とかの外部から情報を取る利用頻度が低そうな機能が、明らかに利用頻度の高いifやwhileなどの制御構造と同列に並んでおり、機能リストが結構長くなっています。初めて触る人にとっては、「画面に物が多いこと」は壁になりそうに思えます。

そして、ちょっとややこしいものを作ると、結構手こずります。縦シューのような伝統的なゲームや、マス目単位のテトリスなどはかえって作りにくいのです。例えば「当たり判定の結果どちらかのオブジェクトを消す」という処理をすると、片方のオブジェクトにしか通知が来ず、どちらに来るかが不定だったりします。また、オブジェクトのクローンも結構大変です。変数はデフォルトでC#で言うclass staticなために共有されてしまって予想外の挙動になりやすいですし、メッセージの受信は全インスタンスで行われてしまい、インスタンスの識別は一手間かけねばなりません。「当たった相手のメソッドを呼ぶ」という機能がないので、メッセージを多用することになるのですが、メッセージの受信順が不定なのも厄介です。かといってクローンなしでは、出す物の数だけスプライト(実質class)を定義する必要があり、それぞれにコードを複製して入れねばなりません。 C#で言えば「同じ挙動のキャラが16体出るのでクラスを16個作ってコードはコピペ」というような状態です。「にゃんこ大戦争」的なものは基本のコーディングは簡単なのでサンプルとして良いように思えますが、クローンが避けられない題材なので、初心者向けのサンプルとしては若干難しさがあります。

加えて物理が統合されていないので、ジャンプのような「よくある挙動」をコードにするのは初心者にはかなり大変です。ロジックを書かせることに集中するなら「何もしていないのに動く」は邪魔でしかなく、 Scratchのコンセプトは正しいと思うのですが、「ちょっと触って動いて楽しい」を求める場合にはこれが難しさになります。例えばスーパーマリオのようなものを作りたければ、 ScratchよりもUnityの方が簡単かもしれません。

以上のようなことがあり、ある程度コードを書けると見込める小学校高学年以上であっても、時間が限られたイベントでコードを書いてもらうのは少々工夫が必要になりそうです。最低限Scratchで作りやすい種類のものを作るようにうまく誘導することは必要でしょう。

Sunabaをどうにかしたい

Sunabaは「キーボードを打ってコードを書くことを覚悟した人」にとっては悪くない選択肢だと、自分では思っています。しかし、「キーボード」というだけで、すでに十分すぎるほど致命傷です。そして、描いた絵を簡単に出せないこともまた致命傷ですし、物理がないこともそこそこ辛い制限になります。どれもSunabaの設計思想的にわざとではあるのですが、今回のようなイベントではまるで使い物になりません。

そこで、Scratchのように部品を並べてマウスで並べるUIをつけ、スプライトを描いて任意の場所に貼りつけたり動かしたりする機能をデフォルトで用意し、当たり判定と物理を入れることを考えていたりはします。それができて操作性に問題がなければ、「ゼロからコードを書いて何か動くものを作る気がある人」にScratch以外の選択肢として提案できるはずです。エントリポイントが一つしかなく、メッセージやオブジェクトのような概念もないので、変数と関数とループと分岐が使えればそれで全部です。「Scratch向きでないものを作ると妙に難しくなる」といったことも起こりにくいでしょう。とりわけマス目単位のゲームは作りやすいはずです。

今回Scratchの偉大さを思い知ったので、「これがあるのに何故過去の私はSunabaを作ったのか」と自己嫌悪に陥ったりはしたのですが、元々のSunabaの用途である「大学での授業」という話に限れば Scratchでは少々合わなかったでしょうし、上に書いたように今回のような用途でもScratchがパーフェクトというわけではありません。ちょっとやる気が出てきました。