don't diffuse there the blue t;


"ブルー t"の問題点

20XX年X月Y日、Twitterは新たなる暴露の出現を受けて犯罪を公表した。

拡散は2006年7月に始まった。
のちにTwitter社と変更されるObvious社が活動を開始したのだ──。

っけから"don't click blue e"のパロディーで始まりましたがバカ発見機やデマ拡散機とまで言われるtwitterやSNSの問題点の話です。
そもそもtwitterとは口語では「オラわくわくすっぞ!」という意味です。
悪い意味ではべらべら喋る人とか嘲る人とかいうニュアンスもあります。嘲る(あざけ)とは馬鹿な者を見て笑うという意味ですのでバカ発見機を体現しています。

はなぜバカ発見器と呼ばれるのか説明するところから始めるとしましょうか。

きなり核心からですが、SNSでは個人情報を詳細に──しかも自ら──公開しているにも関わらず犯罪自慢や仕事先で見かけたオフの有名人の情報を発信していたりします。
足早に行きますが、要するにモラルの問題が浮き彫りになってるんですね。「ソーシャル」という事なのでやっていることは井戸端会議の奥様方の悪口伝達ゲームや口コミの風評被害と同程度のものです。

はなぜこうまで簡単に浮き彫りになるかといえばやはりInternetというものが常にオープンでワイドなものだからでしょう。そして誰にも所有されることもありません。
誰もがリンクし誰もが参加している場所なので自分の想像している以上に人の目があるということでしょう。

目を気にする日本人にもかかわらずSNSで自らあらゆる事を発信するというのは些か矛盾しているようにも感じます。それだけ普段気にしているものが中身がないということでしょうか?

の発信という行為も情報を取捨選択しなければデマ拡散器ということになるわけですね。
さて、この話もどこに落とそうかというそういう事ですが……それはまさにデジタルデバイドです。
これは自分の住んでいる国だけで済めばどこもそう代わりはないでしょう。しかし、WWWというのは国は関係ありません。これをわかりやすいように国際社会に置き換えれば南北問題やはたまた、封国してきた日本と開国を迫ったアメリカと言った感じでしょうか。

のまま情報に対する二極化が進めばいずれは黒船がやってくるのでしょう。mosaicでWWWを知った身としてはそれもまた体験してみたいものです。マイケル・ムーアあたりがドキュメンタリーを作ってはくれないでしょうか?

ADVエンジンの機能から見る実装寄りの話

ADVエンジンだけでなくRPGのようなメッセージを表示する必要のあるゲームすべてに関わる話ですがエンジンはシナリオスクリプトをパースしなければなりません。
シナリオスクリプト・パーサ(以下、パーサ)の機能はADVエンジンではシステムの「出来ること」に直結します。

本的なところでADVエンジンのパーサは任意のタイミングで停止し、同じく再開できなければいけません。
つまり、スレッドセーフであるかは別として再入可能であるということです。
さらに、パーサ・インスタンスを作りなおさずに別のシナリオスクリプト(以下、シナリオ)を処理できたほうがリソース─主にCPUパワー─も消費せず関連して、あるシナリオから別のシナリオを呼ぶ場合においてモタつく事がないでしょう。
よって、再利用可能であることが望ましいです。このことはユーザー任意のシーンに飛ぶ機能の実装を考えれば想像に容易でしょう。

然パーサの処理はプル型でなければいけません。なにやらxmlパーサの要件に似ています。
プル型で再入可能で再利用可能といえばStAXですね。これはストリーム指向でイベント駆動です。

なにやら、方針が見えてきました。次にイベント駆動を考えてみます。

ル型で再入可能なのでparser.nextメソッドによってシナリオの解析を進め、次の処理対象を返します。
このとき、素直に処理対象をnextメソッドの戻り値にしてもいいですがこれでは少し不便です。
たとえば画面には進歩具合を反映せずに─内部処理だけささっとやって─高速にスキップさせたいとします。
そのときには画面エフェクトなどは処理する必要はありません。フラグや変数をやっつければいいだけです。
ならば、処理を行うのに不要なデータを受け取る必要はありません。処理を行う前に受け取るデータを識別するためにはデータに対応するイベントが必要になります。
nextメソッドでパースを進めイベントの種類を返し、処理が必要なイベントか判断したら実際に処理を行います。これがイベント駆動です。

れがないと処理対象を見つけたと同時にシナリオに書かれた形式から処理対象を実際に処理できる形に改める処理までが一括で動作してしまいます。
この挙動は不要な処理対象を無視したい場合には無駄な動作が含まれるためリソースの無駄遣いでもあります。
イベント駆動ならば無視したいイベントを見つけたときにはparser.consumeFoo─またはnextBar─メソッドを呼び出し、次のイベントまで進めるだけで済みます。

ほかにもパーサのハンドラの実装が少し煩雑になり気味です。

