Hatena::ブログ(Diary)

shi3zの長文日記 RSSフィード Twitter

2015-01-23

いわゆるツクール系ソフトの企画を立てた時のことと、MOONBlockによるAOP 09:49

 昨日のネタ(プログラムはもっと簡単にできる - shi3zの長文日記)の続きですが、「そんなに親切にしたらただのツクールじゃん」というツッコミがありました。

 そして思い出したのですが、僕がツクール系ソフトを企画していたってことは今まであまり喋ったことがありませんでした。というか僕自身も忘れてました。


 ひょっとすると、僕がMOONBlockをやっているのはその経験が影響を与えているのかもしれません。



 僕が企画したのはアスキーから発売されたネットワークRPGメーカー2000というソフトで、主に担当したのはTECH Win山川編集長へのプレゼンまでと、実際のサンプルゲームの仕上げで、中身を作ったのははむぞーこと高橋昇剛でした。


 このゲーム、ツクール系としては初めてのネットワーク対応ツールで、当時、ネットワークゲームの開発ノウハウが確立されていない頃に企画しました。98年頃だったと思います。


 非常によく覚えているのは、当時のTECH Winの山川編集長が「なぜログインはツクールを作ることになったのか」という話です。


 「その昔、河野真太郎という天才的な編集者が居て、彼は"いずれ衛星通信や高速通信が整備されて、ゲームが毎週のように配信される時代がやってくる。しかしそんな時代が到来したときに困るのは、ゲームを作るのが恐ろしく大変だということだ。原稿用紙が原稿の書き方を形式化したように、ゲームの作り方を形式化し、ゲーム開発全体を効率化しなければゲーム業界は滅んでしまうかもしれない"と考えていた。そこでゲームジャンルごとにゲームの作り方を形式化し、シューティングゲームツクール、アドベンチャーゲームツクールを作った。そしてRPGツクールに至ってこの流れは完成した。RPGツクールなら全くプログラミングを意識せずに自由な物語を作ることが出来る。さらにここからネットワークRPGを作ることが出来れば、ただでさえユーザ同士で遊ぶことが出来るネットワークRPGの、世界そのものをユーザが創り出すことが出来ることになるはずだ」


 この山川編集長のアイデアをもとに企画書に起こしたのが僕だった、というわけです。

 企画書の仮タイトルは「ネダンゴ2000」で、簡単な仕掛けの入ったDiabloタイプのクォータービューのネットワークRPGを作ることが出来る、というのが目標でした。スクリプト言語とかも入れたかったのですが、当時の僕の力量ではそこまで企画書に盛り込むことはできませんでした。


 翌週、この企画書を提出すると「値段が2000万か!」と見積もりを出す前から山川編集長に言われ、その場でゴーサインが出ました。


 山川編集長の発言を振り返ると、もともとツクールのアイデアは今で言うUnityのような、ゲームエンジンの構想を含んでいたのです。


 ところがUnityを見ればわかりますが、Unityは特定のジャンルのゲームを作ることに特化した環境ではありません。

 Unityでは事実上どのようなゲームも作ることが出来ます。


 Unityはゲーム開発環境であると同時にプログラミング環境でもあるからです。


 ちなみに大元の「ネットワークRPGメーカー2000」は絶版ですが、それが含まれる「ネットワークRPGをつくろう」というムックは入手できます。


 MOONBlockをあまり親切にするとツクールになってしまってプログラミング教育にならない、という指摘が前回のブコメでありました。


 しかし、ツクールはもともとプログラミングを簡略化するための環境です。

 僕はこの二つの概念を対立させることなく融合できると考えています。


 MOONBlockには「キット」という、プログラミングに必要なブロックを纏めたライブラリがあります。

 このキットのなかで、「シューティングゲームキット」や「パズルゲームキット」「アクションRPGキット」みたいなものを提供して、最低限、特定のジャンルのゲームはもっと素早く作れるようにするのはアリかなと思います。


 たとえば今のMOONBlockの場合、内部的にはenchant.jsのSpriteクラスを継承した「パペット」クラスの定義をすることでゲームを作って行きますが、自機を表現するためには「出現」ブロックを「ひとりで出て来る」指定し、さらに「動き」ブロックから「タップしたところに向かって移動」を選ばなくてはなりません。


 東さんはそうではなく、「主人公」というブロックをパペットに付けるべきだ、というのです。


 これはブコメにもありましたが、アスペクト指向プログラミング(AOP)っぽい考え方かもしれません。


 普通のプログラミングだったら「主人公」ブロックを作るのではなく、パペットを継承した主人公クラスを作るべきです。


 しかしそれだと外部(非プログラマ)から見た時に「どちらもパペットなのに主人公と敵役と味方役」という三種類のパペットが登場することになって混乱します。


 JavaScriptのプロトタイプ型オブジェクト指向の特徴を最大限利用すると、確かにAOPっぽく「主人公」ブロックが追加されるといくつかの振る舞いが変更されるようにした方が効果的かもしれません。


 「できあいの部品を組み合わせるだけならば、それはプログラミングではないのではないか」という指摘に関しては、「これはフレームワークコンポーネントである」という答えを返したいと思います。


 プログラミングの世界では、全てをプログラマがコントロールする形でプログラミングを行う最古のゲームプログラミングから、フレームワークを利用して必要な差分だけをプログラミングする時代、そしてUnityやUnrealEngineのようなゲームエンジン上で複数のソフトウェアコンポーネントを組み合わせる時代へと進化してきました。


 その目的は、できるだけ典型的なプログラミングをする手間を減らすこと、です。


 ファミコン、スーファミの時代はOSに相当する部分まで自分たちでプログラミングする必要があったことなどを考えると、最近のプログラムは恐ろしく簡単です。


 次になぜ「ゲームを題材とするのか」というと、「プログラミングを学びましょう」と言っても喜んで学ぶ人はほとんど居ないからです。



 それは「有限テンソルを学びましょう」くらい、実際に何の役に立つのかイメージしにくいワードです。


 目的がハッキリしていないと人は学ぶことが出来ません。

 エントリーバリアを下げる方法のひとつとして、ゲームは有効な手段です。