よって、nextで進め処理が必要な場合にのみgetBazで必要な情報を取得します。ここもStAXと同じになりますね。

かにも「次の選択肢に進む」や「前の選択肢に戻る」と言った機能を考えます。
これらは現在位置から相対的に前進か後退を行います。なので両端連結リストのようにアクセスできる必要がありますね。
さらに任意のポイントに飛びたいこともあるのでランダムアクセスも出来る必要があります。
つまり、シナリオのパースと言っても扱う側からすればほかのデータ構造と変わりありません。

まとめ

  • シナリオパーサはストリーム指向でプル型が良い
  • イベント駆動が便利
  • 前進後退・ランダムアクセスが必要

今回は実装例はありません。

コーヒーマシンの未来

にはwebの世界で印象深い出来事が3つあります。
弁当箱にしか見えないV90モデムや我々に常にユーモアを提供し続けてくれたAOLやハロウィン文書ではありません。

つは当時はじめてwebに繋がり閲覧したKEKのページです。
日本語で書かれているページには感動しました。翻訳ソフトと辞書片手に翻訳する手間が省けるからです。
という冗談は今では通用しないでしょうが当時本当にあった苦労話です。
そもそもWWWサーバー数が20くらいにページ総数が300ちょっとくらいの時代です。日本語のページに出くわすほうが珍しいのです。

れから少したってブラウザといえばNNという時代になりました。
mosaicとNNの争いが終わって平和になるかと思っていた頃、突如としてIEが喧嘩相手に名乗りを上げました。
その後、ブラウザ戦争へと発展するわけですが、そうなる以前にビル・ゲイツが放った言葉が2つ目の印象深い出来事です。

「webへアクセスするのはごく一部で大多数の人間には流行らない」そう言いました。

たしかにあの当時はYAHOOがYAHOOと名前を変え、少しして商業化した前後くらいでそれ以前は大多数の人々に有用なものは無いといって過言ではないほど、というより誰かが利用するにはインフラが不足している感がありました。

かし、ティム・バーナーズ=リーを知りWWWの仕組みを知りmosaicでwebに繋がった人々はおそらく総じて、将来誰しもがwebへ繋がりそこにあるものを利用する時代がやってくると思っていたことでしょう。
なのでいくら敵将に放った言葉とは言えIEの長がそのようなことを口にしたこと自体が衝撃的でした。
これにはその後、win95OSR2にTCP/IPとIE4が標準装備されたというオチがあります。

がてブラウザ戦争が本格化する時代がやってきます。
だいたいその頃の出来事ですがある時マーク・アンドリーセンがこう言いました。

「PCのスイッチを入れてOSが立ち上がってそこからアプリケーションを立ち上げるように、PCのスイッチを入れたらすぐにブラウザが立ち上がってブラウザがOSの代わりをするような、そんな時代がやってくる。」

このような感じのことを言っていました。ブラウザがアプリケーションの基盤になる時代が来るという意味です。これが実に衝撃的でした。

たしかにブラウザを立ち上げればWEBにある情報に素早くアクセスでき、BBSやチャットに居るかも知れないどこの誰かもどんな特技を持つかも分からない名前と所属しか分からない人々とコミニュケーションを取ることが出来ました。
この頃にはサーバーが10や20の時代とは比べものにならない情報と人が存在していましたのでとても有用なものでした。

PCがさらに普及すれば皆がPCを立ち上げてすぐさまメール確認とWEBの巡回を始める時代が来るでしょう。実際にそうなりました。
そうなれば人々はOSをあまり意識せずブラウザに注目することになります。
人が増えるに連れWEBの世界は便利になり更に人が増えます。
ブラウザ上で行う作業はさまざまな種類へと増え、誰しもがブラウザで何かをこなし使いこなします。
そうして登場したのがWEBアプリケーションです。

こでマーク・アンドリーセンの言葉を思い出しましょう。ブラウザがOSの代わりをする時代です。

ブラウザが基盤となる時代です。今がその時代です

代は現在に移り、今やfirefoxが産み出した拡張機能という機能は受け入れられ、それがWEBアプリケーションを便利に使いこなすUIとなっています。
それだけではありません。

javascript関連技術が進化しブラウザとjavascriptを用いてアプリケーションを走らせるどころかWEBアプリケーションをオフラインで実行することだって出来ます。chromeではなんとネイティブコードが走ります。

ラウザは今やあらゆるデバイスに搭載されその殆どに共通したルックアンドフィールが見られます。
つまり、PCやその他のデバイスといった別け隔てなく基盤になりうる可能性を持ちます。その可能性がきっとWEBの未来へ繋がるでしょう。

誰か今後のWEBの未来を予言する人は現れないものでしょうか。

て、研究所からひたすら眺められるだけの仕事をついに全うしたコーヒーマシンはいまごろ余生を堪能している頃でしょう。
世界一有名になったコーヒーマシンがどんな余生を堪能しているかは人間の私には想像もつきません。(実はその後の経緯も当然知っていますがそれは言わないお約束ですよね)

スマートフォンのADVエンジンが少ないので考えてみる

趣味プログラマなので商業は知らない。
同人とかでPCだと吉里吉里/KAGやNScripterやYU-RISなどがある。うぃんどみるのCatSystem2や海外だとren'pyなんかもある。
しかし、スマートフォンのADVエンジンは少ない。Artemis Engineあたりが知名度と実績の両方があるのではないだろうか。

ところでスマートフォンのADVエンジンに必要な機能とはなんだろうか?

まず基本的なもの──
  • テキストを垂れ流して改行・改ページを行う
  • 選択肢
これだけあればとりあえずユーザー側は読み進められる。
ここで重要になるのはインターフェース。PCと違ってスマートフォンはマウスもH/Wキーボードも期待できない。
タッチパネルかせいぜい一つくらいの物理ボタンしか使えない。重要な問題その一だ。

次に開発側に必要なもの──いろいろありすぎて困るが欲しがるのはこんな機能だろう。
  • 目立つ演出機能
  • やたらライタが書きたがるスクリプト(ドメイン特化言語)
  • 結局イタチごっこなのに妙にこだわる暗号化
  • 漠然と要求されるタッチパネルらしい機能
  • ネットワーク経由のデータ取得
タッチパネルとネット経由でアーカイブダウンロードして端末のストレージに保存はたしかに欲しいですね──というわけで採用──ネット越しにデータ置くついでに暗号化もサポート。
これについては独自アーカイブに暗号化用フィルタつければ良さそうだ。

問題は残りのスクリプトと演出ですか、そうですか……。
同人や某ゲーだとライタがシナリオ書くついでにスクリプト打ちますね。
なので演出も自分で書きますか。
グリグリ動かしたいですか、そうですか……。

というわけでDSLも採用──なんかバブル時代の求人のごとく採用されてゆく。

そしてこれが「Android用スクリプト乗っけたADVエンジン」
画面は開発中のものです

e3roidを使ってKAGライクを実装しようと思ったらKASというエンジンを見つけたのでささっとそれをいじった──ライセンスがすごく緩かったんだよバーニィ!
具体的に何をしたかというとMozillaのjavaによるjavascriptの実装であるRhinoをKASに組み込んだだけ。これにより変数が使えエンジンをDSL側から叩くことができるようになった。
 そこで当然やりたくなるのが目立つ演出とやらだろうと思って……まだ何も実装していない。
なぜかというとここに一つ問題があるから。

スクリプトを組み込んだということはプラグインを用意してエンジンを拡張できる機能があるのが定番だがAndroidだと別段プラグインという形でコードを動的ロードする意味は薄い。
必要なファイルは全部一つに固められてしまうからだ。これならエンジンの必要な部品は全部一つのアーカイブに固めてデプロイし、タイトル個別のデータはネット越しに端末にインストールすればいいだろう。

こうしたほうがマーケットからゲームをダウンロードした上で新たに外部から何かをダウンロードする量が減る。ユーザー視点で見れば マーケットから落としてすぐにプレイしたいだろうにもかかわらず、外部との通信で更に長い時間を待たされるのは嫌だろう。
ならばただでさえ長くなる外部からのダウンロードを更に引き伸ばすより、データより容量の少ないプラグインをマーケットにあるアーカイブに含めて気づかないうちにダウンロードさせるほうがユーザーのストレスが少ない。
なのでスクリプトによるプラグインはちょっと待った。

そしてもう一つ問題がある。
ゲーム開発でスクリプトを組み込む理由はコード書いてそのままインタプリタで走らせて素早く試すためだ。
しかし、eclipse+ADTで開発するときファイルが更新されるたびにビルドが行われる。オートビルドを切ればいいのだがそうするといろいろと面倒くさい。
なのでインタプリタで素早くという利点は失われる。それならインタプリタで動く必要はない。javaの煩わしい冗長さから解放されて目的の処理を素早く書ければいい。
javascriptはマルチパラダイムで手続き型にもオブジェクト指向にも関数型にも書け、さらに最近の動的言語らしい機能の殆ど──rhinoはjs18まで実装されているのでGecko以外のブラウザサイドの実装とはわけが違う──を備えている。

要するにインタプリタでなくてもそれらの機能を駆使して手早く目的を果たせればいいことになる。
そこで閃いたのがscalaだ。これならそれらの要求を満たし事前にバイトコードにコンパイルされるのでインタプリタより早い。
しかしscalaにも欠点が一つある。scalaでAndroidをやると出来上がるサイズがかなりデカイのだ。

ここら辺はどうするか実際に実装してみて比べてみることにする。
しかし、それはまたいつかの話。