http://gyazo.com/e29004cb8bf9444718ed184c375ad3d0.png

 品川女子の一年生達がenchantMOONに飛びついたのも、僕が最初に「今日はゲームの作り方を教えます」と言ったからだと思っています。


 それはもう、生の反応ですから、非常に強い印象で覚えています。


 最初から僕が「今日はハイパーテキストの作り方を教えます」と言っていたらチンプンカンプンで興味を失っていたでしょう。


 僕が「ゲームの作り方を教えます」という出だしからスタートしたのは、品女で家庭科を教える酒井先生、学年主任の田口先生と事前に入念な打ち合わせを行って、今の女子中学生が何に興味を持っているのか、非常に詳細にリサーチした結果、ゲームという切り口が一番取っ付きやすいと思ったからです。

http://gyazo.com/0538734c4ff40a2e91f62eac4584a297.png


 実際のアウトプットは、ゲームとハイパーテキストが見事に融合したものでした。

 彼女達は自らの意志でMOONBlockとenchantMOONを使いこなし、思うがままの表現を可能にしたのです。


 そして説明の時間を短縮するためには、できるだけ早く結果が見れた方がいいのです。

 早く結果を見ることが出来れば、飽きさせずに次の展開を教えることが出来ます。


 たとえば「主人公」ブロックを追加して、「敵キャラ」ブロックを追加したら、次に「敵キャラにヘンな動きをさせたい」と思わせるのはそれほど難しくありません。ごく自然な感情です。


 この「ヘンな動き」というのが、たとえばジグザグな動きなのか、それとも円運動なのか、それともランダムウォークなのか、というのは子ども達の発想によって違ってきます。


 これは手続き的に書いてもいいし、「動き」ブロックの「ジグザグに移動(縦)」のようなブロックを適用することでも実現できます。


 いろいろな方法で彼女達の求める動きをさせるプロセスを示してあげることが出来れば、ごく自然にプログラミングの作法を身につけることが出来ます。


 ひとつの目的を達成するのに色々な方法を提供するというのは、プログラミングの世界では構文糖衣と呼ばれます。


 また、ゲームのジャンル毎にそれぞれ特化したブロックを提供するのはドメイン固有言語(DSL)と考えることができます。


 ツクールは非常に限定されたDSLでしたが、MOONBlockに一部ツクール的な機能を取り入れることにより、LISPプログラミングのように、部分的にDSLを用いながらも汎用言語としての機能を活用するというプログラミングが可能になるはずです。


 そしてしばしば、その方がよりプログラミングのための回り道が少なくなります。


 現状のMOONBlockでも、適切なブロックを追加すれば3Dゲームをプログラミングすることは可能です。

 実際、2012年のSIGGRAPHの展示では、僕が実験的に作ったWebGL版のMOONBlockというのも試しました。


 しかしそれだけでは複雑な3D空間をブロックで扱う意味はあまりなく、より理解しやすい2Dのゲーム開発を簡易化したあとで3Dに拡張した方が良いと考え、一旦3D化はペンディングしたのです。


 ゲームジャンルごとのキットを用意する構想そのものはもともとあったのですが、それに「主人公」や「敵」といったアノテーションをAOP的に挿入するという手法は、東さんとの会話中に思ったものです。


 それがより(文科系の人々から見て)自然な表現であれば、積極的に取り入れて行くべきだと僕は考えています。


 そもそもプログラミング言語自然言語に近づけようという試みは過去にも何度もされてきました。

 SmalltalkやHypertalkもそうした試みの一例です。


 記号言語では煩雑になりそうな処理も、ビジュアル言語ならより自然言語に近い記述ができます。


 「こんなの本物のプログラマー向けの言語じゃない」という批判に対してはこう返しましょう。


 「機械語世代からすれば、スクリプト言語なんてプログラミング言語じゃない、と言われる時代は長く続いた。しかしそんなことを言ってる人は既に滅ぶか、主旨替えをすることになった。機械語世代のプログラマーを、スクリプト言語世代のプログラマーが数で圧倒したからだ」


 

 品女の学生達は、放っておけば一生RubyもLISPも知らずに過ごすでしょう。


 そういう人たちがMOONBlockによって自らの意志をプログラムとして表現できたら。

 そうした中から本当に凄いプログラムが産まれて来るかもしれません。


 事実、彼女達は一切の補助無しにわずか一ヶ月間に独力でハイパーテキスト迷路やハイパーテキストによるクイズゲーム、落ちものアクションゲームといったものを開発することができました。enchantMOONを貸与した20名の生徒、全員がです。

http://gyazo.com/bd324ec123a49574535a488066ac4328.png

 MOONBlock自体がまだ非力であることから、ここから完全に革命的なプロダクトがまだ産まれるには至っていませんが、仮にJavaScriptとenchant.jsを教えていたとしたらそんな成果を得るのに何年掛かるかわかりません。


 それが「本物らしいか」どうかなど、どうでもいいのです。

 プログラミング言語など、所詮はツールに過ぎません。


 ツールに求められる最も重要な機能は「いかに労力を少なくして結果が得られるか」ということに過ぎません。


 ツールを使うための訓練は短ければ短いほどよく、使うために払う労力は少なければ少ないほど良く、使ったときの効果は高ければ高いほど良いわけです。


 中学一年生向けの50分の授業時間以内に全生徒にチャットプログラムを書かせるのは、ビジュアル言語以外では非常に難しいでしょう。大学の授業だって難しいと思います。


 それどころか、今回の授業ではチャットプログラムの改造まで時間内に説明しようとしています。


 生徒達にとっては、そのプロセスが本物であるかどうかはどうでもよく、作られたプログラムが、「事実、チャットとして動作する」ということの方が遥かに重要なのです。


 AOPの導入で、プログラミングはもっと信じられないくらいに簡単になるでしょう。

 いずれMOONBlockの基本ブロックの構成も整理したいとは思っていますが、とりあえず重要なのは、こういう側面です。