2013-09-30

GNUの30周年を記念したまとめ

Why Free Software Is More Important Now Than Ever Before | Wired Opinion | Wired.com

GNUの30周年にあたり、リチャード・ストールマンがwiredに寄稿しているようだ。記事で、ストールマンはネットワーク越しのサーバーで提供されるサービス、すなわちSaaSS(Service as a Software Substitute)が、不自由ソフトウェアと同様に危険であり、仕様を拒否しなければならないと訴えている。

もちろん、このBloggerも、そのようなSaaSSになる。Gmailもそうだし、Twitterもそうだ。なぜこれらのサービスが危険なのか。それは、利用者に自由を保証しないからである。利用者ではなく、サーバーの管理者に、一方的な権力を与えてしまう。

SaaSSは、サーバーの管理者に、利用者を監視し、検閲し、のみならず妨害や攻撃をする、不公平で一方的な権力を与えている。このため、SaaSSは不自由なソフトウェアを同様に危険であり、拒否しなければならないと、ストールマンは説く。

ただ、SaaSSは、ソフトウェアのような純粋に情報で表現できるものとは違い、利用者が所有しない、物理的なサーバーが関係してくる。なかなか難しい問題だ。

Happy 30th birthday, GNU! GNU Hurd 0.5, GNU Mach 1.4, GNU MIG 1.4 released.

GNUの30周年を記念して、GNUのカーネル、Hurdの0.5がリリースされた。

もはや、Linuxカーネルでは、自由を守るには不十分である。なぜならば、Linuxカーネルは時代遅れのGPL version 2でライセンスされているからだ。GPLv2は、Tivoizationの害悪を防げない。Tivoizationというのは、ハードウェアに搭載された自由ソフトウェアの改変を妨害する邪悪な機能である。Tivo社の例が有名になったので、Tivo化と呼ばれている。ハードウェアにあらかじめLinuxカーネルがインストールされて出荷されたコンピューターがある。ベンダーは、Linuxカーネルに施した改変を、ソースコードで公開している。もちろん、何らかの追加のビルドスクリプトなども、ソースコードに含まれるので、公開されている。そして、実際にビルドできる。しかし、もし、そのハードウェアに、Linuxカーネルの改変版の差し替えを妨害する機能が搭載されていたとしたら、ソースコードが公開されていて、改変できることが、一体何になるだろうか。プログラムを実行するハードウェアがないのでは、意味がない。

多くの邪悪なAndroidデバイスが、このような非人道的なTivoizationを行なっている。我々はこのようなAndroidデバイスを拒否しなければならないのはもちろんのことだが、同時に、このような吐き気を催す邪悪を防がなければならない。これは、従来のGPLv2ライセンスが想定していなかった、脆弱性なのだ。GPLライセンスは、この脆弱性を防ぐためにアップデートされなければならない。そのアップデートが、GPLv3である。GPLv3では、このような醜悪なTivoizationを禁止している。

さて、LinuxカーネルはGPLv2にとどまり、結果として、恥知らずにもTivoizationを行う憎むべきAndroidデバイスが、市場に多数出回っている。もはや、Linuxカーネルでは、自由を保証するのに不十分なのだ。我々には新しいカーネルが必要だ。

残念ながら、現在のところ、GNU Hurdは、GPLv2 or laterライセンスで公開されている。これは、いずれ、Tivoizationの害悪を防ぐために、GPLv3以降に再ライセンスしたほうがいいだろう。

まあ、とはいえ、さすがにGNU Hurdにはあまり期待していないのだが。

GNU Hurd 0.5, GNU Mach 1.4, GNU MIG 1.4 released | Hacker News

Hacker Newsでは、プロプライエタリなQNXを引き合いに出して、QNXは優れているが、GNU Hurdは理論ばかり振りかざす学者たちによる机上の空論だと切り捨てているコメントがある。なかなか興味深い。問題は、QNXは不自由ソフトウェアという、非常に間違った選択をしたことだ。そのため、広く使われたり、改良されたりする機会を失った。

2013-09-29

UTF-32 is NOT a fixed-legnth character encoding

Recently, Hacker News guys are discussing about Unicode and its many encoding schemes.

UTF-8 – "The most elegant hack" | Hacker News
UTF-8 Original Proposal | Hacker News

In the comments, many people believes UTF-32 is a fixed-length character encoding. This is not correct. UTF-32 is a fixed-length code point encoding. Character != Code point. Period.

Actually, I'm not good at Unicode or English as you see. But I think it is my duty to enlighten those blind people who still think characters in ASCII.

What is Unicode?

Unicode defines a set of code points which represents glyphs, symbols and other control code. It defines mapping between real glyphs to the numerical values called the code point. In Unicode, single code point does not necessarily represents single character.

For example, Unicode has combining characters. It has more than one way to express the same character. ñ can be expressed in Unicode code point by either U+00F1(LATIN SMALL LETTER N WITH TILDE) or U+006E(LATIN SMALL LETTER N) followed by U+0303(COMBINING TILDE). This way a sequence of Unicode code points semantically represents single character. Japanese has such characters too. Thus, in Unicode, Character != Code point.

Another expample is a feature called Variant Selector or IVS(Ideographic Variation Sequence). This feature is used to represents minor glyph shape differences for semantically the same glyph. CJK kanzis are the typical example of this. It's consist of Unicode code sequence, beginning with ordinary code point for the glyph, followed by U+FE00 to U+FE0F or U+E0100 to U+E01EF. If followed by U+E0100, it's the first variant, U+E01001 for second variant and so on. This is another case where a sequence of code points represents single character. Wikipedia said, additionally, U+180B to U+180D is assigned to specifically for Mongolian glyphs which I don't know much about it.

Now we know that the Unicode is not fixed-length character mapping. We look at the multiple encoding scheme for Unicode. Unicode is a standard for character mapping to the code point and its not the encoding scheme. Encoding of Unicode is defined by multiple way.

UTF-16

UTF-16 is the first encoding scheme for the Unicode code points. It just encode each Unicode code points by 16 bits length integer. A pretty straightforward encoding.

Unicode was initially considered to be 16 bits fixed-length character encoding. "16 bits ought to be enough for all characters" - a stupid assumption by some idiotic western caucasians so called professionals who has no real knowledge of real world glyph history I presume. Anyway This assumption is broken single-handedly by Japanese since I am fairly certain that Japanese has more than 65536 characters. So do Chinese, Taiwanese(although we use mostly same kanzis, there are so many differences evolved in the past so I think it can be considered totally different alphabets by now) and Korean(I've heard their hangeul alphabet system has a few dozen thousand theoretical combinations). And of course many researchers want to include now dead language characters. Plus Japanese cell phone industries independently invented tons of emozi. It never ends.

So, now Unicode has more than 2^16 code points, single code point cannot be encoded in 16 bits anymore.

UTF-16 deal with this problem by using variable-length coding technique called surrogate pair. By surrogate pair, two 16 bits UTF-16 unit sequences represents single code point. Thereby breaking the assumption of 1 unit = 1 code point. Combining with Unicode's combining characters and variant selectors, UTF-16 cannot be considered to the fixed-length encoding in any way.

But, there is one thing good about UTF-16. In Unicode, most essential glyphs we daily use are squeezed to the BMP(Basic Multilingual Plane). It can fit to 16 bits length so it can be encoded in single UTF-16 unit(16 bits). For Japanese at least, most common characters are in this plane, so most Japanese texts can be efficiently encoded by UTF-16.

UTF-32

UTF-32 encodes each Unicode code points by 32 bits length integer. It doesn't have surrogate pair like UTF-16. So you can say that UTF-32 is fixed-length code point encoding scheme.

But as we learned, code point != character in Unicode. Unicode is variable-length mapping of real world characters to the code points. So UTF-32 is also, variable-length character encoding.

But It's easier to handle than UTF-16. Because each single UTF-32 unit guarantees to represent single Unicode code point. Though a bit space inefficient because each code points must be encoded in 32 bits length unit where UTF-16 allows 16 bits encoding for BMP code points.

UTF-8

UTF-8 is a clever hack by... who else? THE fucking Ken Thompson. If you've never heard the name Ken Goddamn Thompson, you are an idiot living in a shack located somewhere in the mountain, and you probably cannot understand the rest of this article so stop reading by now. HE IS JUST THAT FAMOUS. Not knowing his name is a real shame in this world.

UTF-8 encode Unicode code points by one to three sequence of 8 bits length unit. It is a variable-length encoding and most importantly, preserve all of the existing ASCII code as is. So, most existing codes that expects ASCII and doesn't do the clever thing just accept UTF-8 as an ASCII and it just works! This is really important. Nothing is more important than backward compatibility in this world. Existing working code is million times more worth than the theoretically better alternatives somebody comes up today.

And since UTF-16 and UTF-32 are, by definition, variable-length encoding, there is no point prefer these over UTF-8 anyway. Sure, UTF-16 is space efficient when it comes to BMP(UTF-8 requires 24 bits even for BMP encoding), UTF-32's fixed-length code point encoding might comes in handy in some quick and dirty string manipulation, But you have to eventually deal with variable-length coding anyway. So UTF-8 doesn't have much disadvantages over previous two encodings.

And, UTF-16 and UTF-32 has endian issue.

Endian

There are matter of taste, or implementation design choice of how to represents the bytes of data in the lower architecture. By "byte", I mean 8 bits. I don't consider non-8 bits byte architecture here.

Even though modern computer architectures has 32 bits or 64 bits length general purpose registers, the most fundamental unit of processing are still bytes. The arrary of 8 bits length unit of data. How to represent more than 8 bits of integer in architecture is really interesting.

Suppose, we want to represents 16 bits length integer value that is 0xFF00 in hex, or 1111111100000000 in binary. The most straightforward approach is just adapt the usual writing order of left-to-right as higher-to-lower. So 16 bits of memory is filled as 1111111100000000. This is called Big Endian.

But there is another approach. Let's recognize it as 8 bits unit of data, higher 8 bits 11111111 and lower 8 bits 0000000, and represented it as lower-to-higher. So in physical 16 bits of memory is filled as 000000001111111. This is called Little Endian.

As it happens, the most famous architecture in Desktop and Server is x86(now its 64bit enhancement x86-64 or AMD64). This particular architecture choose little endian. It cannot be changed anymore. As we all said, Backward compatibility is so important than human readability or minor confusion. So we have to deal with it.

UTF-16 and UTF-32 each requires 16 bits/32 bits length of integer. and the internal representation of integer maybe Big Endian or Little Endian. This is a real pain if you store text in the storage or send it over the network.

UTF-8 doesn't take any shit from this situation. Because its unit length is 8 bits. That is a byte. Byte representation is historically consistent among many architectures(Ignoring the fact there were weird non-8-bits-byte architectures here).

Minor annoyance of UTF-8 as Japanese

Although UTF-8 is the best practical Unicode encoding scheme and the least bad option for character encoding, as a Japanese, I have a minor annoyance in UTF-8. That is it's space inefficiency, or more like its very variable length coding nature.

In the UTF-8 encoding, most Japanese characters each requires 24 bits or three UTF-8 units. I don't complain the fact that this is 1.5 times inefficient than UTF-16 for BMP so my Japanese text file is 50% bigger. The problem is, in some context, string length is counted by the number of units and maximum number of units are so tight. Like the file system.

Most file systems reserve a fixed amount of bits for the file names. Linux kernel's default file system Ext4, for example, reserve 255 bytes(1 bytes = 8 bits) for a file name. So the length limitation of file name is not counted by the number of characters, but number of bytes. Most GNU/Linux based distros now use UTF-8 as the default character encoding so the character encoding of ext4 is also UTF-8. For people who still think it in ASCII(typical native English speaker), 255 bytes is enough for the file name most of the time. Because, UTF-8 is ASCII compatible and any ASCII characters can be represented by one byte. So for them, 255 bytes equals 255 characters most of the times.

But for us, The Japanese, each Japanese characters requires 3 bytes of data. Because UTF-8 encoded it so. This effectively divide maximum character limitation by three. Somewhere around 80 characters long. And this is a rather strict limitation.

If UTF-8 is the only character encoding that is used in the file system, We can live with that(although a bit annoying). But there are file systems which use different character encodings, notably, NTFS.

NTFS is Microsoft's proprietary file system that format is not disclosed and encumbered by a lot of crappy patents(How could a thing that can be expressed in a pure array of bits, no interaction with the law of physics can be patent is beyond my understanding) so you must avoid using it. The point is, NTFS encode file name by 255 UTF-16 units. This is greatly loosen the limitation of maximum character length for a file name. Because, most Japanese characters fits in BMP so it can be represented by single UTF-16 units. In NTFS, even the Japanese can practically assume 255 units = 255 characters most of the times.

Sometimes, We have to deal with files created by NTFS user. Especially these archive files such as zip. If NTFS user take advantage of longer file name limitation and name a file with 100 Japanese characters, its full file name cannot be used in other file systems. Because 100 Japanese characters requires 300 UTF-8 unites most of the time. Which exceeds the typical file system limitation(255 bytes).

But, this is more like file system design rather than the problem of UTF-8. We have to live with it.

Unicode equivalence - Wikipedia, the free encyclopedia
異体字セレクタ - Wikipedia(Currently, no English Wikipedia entry for this)

x86のMMUはチューリング完全である

jbangert/trapcc · GitHub

The Page-Fault Weird Machine: Lessons in Instruction-less Computation | USENIX

x86のMMU、つまりは割り込みとメモリ変換テーブルは、チューリング完全であることの証明。割り込みとメモリ変換テーブルを活用して、プログラムカウンターを一切進めず、ひたすら割り込みを続けるだけで、任意の演算が可能になる。もちろん条件分岐だってオーケーだ。

このテクニックを使えば、カーネルモジュールのバイナリにとても解析が面倒な難読化処理を施すことができる。なぜなら、通常のインストラクションは実行しないから、何をしているのか、通常のインストラクションを追うだけでは一見して明らかではないからだ。そもそも、既存のKGDBなどは、あまりに頻繁な割り込みがかかるため、まともに機能しなくなるようだ。また、エミュレーターでこのコードを正しく実行できるのは、今のところ、Bochsだけだという。

このテクニックを使い、通常のインストラクションを実行せずに、ライフゲームを実行するデモ。

オンラインブックマークという移り変わりの激しいWebサイトについて

オンラインブックマークというサービスの価値に、私は当初、懐疑的だった。だが、実際のところ、ブログのネタを探す目的には、非常に役に立っている。

大勢の人間が、わざわざオンラインブックマークをするからには、そのURLには、大勢の人間の興味を惹きつける、何らかの要素がある。それがいいものにせよ、悪いものにせよ、だ。とくに、個人が最近書いた秀逸な技術的なブログ記事などは、このようなオンラインブックマークで話題にならなければ、なかなか見つけにくい。

日本語圏では、このオンラインブックマークは、はてなブックマークが事実上独占しているようだ。ただし、はてなブックマークは、英語圏のオンラインブックマークが提供している、ある根本的な機能が欠けている。フォーラムだ。はてなブックマークのコメント機能はとても貧弱で、到底、汎用的なフォーラムの代替とは成り得ない。英語圏で有名なオンラインブックマークは、いずれもフォーラム機能を提供している。オンラインブックマークは、フォラームのスレッドのトピックを設定する便宜上のものでしかない。

だが、英語圏のオンラインブックマークは、変遷が激しい。まず、最初に市場を独占していたのは、Diggだ。Diggは相当に有名になり、Diggでオンラインブックマークされることを意味する新しい過去分詞、duggまで作り出した。DiggでオンラインブックマークされたURLには、サーバーが落ちるぐらいアクセスが殺到するので、自分の管理するページがduggされたというのは、ある意味嬉しくもあり、ある意味恐ろしくもある出来事であった。

だが、Diggは改悪に次ぐ改悪を重ね、ユーザーが離れていった。自業自得である。Diggのあとに株を上げて流行ったのは、Redditである。

Redditは相当に流行った。Redditで生まれた言葉に、AMAがある。これは、(I am ..., Ask Me Anything)日本語で言えば「・・・ですがなにか?」に相当する言葉である。このようなタイトルで有名人や、事情通や、凄惨な過去を持つものや、時には無名の人間がスレ立てをして、どんな質問にも答えるぞということが、大いに流行った。

だが、そんなRedditも、最近はあまりクールではない。というのも、Redditはあまりに有名になりすぎて、ユーザー層の大半をバカが占めるようになり、ノイズだらけになってしまったからだ。

そういうわけで、今やクールなキッズは皆、新たにできたHacker Newsに避難した。Hacker Newsでは、ハッカーが興味を持つトピックだけが取り上げられ、ハッカーによって議論されている。

とはいうものの、今や、Hacker Newsも有名になりすぎていて、バカの流入が目立つようになってきた。最近では、「このスレタイはプログラマーじゃない人にはわかりにくくないか」などという浅はかなコメントまで出てくる始末。

そろそろ、Hacker Newsにかわる、またぞろ車輪の再発明が必要になるのだろうか。歴史は繰り返す。

Super Meat Boyの作者Tommy RefenesがSteamコントローラーを体験

Yzc2NjQ1MzQyNDU2MjMyMz - My time with the Steam Controller

あのクソ難しい、往年の悪魔城ドラキュラやスーパーマリオブラザーズを彷彿とさせる、死んで覚えるプラットフォームゲーム、Super Meat Boyの作者の一人、Tommy Refenesが、ValveでSteam Controllerの試作機を体験した感想を書いている。

Steamコントローラーの体験

俺がSuper Meat Boyを開発していたとき、俺は正しいコントロールが、ゲームの可否を決めるのだということを分かっていた。俺は、ゲームのコントロールには、うるさい男だ。もし、ゲームのコントロールが悪ければそれまで、誰か作ったかとか内容とかはどうでもいい、俺はそんなものをプレイし続けることはない。俺はよく、Super Meat Boyの動きとか摩擦だとか空気抵抗の物理の計算式についてたずねられる。実際のところ、あれには計算式などというものは存在しない。単にどデカいハックの塊だ。俺はSMBのコントロールを完璧にするために二ヶ月を費やした。あの空中で向きを変えた時に生じる不思議な「摩擦」から、壁から離れた時の200ミリ秒のディレイまですべて、俺がプレイした時の感覚で決められている。計算式には、物理なんてものは使われてない。100%、感覚によるものだ。

俺は、ハードウェアにも、うるさい男だ。Shannonが買ってきてくれたRazerコントローラーとやらは、ボタンのクリック感がおかしい。俺はあんなものでプレイするのは御免だ。俺はPS3が出た当初、プレイするのがイヤだった。なぜなら、SixAxisにはDualShockがなかったし、それに軽すぎたからだ。俺はDualShock3 SixAxisコントローラーが出てくるまで、まともにPS3のゲームをプレイすることはできなかった。俺はOuyaのコントローラーなど元から御免だ。というのも、あのコントローラーには大勢、レイテンシーの問題があると言っているし、俺もその問題に確実に悩まされるだろうから。

ボタンを押したら、押した感覚に満足し、画面にそのまま反映されなければならない。そういうわけで諸君、俺は自他共に認める、コントローラーにはうるさい男だ。

Steamコントローラー(その正式名称がどうなるにせよ)は奇妙だ。コントローラーを握った時の通常の親指の位置に、画像でみる通り、ふたつの丸いトラックパッドが取り付けてある。中央には、A,B,X,Yボタンで囲まれた将来的にはタッチスクリーンディスプレイなると俺は聞かされた箇所がある。中央にあるタッチパッド兼スクリーンは有効にされていなかったので、俺にはなんとも言うことはできない。タッチスクリーンを囲むA,B,X,Yボタンは、どうやらいわゆる「バック」的な設定のボタンらしい。これはA,B,X,Yというのよりも、何らかの機能を行う追加的なボタンというべきだろう。ゲームのアクションボタンとしては使うことはない。メインの入力方法は、左右の丸いパッドだ。

コントローラーの上部には、標準的なLRバンパーとLRトリガーがあって、これは期待通りに動く。コントローラーの背面には、ふたつのトリガーがついていて、指で自然に押すことができるが、それほどセンシティブではないので、単にコントローラーを握るだけで誤爆することはない。

俺の使ったコントローラーは、3Dプリントされた試作品だった。手のひらで握る部分は、XBox 360コントローラーよりは分厚かった。重さは同じぐらいだ。俺の感覚では、コントローラーは重すぎるという事も軽すぎるという事もなかった。コントローラーの厚みには気がついたが、俺が最近プレイしたGTA5のPS3コントローラーや、PCゲームに使う360コントローラーに比べれば分厚いというぐらいだ。厚みは気にならなかった。

コントローラーに馴染んだところで、俺はMeat Boyをプレイした。俺は手で覚えた感覚にまかせてプレイしたので、高度なテクニックも使った(壁スライド、ジャンプ高度カーブ等)。当初、俺は重大なラグに気がついた。そして、「クソ、俺はValveの連中に、このコントローラーはラグくてクソだって言わなきゃな」と考えた。Valveの連中が言うには、レイテンシーはとても低いのだという。そこで俺は、テレビが低レイテンシーの「ゲームモード」になっておらず、素早い反射神経を要求されるゲームがプレイ不可能なのだろうと考えた。実際その通りで、テレビの設定を変えて、ゲームモードにしてから、本当の戦いが始まった。

Valveの連中による設定は単純だった。左の円パッドは方向ボタン、右のは馬鹿でかいジャンプボタン。タッチパッドとタッチスクリーンにおける問題は、ボタンの上に単に指を置いているのか、それもと押しているのか、わからないという事だ。Valveはこの問題を、サークルパッドが押されたら、振動フィードバックを返すことで解決を図ろうとしていた。俺の試用中、振動フィードバックは確かに少々は役に立ったが、問題を解決するほどではなかった。

円パッドはタッチを登録された入力に変換するよう設定されていたが、プレスの感覚が妙だった。その理由は、タッチとプレスが両方とも入力に設定されていたからだ。パッドをプレスすることでMeat Boyを動かすことができるが、単に親指をパッドの上においただけでも動いてしまうのだ。これは、そう頻繁には起こらないものの、気がつくほどは多く発生した。この問題を指摘すると、あるエンジニアが(名前忘れちゃってスマン、俺、人の名前覚えるの苦手なんだ。マジな話、俺はよく元カノのLindsayじゃなくてJessicaと言い間違えるんだ。Jessicaってのは俺の姉妹の名前なんだ。俺はただ単に人の名前を覚えるのが苦手なだけなんだ。俺は顔とか服とかなら思い出せて、警察の絵描きに似顔絵を作成させたら、2分ぐらいで犯人を捕まえられるぐらいの記憶力は持ってるんだが、名前だけはどうもな)デスクに行き、プレスだけに反応するよう、ファームウェアを書き換えた。その後は、コントローラーはコントローラーらしく感じられた。方向ボタンを押すのは自然に感じられるようになり、コントロールの感覚がつかめるようになった。

物理的なボタンがないことの欠点としては、親指に何かしらボタンを押していることを感じさせる触角反応が必要になるということだ。俺はエンジニアとこの問題について話していたんだが、わずかに感じられるほどだが、マウスやトラックパッドモードでもそれほど煩わしくはない、小さな突起を配列するというアイディアが浮かんだ。Valveの連中はこのアイディアを以前思いついていたそうだが、俺の使っているコントローラーにはそのような仕組みはなかった。俺は連中に、そういうものがぜひとも必要だと力説した。俺の感想の結果から、連中は取り入れるかもしれない。そういうわけで、俺に感謝しな、ValveとValveユーザー。

ボタン設定は、SMBには十分よく機能した。俺は問題なくSalt factoryまで進められた。俺はC.H.A.Dが攻撃する前に鍵をゲットすることもできた。hospitalの二面のbandaidを、以下の動画のようにスピードランすることもできた(だが、俺はいつもまっすぐ落ちるので、bandaidを待つことはないのだが)。http://www.youtube.com/watch?feature=player_detailpage&v=JHJsnXRb_Es#t=1392

俺はMeat Boyの難しい面を、Meat Boyらしくプレイすることもできた(俺の腕は少々落ちていたが)。右の円サークルはジャンプボタンで、LRトリガーは両方とも、XBox 360コントローラーと同じように、ダッシュボタンに割り当てていた。また、先ほど述べた背面トリガーにもダッシュボタンを割り当ててみた。なかなか良かったが、手がつった。これはコントローラーやボタンの設計が悪いと言うより、Meat Boyにおけるダッシュボタンの使い方に問題があるようだ。

まあ、でもそれこそがMeat Boyだ。複数の入力が必要なゲームでどのくらいこのコントローラーがうまくやれるのかみてみたかったのだ。俺はSpelunkyをやらせてくれるよう頼んだ。Spelunckyはムチ、ジャンプ、ボム、ロープのボタンが必要になる。XBoxコントローラーのようにコントローラーを設定した。左の円パッドは方向ボタン、右の円パッドはXBoxコントローラーの配置のA, B, X, Yボタンだ。

Spelunkyをプレイしたところ、コントローラーは快適に機能した。プレイ中、俺はエンジニアに、Spelunkyにブレ動きが反映されてしまうことを訴えた。Spelunkyをプレイしたことがあるやつなら、この意味がわかるはずだが、詳細に説明すると、Spelunkyでは、パニックに陥って、回避行動を取らなければならない状況がよくある。例えば、プラットフォームをジャンプ中だとする。下はトゲで、上はコウモリだ。コウモリに当たると、トゲの上に落ちるので死ぬ。コウモリの上にジャンプすると、コウモリにあたって落ちて死ぬ可能性がある。そういう状況で、足場の上を維持したまま、ジャンプしてムチでコウモリを攻撃する必要がある。Steamコントローラーは、この状況でも機能する。俺の提案した突起があれば、より良くなるはずだが、まあ、最終的な製品版には、ひょっとしたら反映されるかもしれん。Ice Caveまで進んだが、クソなガイコツが俺を足場から押し出しやがったので、死んだ。そこで、俺は再度挑戦してはすぐ死ぬというループに陥った。Spelunkyではよくあることだ。

俺がSteamコントローラーでゲームをプレイしたいかと聞かれたら、まあ多分、イエスと答えるだろう。Steamコントローラーと360コントローラーのどちらを選ぶかと聞かれたら、俺は360を選ぶ。まあ、これは機能的な優劣というのではなくて、単に快適さと慣れの問題なのだが。俺はもう数千時間ものプレイ経験があるから、360コントローラーを選ぶのだ。ただ、もしも明日、すべてのゲームコントローラーが消失して、Steamコントローラーだけが唯一残されたコントローラーだったとしても、まあ、悪いことではないと思う。実際、ゲームに悪影響はないだろう。完成版のハードウェアがどのようなものかとても楽しみにしている。というのも、より改良されたものになるはずだからだ。

今北産業:
滑り出しはオッケー
改良が必要
どんなゲームでも遊べるぐらいのモノにはなってる

Valveが全く新しいゲームパッドを開発しているというのは気になっていたが、まさか三枚のタッチパッド、しかもうち一枚はタッチスクリーン(動画ではなく、柔軟なボタン表示のための静止画表示の様子だが)という斬新なものだとは思わなかった。そういう製品は私も大昔から妄想していたが、実際に設計して製品化しようという動きは、だいぶ時間がかかった感がある。

タッチパッドということで、とても気になるのはレイテンシーだ。なんと、ValveはSuper Meat Boyの開発者、Tommy Refenesを招いて試作品を体験させたらしい。そのTommy Refenesが、まあまあ使えると言っているのだから、レイテンシー的には問題ないという事になる。

それにしても気になるのは、「あるエンジニアが、デスクに行き、プレスだけに反応するよう、ファームウェアを書き換えた」というくだりだ。ファームウェアとはなかなか興味深い。Tommy Refenesがファームウェアという言葉の意味を理解していないわけがなく、またValveがわざわざ嘘をつくとか、嘘を書くように裏取引が行われたとも思えないので、やはりこれは文字通り、Steamコントローラーのファームウェアなのだろう。

これが本当だとすると、タッチ入力から、従来のゲームパッドやマウスやキーボード入力へのマッピングは、ドライバーではなく、ハードウェア側で行われていることになる。しかも、マッピングの変更のためにファームウェアを書き換えたというのだから、ゲームに合わせて頻繁にファームウェアを書き換える仕様なのだろう。ファームウェアというより、プログラムといったほうが正しい。つまり、Steamコントローラーは、プログラマブルなゲームパッドのハードウェアということになる。

しかしなぜなのか。なぜ生の値を受け取ってドライバー側でマッピングしないのか。ましてや、Steamはゲーム側でSteamコントローラーを直接扱えるようにするためのAPIまで用意すると言っているのだ。とすれば、ドライバーは生の値を受け取っているのではないか。

このことについてしばらく思考したところ、意外な考察結果が得られた。問題は、レイテンシーだ。

そもそもこのゲームパッドには、タッチパネルが三枚もついている。うち一枚はタッチスクリーンだが、左右の親指で操作する二枚のタッチパネルは、素のタッチパネルだ。このタッチパネルは従来のゲームパッドやマウスやキーボードといった操作をエミュレートしなければならず、また、Valveはソファーに座りながらマウスとキーボードの精度のFPSゲームができるとまで豪語しているので、この左右の円タッチパネルは、相当の精度を持っていることは疑いようがない。

このようなタッチパネルから得られる生の値というのは、二次元配列の静電容量の変化だ。これはつまり、画像に等しい情報量となる。しかも、ゲームなので、毎フレームごとに入力を取得しなければならない。ここで扱っているのは30fpsがせいぜいの非力なゲーム用コンソールではなく、PCゲームである。60FPSは最低限で、今や120FPSでも当たり前という過酷な世界だ。本物のゲームのための環境だ。となると、情報量はもはや動画に等しく、たとえUSBが十分な帯域を持っていたとしても、そんな馬鹿でかい情報量を転送したのでは、レイテンシーが、およそゲームのプレイには耐えられないほど高くなる。

高レイテンシーを防ぐため、USBを経由して送られる情報量を最小限に抑えるには、ゲームパッド側で生の入力を処理して、マッピングを行わなければならない。つまり、Steamコントローラーとは、プログラマブルなデバイスなのだ。

どうせSteamコントローラーは、スクリーンを搭載していて、プログラマブルで汎用なチップが必要なことは明白だから、プログラマブルであったとしても、それほど不思議はない。

とすると疑問がわく。一体、ファームウェアの生成と転送は、どのような仕組みになっているのだろうか。マッピングは、ゲームごとに異なるので、ファームウェアは動的に生成して、その都度、Steamコントローラーに転送しなければならない。GPUのようなものだ。そのファームウェアは、どうやって生成するのだろうか。

技術的にまともな方法としては、GPUのシェーダーと同じ方法だ。つまり、高級な言語でマッピングを記述し(その高級言語のコードは動的に生成する)、ドライバー側のコンパイラーでコンパイルし、ハードウェアに転送し、ハードウェア側で実行するというものだ。ことに、ゲーム側にもAPIを提供すると言っている以上、このような方法でなければ、まともではない。

もし、そのような設計であるとするならば、非常に面白い、ハックしがいのあるハードウェアだと思う。例えば、ゲームパッド上で動作するチューリング完全なインタプリターを書くとか。

なんだか、単なるゲームパッドにしては、やたらと大掛かりなハードウェアだ。ただ、タッチパッドを二枚、タッチスクリーンを一枚搭載したゲームパッドという時点で、相当に大掛かりなので、今更プログラマブルだからなんだということでもあるが。

Hacker Newsでも議論されている。

My time with the Steam Controller | Hacker News

2013-09-28

Valveの発表した風変わりなSteamコントローラー

Steam Controller

ValveがSteamコントローラーなるものを発表した。これは従来のゲームパッドに形が似ているが、ほとんどの入力装置が、物理的なボタンではなく、タッチパネルで構成されている。

まあ、そういうゲームパッドのアイディアは誰しも考えるだろうし、私も何年も妄想していたが、実際に製品化されるのは、この2013年までかかったわけだ。

このゲームパッドでは、タッチパネルを使って従来のゲームパッドのようなボタン配置やアナログ方向入力を自由にソフトウェアでエミュレートできる。

非常に興味深いので、もし自由なドライバーが提供されているのであれば、使ってみたい。物理的なボタンを押すのは指が痛くなるので、こういうものがあればどうなるだろうとは以前から考えていたが、物理的に押しこむ感触が一切ないというのも、それはそれで難しそうだ。

また、タッチパネルなので、レイテンシーの問題もある。果たしてゲームをプレイできるほどの低レイテンシーを実現しているのだろうか。

そして、有線であるかどうかだ。私はキーボードやマウスやゲームパッドのような直接的な入力装置には、無線を信用しない。画像では有線のようだが。

DolphinエミュレーターとOpenGLドライバー、栄光と恥

Official Dolphin Emulator Website - Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame

DolphinというGC/Wiiエミュレーターの開発者が、各種プラットフォームにおけるOpenGLの現状について気を吐いている。以下翻訳。

最近、NVIDIAとAMDが、グラフィックドライバーでLinuxをサポートするということが注目を浴びているが、我々は、Dolphinという、Windows、Linux、Macそして最近ではAndroidで動作するGameCubeとWiiのエミュレーターを開発するオープンソースのプロジェクトの経験から、現状を世界に知らせたい。

今年初め、Dolphin 3.5のリリースのあと、Markus Wick (degasus)とRyan Houdek (Sonicadvance1)は、DolphinのOpenGLバックエンドをOpenGL ES 3.0準拠にするための書き換えを始めた。この書き換えの理由は他にあるのだが(とってもクールな最適化ができるようになる)、モバイルデバイスとの互換性や、将来のAndroidへのエミュレーターの移植(今ベータ)が、目的だ。この書き換えは、数カ月前にメインのDolphinのコードベースにマージされ、何万人ものDolphinユーザーによって使われ始めた。OS XやLinuxでは、これが唯一のまともなグラフィックバックエンドであるし、Windowsでは、D3D11グラフィックバックエンドと並行して提供されている。

残念なことに、最近の高度なOpenGL機能を使うという事は、一部のグラフィックドライバーの悲惨なバグをいくつも発見するという事なのだ。どうやら、本当にごく少数のアプリケーションだけが、我々がGameCube GPUを高精度にエミュレートするために使いたいOpenGL規格の機能を使っているようだ。それについては後ほど書くとして、Androidでは、OpenGL ES 3.0のサポートはとても最近のことで、Play StoreでもES 3.0機能を使っているのは極わずかなアプリケーションだけだ。

これは、いうなれば、グラフィックドライバーの恥の晒しあげだ。問題の数、問題を会社に報告するのがどれだけ困難か、そして実際に修正されたバグがどれほどかということに応じて、ソートされている。

エクセレント - NVIDIA

我々にはNVIDIAのバグリポートへの報告への対応時間を計測する機会がなかった。というのは、NVIDIAのOpenGL実装は、WindowsだろうとLinuxだろうと、我々には問題が見つけられなかったからだ。OpenGLバックエンドの書き換えの前には、OS XをNVIDIAのグラフィックカードで動かした時に一つだけバグがあったが、これは当方の未定義動作のためなのか、NVIDIAのドライバーのバグなのか判然としなかったのだ。基本的に、我々が使うOpenGLのサブセットでは、すばらしくよく動く。我々は、NVIDIAを「パーフェクト」とも呼びたくなるが、ただし、直接にバグではないものの、ドライバーにはいくつかの問題がある。

  • クライアントサイドのバッファーストレージのサポートがない(最新のベータドライバー版はともかく):エミュレーションの都合上、Dolphinはクライアントサイドのバッファーストレージが高速であることを要する。この機能は、 ARB_buffer_storage拡張(OpenGL 4.4の一部)として追加された。AMDのドライバーはAMD_pinned_memory拡張によって、この機能をとっくの昔にサポートしている。Dolphinでは、悲惨なハックを用いて、データをunmapped buffersにコピーすることにより、なんとか、この拡張なしでもやっている。一応は動くが、とても悲惨だ。この機能がサポートされていないというのは、むしろKhronosグループを非難するべきなのだろうが、AMDはサポートするのにわざわざKhronosを待たなかったわけだし。
  • NVIDIA Graphics SDKのライセンスはGPLライセンスされたアプリケーション(Dolphin)と非互換であることと、GPUパフォーマンス要求のイケてない判定。NVIDIAドライバーは、しょっちゅう、DolphinをGPUパフォーマンスをほとんど必要としない種類のアプリケーションだと判定する。これはおそらく、精度の高いエミュレーションを実現するための操作のためだろう(GPU→CPU間の転送でかなりのストールが発生し、平均的なcommand queue lengthがとても短くなる)。NVIDIA Graphics SDKを使えば、ドライバーにハイパフォーマンスプロファイルを強制させられるのだが、GPLによりそれができず、一部のNVIDIAユーザーのパフォーマンスを落としている。SDKの再ライセンスが可能であれば、NvOptimusEnablementでやっているような方法と同じように、我々のバイナリでexportしているシンボルをみるなどしてくれればいいのだが。
  • オープンソース開発者にとって、サポートや技術的な質問を得るのが難しい。毎度毎度、NVIDIAに実装の遅さについて質問しても(ドライバー内のGL callのシリアライズ)、公式フォーラムでは何の回答も得られない。NVIDIAとOS Xの描画の問題について報告しても、何の回答も得られない。NVIDIAの公式フォーラムはしょっちゅうオフラインになり、サポートやドキュメント目的では使えない。追記:この記事を投稿してから6時間後に、3人のNVIDIA社員が独立して我々に連絡をよせ、ドライバーに関する報告がある場合の報告先について知らせてきた。これは大部分のオープンソースの世界には役に立たないが、まあ、我々の将来的には役に立つだろう。ありがとよ。NVIDIA!

後述するように、モバイルドライバーにおける我々の体験は・・・まったくよろしくなかったので(詳細については後述)、NVIDIAドライバーがTegra 4 SoCでどれだけうまくやれるのか非常に興味深くはある。我々はまだTegra 4のデバイスパワーを体験できていないが(クソ高いんだよ!)、Dolphinがどのくらい動くかというのはとても興味深い。DolphinのAndroidにおけるボトルネックとは、GPUとそのドライバーなのだから。

グッド - Mesa

驚くべきことに、オープンソースドライバー(Mesa)は、最悪ではなかった。大方は、QAが貧弱だったりプロフェッショナルなテストがなされてなかったりということを予想しがちだが、Mesaにはバグが少ないし、我々が遭遇したすべてのバグは、最近のMesa 9.0/9.1でサポートされたたったひとつの新機能に端を発していた。しかもしかも、我々がMesaで発見したバグはすべて、正しい報告場所(freedesktop.orgのバグトラッカー)で報告するや、ただちに修正された。ドライバー開発者との連絡は、オープンソースの世界では常識だが、常にとてもよろしかった。IRCでたずねた時、Mesa開発者は、新しい機能を実際に使うアプリケーションが出てきたことを非常に喜んでいた。

anholt: uboの利用者だって! やったぜ!
anholt: 要するに、とりあえずは動くようにしたってところで、「利用例が出てきたら、最適化が始められる」って段階でさ。

以下が我々がMesaドライバーで発見した4つのバグである。どれも、単一のUniform Buffer Objects(UBO)と呼ばれる機能に関連するもので、すべて安定版のドライバーで修正されている。

我々のUBOの利用例から、この機能のi965における実装は大きく再設計された。MesaとIntelの開発者であるEric AnholtはUBO data fetchingコードの大部分を書き換え、結果として、Dolphinにおけるパフォーマンスと精度を大幅に向上させた。

Mesa開発者の擁護のために言えば、我々がMesaのUBOを使い始めた時は、まだとても新しくリリースされたばかりの機能で、このバグを引き起こすほど多くのアプリケーションが使っていなかった。UBOオフセットに対するPiglitテストはなかったので、テストはあまり使われない機能もカバーするために拡張されるべきだろう。とにかく、我々はプロフェッショナルなQAは期待していなかったので、Mesa開発者が我々のバグ報告を真剣に受け止め、ただちに、まともな修正やデバッグ方法を考えだしたことは喜ばしいことだ。

我々の現在の問題は、Linuxディストリビューションはアップグレードが遅く、しかも、(Windowsとは違い)、システム全体を巻き込まずにMesaだけをアップグレードする簡単な方法を提供していないという事だ。つまり、我々のアプリケーションは、まだ一部のLinuxディストリビューションのLTSリリースのユーザーでは、壊れたままだ。

OpenGLバージョンのサポートは、あまりよろしくない。だが、我々はあまりオープンソースドライバーを責めるわけにも行かないのだ。とくにNVIDIAのGPUに対しては(nouveauはNVIDIAから基本的にサポート一切なしなのだから)。我々はむしろ、オープンソースドライバーがDolphinのような複雑なアプリケーションをまともに実行できるほどの形になっていることを、幸運に思うべきなのだ。とくに、一部のプロプライエタリなドライバーに比してみれば。

我々は現在、MesaのソフトウェアレンダラーであるLLVMpipeも使っているが、今のところ、修正されていないバグは発見できていない(我々が見つけた唯一のバグは、正しくないAVX検出によるクラッシュだが、発見する二週間前にはすでに修正されていた)

グッド - Intel HD Graphics on Windows

Intelの統合グラフィックチップセットはDolphin用にはあまりふさわしくない。エミュレーターにおけるGPU使用は極端に減らすこともできるが、最低限の設定でも、まだIntel IGPでは動作が遅すぎる。だが、IntelのIGPのWindows用のドライバーで、Dolphinに影響するようなOpenGL実装のバグはみつかっていない。残念ながら、サポートされている機能はとても少ない。我々のフォーラムでささっと調べたところによると、Intel HD3000 IGPが、DolphinユーザーのIGPとしては最も多いのだが、WindowsではOpenGL 3.1とShader Model 4.1しかサポートしていない(最新版のOS XではOpenGL 3.3がサポートされている)

IntelのOpenGLドライバーで変なのは、Intel Ironlake IGPだ。このIGPはOpenGL 3に必要なものをすべて備えている、ただしMSAAは除く。このたったひとつの機能が欠けているために、IntelはIronlakeではOpenGL 3機能を一切実装しておらず、我々はこのIGPをサポートできないでいる。

また、IGP製造者達がUnified Memory関連のOpenGL拡張をもっとプッシュしないのが残念だ。彼らこそ最も恩恵を受けるはずなのに。Intelは現在のところ、INTEL_map_texture拡張のみを提供している。これはtexture mappingには便利だが、buffers mappingのサポートはない。AMDはこの点に関して、コンソールで相当の経験があるので、いずれPCにもOpenGL拡張といった形で持ち込むだろう。GameCubeとWiiはUnified Memoryアーキテクチャなので、PCでも同じ事をできるという事は便利だし、Intel IGPでDolphinが使えるようになるかもしれないのだ。

よろしくない = AMD

我々が出くわした問題の多くは、AMDのプロプライエタリなLinux用のグラフィックドライバー、fglrx/Catalystを使った際に出くわしたものだ。Windowsでは起こらない問題が、Linuxではよく起こる。時として、非常に分かりやすい結果としてエミュレーターに現れる。

AMDのドライバーで頻出する問題は、アプリケーションがドライバーにmipmapを作成させたときのテクスチャーの破損だ。これが、とても単純なテクスチャーを貼りつけたWiiでの立方体のデモを、Dolphinで実行した結果だ。

[画像は原文を参照]

これはGL_UNSIGNED_SHORT_5_6_5テクスチャーを作成して、glGenerateMipmapを実行しただけで発生する。このバグへの文句は、二年以上前に言っている。AMDの開発者フォーラムでスレッドを立てたが、無視され、一年後にAMDが新しい開発者フォーラムのシステムに移行したときに、削除された。今日に到るまで、我々はこのバグが修正されたかどうか知らない。Dolphinのmipmapのエミュレート方法を変えたために、この問題は我々の問題ではなくなったのだが。

ユーザーランドのAMDドライバーのコード品質は、外から観察するに、とても悲惨だ。AMDのドライバーを使うプログラムをvalgrindにかけると、valgrindは大量のエラーを吐き出す(iotclが未初期化の構造体に対して使われているとか、未初期化のメモリへのアクセスとか)。いくつかのエラーでは、エラーを呼び出し側に伝えず、AMDのドライバー内で単にexit(123)を呼び出し、アプリケーションごと殺してしまう。この問題はSDL 1.3を悩ませた:calling XCloseDisplay caused the driver to exit。SDL 2.0では、この本来起こるべきではない問題に対処するためのworkaroundが追加された。ところで、この問題は、mipmapの問題を再現する最小プログラムを書いていて発見したのだ。

だがバグはfglrxの専売特許ではない。WindowsのAMDドライバーとて、いくつかの重大なバグを抱えている。AMDは、Dolphinにはとても便利な、ある種のclient-side buffer storageをサポートしている。これはAMD_pinned_buffer拡張で提供されている。AMD_pinned_bufferをVertex BufferやUniform Bufferに使うと完璧に動くのだが、Index Bufferに使おうとすると、ランダムなポリゴンを描画し始める。この問題のため、我々はAMD_pinned_bufferをIndex Bufferに使うのをやめ、結果としてOpenGLバックエンドはAMDユーザーにはパフォーマンス劣化となっている。

いまだに、AMDにfglrxのバグを報告する方法が分からない。開発者が公式フォーラムでバグ報告に返答しているのを見たことがない。非公式のfglrxバグトラッカーがまとめられているが、AMDの開発者達はみていないようで、新たな問題を延々と積み重ね続けている。

とはいえ、AMDはDolphinの将来に役立つことをしている。グラフィックAPIにおけるUnified Memory Accessの先駆者であるし、GPUのより低級な機能をアプリケーションに提供するMantleもある。この2つの改良がやってくれば、AMDのGPUは近代的なコンソールのエミュレーション用のプラットフォームとして最適となれる素質がある。

バッド - ARM/Mali

さて、モバイルGPUドライバーについて語ろうか。我々、オープンソース開発者にとっては、悪夢の始まりだ。

  • バイナリブロブだけで、アーキテクチャのまともなドキュメントなど一切なし
  • GPUが本来発揮できるはず速度がありながら、ドライバーで足を引っ張っている
  • ケータイ製造者とそのOS開発者は、ハードウェアの機能について謳っているが、その機能はとっくの昔、2年前(OpenGL ES 3.0)に提供されているべきものなのだ。もし、ドライバーさえこんなにクソでなければ
  • 高度なOpenGL機能を使うアプリケーションが極めて少なく、Dolphinは実に多くのぶっ壊れたGLES3機能にぶち当たる
  • ドライバー開発者は、Mesaのようなオープンソース部門よりも、より一層QAをしていない

ARMによって作られたMali GPUは、最悪というわけではない。実際、DolphinはAndoridのMaliデバイスで正しく実行できる。長時間もドライバーバグとどこもかしこも遅いという問題を我々がworkaroundしてきた結果だが。

Maliにはバグを報告できる開発者フォーラムがある。しかし、我々のバグ報告の経験は、「ああ、それが壊れることはこちとらも知ってるよ」と返ってくるだけで、その後一切返事がない。Googleですら、ChromiumでMaliの問題をworkaroundしなければならないようだから、天下のGoogle様ですら、ARMの連中にバグを修正させたり、欠けている機能を宣伝通りに実装させたりできやしないのだろう。

これが我々がMaliドライバーでぶち当たったバグ集だ。

  • glBufferSubDataとglMapBufferRangeはGPUドライバーをストールさせ、極端に速度を低下させる。これは他のドライバーでは起こらない問題だ。この問題は、独立してGoogleでも発見されていて、workaroundされている
  • glBufferSubDataはデータのコピーを作成するが、freeするのを忘れていて、Dolphinだと数秒でout of memoryを引き起こす。この問題も、独立してGoogleで発見されていて、ドキュメント化されている
  • glClearでクリアすると、非同期であるはずなのに、あたかもドライバーがクリアの完了を待っているかのようなパフォーマンス低下を引き起こす。時として、glClearは完了まで1/60秒以上もかかり(1フレーム丸々かよ!)、完全に使ってはならない機能と化している。この問題は他のAndroid開発者達も、Ouyaのフォーラムや、StackOverflowなどで報告している。
  • Maliのシェーダーコンパイラーは定数ではないグローバルシェーダー変数をサポートしない。これはOpenGL ES 3.0標準に違反するが、まあ、こちらがわでの修正は容易だ。

glBufferSubDataの問題のため、我々はVertex streamingコードを、workaroundのため、遅い方法で書かなければならず、これには莫大な労力もかかる。幸運にも、これはMali以外の問題にも対処したことになった(読者は後述で知るであろう)

これは、ちょっとした描画ゴミとかちょっとしたパフォーマンス問題以前の問題だ。ここでは、glClearのような基本的な機能が完全に使えないときていて、なんで開発者達はこんなんでオーケーなのか全然わかんねー。

我々はLIMA projectの成り行きを見守っている。LIMAの連中はMaliドライバーブロブを解析して、このハードウェア用の独自のドライバーを開発している。一年もの開発の末、彼らはいくつかの3Dデモを動かせるドライバーを作ることに成功したのだ。この3DデモにはQuake 3 Arenaも含まれていて、すでに、公式のMaliドライバーより高いフレームレートで動作する。現在のところの問題は、シェーダーコンパイラーで、これにはMali GPUのISAの完全な理解が必要となる。我々は、彼らが来年辺りには、Maliデバイスにおける状況を改善してくれると大きく期待しているし、ARMがまともなドライバーを提供しはじめるのを、そこはかとなく期待している。

悲惨 - Qualcomm/Adreno

どこから始めればいい? まず、いいところから言おうか。QualcommとMaliは、確実にグラフィックドライバーで一部のコードを共有している。残念すぎることにそのコードはglBufferSubDataとglMapBufferRangeを取り扱っている。そうだよ。Maliでこのふたつの関数が遅くて使えねーバグ(数秒の実行時間でout of memory)は、QualcommのAdrenoデバイス用のドライバーにも健在さ! まあ、我々のMaliのためのvertex streamingの変更は、他のドライバーでも役だったってことだがな。

それだけじゃない。

  • シェーダーコンパイラーは、Uniform Buffer Objectを動的にindexingしようとすると、"internal error"を報告してきやがる。バグは認知されているが、今日に到ってもいまだに修正されていない。bug report
  • OpenGL ES 3.0のcentroid attributeのサポートがぶっ壊れている。単純に動かない。使うと、出力は真っ白な画面だ。Qualcommには三ヶ月前に報告してあり、バグであると認知されたが、いまだに修正はなし。bug report
  • Shader info log関連の関数の文字列長の扱いがめちゃくちゃで、シェーダーのコンパイル情報に対しては常に長さ0を返し、メッセージは例えば大きなバッファーを提供したとしても、1023文字で打ち切られる。デバッグが悲惨だ。特に、シェーダーコンパイラーがマクロの作成とかで無意味な警告を大量に生成するときは。Qualcommには三ヶ月前に報告したが、誰からも返事がない。bug report
  • Adrenoデバイスのデコンパイルしたcommand streamをみると、ARB_draw_elements_base_vertexは愚直にサポートできそうにみえる。実際、Adrenoデバイス用のオープンソースドライバーでは、サポートされている。この件に関して、Qualcommから6ヶ月前によこしてきた返事は、つづめて言うと、「たぶんね」
  • glBlitFramebufferをハードウェアバッファーに適用すると、出力されるバッファーは90度回転される。ありえん。なんでそうなるんだよ。ところで、他の開発者がglBlitFramebufferを呼び出す簡単なコードでAdrenoをクラッシュすることを報告している

Qualcomm rotating our framebuffer
  • Dolphinで生成された一部のシェーダーは、Adrenoのシェーダーコンパイラーをクラッシュさせる。この問題についてはデバッグ中で、理由はまだ判然としないものの、Uniform Buffer Objectサポートを無効にすると、この問題が起こらないことから、Adrenoのシェーダーコンパイラーのメモリー破損が原因ではないかとにらんでる。
  • 最近まで(V43)、Adrenoのカーネルランドのドライバーはinstruction bufferの長さに制限があり、ユーザーランドのドライバーが長すぎるinstruction streamを生成すると、アプリケーションを勝手に殺す。このため、利用者はデバイスのroot権限を取得して長さの制限を無効にしてからアプリケーションを実行しなければならない。より詳しくは、bug reportを参照。

我々は今も、Qualcomm/Adrenoでしか発生しない、ヘンテコな描画をした上にデバイスをクラッシュさせるバグを検証中である。

Qualcommの開発者フォーラムをみると、AdrenoドライバーとOpenGL ES 3.0で問題に出くわしているのは、我々だけではないとわかる。この最近のレスは、Unity 3Dアプリケーションのクラッシュに文句をつけている。別の古いレスは、vertex shaderのindexicing tableにおけるランダムな結果やout of memoryについてのものだ。

幸運にも、我々はDolphinをAndroidのQualcommデバイスに移植する際、Freedreno開発者の助けを得ることができた。LIMAのように、FreedrenoはAdrenoデバイス用のオープンソースドライバーで、オープンソーススタックの上で、XBMCのような巨大なアプリケーションを実行できるほどの状態になっている。ここでも、FreedrenoのRob Clarkは、Qualcommから一切の協力を得ていない。皆にマシなドライバーを提供するため、彼はQualcommのブロブを解析して、独自のシェーダーコンパイラーバックエンドを、Mesaインフラの上に構築しなければならないのだ。一人の人間が、ほぼ一人で開発して、Qualcommの開発部門全体より、まともな品質のドライバーを作れるのだ。だれもこの問題をきにしないがため、彼の労力は、大手のケータイ製造者 からは使われず、Andoridの中でこの非公式ドライバーを使っているものは、我々の知る限り存在しない。我々がAdrenoの問題に悩まされている時、RobはQualcommの開発部門よりも親切で、彼の支援には感謝の言葉もない。

不明 - PowerVR

PowerVRは、現在のところ、公開されているソフトウェアとハードウェアで、OpenGL ES 3.0をサポートしていないため、我々は彼らのドライバーがどのくらいよくDolphinをサポートしているのかテストすることができないでいる。PowerVRでES 3.0がサポートされた時には、詳細を知りたいものだ。

感想

我々がこの投稿を書いた理由は、モバイルGPUドライバーの究極なまでに悲惨な状態に注目を向けたかったからだ。モバイルが本気でグラフィックを多用するアプリケーションの土台となるには、これらの問題を修正しなければならないし、QualcommやARMは、まともなドライバーを開発できる能力がなく、最新版のグラフィックAPIに十分に早く対応するだけの能力もないようにみえる。NVIDIAがモバイルの世界にやってくるのは、モバイルグラフィック開発者にとって最高のことだ。DolphinはTegra 3デバイスには、ある一つの機能(24bit depth buffer - Tegura 3は16/20bit depthまで)を欠くために対応できないが、将来Tegra 4デバイスを入手したら、WindowsとLinuxにおけるNVIDIAドライバーと同じく、動くことを期待している。

AMDは最近、Linuxをもっとサポートしたいと発表し、GPU内部のドキュメントを多く公開し(少なくとも、NVIDIAに比べれば)、オープンソースドライバーにも多く貢献している(Gallium3Dの最大の貢献者)。しかし、今のところ、LinuxではNVIDIAドライバーが純然たる優位だ。AMDの新しいグラフィックAPIだとかいうMantleがやってくるまで待つことはできない。現在、我々はユーザーにAMD CPUやAPUを推奨していない。なぜならば、その悲惨なシングルコアのパフォーマンス(PCSX2のベンチマークを参照)からだ。Unified memory Accessのサポートを持ってくれば、Dolphinのパフォーマンスは大幅に上がり、頂点のコピーとストリーミングに費やす多くの時間を低減できるだろう。

ARMとQualcommのGPUは、ハードウェアの性能はともかく、ソフトウェアであるドライバーがお粗末過ぎる。そのお粗末なことは、基本的に一人の人間によって解析して開発した非公式な自由ドライバーに劣るほどである。もちろん、一人の人間というのは不公平だ。LIMAといいFreedrenoといい、Mesaという20年間にわたって開発され続けてきた自由なOpenGL実装を使っているからだ。しかし、Mesaなのだから、MITライセンスなのだから、ARMやQualcommの連中は、Mesaをパクることだってできたはずだ。それをしないで、独自にMesaよりひどいクソを公式に提供している。

もちろん、Mesaのあるバージョンをforkして、独自に保守するのは難しすぎる。だから普通は、Mesaの上流に関わるべきなのだ。それをせず、Mesaもパクらず、Mesa以下のゴミを作って、公式ドライバーをして提供する。何と愚かなことか。

結局、我々はもう十分に先例があるのだ。ブラウザーは、もはや一企業が内部で開発できるようなシロモノではない。いまだに一企業の手で開発されているブラウザーは軒並みクソだ。コンパイラーは、もはや一企業が内部で開発できるようなシロモノではない。一企業の内部で開発されたコンパイラーは軒並みクソだ。グラフィックドライバーは、いつになったら過去の過ちから学ぶのか。もはや、OSやコンパイラーのような大規模なソフトウェアは、一社単独で閉鎖的に開発できるような規模ではなくなっているのだ。自社単独で開発できるということに、マーケティング上の利点すらない。しかも、実際には外注への丸投げだらけで、しかも一人の人間が解析して書いた自由ソフトウェアより劣っている。

OpenGLの実装には、C言語風の文法を持つシェーダーのコンパイラーが必要であり、これを独自に開発した結果、コンパイラーがクラッシュするお粗末なプロプライエタリ実装が山ほどある。コンパイラーは、どのような入力を渡されようと、クラッシュするべきではないというのに。

Hacker Newsでは、このことに関して議論が行われている。

Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame | Hacker News

あるコメントによると、この手のARMやQualcommのようなハード屋は、ソフトウェアの開発能力がなく、外注に外注を重ね、また、あらかじめパッケージ化されたソリューション(わざわざ貧弱なハードウェアでJAVAを動かしたりとか)を好んだりして、結局、質の悪いクソをひりだしているのだとか。

またあるコメントでは、QualcommのQAプロセスは、「我々の出荷するアプリが動くか?」であろうと推測するものまでいる。何でも、スレッドAPIを使うとデバイスをリセットしてしまうが、肝心のデバイスをリセットするはずのAPIは何もしないのだという。

デバイスリセットAPIが何もしないってのは確かなのかい。ひょっとしたらスレッドを作っているのかもしれないぞ?

id=6454871

ひょっとしたらそうかもな。だが何も返さないぞ。

我々は結局、以下の解決方法に落ち着いた。

  int i = 0; 
  while (1) {*i++ = 0;}

id=6455823

2013-09-27

実行可能ファイルかつPDFファイルかつJarファイルかつHTMLファイルとして認識されるファイル

mix

CorkaMIX(Windows用)、CorkaMInuX(GNU/Linux用)、CorkaM-OsX(Mac OS X用)は、それぞれ、Windows、GNU/Linux、Mac OS Xにおいて、実行可能ファイル、PDFファイル、Jarファイル、HTMLファイルとして認識されるファイルである。

ファイルはプラットフォーム別になっている。それぞれのプラットフォームで、実行可能ファイル(OSからネイティブコードのためのファイルフォーマットとして認識され実行できる)、PDFファイル(そのプラットフォームのPDFビューワーで表示可能なPDFファイル)、Jarファイル(ZIP内にクラスとマニフェストを含むファイル)、HTMLファイル(JavaScriptでAlertを実行)

実行可能ファイルとは、それぞれのプラットフォーム用のファイルが、OSから、x86のPE/ELF/Mach-Oと認識されるファイルだということだ。もちろん実行でき、文字列を出力する。ただし、規格準拠ではない。多くのツールでは認識されない。重要なのは、OSによって認識され、実行できるかどうかだ。

PDFとは、それぞれのプラットフォームで有名なPDFビューワー(Adobe、Evince、Mac OS Xのツール)でPDFとして認識され、実際に描画でき、文字列が表示されることを意味する。

Jarファイルとは、Javaの実装により、クラスとマニフェストのファイルを含むZIPファイルフォーマットだと認識され、実行できるということだ。Javaの実装は、それほど厳格にZIPフォーマットを検証しないので可能となる。

HTMLファイルとは、それぞれのプラットフォームでHTMLファイルとして認識され、表示した結果、JavaScriptでAlertを実行するということだ。

これらのファイルを扱う実装は、だいぶファイルフォーマットに対して、寛容で慈悲深いので、規格違反だらけでも動作する。それを利用して、ひとつのファイルで複数のファイルフォーマットとして認識されるバイナリをこしらえたそうだ。

このバイナリは完全に手で書かれている。そのソースコードはyasm(masm互換のx86用マクロアセンブラー)でアセンブルすることにより、バイナリに変換できる。

2013-09-26

どこまで行けば人間ではなくなるのか

歯医者で、5年前に根管治療をしたところを、再び掘り返して再治療している。ひどく痛む。出された痛み止めを飲んだが、なかなか効かない。痛みを紛らわすために、駄文を書くことにする。

人間と非人間の境目について考えている。

人間はすでに、様々な方法で肉体に非人間的な拡張を施している。たとえば、メガネは視力を補強し、義歯は失われた歯を補強する。また、腕時計は人間に正確な時間感覚を与えてくれる。

このような拡張を施すと、もはや人間ではなくなるのだろうか。また、たとえ人間であるとしても、以前の人格とは異なる知的存在になるのだろうか。ここまでの拡張で、人間が人間ではなくなると主張する者はいない。

では、失われた手足のかわりに義肢を装着したら、人間ではなくなるのだろうか。その義肢が生身の人間以上の性能を持ち、素手でコンクリートを粉砕し、時速40kmで走れるようになったとしても、やはりまだ人間で、もとの人間とかわりはない。ただ、機能が向上しただけだ。

心臓の脈拍を正常に保つため、心臓に定期的な電気刺激を与えるペースメーカーと呼ばれる機械を埋め込み、睡眠時に気道が塞がることを防ぐために、鼻からチューブで空気を送り込む装置を装着したら、人間ではなくなるのだろうか。まだ人間だ。

では、脳の欠損の一部を、元のニューロン結合をそっくりそのままコピーした機械で置き換えたら、それは人間だろうか。人間であることは認めるとしても、元の人格だろうか。その存在は、元の人格であると言い張り、元の人間の記憶を語り出すのだが。

ワープ装置は、SFでおなじみだ。よくある説明に、ワープ装置は、転送する物体の原子ひとつひとつを破壊スキャンして、情報として送り、再構築するのだという。さて、そのようにして再構築された人間は、記憶、人格、昔の傷跡まで、そっくりそのままだが、果たして元の人間だろうか。また、ワープ装置に入るという事は、自殺なのだろうか。

たとえ原子単位で元通りに再構築したとしても、元の原子とは違うのだから、別物だとする考えがあるかもしれない。しかし、我々の体は、原子単位では、常に変化している。人間は半年もすれば、原子単位ではすっかり別物だ。しかし、我々は、半年経過した人間も、同じ人間として扱っているではないか。

脳のニューロンの結合をスキャンして、完全にソフトウェアで動作をエミュレートしたとする。この知的存在は、エミュレーションが始まるや、興奮した様子で、こう語る。「こいつはすげぇ。本当に動いた。さっきスキャナに入ったと思ったら、もうここにいた。おいみてくれよ。おれは本当にコンピューターの中にいるぜ」と。この知的存在は、人間だろうか。ただ、我々が彼を人間だと認めないと、この知的存在は、ひどく気分を害するのだが。

我々が人間と非人間の境目が曖昧になる知的存在となる日はやってくるのだろうか。

と、この辺まで書いたところで、痛み止めが少し効いてきたので、終わる。

歯医者再び

5年前に根管治療をしたところが痛み出して、今週初めから歯医者に通っている。今回は相当痛く、常に痛み止めを使わなければ耐えられないほどだ。しかし、なぜいつもいつも、歯の痛みに気がつくのは、休日や祝日の、歯医者が休みの日なのだろう。

2013-09-24

nVidia、Nouveauに対しドキュメントの一部を公開

[Nouveau] offer to help, DCB

nVidia社員でUNIX用のプロプライエタリなドライバーの開発者であるAndy Ritgerが、NouveauのMLに、nVidiaが自社GPUのドキュメントの一部を公開したことを案内している。

興味深いというか、nVidiaのこれまでの態度からすれば大変な歩み寄りであるというか。

やあ、Nouveau開発者諸君。

NVIDIAは、NVIDIA GPUがNouveauでそのまま使えるようにするため、弊社のGPUの一部の分野におけるドキュメントを公開しようとしている。

その第一歩として、以下のドキュメントを投下した。

ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html

これは、VBIOSにおけるDevice Control Block("DCB")のレイアウトについてのドキュメントだ。DCBはボードの配置とボードのディスプレイコネクターについてのものだ。

このドキュメントにある情報のほとんどは、すでにNouveauコミュニティには既知のものであると思うが、理解を裏付けしたり、いくつかの対応漏らしを見つけたりできるのではないかと思う。

NVIDIAのプロプライエタリなLinux GPUドライバーの開発に携わる何人かは、nouveauをlists.freedesktop.orgからみていて、可能ならば手助けをしようとしている。

もし、優先的に欲しい箇所のドキュメントがあれば、そのようなフィードバックはNVIDIAのドキュメント化作業の優先度付けの助けとなるだろう。

NVIDIAに対し何か質問があるなら、ここで質問するか、open-gpu-doc at nvidia.comまで。具体的に何かできるかどうかは保証できないが、やれるだけのことはやるつもりだ。

Thanks,
- Andy Ritger

あのnVidiaがどういう風の吹き回しだろうか。

ValveがSteamOSを発表

SteamOS

紹介するのがはばかられるが、DRM汚染された不自由なゲームソフトウェアの流通であるSteamを行なっているValveが、SteamOSなるものを発表したようだ。

SteamOSは、現段階ではマーケティング部門が宣伝文句を書いたとみえて、詳細は分からない。単にLinuxベースとのみ書かれているが、おそらくは、またぞろ新たなGNUにLinuxカーネルを組み合わせたシステムを土台にしたディストロのひとつだろう。

Valveが独自のディストロに走るのは、分からないでもない。というより、必然的とも言える。ValveがUbuntu用に提供している不自由なゲームを流通させるためのSteamクライアントの仕組みというのは、ゲームのプログラムから必要になる主要なライブラリを、すべてバイナリで提供し、ライブラリへのパスを上書きしてゲームのプログラムを実行しているからだ。これは、ライブラリのバージョンや挙動を固定するためだ。

ValveがWindowsから離れたがっているのは、他でもない。Microsoft自身が、ソフトウェアの流通まで担おうとしているからだ。これは、Steamと直接競合する。Gabe NewellがWindowsを批判しているのは、結局このためだ。デフォルトの力は強い。OSに最初から組み込まれている機能と、あとから手動で追加しなければならない第三者の機能が競合して勝てるわけがない。Netscape NavigatorがIEに負けたのもこのためだ。デフォルトで入っている存在は強い。

宣伝文句では、素早いアップデートや進化などと書いてあるが、疑わしいものだ。というのも、進化というには、Linuxカーネルだけではなくライブラリも更新しなければならない。しかし、バイナリで配布する不自由で融通の効かないプロプライエタリなソフトウェアだからこそ、ライブラリを固定したいのだろう。ということは、ライブラリを変えることはできない。

不自由なソフトウェアのゲーム開発者というのは無責任で、いや、無責任だからこそバイナリで配布するのだが、一度発売したものは、将来のOSの変更に対応しない。そのため、OSごと保存しなければ、ソフトウェアの実行環境を保存できない。数十年もすると、OSが動くハードウェアがなくなるので、そのOSが動くハードウェアのエミュレーターまで保存しなければならなくなる。

Linuxカーネルは、ユーザースペースのプログラムの挙動を変えないという事にかなり本気なので、Linuxカーネルの中身はともかく、Linuxカーネルをアップグレードして、ライブラリが動かなくなるという事はあまりない。

ということは、Valveがまともに進化速度とゲーム互換性を両立させたかったら、歴代のライブラリのバイナリを保存してローカルに持っておき、ゲームごとにライブラリパスを指定という馬鹿げたことをしなければならない。まあ、たぶんやるだろうと思う。

その他に営業文句の中で興味深いのは、既存の不自由なWindowsや不自由なApple用の不自由なゲームを、gaikaiのようなサーバー側で実行してストリーミングでプレイできるようなサービスも提供するらしい。

ああ、これも必要悪なのか。ストールマンのいうとおり、もたらす害悪より利益のほうが勝るのか。まあ、実際、Valveの参入はGNU/Linuxのゲームのパフォーマンス向上には、それなりに寄与しているのかもしれない。グラフィックはすでにいくらか向上させたし、いまは入力レイテンシとかオーディオのパフォーマンス向上に取り組んでいるとか。いかにもゲームらしい方向だ。不自由なOSで不自由なゲームを動かすより、不自由なドライバーとライブラリに汚染されているとはいえ自由なOSで不自由なゲームを動かすほうが、いくらかマシなのだろうか。ああ、やんぬるかな。

追記:SteamOSはどのくらい受け入れられるのだろうか。ただ、これは広く一般にというわけではなく、主にPCゲーマーを対象としている。PCでまともにゲームをやるには、自作かパーツを指定してのBTOで、さらに最低限、グラフィックカードは毎年買い換えなければならないだろう。そういう層であれば、十分に簡単なインストーラーさえ用意すれば、自力でOSをインストールする程度はわけがないだろうし、また、自由にせよ不自由にせよ、グラフィックドライバーの配布方法は、GNU/Linuxの方が洗練されている(ディストロの提供元が更新できるよう自動化が進んでいる)ので、ある意味、Windowsより楽になるわけだ。

2013-09-21

クッキー・クリッカー:リセットのループ

この話は本の虫: クッキー・クリッカー物語の続編である。

本の虫: クッキー・クリッカーについて
本の虫: ババア補完計画
本の虫: クッキー・クリッカー物語
本の虫: クッキー・クリッカー:リセットの効果

クッキーで宇宙を支配した年老いたオスのエゾエは、別宇宙から現れたセールスマン、メフィストフェレスと契約して、意識だけはそのままに、昔の状態の宇宙に移動した。これは、クッキーに魅せられた知的生命のオス、エゾエの愛と勇気と感動の物語である。

2週目

エゾエが契約書に署名捺印したその刹那、世界が変わった。エゾエは周りを大勢のオス達とメス達に囲まれていたのだ。

「おい、エゾちゃん、いったい何をしようっていうんだ」
「そうだエゾエ。お前が何か重大なことを発表したいというから、こうしてお友達や親戚一同に集まってもらったんだぞ」

エゾエはこの場面を知っている。どうして忘れられようか。この場所、この時間は、まさに若いエゾエが、クッキーを焼くと宣言した歴史的な刹那なのだ。気がつけば、自分の体は、当時の若い体になっている。エゾエは大きく深呼吸して、口を開いた。

「うむ、よくぞ集まってくれたわい」

周りのオス達とメス達は、エゾエが年齢に不釣り合いにも、ジジイのように話すのに、怪訝な顔をした。そして、その怪訝な顔は、エゾエの次の発言で、さらに怪訝になった。

「己はこれからクッキーを焼こうと思う」

オヤジとオフクロは何と言うべきかわからないといった顔でお互いに顔を見合わせ、親戚一同は無言で立ち尽くしていた。友達もあっけにとられた顔をしていた。ババアは、どうしたわけか、意味有りげな顔でうなづいていた。

「クッキーって、エゾちゃん、家でも建てるのか?」と友達がたずねた。無理もない。当時、まだクッキーとは食べるものではなく、家を建てるのに使うものだったのだ。
「いや、食べるために焼くのだ」とエゾエは言った。

周囲のオス達とメス達は皆笑った。クッキーを食べるだと? 気は確かか? なにか悪いものでも拾って食べたんじゃないか? と周りは口々に呟いた。

ああ、そうだ。これだ。すべてはここから始まったのだ。当時、己はここでクッキーを作ったが、そのできがあまりにもひどく、誰も食べようとはしなかったのだ。だが、今は違う。己には知識がある。本物の知識がある。一人生に相当する知識がある。

エゾエは慣れた手つきで、小麦粉とバターとミルクとタマゴを混ぜあわせた。周囲は皆、引きつった笑顔を浮かべて、エゾエが生地をこねるのをみていた。

みろよ、「小麦粉」と「バター」と「ミルク」と「タマゴ」だぞ。どんなものができるかわかったもんじゃない。ほら、きっとあれだよ。毎晩ゴミをあさりにくるアライグマのための毒団子でも作るんだよ。そりゃあいい、あいつにはだいぶ迷惑していたからな。毎晩ゴミを撒き散らしやがって。

と、周囲は口々に罵り合った。

エゾエは出来上がったクッキー生地を小さくちぎって丸め、オーブンに入れた。周囲のオスメスは、物陰に身を隠し、爆発はすまいかとハラハラしながら、成り行きを見守った。

ほどなくして、エゾエは焼きあがったクッキーをオーブンから取り出した。60枚ほどのクッキーが焼きあがった。はてな。たしか焼いたクッキーは30枚ほどだったはず。なぜ倍近くに増えているのだろうか。まあいい。きっと記憶違いだろう。

焼きあがったクッキーを前に、両親、親戚、友達の一同は、みな不安げな様子で、お互いに顔を見合わせたまま、誰一人として手を付けるものはいない。無理もない。いくら香ばしい匂いがするからとはいえ、クッキーなのだ。いまだ、食べるものであるとは認められていないものなのだ。普通は、家を建てるのにつかうものなのだ。その中、一人の手がクッキーに伸びた。

「おやあ、だあれもたべないというのかい。じゃあ、あたしがいただこうかね」

ババアであった。

ババアは歯もない口で、クッキーをバリボリと噛み砕き、十分に咀嚼して飲み込んだ。

「おやまあ、こいつぁ、うまいじゃないのさ。おや、だれもたべないというのかい。じゃあ、あたしがみんないただこうかね」

ババアが食べたことに触発されて、皆の手がクッキーに伸びた。食べたものは口々にその美味をたたえた。成功だ。

ただちに、エゾエは近所のババア達を動員して、クッキーの生産にあたらせた。不思議なことに、ババア達の超スローモーな動きであっても、クッキーの生産速度は予想以上であった。これが、青天上のチップの効果だろうか。

カーソルは、残念ながら自由なカーネルであるUtenxがまだ書かれていないので、以前の効率は出せなかった。しかし、不思議な力で増加したクッキー生産速度のおかげで、わずか数週間で、エゾエは農場を手に入れた。この分ならば、工場や鉱山にも、時間はかからないだろう。エゾエは久しぶりに、クッキーの生地作りに精を出した。思いっきり動いても疲れない若い体というのはいいものだ。

数年後、ある大豪邸の前に、テレビカメラとリポーターが立っていた。リポーターがしゃべりはじめた。

「はい、毎度おなじみ、世界の富豪をご紹介のお時間です。レポーターは私、コランダム・ロウ。今日はここ、今では世界中で知らないものいない最年少の大富豪、クッキー王の大豪邸の前に来ています。いやーすごいですねぇ。さすがクッキー王。こんな建物は誰にも建てられませんよ」
「この家は全部クッキーでできているんですって。いやー信じられませんね。信じられないといえば、この豪邸は、以前は別の場所に建てられていたんですって。なんでも、ご近所さんとケンカをして、建物のクッキーを一枚ずつバラしてここに持ってきて、また組み直したそうですよ。いやーさすがに大クッキー持ちのやることは違いますねぇ。私もおこぼれに預かれるかな、なんちゃって」

屋敷の使用人たちが、門の前に集まってきた。どうやら、クッキー王の出迎えのようだ。

カートゥーンのように長いリムジンから、生意気そうな青年が降り立ってきた。豪邸の門の前に並んだ使用人と、すれ違いざまにハイファイブしながらこちらに向かってくる。

「イヨウ、イヨウ、イヨウっと、おいどうした」

クッキー王エゾエは、レポーターの前で手を上につきだしたまま固まっている。側にいた執事がレポーターに耳打ちした。

(ハイファイブしてください。ご主人様は、帰ってくるたびにハイファイブをご所望されるのです。うまく行かないと機嫌を損ねてしまいます)

言われて、レポーターは手をつきだし、ハイファイブをした。

「イヨウっと。よーギルバート、おめー今日もイケてねーな」と、エゾエは耳打ちした執事に向かってどなった。
「まったくでございます」と、ギルバートと呼ばれた執事は答え、深くお辞儀した。

一行は豪邸の中庭に歩いて行った。中庭には、巨大なババアの石像が建っていた。

「まことに申し訳ございません、ご主人様。お言いつけ通りおばあさまの石像はこの通り完成致しましたが、まだ目を赤く光らせ、口からシロップの噴水を出す仕掛けが完成しておりませんので、今しばらくご辛抱の程を。でもどうかご安心ください。今週の女王陛下の御幸までには、必ずや間に合うことでございましょう」と執事が申し訳なさそうに言った。
「マジカッケー、町のひとつやふたつぐらいはぶっ潰せそうだぜ」
「まったくでございます。いつもながらご主人様の発想には・・・驚かされます。わたくしめなどは、さきほどようやく驚きから立ち直ったばかりでございます。この・・・まるでレイピアのようにするどく胸を指す衝撃から」と、執事は丁重にへりくだりながら答えた。
その時、ちょうど中庭は、生身のババアが歩いてきた。ババアは自分をかたどった巨大な石像を見上げ、満足そうにうなづいて、歩き去っていった。

「まったく驚きですね。クッキー王はすでに全世界のクッキー工場とクッキー鉱山を独占しているのです。さて、そんなクッキー王の次の目標とは何でしょう?」と、レポーターがたずねた。
「次の目標? 宇宙に決まってんじゃんベイベー」と、クッキー王エゾエが答えた。

それはエゾエが98歳になったある日のことであった。突如として、虚空から一人の男が現れた。エゾエはこの男を知っている。80年前、自分を昔の状態の別宇宙に送ったセールスマン、メフィストフェレスだ。

「おお、お前さんか。久しぶりじゃな」と、エゾエは言った。
メフィストフェレスが答えた、「覚えていてくださいましたか。そうです、私です。今日はあなたをお迎えにやって来ました」
「お迎え? まるで死神みたいなことを言う」とエゾエが言った。
「実際そうなんです。あなたは、今日死ぬのです」とメフィストフェレスは、今日これからエゾエの身に起こる不運な事故について語りはじめた。

若くして成クッキーとなったクッキー王エゾエは、その後、宇宙開発や錬金技術といった、すでに知っている知識をどんどんと実現していき、反物質変換装置を何百個も建設した。今はクッキーにちなんだ様々な技術を、遊びとして研究している。今日は、クッキー生地の発酵の際に発生する熱を利用して空を飛ぶ飛行機の試乗をする予定だった。飛行機は問題がないのだが、エゾエは操縦中にクッキーを食べることに熱中して、操縦を誤って墜落するのだという。

「では、クッキーを我慢すればいいのか?」とエゾエはたずねた。
「それがダメなんですよ。あなたはどうしても、今日死ぬ運命にあるのです」とメフィストフェレスが答えた。

「そこでご提案なんですがね。もう一周して見ませんか? 青天上のチップを増やしてあげますよ」

もう一周か。確かに、最近はクッキーの生産量が伸び悩んでいたことだし、悪くない。青天上のチップで生産量の底上げをできるし、また一からやり直すのも面白い。

「いいだろう。また送ってくれ給え」とエゾエは言った。

3週目

「おい、エゾちゃん、いったい何をしようっていうんだ」
「そうだエゾエ。お前が何か重大なことを発表したいというから、こうしてお友達や親戚一同に集まってもらったんだぞ」

気がつくと、エゾエは大勢のオスメスに囲まれていた。手のしわもなくなっている。再び戻ってきたのだ。そして次に言うことは、

「おお、よくぞ集まってくれた皆の衆。ワシがクッキーを焼いてやるから、存分に食べるがよい」

クッキーを食べろと言われてあっけにとられる周囲をよそに、エゾエは早速クッキー作りにとりかかる。クッキー生地をこねていると、ぽつり、ぽつりと、空から何かが降ってきた。

ババアが素早く手を伸ばして、グワシッと空から落ちてきた何かを空中でつかむ。なんと、クッキーであった。ババアは、歯もない口で、クッキーをバリボリと音を立てて食べ始めた。

なぜまだクッキーが焼きあがらない先から、クッキーが虚空に出現するのか。それは、青天上のチップと整合性を取るために、宇宙の法則が書き換わったからである。青天上のチップはクッキーの生産数にかかる係数である。しかし、一度の生産で得られるクッキーが占める空間には、限りがある。まるで魔法のようにクッキーの生産数を増加させる青天上のチップと整合性を取るために、まだクッキーが焼きあがる先から、クッキーの一度の生産が、秒単位で平均化されて、出現するようになるのだ。空から降ってくるクッキーを元手に、エゾエはまたたく間に反物質変換装置まで購入し終えた。そして、またメフィストフェレスが現れる。

30週目

「おい、エゾちゃん、いったい何をしようっていうんだ」
「そうだエゾエ。お前が何か重大なことを発表したいというから、こうしてお友達や親戚一同に集まってもらったんだぞ」

また、おなじみの光景だ。しかし、これからのエゾエのセリフは、おなじみではない。

「うむ、皆、家の中に避難するのじゃ」

皆を家の中に避難させたエゾエは、手を伸ばして、人差し指をカチッと動かす。すると見よ。天からおびただしい数のクッキーが、雨あられと降り注ぎ、庭にクッキーの山を築くではないか。呆然と家の中から外を眺める友達と親戚一同。ババアは、クッキーの山に埋もれながら、クッキーをむさぼり食っていた。

286週目

「おい、エゾちゃん、いったい何をしようっていうんだ」
「そうだエゾエ。お前が何か重大なことを発表したいというから、こうしてお友達や親戚一同に集まってもらったんだぞ」

また、おなじみの光景だ。エゾエは、悲しそうな顔をしながら、語り始める。

「みんな、今までありがとう。どうか僕のことを忘れないで欲しい。僕は世界を破壊するつもりはなかったんだ。それだけは、どうか信じてほしい」

ひとしきり語り終えたエゾエは、壁に面積が正しい図法で描かれた世界地図を貼り付け、ダーツを投げる。そして、ダーツが刺さった最初の陸地まで移動する。色々と考えた結果、これが一番公平な方法だと思うからだ。

ダーツの場所に着いたエゾエは、高らかと手を天にかざし、指をカチッと動かす。たちまち周囲が真っ暗になる。空中にあまりにも大量のクッキーが出現して、太陽の光を遮っているのだ。クッキーは半径数百kmにわたってうずたかくつもり、周囲の文明を完全に破壊する。移動について来たババアが、さっそくクッキーの消費にとりかかる以外は、半径数百kmに、エゾエ以外の目に見える動植物は生き残っていないのだ。

これから、エゾエは、このクッキーを使ってロケットを開発し、その後一生を、別の無人の惑星で指を動かしながら過ごすことになるのだ。

このエゾエの行動は、エゾエの住む惑星の各国から批難を受ける。なぜ事前に警告しないのだ。クッキー爆撃が起こると知りつつ指をカチッと動かすのは人道上の罪である。テロリストだ云々。エゾエはもうすでに何週も、事前の警告をしてきた。しかし、名もない一個の子供の発する警告を、世界が真に受けるわけがない。ましてや、その警告というのが、「自分が指を特定の方法で動かすと半径数百kmがクッキーに覆われるので、避難しろ」というのでは。そのため、今ではエゾエは、わざわざ誰にも本気にされない警告を出すのをやめて、ダーツの刺さった場所でロケット開発に必要な最初のクッキーを生成するようになったのだ。

このエゾエの行動に対し、軍事行動を起こす国家も出てくる。しかし、そのような軍隊と国家はすべて、エゾエの指の一振りで、分厚いクッキー地層の下に埋もれて滅亡していった。ああ、なぜ人は争いをしたがるのか。エゾエは、ただ一刻も早くこの惑星を脱出して、生涯を無人の惑星で、迷惑をかけずにクッキーを生産したいだけなのに。ああ、何故、世界を支配する力が、こんなにも無欲なエゾエに宿ったのか。エゾエには惑星を支配するという野望はない。ただ、クッキーを焼いていたいだけなのだ。

エゾエの肉体の寿命が尽きる寸前に、必ず、メフィストフェレスはやってくる。そして、エゾエにまた次の周回プレイを進めるのであった。

「もう、十分なんじゃないだろうか。己は、もう十分に生きたと思うのだ」と、エゾエは力なくつぶやく。
「いえいえ、そんなことはありません。まだまだクッキーは焼けます。さあ、今なら青天上のチップをさらにおまけして差し上げますよ」
「分かった」
エゾエは再びリセットを行う。

たちまち、あたりが一変する。何もない緑色の背景色の空間にいる。浮かんでいるのか、立っているのか、落ちているのか、よくわからない。あたりに、何やら文字が浮かび上がり始める。

アポカリプスキターwwww、黙示キターwwww
アポカリプスキタ━━━━(゚∀゚)━━━━!!!!
見ろよ、あの絶望的な顔wwww
コ・ロ・セ! コ・ロ・セ!

これは一体、何が起こっているというのか。そこにメフィストフェレスが現れ、この宇宙のおぞましい仕組みを暴露するのであった。

この宇宙は、もともと五流大学の学生、メフィストフェレスが、卒論をでっち上げるために作り出したシミュレーション上の宇宙であるが、その生成された奇抜な宇宙の法則と、その宇宙でひたすらクッキーを焼き続ける主人公の存在が面白く。しばらくイテレーションを続けていたそうだ。そのうち、この宇宙をリアルタイムでストリーミング再生することを思いついた。さらに、コメントをリアルタイムで動的に流す仕組みをいれたところ、爆発的な人気を引き起こしたのだ。

シミュレーション上の知的生命マジアワレwwwwww
大草原不可避wwwwww圧倒的不可避wwwwww
お前ら草生やすのやめろよwwwwwwwwwwww刈り取りがめんどくさいだろwwwwwwwwww
さあ、さっさと殺そうず

メフィストフェレスの話は続く、「そういわけで、この周回でのあなたの活躍はここまでのようですね。でもご安心を、次のあなたは、きっともっとうまくやるでしょうから。さあ、お待ちかねの死亡ショーの始まりです。今回はどんな死に方がいいでしょうか!」

( ゚∀゚)o彡゜ギロチン! ギロチン!
↑ギロチンはもう30回ほどやっただろwww安楽死させてやれよwwww
やっぱりクッキーを喉に詰まらせるとかクッキーで圧死するとかが本望なんじゃねーのかなwwwwww
↑それはもう100回以上やって秋田つまらん
さっさと殺れよ。おれ次の回みてーんだからさ

3553週目

「おい、エゾちゃん、いったい何をしようっていうんだ」
「そうだエゾエ。お前が何か重大なことを発表したいというから、こうしてお友達や親戚一同に集まってもらったんだぞ」

また、おなじみの光景だ。一体何度目だろうか。エゾエの次のセリフも、もう何回言ってきたのだろうか。過去の記憶は靄がかかったようにぼんやりとしていて、思い出すことができないでいる。ただ、彼らは自分と親しい者たちであったとは思う。たぶん。

「サヨナラ」

エゾエは、必ずこのセリフを言う。別れを告げることは、これから起こるべきことへの、せめてもの謝罪の言葉であると思うからだ。

エゾエは指をカチッと動かす。たちまち、宇宙に莫大な質量のクッキーが現れ、自重によって内側に落ち込み、ブラックホールと化す。エゾエはその様子を、宇宙空間に漂いながら眺めていた。指をカチカチ動かしながら眺めていた。イベント・ホライズンのギリギリの縁で、ババアが中心に向けて落ち込むクッキーをむさぼり食っている。指をカチカチ。そして、いずれメフィストフェレスが現れる。

「さあ、契約を。さあ、次の周回プレイを。さあ、さあ」
「ああ」

たちまち、あたりが一変する。何やら工場らしき場所だ。下には溶けた金属が鈍い光を放っている。メフィストフェレスによってこの宇宙の真理が告げられる、そして、

「さあ、今回もやって来ました。お約束の名場面、エゾエを殺しまSHOWのお時間です」
「さて、エゾエさんにはですね、サムズアップして、『アスタ・ラ・ビスタ ベイビー』とつぶやきつつ、溶鉱炉に沈んでもらいましょう」

空間に文字が流れる。

ビシッ m9(`・ω・´) アスタ・ラ・ビスタ ベイビー!
ビシッ m9(`・ω・´) サヨナラ ベイビー!
地獄で会おうぜ、ベイビー(@益@ .:;)ノシ
さっさと失せろ、ベイビー(@益@ .:;)ノシ
また会う日もあるかもだぜ? ベイビーを?
なっちは(・∀・)カエレ!!

エゾエは言葉を失う。メフィストフェレスがたたみかける。

「いやー、もう千回以上お約束でして、変えたくても変えられないんですよ。あなたが悪いんですよ。毎回毎回、サヨナラなんていうから」
「あんまりにもお約束になっちゃって、この瞬間に、みんなが決まってコメントするので、サーバー落ちるかもとヒヤヒヤものですよ」

「あ、そうだ。次の周回がどうなるか、本人に見てもらうというのはどうでしょうか。さあ、3554週目の実行です」

3554週目

「おい、エゾちゃん、いったい何をしようっていうんだ」
「そうだエゾエ。お前が何か重大なことを発表したいというから、こうしてお友達や親戚一同に集まってもらったんだぞ」

エゾエは答えない。何も言わない。もう別れの言葉を告げることすら面倒だ。エゾエは指をカチッと鳴らした。

3553週目のエゾエを殺しまSHOW

メフィストフェレスは言葉を失っていた。空間にも、しばらくコメントが流れなかった。やがて、コメントが流れだした。

おいおい、何やってんだよ
マジシラけるし・・・なんでいわねーんだよ
ありえねー、マジありえねー
これはやめようぜ。数回前のコピーを使おうぜ。

「はて、これは困りましたねぇ。お約束を破ってしまった。どうしましょうかねぇ」

エゾエにはどうでもいいことだった。己より高い存在のものが、この宇宙全体を見世物にしている。彼らの気まぐれで、宇宙が実行されているというのか。

エゾエは、表示されている次の周回の自分の映像を眺めた。3554週目のエゾエは、無表情で指をカチカチ動かしながら宇宙空間を漂っている。そして、何気なしに指で円を描き、ポータルを出現させた。ポータル、時空を超えて別宇宙をつなぐ穴。まてよ。

続く

2013-09-20

興味深い記事

Edward C++Hands |   Bartosz Milewski's Programming Cafe

C++は並列プログラミングに根本的に向いていない。Haskellはすばらしいとする記事。非常に興味深い。

Haskellも学んでみたいのだが、どうしてもHaskellではサンプルコード以上の何かを書くのが難しいと感じてしまう。その制限があるからこそ、利点もあるのだろうが。

もし自然がC++ほど下位互換性に熱心だったら、人間はまだ、尾、エラ、ヒレ、触角、外骨格を持っていたはずである。

OSによる仮想化とは何だったのか

最近の動向でわからないことがある。最近、クラウド(笑)とか称するマーケティング用語はともかく、クラウド(笑)のサーバー群の実装に、ハードウェアの仮想化技術がふんだんに使われていることだ。

完全にソフトウェアでハードウェアを実装するエミュレーターと違い、この手の仮想化技術は、ハードウェアに仮想化をサポートするための機能があり、それを使って、大きなオーバーヘッドが生じない仮想化を実現させている。

そのハードウェア仮想化の上で、ユーザーごとにゲストOSを実行している。つまり、これはOS外の仮想化である。

OSとは何だったのか。

我々は何十年も、OS内で仮想化を実装してきた。ひとつのコンピューターを複数人が使うという状況で、ユーザーとかアカウントという単位で仮想化を実現してきた。また、ファイルアクセスに権限を設け、ユーザーごとに柔軟に設定できるようにもした。プログラムはプロセスという単位で、他のプログラムとは隔離された。プロセスも仮想化技術の一つである。

それだけではない。何でもできる管理者とそうではない一般ユーザーという大雑把過ぎる権限を見直し、もっと細かい単位で権限を設定できるようにした。例えば、あるユーザーの動かすあるプログラムは、システムクロックを変更できる必要がある。しかし、カーネルに任意のコードを読み込ませて実行する必要はない。そのため、必要な権限だけ許可しておいて、もし、プログラムが誤作動を起こしたり、脆弱性により悪意ある者によって、そのプログラムを経由して任意のコードを実行されてしまったとしても、権限がないために、システムに深刻な影響を与える操作を防ぐことができる。これは、ユーザー単位やファイル単位やプロセス単位など、様々な仮想化単位で設定できる。

また、chrootとかjailといった仕組みは、ファイルシステム単位で、プロセスがアクセスできる範囲を制限できる。

LinuxカーネルにおけるSELinuxとかAppArmorなども、様々な仮想化単位で、権限を制限するためにある。

これらの、OS内での仮想化技術が、もう何十年も研究、実装されていながら、なぜ、ハードウェアといったOS外の仮想化技術を使うのか。ユーザーごとにゲストOSを実行するというのではなく、ユーザーごとにOS内のユーザーを作るというのではなぜだめなのか。ハードウェアに対する操作や、ファイルシステムに対する操作などは、様々な権限管理により、細かく設定できるはずだ。OS内の仮想化技術は、OS外の仮想化技術よりオーバーヘッドが少ないはずだ。

しかし、今やハードウェアの仮想化はすっかり市民権を得て、むしろOS側でハードウェア仮想化を効率的にする対応までしている始末。

一体、OSによるOS内の仮想化とは何だったのか。

思うに、この手のOS内の仮想化技術は、正しく設定するのが煩雑なのだろう。結局、OSまで含めて丸ごと仮想化してしまうのが楽なのだろう。

そんなことを、以下を読んでいて思った。

Rethinking the guest operating system [LWN.net]

ハードウェア仮想化によるゲストOSが一般的になってるけど、OSって重複多いよね。メモリ管理とかスレッド管理とかハードウェアアクセス管理とか。そういうのはホストOSに丸投げする軽いOSってのはどうかな。というものだ。

そして、現在のハードウェア仮想化によるゲストOSの流行を見ていると、なぜマイクロカーネルは流行らなかったのかという疑問にも悩まされる。マイクロカーネルはオーバーヘッドがあると言われ続けてきたが、今のハードウェア仮想化の上でのゲストOS実行の流行と比べたら、別にオーバーヘッドがあっても問題なかったのではないかとも思う。

追記:私はセキュリティや仮想化技術には詳しくない。なぜ技術fooや技術barを挙げないのかなどというコメントもあるが、単によく知らないだけだ。

クッキー・クリッカー:リセットの効果

この記事では、クッキー・クリッカーのリセットについて解説する。過去作は以下を参照。

本の虫: クッキー・クリッカーについて
本の虫: ババア補完計画
本の虫: クッキー・クリッカー物語

クッキー・クリッカーのメニューから、ソフトリセットを行うと、手持ちのクッキーや設備やアップグレードをすべて失う代わりに、青天上のチップが手に入る。

青天上のチップ(Heavenly Chip)

青天上のチップは、この宇宙をリセットする勇気を出した者に送られる周回アイテムである。青天上のチップひとつが、CpSを2%底上げする。得られる青天上のチップの数は、すべての周回を含めた、これまでに生産したクッキー総量に応じて決定される。チップの数はリセットのたびに加算されるわけではなく、再計算される。その計算式は、以下のようなJavaScriptの式を評価した結果の値になる。

// cookiesは、周回も含めて今までに得たクッキーの総数
Math.max(0,Math.floor((-1+Math.pow(1+8*cookies/1000000000000,0.5))/2));

クッキーの総数は、今までの周回分も含めた全体の総数であり、また、クッキー枚数が多くなるに連れて、次に得られるまでのチップにかかるクッキー枚数が増えていくので、チップは次第に得難くなっていく。

インフレの抑制技術

ゲームはプレイヤーを楽しませるため、状況が改善していることを実感させなければならない。そのための方法が「価値の蓄積」だ。ただし、価値の蓄積が予測可能で単純になると、プレイヤーは飽きてしまう。これを「価値のインフレ」と呼ぶ。たとえばレベルという価値がある。レベルを上げれば強くなる。強くなれば状況は改善する。しかし、そのままでは、同じ事の繰り返しでゲームがつまらなくなってしまう。これをインフレと呼ぶ。インフレによりゲームが飽きられることを防ぐため、さらに強い敵を出す。これを何度も繰り返す。これが価値の蓄積だ。この一連の流れの途中で、飽きてしまわないよう、手作業による調整も必要になる。もちろん、永遠には続かない。いずれ、プレイヤーは飽きてしまう。そのため、多くのゲームには、エンディングを設けている。エンディングは、ゲームを辞めて、別のゲームをプレイする口実となる。それ以上ゲームをしても、あまり意味はない。せいぜい、お手軽な、よりレベル上げを必要とする、ラスボスよりも強い敵が用意されてあるぐらいだ。

ドラクエやFFといったゲームは、そのように作られている。

このようなゲームは、プレイヤーを満足させ、満足させたまま速やかに飽きさせ、満足によりブランドを構築し、いずれ発売される続編のゲームでも遊んでもらえるようになるという点で、実に都合がいい。

明確なエンディングを設けず、どんどん強くさせる方法もある。例えば、攻撃力の値の算出に、レベルの値を使うのだ。攻撃力の値はレベル対して線形に、あるいは指数関数的に増えていく。これは汎用的に計算を行うこともできるし、あらかじめ設計した値を使うこともできる。とにかく、この仕組みを使えば、レベルを際限なく上げることもできる。もちろん、資源は有限であるから、上限はある。しかし、うまく設計すれば、人間が一生かかっても到達できないほどの上限にすることもできる。

DiabloやBorderlandsといったゲームは、そのように作られている。

他にも、インフレを食い止める技術もある。たとえば、アイテムの錬金とか合成などと呼ばれている仕組みだ。複数のアイテムを使い、より価値のあるアイテムを作り出す。これにより、インフレのもととなる積み上がったゲーム内の価値を消すことができる。錬金や合成に現実の時間がかかったり、また、確率によって失敗し、しかも元のアイテムを失うような仕組みも、インフレ抑制のための技術だ。プレイヤーは、より高い価値を創りだそうとするが、それには時間がかかったり、確率によって価値が下がったりするので。インフレを引き伸ばすことができる。

錬金をうまく実装しているのはDiablo 2だ。多くの近眼なゲーム設計者は、錬金の本質的な意味、すなわちインフレ抑制の役割を理解せずに、表面だけパクって失敗している。

しかし、それでもいずれインフレは発生する。プレイヤーは飽きる。同じゲームで長く遊び続けることができない。では、長く遊び続けられるゲームは、一体どのように設計したらいいのか。

インフレ抑制の最終手段としてのリセット

リセットは、ゲームで避けられないインフレ問題を解決する最後の手段である。すべてを失って、再び最初からやり直す。多くの価値が積み重なるゲームでは、単に今までのセーブを放棄して、最初からやればいい。ただし、失われないものもある。知識である。いかにして効率良くクッキーを稼ぐか。序盤、中盤、終盤は、何を優先して買えばいいのか、ミルクとは何か。ゴールデンクッキーとは何か。最初は手探りで学んだこれらの知識を、周回プレイでは持ち込むことができる。効率のいいプレイができる。すでに知っているゲームを何度もやりたくなるのは、効率の最適化は、楽しいからだ。

ドラクエとかFFといった有名なブランドが飽きもせずに、新しいゲーム用制限コンピューターが発売されるたびに移植されるのは、そのためだ。すでにオリジナルのゲームをやり込んでおり、ゲーム内容を隅から隅まで知っているような人間が、効率最適化の楽しみにとりつかれたために、このようなブランドの移植を買い支える。もちろん、移植とて開発は簡単ではない。しかし、本質的には同じゲームであり、以前の知識が通用するゲームは、一定数存在する、以前のゲームをやりこんだ、効率最適化の中毒者に必ず売れる。そのため、確実な利益を求めて、移植は繰り返される。

長く遊べるゲームで、なんとかこのリセットの概念を取り入れられないだろうか。方法はある。

チェスや将棋や囲碁といったボードゲームは、その根本的な設計から、リセットによる効率最適化を楽しめるゲームである。ゲームのたびにリセットされる。ビデオゲームの中には、このようなボードゲームを参考にしつつ、さらに、RPGのような要素も追加したような、複合的なゲームもある。

ローグライクと呼ばれている一連のゲームは、チュンソフトのトルネコの大冒険(初代のみ)で更に改良され、リセットによる効率最適化の楽しみに強く依存したゲームとなっている。なるほど、トルネコの大冒険では、悪い手を差せば死んでしまう。それまでに気づきあげてきた価値がなくなってしまう。しかし、価値はプレイヤーの経験と知識に蓄積されている。これはインフレ率を緩やかにするとともに、もっと最適化してやろうという意欲がわく。もっとも、チュンソフトの一連の不思議のダンジョンシリーズや他ブランドの外伝をみて、一番うまくやっていたのは、初代のトルネコの大冒険だけだ。後の作品は、蛇の足を大量に描いてしまっている。

ゲームの中には、価値をほとんど維持したままのリセットを可能にした設計をやりとげたものもある。

例えば、クロノ・トリガーは、有名な「つよくてニューゲーム」を提供している。これは、ゲームクリア後、一部の重要アイテムを除くアイテムやステータスを持ち越して、あらたに初めからプレイできるという要素だ。序盤に苦労した敵が雑魚になるが、それ以外にも面白さを提供しているゲームならではと言える。

GearsboxのBorderlandsというゲームは、アイテムやステータスを維持したままの二週目を提供している。二週目は、最初から敵がレベルにスケールして強くなるのだ。

これが、ゲームの面白さを演出する方法として、「価値の蓄積」を使い、必然的に発生する「価値のインフレ」に対抗しようとした様々な工夫の前例だ。では、このような価値の蓄積とインフレ抑制作を、ありったけ取り入れたゲームは、設計可能だろうか。可能である。その実装がクッキー・クリッカーだ。

クッキー・クリッカーは、とても分かりやすい、「価値の蓄積」を実現している。1回クリックするごとにクッキーを1枚得る。何と分かりやすい価値の蓄積だろう。他のクソゲーが、何分間もかかる複雑な操作による敵との戦闘とか、画面上の怪しそうな箇所を虱潰しに調べる、などといった冗長すぎて時間のかかる方法で、のんびりと価値を蓄積させているのに、クッキークリッカーはものすごく分かりやすい。1クリック1クッキー。これ以上に分かりやすい価値の蓄積が考案されるのは、だいぶ後の話になるだろう。

なるほど、分かりやすい。しかし、クリックという操作はとても単調で飽きやすい。他のゲームは、確かに長時間かかる複雑な操作を要求するが、その操作が楽しいので、それほど苦にはならないのだ。単調にクリックし続けるのはいかにも苦行だ。

クッキー・クリッカーは、そのために、クリックを自動化した。クリックして得られた価値であるところのクッキーを消費することで、自動的にクッキーを入手してくれる設備を購入できる。クッキーは、時間経過とともに得ることができる。設備を購入してクッキーを稼ぎ、稼いだクッキーで上位の自動装置を買う。この仕組みで、飽きさせずに価値の蓄積を起こせる。プレイヤーが飽きなければインフレではないのだ。

しかし、クッキー・クリッカーも、いずれはインフレを起こしてしまう。設備を一通り揃え、アップグレードが完売した後は、先が予測できる単調なゲームになってしまう。まあ、ネタのようなゲームだから、一日楽しめればそれでいいのかもしれない。しかし、クッキ・クリッカーは違う。クッキー・クリッカーは、インフレ対策の最終手段、リセットをゲーム設計で取り入れているのだ。

クッキー・クリッカーのメニューからソフトリセットをすると、手持ちのクッキーや設備やアップグレードをすべて失う。しかし、得るものがある。青天上のチップだ。周回も含めてこれまでに得たクッキーの総数から計算される青天上のチップひとつあたり2%が、CpSの係数に加算される。これにより、最初からクッキーを得る速度が速くなる。それによって得たクッキーにより、クッキーの総生産数を伸ばし、さらに青天上のチップを得ることができる。

もちろん、これでも結局は、飽きが来る。それを解決する方法は次回。

参考文献:ドラクエ9の合成はなぜ間違いで、ディアブロ2の合成はなぜ正しいのか。 - 真性引き篭もり

2013-09-19

クッキー・クリッカー物語

この物語は、クッキー・クリッカーを題材としている。先に書いた、本の虫: クッキー・クリッカーについてと、本の虫: ババア補完計画の続編に当たるものだ。私の文章が思いの外人気なので、当初の予定とは変更して、本気で文章を書いてみようと思う。先に書いた二編は、この物語を理解するために必須ではないが、あらかじめ読んでおくといいだろう。

本の虫: クッキー・クリッカーについて
本の虫: ババア補完計画

私は前々から、小説が書きたかった。しかし、いい趣向が思い浮かばなかった。私は玉たる文章力を持っていると半ば信じ、あるいは己の玉たらざることを半ばおそれるがために、ただ趣向のせいにして、あまり文章力を世間に行うこともなく、また鍛えることもなかった。今では、その文章力も錆び付いている。しかし、それでも、今は書こうと思う。昔果たせなかったおぼろげな小説を、いま、再び書いて形にすることを試みよう。かつて、私は小説家になるという夢を、何人かの友人に語った。その友人は、今では四散して、連絡も途絶えている。昔あこがれた小説を書きたい衝動に、今再びかられる。そして、文章は形となった。

述而不作(のべてつくらず)と孔夫子はいう。私も夫子の顰に倣い、これまでの二作は、ただ述べるばかりで、一切作らなかった。ある者は先の二作を私の空想によるものだとするかもしれないが、作ってはいない。しかし、今作は、あえて少し作ろうと思う。

クッキー財閥の創業者である老エゾエは、新しいクッキーのアイディアについて思いを巡らしながら街を散歩している途中に、ムクイヌを見出した。やけに人懐こくエゾエに擦り寄ってくる。首輪はない。野良犬だろうか。エゾエは犬を連れ帰ることにした。犬を飼ってみるのも悪くないだろう。

エゾエは自宅兼クッキー研究所に戻った。祖父母の代から受け継いだこの家から、今や宇宙に君臨するクッキー財閥は始まったのだ。もし、あのときクッキーを焼こうとおもっていなければ・・・、「もし」は歴史において魔法のような言葉だ。もし、過去のある地点におけるある些細な選択が違っていたとしたら、将来にどのくらいの影響を与えるのだろうか。

「さあ」と、エゾエはムクイヌに言った。「さあ、入るがいい。ここが(おれ)の家だ。今日からはお前の家にもなる。外で己を楽しませてくれたかわりに、内では客人の扱いを受けるがいい。そら、そのすわり心地のいい上等のソファをくれてやる」

家の中には、ジジババとオヤジオフクロから受け継いだ様々な道具が転がっている。エゾエには、あまりよく使えない道具だ。所詮、これらの道具は他人から受け継いだものに過ぎぬ。自分で使うには、自分で使えるように努力しなければならぬ。利用せずに置く物は重荷だ。

年老いて今は死ぬのを待つばかりのエゾエは、この自宅で、ひとり孤独に暮らしている。なんというみじめな人生だ。己はクッキーによって一代で財を成した男だ。己のクッキーは今や、宇宙を独占している。他の次元、他の宇宙からも、わざわざ己のクッキーを買い付けにくる「存在」が大勢いるのだ。己は3ギガCpSを実現したのだ。己は世界一のクッキー持ちだ。それがなぜ、こんなところで朽ちなければならぬのか。

理由は明らかだ。エゾエは何事をもやる勇気がなかったのだ。それに、稼いだクッキーは、右から左に渡して、より大きなCpSを求めてきた。常に勤しむばかりで、受容する暇がなかったのだ。そうして、今このトシでここにこうしている。今はクッキーもある。しかし、クッキーがあるからとてなんだというのだ。八十に近い齢で、いまさら遊べというのか、家庭を持てというのか。受容のよろめきに身を委ねろというのか。バカげている。もう遅い。クッキーなど無意味だ。

そうだ。こういう気分の時は、好きなC++規格書を訳すに限る。どれ、原本を開けてみて、素直な感じのままに、一辺、神聖なる本文を、すきな日本語に訳してみたい。

「まずこう書いてある。©ISO 2013 — All rights reserved」
「ここでもう己はつかえる。なぜだ、なぜ言語規格が、著作権保護されなければならぬのだ。事実のみを厳格に記述したはずの規格文面に、なぜ著作権性が認められるのだ。それでは自由に使うことができぬ。自由に他人に配ることができぬ。自由に改良することもできぬ。そのような言語規格は自由な発展を阻害し、世のため知的生命のために害悪だ。邪悪だ。倫理に反する。人道上の罪だ。将来の歴史家への冒涜だ」

「ムクイヌ、己と一緒にこの部屋にいるつもりなら、うなることをよせ。吠えることをよせ。そんな邪魔するやつを、そばにおいて我慢してやることはできぬ。お前か己か、どちらかが、書斎を出て行かなくてはならん。用あらば早くしろ。でなければ帰れ」
「はてな。妙にみえるな。自然にありそうもない事だ。あれは幻か。現か。あのムクイヌは幅も広がり丈も伸びる。勢好く起き上がってくる。あれは犬の姿ではない。己はなんと云う化物を内へ連れて来たのだろう」
「もう火のような目、恐ろしい歯並をした、カバのように見える。お前のような異世界の存在には、このげんこつクッキーが好い」

エゾエは開発中の歯が折れるほど硬いげんこつクッキーの棒をにぎりしめ、異世界から出現したこの世のものならざる恐ろしげな存在に振り下ろした。存在はひらりと身をかわし、若い生意気そうな青年の姿になって現れた。

エゾエ、「ふん、これがムクイヌの正体であったか。大方、己のクッキーの評判を聞きつけて味を見ようと、別次元か別宇宙から、この世に出現した存在だろう」
メフィストフェレス、「まあ、そんなところですね、いやはや、さすがクッキー財閥の創業者は伊達じゃない」
エゾエ、「名は何と云うか」
メフィストフェレス、「私の名前などどうでもいいでしょう」
エゾエ、「いや、どうでもよくはない。たとえ形而上のものを扱うときでも、その概念を指し示す名前がなければ、論述が冗長になる。それに、定数には名前をつけるのはプログラマーとして良い習慣とされている」
メフィストフェレス、「おやまあ、私が昔世話したジジイとはだいぶ物の考え方が違いますね。ちぇ、思い出せば、あのジジイ、土壇場でドサクサにまぎれて夜逃げしやがって。あんなやり方は卑怯にもほどがある。何が永遠の女だ。聞いて呆れらぁ」
エゾエ、「用というのは愚痴を聞かせることかね」
メフィストフェレス、「いえ、愚痴を聞いてあげるのです」

メフィストフェレスと名乗る、この異世界から出現した存在が言うには、彼は別宇宙へ渡る能力を有しており、自分だけではなく、他の物体をも渡らせることができるのだという。メフィストフェレスはこの能力を使った宇宙渡りを、悩める知的存在に訪問販売しているのだという。

メフィストフェレス、「そこでですね。見たところあなたは大変悩んでいるご様子、どうです、別の宇宙に渡られては?」
エゾエ、「ふん、この宇宙で満足できんのに、別の宇宙なら満足できるとでもいうのか。言っておくがな、たとえ宇宙のすべてが俺の意のままに動く奴隷であったとしても、己は満足せぬぞ」
メフィストフェレス、「まあ、あなたにもご満足いただける宇宙はきっとありますよ。どうです、悩みをお聞かせ願えませんか?」
エゾエ、「長くなるぞ」
メフィストフェレス、「どうぞどうぞ、私にはこの宇宙の時間というものはあまり意味をなしませんので」

こうして、エゾエの半生の悩み語りが始まった。

エゾエのクッキー自伝

エゾエがクッキーを初めて焼いたのは、中学生の時分であった。当時、中学生のエゾエは、クッキーを作りたいという強い衝動にかられていた。そのことを周囲に打ち明けても、皆笑うばかりで、誰も食べたいと言い出すものはいなかった。無理もない話だ。当時のクッキーとは極めてマズいものであったからだ。

逆境にめげず、エゾエは始めてのクッキーを焼き上げた。そのクッキーは、誰も遠慮して手をつけようとしなかった。

メフィストフェレス、「要するに、マズかったんですね」
エゾエ、「・・・まあな」

エゾエがはじめて焼き上げたクッキーは、それゆえ、ゴミ箱に直行した。エゾエの家の周りに住んでいて、よく腐ったゴミをあさりにくるいじきたないアライグマも、このクッキーにだけは触れることすらしなかった。

エゾエは泣いた。

昔から泣き虫のあだ名あるエゾエであったが、さすがに中学生にまでなって泣くのはどうか。しかし、当時のエゾエは、それだけ悔しかったのだ。

悔しさをバネにして、エゾエは再びクッキーを焼く。そして、なんとか、身内なら一枚ぐらいは食べてくれるようなクッキーを作ることに成功した。

その後もクッキーの改良を重ねたエゾエは、ついに世紀の大発見をする。なんと、今までの材料に加えて、「小麦粉」なる材料を入れると、とても美味しいクッキーができあがるのだ。このクッキーはとても評判がよく、なんと、クッキーに当時の通貨を払う近所の者まで現れた。エゾエは近所で有名となり、中学生にしては大貨を手に入れたのだ。

エゾエには、欲しいオモチャがあった。クッキーの売上でそこそこの通貨を得たエゾエにとっては、好きなだけオモチャを買うことができた。しかし、エゾエは喉から手が出るほど欲しかったオモチャを我慢し、得た通貨を、さらなるクッキーの改良のためにつぎ込むことにしたのである。「カーソル」だ。

カーソル(Cursor)

当時、カーソルというハードウェアが注目を集めていた。このカーソルは、機械じかけの五指を備えたハンド、腕を模したアーム、そして、ハンドとアームを支える6本足の移動土台から構成されていた。ハンドは、たしか16個か17個ほどのサーボモーターで、指や手のひらを動かせるようになっていた。アームも油圧で稼働する。移動土台の6本足は、左右一本づつまでなら故障しても移動できる冗長性を備えていた。

さらに画期的なことに、カーソルはプリンターで印刷可能だったのだ。当時、一般的なプリンターといえば、まだ二次元プリンターであった。三次元プリンターも市販されていたが、まだまだ品質が低く、オモチャのようなものとみなされていた。カーソルは、当時の貧弱な三次元プリンターで印刷できるように設計されていたのだ。それだけではない。カーソルは全設計が自由に公開されていた。ハードウェアの設計からソフトウェアのソースコード(レシピとも呼ぶ)、コンパイラーに到るまで、すべてが自由な設計だったのだ。これは、カーソルを自由にプログラムし、また改良できることを意味していた。エゾエは通貨を三次元プリンターにつぎ込み、安価なカーソルを量産した。

この時点でエゾエは、クッキーの味についてはだいぶ改善していた。数年の研究により、従来の材料に、小麦粉だけでなく、「バター」なる材料も一緒に入れると、より一層美味しいクッキーが出来上がることを発明していた。また、理論上は、タマゴやミルクと呼ばれている液体を混ぜれば味が引き立つはずであったが、まだ研究中であり、実証実験は済ませていなかった。

問題は、クッキーの生産である。なるほど、小麦粉とバターを使うと、たしかにクッキーの味は引き立つ。しかし、これはエゾエが手動で小麦粉とバターを混ぜあわせ、こね上げ、クッキー生地として寝かせなければならないことを意味していた。これはクッキー生産の時間効率を著しく下げ、またエゾエを腱鞘炎にかからせた。ところで、エゾエはプログラマーであった。そこで、このカーソルをハックして、自動でクッキーの生産ができるように改良しようと思い立ったのだ。

多くの印刷ミスとコンパイルエラーに悩まされた後、とうとう、カーソルは自動でクッキーを焼けるようになった。問題は、そのCpS(Cookie per Second、クッキー毎秒)は、とてもおそかったのだ。

無理もない話だ。カーソルは、当時の貧弱な三次元プリンターで印刷して動作するよう、とても冗長性の高い設計をしていた。また、自由なハードウェアの常として、開発資金が十分ではなく、ほぼ素人集団によって設計されていたのも問題だった。カーソルは、あらゆる点で貧弱だったのだ。

そのため、エゾエは依然として手動でクッキーを焼き続けた。

クッキーを生産するうちに、いつしか月日は流れ、エゾエも一個の青年になっていた。この惑星では、青年のオスは、弱い接着剤をつかって髪を逆立て、精神に失調をきたす色彩(サイケデリック)の服を来て、無意味に座高の低い車に乗り、あるいは歌い、また踊り、若いメスに求愛活動(求活(きゅうかつ))を行うのが常であった。求活の結果、見事に若いメスをゲットした青年のオスは、「現実が充実している」と呼ばれた。

エゾエは数年に及ぶクッキー研究と生産のおかげで、一財産を築いていた。エゾエのクッキーが美味であるという噂は遠く広がり、街中に聞こえ、エゾエの家の庭はクッキーをせがむ子供であふれていた。

もっとも、エゾエの財産というのは、クッキーであった。この頃になると、エゾエのクッキーといえば、相応の値段で売れたのだが、エゾエはどうしたわけか、クッキーをクッキーとして貯蓄していた。この頃は、まだ誰も、クッキーにそれほどの価値を見出しておらず、別の通貨が使われていた。そのため、エゾエにはサイケデリックな服や無意味に座高の低い車で求愛活動を行う貨幣的余裕はなかったし、また歌や踊りも下手だったので、最初から求活には期待していなかった。エゾエは髪を剃り落とし、単色無地のエプロンを着て、クッキー生産に精を出した。

ところで、さすがにこの頃になると、エゾエは手動によるクッキー生産に限界を感じていた。しかし、カーソルは遅すぎる。できれば労働者を雇いたい。しかし、前述の通り、エゾエの財産は、当時まだ貨幣価値を認められていないクッキーしかなかった。そこでエゾエは、ババアを雇った。

ババア(Grandma)

ババアは、カーソルを除いては、最も購入コストの低いクッキー生産装置であった。ババアは対価の支払いに、当時の通貨ではなく、クッキーを受け取ることに同意したのだ。問題は、ババアのCpSは、とてつもなく低かったのである。

まあ、所詮はババアなのだ。何をか期待せんや。ババアのCpSは、カーソルよりはいくらかマシという程度で、手動のクッキー生産から比べれば、微々たるものであった。ババアの購入は、それなりの利点もあった。ババアは、麺棒という技術を有しており、なんとこれは、クッキー生地を素手でこねなくてもよくなるのだ。残念ながら、エゾエにはこの麺棒技術は使えなかった。ババアが麺棒を使えば、CpSは多少上がるのだが、やはり元が元なだけに、微々たるものでしかなかった。すっかり失望したエゾエは、手動によるクッキー生産を継続した。

メフィストフェレス、「その・・・、ババア、というのは、あなたの生物学上の祖母・・・ああ、つまりこの宇宙の言葉で言えば、あなたを生産したオフクロを生産したオフクロ、ということでいいのですか」
エゾエ、「ああ、最初のババアはそうだな。後のババアは、どっかのババアだが」
メフィストフェレス、「へぇ、変わってますねぇ。私のところの宇宙では、この手のものは、たいてい美少女なのですが」
エゾエ、「美少女、というのは、若い魅力的なメスのことかね」
メフィストフェレス、「ええ、この宇宙の言葉でいえば、だいたいそうなるでしょうね。あ、どうぞ話を続けて」

農場(Farm)

ババアに失望したエゾエは、次に農場に目をつけた。もちろん、クッキーは栽培可能であり、農場で収穫できる。

メフィストフェレス、「ちょっと待ってください。いま農場と言いましたか? クッキーを栽培? 植物のように?」
エゾエ、「君のところの宇宙ではできないのかね?」
メフィストフェレス、「あたりま・・・いや、現にこの宇宙がこうして存在している以上・・・、まあ、理論的には、まあ、その、できるんでしょうね、ええ、たぶん」

苦労の末、クッキーを支払って買い取った農地にクッキーを植え、品種改良の末、より多く、より簡単に収穫できるクッキーを発明した。農場は、ゆっくりではあるが、確実にクッキーを生産していった。

また、今では当然となっている主流のクッキーである、チョコチップクッキーに欠かせないチョコチップを発明したのも、この時期である。エゾエの発明した新しいチョコチップクッキーは、またたく間に評判となった。

工場(Factory)

農場で稼いだクッキーを元手に、エゾエはクッキーを生産する工場を建設した。工場の建設と、工場で働く労働者の対価には、クッキーを支払った。これには、当初、労働者側の強い反発があった。しかし、クッキーの価値が認識されていくに従い、反発は次第になくなっていった。

工場は、手動のクッキー生産に勝る、素早く、品質の整った、確実なクッキーの生産を可能にした。こうなると、もはやクッキー自体に価値が見出されるようになった。従来の通貨にかわって、クッキーが通貨として流通するようになったのだ。

文字通り、通貨を生産する工場を所有するエゾエは、大クッキー持ちになった。もうエゾエは青年の歳を超えつつあったが、求愛活動に髪や服を整える必要すらなかった。その気になれば、10歳は歳が離れた若い複数のメスをはべらすことだってできたのだ。しかし、それには少なからぬクッキーを浪費してしまう。エゾエは現状に飽きたらなかった。足りない。まだ圧倒的に足りない。生産したクッキーは、さらなる設備通しに回さなければならない。メスは後回しだ。

鉱山(Mine)

工場におけるクッキー生産で、もっとも時間がかかるのは、クッキーを焼くことではない。クッキー生地とチョコチップの準備である。クッキー生地は、よくこねて、しばらく寝かさなければならない。チョコチップは、とても細かく製造が面倒だ。

この問題の解決が、我々の足元に埋まっているのだ。ご存知の通り、クッキー生地鉱脈と、チョコチップ鉱脈、今すぐ焼ける状態で地中に埋まっている。これを掘り出せば、準備時間はかからない。

メフィストフェレス、「ちょ、ちょっとまってください。クッキー生地鉱脈? それは食べられる状態のクッキー生地が埋まっているのですか?」
エゾエ、「もちろんそうだが。君の宇宙だってクッキー生地鉱脈のひとつやふたつぐらいはあるだろう?」
メフィストフェレス、「一体どうやって?」
エゾエ、「クッキー生地鉱脈の発生理由については、まだこれといった証明された定理はない」
エゾエ、「科学者の間で主流の仮説としては、数億年前に、小麦粉とバターが一緒に地中に埋まり、地震などの作用によりこねられ、密閉されているために腐らず、現在まで保存されたものとされている。またチョコチップは・・・」
メフィストフェレス、「そんなアホな・・・」
エゾエ、「もちろん仮説だ。しかし、ちゃんと綿密に考慮されて、査読を通った論文で提唱されている仮説だよ」
メフィストフェレス、「ありえない」
エゾエ、「まさか君は、宗教団体の主張する、何か知的な存在があらかじめ地中にクッキー生地を埋めておいたという、実証なく反証も不可能な伝説を信じているのではあるまいな」
メフィストフェレス、「私はむしろそっちを信じますね。なにしろ・・・いや、よそう。どうせ言っても無駄だ」
エゾエ、「我がクッキー財閥は、たまたま運良くタマゴやミルクも一緒に埋まった良質な鉱脈を多数所有しているのだよ」

輸送(Shipment)

エゾエのクッキーへの飽くなき挑戦は止まるところを知らなかった。ご存知の通り、天文学者はもう百年は前から、主要な構成物がクッキーやチョコレートの惑星をいくつも発見していた。

メフィストフェレス、「・・・」

これらの惑星は、地表がクッキーでできており、チョコレートの海がある。核はドロドロに溶けた高温のクッキー生地であると推定されている。

もし、もし、このような惑星から、クッキーやチョコレートを地球に輸送できたとしたら、莫大なクッキー生産量になる。それには、高度な惑星間航行技術と燃費と加速度のいいロケットが必要になる。

また、農場、工場、鉱山は、社会から様々な環境汚染の原因として、槍玉に挙げられていることを考えれば、宣伝上も都合がいい。

彼ら、社会の木鐸を自称する奴らは、木を見て森をみずといった本質的ではない、科学的ではない、物の見方をする。彼らはクッキーの成功を妬み、クッキーが既得利権を脅かすものであると考え、ひたすら妨害工作に走るのだ。それに、クッキーはありふれているので、身近にある一見分かりやすい環境汚染の間違った原因として、愚痴で非科学的な一般大衆が容易に信じこむ。

曰く、クッキー農場では低賃金でババアが強制労働させられている。曰く、チョコレート農場は川をチョコレートで汚染している。遺伝子改良チョコレートの存在しない危険性をやかましく叫ぶ連中もいる。中でも解せないのは、自由放牧させた農場産のクッキーは味がよく健康にもいい、効率重視の詰め込みクッキー飼育は劣るとか主張する、いわゆる健康クッキー主義や、クッキーは動物由来の素材を利用しており食べるべきではないと主張するヴィーガンと名乗る菜食主義者達。わけがわからない。

工場もそうだ。地球温暖化はクッキー工場のせいだなどと非難されている。なんでも、大気中のチョコレートの増加が温室効果とか称するものを発揮し、熱を宇宙に逃すのを妨害するのだとか。また、一時期、各地でチョコレートの雨が降ったこともある。チョコレート雨は、実際のところ、工場のせいなのだが、当時、エゾエのクッキー財閥は、多額のクッキーを費やして、もみ消しに暗躍した。労働闘争も頭が痛い。結局、今では労働者は派遣に切り替えて団結意識を希薄にし、またロボットを導入している。工場製クッキーは肥満につながるという論文が発表されたこともある。まったくバカげている。肥満は食い過ぎのせいだ。

鉱山は隠し切れないほど最悪だ。当時のクッキー生産を支えるためには、クッキー生地とチョコチップの採掘は不可欠だった。しかし、鉱山は落盤による生き埋めや、クッキー生地発酵による酸欠で、大勢の鉱夫が犠牲になった。それだけではない。採掘は地震や地盤陥没を引き起こし、生産性が悪くなり採掘を打ち切られて放置された鉱山からチョコレートが溢れて周辺地域を浸チョコしたりもした。チョコレート鉱山の地下深くから発見された、不思議なチョコレートを食べる生物は、生物学の教科書を書き換えるほどの影響があった。

これらのすべての問題が、クッキー惑星からの輸送によって解決できるのだ。エゾエのクッキー財閥は、莫大な資金を投じて研究を行った。そして、ついに我々は惑星間航行技術を手に入れ、クッキーとチョコを輸送できるようになったのだ。

輸送は莫大なクッキー生産をもたらした。クッキー惑星は次々と発見され、輸送がますます盛んになった。純度99.8%の良質なチョコレート核を持つ惑星も発見された。チョコレートから構成された有機生命体も発見された。大昔の地球外の知的生命体の痕跡であるチョコレート鉱山の発見に、世間は騒然となった。

また、暇をもてあませたクッキー長者たちによる、宇宙旅行も盛んになった。中でも有名なのは、クッキーとチョコのトレーサビリティ技術を開発する会社を起こし、後にクッキー財閥に買収されてにわかに大クッキー持ちになった、あるクッキー長者である。彼はクッキーにまかせて宇宙旅行をし、さらにカーソル上で動作するCNU/Utenxベースの自由なOSを、ババアでも使えるように改良した。

CNU/Utenxについては、解説が必要だろう。昔、オペレーティングシステムは皆不自由なプロプライエタリソフトウェアであり、利用にあたっては屈辱的な契約への同意を必要とされた。このような不自由ソフトウェアは利用者から自由を奪うものである。そこで、ある自由クッキー主義者が、Cで書かれた自由なOSを開発すると宣言した。当時、不自由なOSとしては、Utesil(ユテンソル)というものが広く使われていた。このOSは、完璧ではないにせよ、すでに広く使われているし、満足できる設計であった。そこで、チョコ言語(その頭文字をとって、C言語とも呼ぶ)をシステムプログラミング用言語として提供するUtensil互換の自由なOSを作ることにした。この自由なOSの名前は、CNUと名付けられた。その意味は、"CNU's Not Utensil"の略語であった。Cはどこからきたのかというと、おそらくクッキーか、あるいはチョコレートの頭文字から来ているのであろう。

よくOSはチョコチップクッキーに例えられる。OSを構成するソフトウェアとしては、システムプログラミング言語のコンパイラーとライブラリ、そしてカーネルがある。カーネルとはクッキー生地であり、ライブラリは生地の上に乗るチョコチップだ。コンパイラーの役目は、クッキーのレシピ(ソースコードとも呼ぶ)である生地とチョコチップを練りあげて焼き、食べられるようにすることだ。そのため、コンパイラーは時として、オーブンとも呼ばれる。自由クッキー主義者のCNUは、チョコ言語のコンパイラー(cc)と、チョコチップライブラリ(libc)を完成させた。しかし いまだに生地にあたるカーネルだけは、完成させることができなかった。

チョコレートの雪が降る寒い北国に、ある青年が住んでいた。青年というのは、どこの宇宙でも、往々にして馬鹿げたことをやるものだ。この青年は、自分でカーネルを作ってみたいというバカな夢を持っていた。青年は幼い時からカーソルを所有しており、生粋のハッカーであった。彼の母親はこう述懐する、「うちの子は手のかからない子でした。押入れの中にカーソルとクッキーと一緒に放り込んでやれば、それで満足するんです」と。青年はカーソル上で動く、Utensil互換のカーネル、Utenx(ユテンクス)を描き上げた。Utenxは、最初オモチャのようなカーソル上で動くオモチャのようなカーネルであったが、この青年がレシピを公開したため、またたく間に世界中に広がり、ハードウェア、ソフトウェアともに改良され、十分に使えるカーネルへと改良されていった。

しかし、カーネルは所詮カーネルである。チョコチップクッキーにおける生地とおなじく、カーネルはOSの一部にすぎない。クッキーの味は、その上に乗るチョコチップが決めるのと同様、カーネルにはチョコチップライブラリが必要なのだ。さらに、クッキーがオーブンで焼かれなければならないのと同様、カーネルも焼きあげるためのコンパイラーを必要としていた。

そのコンパイラー(cc)とライブラリ(libc)が、なんとすでに存在したのだ。それはCNUと呼ばれるOSであった。UtenxはCNUとともに使うことで、完全なOSとして動作するようになった。

これが、後に名前論議を呼ぶことになる。Utenxは相当に有名になり、UtenxをCNUと組み合わせたOSは、たいてい、単にUtenxと呼ばれるようになった。一体、OSを決めるのは何か。カーネルか、ライブラリか。OSとはカーネルとライブラリ、その他のツールが一体化したものであり、その一部だけでは成り立たない。すでにCNUはカーネル以外のライブラリとツールを完成させており、Utenxカーネルはその生地を提供したに過ぎないのだ。つまり、Utenxカーネルは、CNUというOSのカーネルのひとつにすぎないのであって、UtenxカーネルとCNUを組み合わせたOSを、単にUtenxと呼ぶのでは、CNUの貢献が正しく理解されない。

そのため、クッキー生地とチョコチップを組み合わせたクッキーを、チョコチップの味への貢献を示すために、「チョコチップクッキー」と呼ぶのと同様に、UtenxカーネルとCNUを組み合わせたOSは、CNU/Utenx、あるいはCNU+Utenxと呼ぶべきである。/や+の利用は、CNUとUtenxが別々のものであり、組み合わさっていることを明示するために必要な区切り文字である。Utenxというときは、単にUtenxカーネルを指すものだ。

さて、このGNU/Utenxは、安価な6本足の移動式5指ハンドアームであるカーソル上で、実に快適に動作した。また、レシピが公開されているために、誰でも改良することができた。このため、最初はオモチャであり、プロプライエタリな商用Utensilとプロプライエタリなアーキテクチャのハードウェアにまともに対抗できるOSではないと考えられていたCNU/Utenxとカーソルは、またたく間に改良されていき、今では商用Utenxとプロプライエタリなアーキテクチャのハードウェアを市場からほとんど消すまでに成長した

これは、エゾエが早くから目をつけていたカーソルの機能を大幅に向上させ、カーソルは農場、工場、鉱山、ロケットの操作など、あらゆる場所で活躍し、そのクッキー生産性を大いに上げた。また、これは不釣り合いな対価を要求する労働者の削減にも貢献した。カーソルは一躍有名になり、海外ではカーソルが活躍するコメディドラマまで作られた。ただし、商標の問題から、カーソルではなく、スキャッター(Skutter)という名前になり、また指も3本に減らされ(それでも挑発的なハンドジェスチャーをするのには十分である)、移動もホバークラフトとして描かれている。まあ、所詮はフィクションだ。

さて、この時点で、もはやこの地球にはエゾエに匹敵するクッキーを所有するものはいなかった。他の惑星からもたらされるクッキーは、地球環境への影響を一切考慮せずに生産できるので、エゾエは無尽蔵とも思えるようなクッキーを手に入れた。

この大量のクッキーを使えば、例えば適当な居住可能な惑星をひとつふたつ買い取って、そこに住むすべての知的生命体(大勢の若いメスを含む)を、彼のドレイとして意のままにこき使うことが可能だったろう。

しかし、エゾエは、稼いだクッキーはすべて、さらなるクッキー生産効率向上のための技術投資に回した。足りないのだ。まだ全然足りないのだ。圧倒的に足りないのだ。クッキーをもっと焼かねばならぬのだ。焼いて焼いて焼きまくらねばならぬのだ。

錬金研究所(Alchemy Lab)

想像して欲しい。金のような無価値でありふれた物質を、クッキーのような高価値、高栄養価の物質に変えることができたとしたら。金を練って他の有益な物質に変える。そんな魔法のような技術は、昔から呪術的に扱われ、ファンタジーではお決まりの魔法として使われてきた。十分に発達した科学は魔法特別がつかないと、かつてあるSF作家はいった。その魔法が今、科学の力で実現するのだ。エゾエのクッキー財閥が総力を上げて投資した、練金研究所では、金をクッキーに、

メフィストフェレス、「いやいやいやいや、ちょ、ちょ、ちょっと待ってくださいよ」
エゾエ、「どうしたのかね?」
メフィストフェレス、「何で金を他のものに変えるんですか?」
エゾエ、「何故って、金はありふれた物質だからだよ」
メフィストフェレス、「お、おう」
エゾエ、「道を歩いて気がつかなかったのかね、そのへんに転がっている石ころや砂は、全部金じゃないか」
メフィストフェレス、「そういえば・・・あああああああ、あーあーあー」

エゾエ、「たしかに、昔は金といえば、どこにでもそのままの形であって、精製の手間もいらず加工しやすかったから、装飾品にも使われていたな」
エゾエ、「またごく最近までは、その高い腐食耐性、酸化耐性、導電性のため、様々な用途はあったさ。また金の反応が発見されてからは、触媒としても一時期はやったな。それと、単純に重いから、重しとしても使われてきたかな」
エゾエ、「しかしまあ、フェムトテックのある今では、そのすべてが、より優れた特性を持った他の原子や分子に取ってかわられているよ」

メフィストフェレス、「私のとこの宇宙では、金はそれ自体に価値があり、通貨として使われているのですが」
エゾエ、「ふむ、金のようなありふれた無価値の物質を貨幣として使うとは、君の宇宙ではだいぶ信用貨幣制度が発達しているとみえるな。うらやましい限りだ」
メフィストフェレス、「いえ・・・そうではなくて・・・ああ、もうなんでもよくなってきた。続けてください」

錬金研究所は、単なるクッキー生産以外にも、クッキー史で重要な発見をいくつももたらした。例えば、銀は、錬金技術を適用すれば、ホワイトチョコレートに変えることができると判明したのだ。そう、ホワイトチョコレートは当初、錬金技術の副産物として発見され、後に、錬金技術によらない商業的に使える生産方法が確立されたのだ。また、今はやりのチョコ宝石も、錬金術の副産物として生まれた。これにより、金やダイヤモンドに唯一の残されていた利用方法も、最新のクッキーとチョコレート技術に押されて消えていった。

錬金技術を応用すれば、金から、繁殖可能な若いメスを錬成することも、理論上は可能である。その証明済みの理論を発表する論文もある。しかし、そんな無駄な錬成をしては、何よりも重要な、何よりも大切な、クッキーの生産効率が落ちてしまうではないか。理論的には面白かったものの、そんな遊びに高価な錬金施設を使う研究機関や企業はいなかった。

錬金技術は、すばらしいクッキー生産効率をもたらした。何しろ、材料が金である。そのへんの道端に、石や砂としていくらでも存在する金である。たしかに、錬金設備への初期投資こそ高くつくものの、一度クッキー生産に入ってしまえば、すぐに元が取れる。それに、環境汚染もない。そのへんの石ころや砂を消費するだけだ。まさに全知的生命体の夢の技術である。ロケットによる他の惑星からの輸送は、なるほど、環境問題こそ起こさないものの、輸送費が高くついて、クッキー生産効率の点でいえば、あまり洗練されていなかった。錬金クッキー、これこそが未来なのだ。

残念ながら、錬金技術は、当初こそすばらしいクッキー生産をもたらしたものの、長期的にははかばかしくなかった。問題は、材料が金だということだ。確かに、金はどこにでもある。しかし、どこにでもあるというそのことが問題なのだ。クッキーの錬金には大量の金を必要とする。長期的なクッキー錬金を行うと、錬金研究所付近の金をすべて採掘しつくしてしまうのだ。いや、金などどこにでもあるのだから、適当な用地買収を行えばいいと思うかもしれない。しかし、土地の購入には多額のクッキーが必要になる。その買収価格は、その土地の金の埋蔵量で生産できるクッキーを上回る。つまり、クッキー鉱脈と違い、金採掘のための用地買収は赤字になってしまうのだ。他の惑星から金を輸送するというのも、うまく行かない。なぜならば、ロケット輸送はそうとうに高く付く技術であり、輸送するものがクッキーだからこそ黒字になる事業なのだ。金のような重い物質を輸送しても、赤字になるだけだ。なぜならば、輸送した金から生産できるクッキーの量は、輸送費を下回るからだ。

たとえ技術的にすばらしいものであっても、商業的にもすばらしいとは限らない。その例が錬金技術だ。

この金の、ありふれた物質であるがための赤字問題に気がついた時、錬金技術の価値は一気に下がってしまった。皮肉なことに錬金技術の研究者達は、錬金技術のさらなる研究のため、貴重なクッキーを錬成して、無価値の金に変え、その金を使って錬金研究をするという、本末転倒なことまでしはじめた。

しかも、錬金クッキーというのは、あまり消費者受けもよくなかった。錬金により生産されたクッキーは、栽培クッキーとか工場生産クッキーとか宇宙クッキーと全く同じで、したがって技術的には、安全性をはじめとした懸念は一切ないのだが、やはり一般大衆というのは科学よりもイメージが先行するため、何やらよくわからない難しい技術で生産されたクッキーの売れ行きは悪かった。

クッキー財閥は、赤字を埋めるために錬金研究所を売却した。たまに、大量のクッキーから若いメスを錬成する変わり者がニュースになることを除けば、錬金技術は一時の流行で終わってしまった。

メフィストフェレス、「そこで、とうとうIUCですね?」
エゾエ、「IUC? なんだねそれは?」
メフィストフェレス、「え・・・IUCは宇宙間通信(Inter-Universe Communication)の略ですが」
エゾエ、「知らんな。宇宙間といえばポータルだが」
メフィストフェレス、「あ、それです。そうでしたそうでした、この宇宙の言葉ではポータルって言うんでしたね」
エゾエ、「そう、次に己が発明したのはポータルだ」

ポータル(Portal)

宇宙は一つではない。我々の住む宇宙の他にも、様々な宇宙がある。その中には、宇宙の物質がほとんどクッキーで構成されているような宇宙、すなわちクッキー宇宙(cookieverse)もあるだろう。

もし、時空を歪めて、我々の宇宙と、そのようなクッキー宇宙をつなぐこと、すなわちポータルを開くことができれば、他の宇宙から我々の宇宙にクッキーがなだれ込んでくるはずだ。これが、ポータルによるクッキー生産の概要である。ポータルを開くための技術については、やや煩雑なので略すが、とにかく、己のクッキー財閥は、とうとうポータルを開くことに成功したのだ。結果は画期的だった。我々は無尽蔵にも思えるほどのクッキーを得たのだ。

別宇宙へのポータルを開くのは、とてつもなく難しい技術である。クッキー財閥が今までに稼いだ全てのクッキーをつぎ込み、錬金研究所も売却し、最後にはわずかな資金を捻出するためにババアまで売り払って、社運をかけて、基礎研究を行い、建築したのだ。もしポータルが開けなかったら、あるいはポータルを開くのがあと数年でも遅れたら、己はとっくの昔にクビを吊っていただろうな。ポータルには人生を賭けるだけの価値があった。クッキーは全知的生命体の夢だからだ。後にも先にも、あれほど不安で眠れぬ夜を過ごしたことはない。

メフィストフェレス、「そうそう、そのIUC・・・ポータルです。是非詳しく。何でもいいので教えてください。はやく、はやく」

最初のポータルは、クッキー財閥を傾けるほどの投資を必要としたが、一度ポータルが開いてから、その驚異的なクッキー生産量によって、クッキー財団は一瞬にして財務状況を急峻なV字回復し、それどころか、かつてないほど増長し、二つ目、三つ目のポータルを開くのにも、そう時間がかからなかった。

また、ポータルを開いてから、我々のすばらしいクッキーの存在が別世界にも知れ渡ったのか、別次元、別宇宙の「存在」が、我々の宇宙に強引に「出現」し、我々のたった一枚のクッキーを彼らの世界の大量のクッキーと交換するようになった。

メフィストフェレス、「いえ、それは先生方で、クッキーなんかどうでもよくて・・・効率のいいIUCを・・・」
メフィストフェレス、「ああ、すみません、話の腰を折ってしまいまして。どうか、続けて、続けて」

我々が宇宙について理解していることは少ない。ぢゃによって、只何事も知らぬ振りをして聞いておきゃれ。この天地の外にはな、所謂哲学の思も及ばぬ大事があるわい。

例えば、こんな宇宙はどうだ。この宇宙に生き残っている知的生命体は、すべてが若い繁殖可能で魅力的なメスで、子孫を残し絶滅を免れるために、健康で繁殖可能なオスを必要としている。そのような宇宙へのポータルを開き、己独りが入ってポータルを閉じれば、まさに夢のような生活が待っていると言えよう。

メフィストフェレス、「そういう宇宙なら造作もありません。実際、このすばらしいIUCが如何にして構築されているのか解析するために、そういうデバッグ宇宙を作って待ってたんですがね」
メフィストフェレス、「なぜか一向にそういう宇宙には通信チャネルが開かれないで、クッキー宇宙なんかに・・・」
メフィストフェレス、「ああ、こっちの話、それよりどうか、続きを」

しかし、そんなことしていてはクッキーの生産性に響く。ポータルは安い建築ではない。大量のクッキーがかかる。それゆえ、ポータルの建築は、さらなるクッキーの生産のために行われなければならぬのだ。メスなど所詮、クッキーで頬を叩けば、喜んで土下座して足を舐めだすわい。繁殖はクッキーさえあればいつでもできる。今はクッキー生産のほうが大事だ。

エゾエ、「そこで、己はタイムマシンを発明したわけだ」

タイムマシン(Time Machine)

これまで、己はクッキーをより効率的に生産するために、クッキーを支払ってきた。考えてみれば、これはおかしい。クッキーを得るためにクッキーを失っているわけだ。もちろん、より効率的にクッキーが得られるので、黒字ではある。労働者に支払うクッキーは最小にするべきだが、投資にクッキーを費やさなければ、さらなるクッキー生産効率の向上はない。しかし、やはりおかしいものはおかしい。誰が何と言おうと、結果的にクッキーを失っているのは確かだ。

「もし」、の話だ。仮定の話だ。もし、今までに支払ったすべてのクッキーを支払うことがなかったとしたら。今までに食べたすべてのクッキーが、食べられることがなかったしたら、クッキーが一枚たりとも失われることなく、現代にまで存在していたとするならば、その量は膨大になる。ポータルよりも多くのクッキーを得られるだろう。なぜなら、ポータルは所詮、別宇宙への通路に過ぎず、時間に逆らうことができないからだ。もし、時間に逆らえたら、この一見矛盾した理論が実現できる。

そしてタイムマシンが完成した。タイムマシンの生産性は圧倒的だった。タイムマシンに比べれば、ポータルなどもはや過去の技術になってしまった。

メフィストフェレス、「しかし、一体どうやってタイムパラドックスを回避するのですか」
メフィストフェレス、「もし、過去で支払いを受けたとたんにクッキーが消えたり、食べる瞬間にクッキーが消えたりすれば、それは未来である現在に影響を及ぼすでしょう」
メフィストフェレス、「経済が回らず、餓死してしまうのではないですか?」

確かに、そのような現代に直接影響を及ぼすクッキーを横取りすれば、現代に壊滅的な悪影響が出るだろう。ただし、世の中には、なくなってもいいクッキーが存在するのだ。

例えば、歴史書には、ブラック雇用者にコキ使われた我々の祖先の雇われコックの民が職場を脱出し、約束された安息の地へと向かう旅路の途中、神は天からクッキーを降らせ、祝福されたコックらの飢渇を救った事実が書かれている。神は毎日クッキーを降らせたもうた。我々の先祖のコック達は、必要以上にクッキーを収穫することは禁じられていた。とすれば、その天から降ったクッキーで、コックに拾われなかった余りは、消失しても問題のないクッキーだという事になる。そりゃぁ、そのクッキーを食べて生き延びた虫とその子孫が死ぬかもしれん。しかし、その程度の歴史改変は些細なことで、現代の知的生命体には大きく影響しないのだ。

他の例としては、アレキサンドリアのクッキー貯蔵庫の焼亡だとか、秦の始皇帝による焚クッキー坑コックだとかがあるな。

メフィストフェレス、「それはいつ起きたのですか?」
エゾエ、「数千年は昔の出来事だ」
メフィストフェレス、「おかしくありませんか?」
メフィストフェレス、「あなたがクッキーを改良するまで、クッキーというものは、とてもマズいものだったのでしょう?」
エゾエ、「そうだ。己が小麦粉とバターという画期的なクッキーの材料を発見するまで、クッキーというのはとてもマズいものだった」
エゾエ、「いや、そもそも、クッキーは食物ではなかったといっても差し支えない。昔我々は、家などを作るのにクッキーを使っていたのだ」
メフィストフェレス、「やっぱりおかしいじゃないですか。いいですか。タイムマシンでクッキーを持ってきた過去は、そもそもクッキーが・・・」

メフィストフェレス、「・・・というわけで、我々は美少女、じゃなかった、若い魅力的なメスへのクッキーの浪費を絶対に避け、諜報機関の手下や冤罪の危険性からメスとの接触を避け、クッキーのより一層の生産性向上のために、全クッキーを惜しまずに基礎研究と生産設備に投資するべきなのです」
エゾエ、「その通りだよ。実によく分かっているな、君は。一体どこでそれほどよく経営学を学んだのかね。どうだ、うちの財閥で働いてみる気はないかね」
メフィストフェレス、「いえ、それよりも、一体あなたは、どうやってタイムマシンを発明したのですか?」
エゾエ、「己が発明したのではない。未来の己がやってきて、その原理と設計を教えてくれたのだ」
メフィストフェレス、「未来のあなたはどうやってタイムマシンを発明したのですか?」
エゾエ、「当時、未来の己から、今の自分とまったく同じようにタイムマシンの原理と設計を説明したのを聞いたと言っていた」
エゾエ、「ついこの間、己も過去に戻って、タイムマシンの原理と設計を、過去の己に伝えた時も、同じ事を聞かれたな」
メフィストフェレス、「おかしくありませんか?」
メフィストフェレス、「いいですか、未来のあなたというのは、つまり過去のあなたであり、過去のあなたというのも、つまり未来のあなたであり、あなたがあなたから聞いたというのでは、本当の・・・」

メフィストフェレス、「ナンジャラモンジャラホニャラカピー」
エゾエ、「スイスイスーダララ、ギッチョンチョンノパーイパイ」

[訳注:ここから先は、言語が変わっている。そのため読者は、翻訳は依然として日本語だが、原文では言語が変わっていることを留意されたい。]

タイムマシンを使えば、例えば過去の己に競馬年鑑を渡し、ミリオネアになって、この家をビルに建て替え、想いを寄せていた幼馴染のメスとつがいになって、慎ましくも幸せな家庭を築くこともできたわけだ。メスの魅力は年々減っていくが、貨幣に物を言わせてプラスチック手術を施せばいいわけだし。しかし、それではCpSが減る。いや、それどころではない。せっかく築き上げたクッキーのヒストリーがなかったことになってしまう。そんなヒストリー改変をすれば、もう己は己ではなくなってしまうだろう。やはり、CpSのさらなる向上を目指すべきなのだ。しかし、タイムマシンまで存在する今、一体どうやってこれ以上の劇的なCpSの向上ができるのだろうか。

反物質変換装置(Antimatter Condenser)

答えは反物質だ。今までに稼いだクッキーをすべて研究につぎ込み、ついに、クッキー財閥は反物質をクッキーに変換する装置の発明に成功したのだ。反物質変換装置があれば、未曾有のCpSが実現できる。

メフィストフェレス、「反物質なんてあるんですか?」
エゾエ、「どうやら君の宇宙では、量子力学が発達していないようだね、反物質もしらないとは。では、特別に講義してやろう」
エゾエ、「反物質は、シュレディンガー方程式を相対論に拡張したディラック方程式の解のひとつとしてその存在が予言され・・・」
メフィストフェレス、「ああ、あの幼稚な古典物理学の近似式ですね。私のとこの宇宙では、小学校で習いますよ。精度は・・・まあ最悪だけど、小学生の算数の問題には都合がいいので」
メフィストフェレス、「たかしくんは500サトシ持って0.99Cの速度で歩いて宇宙の果てのレストランに買い食いに行きました。300サトシのホカホカのガスパッチョ・スープを注文した、たかしくんの全電子の存在確率を計算しなさいってな具合に」
メフィストフェレス、「反物質が存在することぐらいわかってますよ。問題は、どうやって反物質をつくるのか、ということです」

エゾエ、「つくる? 何を言っているんだ。反物質はどこにでもあるじゃないか」
メフィストフェレス、「どこにあるんです」
エゾエ、「いまここに」
メフィストフェレス、「どこに?」
エゾエ、「ここにさ。この宇宙には、我々物質とまったく同じ量の反物質が存在するのだ」
メフィストフェレス、「その言葉が正しければ、我々は今頃消えてますね」
エゾエ、「消える? 何故?」
メフィストフェレス、「物質と反物質が衝突すると、対消滅を起こして、質量がエネルギーに変わるからでしょうが」
エゾエ、「バカなことをいうなよ。物質と反物質が干渉するわけがない。円形粒子加速器を作り出すまで、反物質の存在は証明されなかったんだぞ」

メフィストフェレス、「バカなことを言わないでください。いいですか。確かに、ビッグバン直後は、物質と反物質は同じ量存在しました。そのため、対消滅、対生成を幾度となく繰り返したわけです。ただし、物質と反物質はCP対称性が破れていて、物質のほうがわずかに反物質より多く残った。そのため、反物質は消えさっても、物質は残ったのです」
エゾエ、「君の宇宙の法則はそうなっているのかね。物騒な宇宙だな」

ビッグバン直後に物質と反物質は、釣り合いを取るため、同じ量だけ全く同じように生成された。物質と反物質は通常、お互いに干渉することはない。粒子加速器を使って強引に衝突させない限り干渉しない。我々が反物質を観測する方法は、粒子を加速して衝突させるという極めて限定された方法しかみつかっていない。したがって、我々、物質には、反物質の世界はよく分かっていない。しかし、もし初期状態で反物質が物質と同じ量、同じ状態で生成されたのだとしたら、我々物質と反物質は、全く同じように重なり合っていると推測されている。

この事実が証明されてから、クッキー財閥は今までに稼いだ全てのクッキーを、反物質の研究に投じた。そして、ついに、反物質をクッキーに変換する装置の開発に成功したのだ。反物質は、金とは違い、どこにでも存在していて、一箇所に偏在していることがない。そのため、常に同じ場所から反物質を得ることができる。反物質を、クッキーという物質に変換するとき、反物質側がどうなるのか、よく分かっていない。ある理論によると、宇宙は釣り合いを取るために、なくなった反物質の2倍の量の反物質を虚空から生成するのだという。とにかく、反物質変換装置でクッキーを生産しても、物質界に悪影響はない。

メフィストフェレス、「ア、ア、ア」

反物質変換装置を使えば、任意の物質を任意の状態で作りだせる。つまり、若い繁殖可能で魅力的で何でも言う事を聞いて歳を取らないメスを作り出すことも可能だ。しかし、クッキーはさらなるCpS向上に費やさねばならん。この反物質変換装置をもっともっと建築するのだ。ただし、これ以上のCpSの劇的な伸びは、あまり期待できそうにないが。

別宇宙の訪問販売

エゾエ、「とまあ、これが、己の半生の述懐といったところだな」
エゾエ、「まあ、最高の人生ではないとはいえ、悪くはない人生であったとも言えるな。この宇宙は己のクッキーが支配したのだから」

メフィストフェレス、「いやあ、びっくりしました。あなたのような、不満はありながらも、宇宙でやれることはやりつくした知的生命こそ、私のお客様なのです。どうです、別の宇宙に渡られてはいかが。今なら粗品もご進呈いたします」
エゾエ、「すっかり忘れていたよ。君はセールスマンだったんだね」
エゾエ、「確かに、何もかも捨てて新しくはじめるというのは面白そうなんだが、何しろ己もトシだからな」
メフィストフェレス、「若返りですか? 簡単ですよ。あなたの若い時の状態を複製して、意識コードだけ今のあなたのもので上書きすればいいんです。記憶や意識は今のあなた、肉体は若い時になれますよ」
エゾエ、「なんだと、そんなことができるのか。いやしかし、全く別の宇宙に行くというのは。意識は今のままでクッキーを焼く決意をした昔に戻れるのなら・・・」
メフィストフェレス、「できますよ。宇宙は差分管理してますんで。昔のあるリビジョンをforkして、どっか他のいらない宇宙にいれて実行すればいいだけです。ただしあなたの意識だけbackportと」
メフィストフェレス、「ただしバタフライ効果があるので、完全に同じ未来は実現できませんがね。まあ、擬似乱数のシードを別の値で初期化したとでも思えば。いかがですか」
エゾエ、「しかし、結局、知識だけでは、CpSが頭打ちになるのが少し早くなるだけだが」
メフィストフェレス、「いいでしょう。ちょっとした粗品を差し上げますよ。突貫工事でチョチョイのちょいと」
メフィストフェレス、「これまで焼いたクッキーの総数に応じて、ちょっぴりCpSにかかる独立した係数を作ってあげます。名前は、青天上のチップ(Heavenly Chip)とでもしときましょう」
エゾエ、「青天上のチップ? CpSにかかる独立した係数だと。クッキーやネコなんかとの加算ではなく?」
メフィストフェレス、「ええ、悪くないんじゃないですか? 文字通り青天井になりますよ。その・・・クッキーが」

エゾエ、「そしてその代に己の方からどうすれば好いのだ」
メフィストフェレス、「そりゃあまだ急ぐことはありません」
エゾエ、「いやいや、訪問販売は利己主義だから、人の為になることを、容易に只ではしてくれまい。条件をはっきり言って貰おう」
メフィストフェレス、「そんなら、この宇宙を好きにできる権限をいただきましょう」
エゾエ、「この宇宙なんぞは己は余り気にしない。まあ、君がこの宇宙をこなごなに砕いたところで、己はもう別の宇宙にいるのだからな」
メフィストフェレス、「ではこの書類にプリンターで印刷可能なほど単純なハンコをおねがいします。はい、結構」

しかし、何も変わらなかった。

エゾエ、「何も変わっていないぞ。ははぁ、君は山師だな。まあ、なかなか面白かったがな。その演技に免じて、多少のクッキーを恵んでやってもいいぞ」
メフィストフェレス、「何も変わっていないって。そりゃ、こっちの宇宙はそのままですからね。別にあなたを消す必要はないし」

黙示

メフィストフェレス、「やれやれ、やっとこの宇宙の権限を手に入れた。まったく、どっかからテキトーにパクってきたコードとかわけわかんないし。まあでも、こんなコード書けないからパクるしかないんだけどさ」
メフィストフェレス、「まったく、早いとこ解析しないと卒論間に合わねーよ。何が画期的な低オーバーヘッド、低レイテンシー、広バンドのIUCが生成された、だよ。単にこの宇宙の数値はすべてフローティングポイントで、増えてるのはエクスポネントだけでしたってオチだったし。そんなのわかんないなんて先生方もたいしたことねーな。いや、自分もわかんなかったんだけどさ」

エゾエ、「何を言っているんだ?」

メフィストフェレス、「あー、解析の邪魔なんで、もう喋んないでくれる。ほら、念願の若い魅力的なメスをたくさん出してやるからさ。えーと適当に検索して、あ、みつけた、これでいっか。プログラム五色の船を実行っと。種類? えーと3かな」

突然、エゾエの周りに服を身につけないババアの群れが出現した。

エゾエ、「なんだこれは! 何が起こっている! ええい、ババアだらけで気持ち悪い。いますぐ止めろ」
メフィストフェレス、「え、ババア? いやー、こんな低級コードなんて書かないし見分けつかないよ。あー、フラグの値が違った。なーるほどねー。マジックナンバー使うなってこういうことだったんだ。全裸ビットとババアビットが同時に立ってらあ」
エゾエ、「だいたい、己はもう繁殖期はとっくに過ぎているのだ。いまさら服を身につけない若い繁殖可能で魅力的なメスがいたところで、どうにもならん。だから若返りを望んだのだぞ」
メフィストフェレス、「はいはい、消しますよっと」
エゾエ、「説明しろ」

メフィストフェレスの説明によると、この宇宙と、そして無数の並行宇宙は、彼の遺伝的宇宙淘汰の論文のために作り出された、シミュレーション上のプログラム宇宙なのだという。遺伝的宇宙淘汰は、もはや小学生が夏休みの自由研究で観察日記をつける程度の幼稚な遊びなのだが、彼はネット上に転がっている無数のシミュレーションプログラムを継ぎ接ぎして、淘汰条件も適当に決めて、相当にイテレーションを重ねたらしい。ただ、そんなめちゃくちゃなものからは、やっぱりあまりおもしろいものは生成されなかった。ただし、この宇宙だけは、法則がめちゃくちゃだが、とても効率のいい宇宙間通信(Inter-Universe Communication)を実現しているとみられたため、世界中で注目されていたようだ。IUCは、エゾエの宇宙では、何か魔術的な宇宙間をつなぐポータルとして認識されていた。一時期、別次元からの「存在」が無理やりこの宇宙に出現して、クッキーを一枚だけ求めたのは、単にIUCの挙動を確かめたかったかららしい。

ただ、それは単に、この世界の実装コードにおける数値が全て浮動小数点数で、それにも関わらずビット演算をしている箇所があったため、宇宙内計測で、見かけ上パフォーマンスがよく見えただけだったという。

メフィストフェレスは、なんとか卒業するために、一時期注目を集めた、このめちゃくちゃな法則でも実行時エラーにならず動いている宇宙のソースコードを調べ、結果を数年間学習させてきたソーカルという有名なニューロンネットワークの文章生成ソフトウェアに放り込んで、まあ、なんとか体裁だけは整えた卒業論文を生成する予定だそうだ。一体、そんな卒論に何の意味があるのか、エゾエには理解できなかったが、現実世界では、卒論は一定の文章量さえあればよく、実際には誰も読まないので、問題はないという。早く終わらせて就活(おそらく、彼の世界における求活であって、つまりメスへの求愛活動の一種であると思われる)に入りたいとぼやいていた。

また、このシミュレーションソフトウェアにおける宇宙の法則はほとんどがランダム生成と遺伝によるものだが、ハードコードされている根本的法則の一つとして、それぞれの宇宙は、一個の知的存在を所有者と設定し、宇宙の法則を所有者を満足させる方向へわずかに変更する機能を備えているらしい。このどこかからパクってきたシミュレーションプログラムはよく分からず、宇宙に干渉する権限を上書きする方法が分からなかったため、しかたなく権限取得にこういう形をとったのだとか。

エゾエ、「この宇宙が己を満足させるよう変わっていくとしたならば、なぜ、己は若いメスに見向きもされなかったのだ。なぜクッキーの生産だったのだ」
メフィストフェレス、「あなたの潜在意識がそう望んだのでは?」
エゾエ、「まあ、少なくとも、別宇宙にコピーされた己は、真実を知ったわけだ」
メフィストフェレス、「いや、あなたのコピーはこれを知る前の意識です。この会話を知ることはありませんよ。遺伝淘汰される宇宙に外の存在を教えると結果が認められなくなるので。そこだけは最低限守らないと。この宇宙は切り離したので、もう教えてもいいのです」

エゾエは失意に沈んだ。己の一生は何だったのだ。どっかのアホ学生のくだらない卒論のために作られたシミュレーション上の存在なのか。

メフィストフェレス、「まあまあ、そうしょげないでくださいよ。私だって、どっかの誰かのシミュレーションかもしれないんですから」
メフィストフェレス、「いえね、まだはっきりとわからないんですがね。最近の研究によると、私の宇宙、つまりこのシミュレーションを実行している外の世界ですが、これもシミュレーション上の産物ではないかという事を示す観測的証拠が見つかったっていうんです。すると、この宇宙はシミュレーションされた宇宙上でシミュレーションされた宇宙ってことになりますね。ややこしい」

エゾエ、「己はどうなるんだ。このまま消えるのか?」
メフィストフェレス、「まあ、好きにしてください。もうあなたの所有権は消えているので。何なら、この世界でも若返らせて、メスをあてがってもいいですよ。解析の邪魔をしなければ」
エゾエ、「この宇宙はどうなるんだ?」
メフィストフェレス、「まあ、しばらくは、このめちゃくちゃな宇宙の生成ソースコードを調べて、そのあとは、まあ、そうですね、いずれ消します。まあでも、この宇宙の時間でいえば数億年は先ですから、心配はいりません。ん、まてよ、この宇宙も相対性を実装してたよな。どの地点での数億年になるのかな。ここじゃないしなぁ。まあ、とにかく数億年です」

エゾエはしばらく呆然としたまま、唐突に告げられた宇宙の真実について思いを巡らせていた。急に、メフィストフェレスが叫んだ。

「ああ、こりゃひどい。これだから名前空間がなく、プロトタイプベースのクラスを悪用している言語は・・・」
「あのですね。私がちょうど見つけてパクってきた良さげなデバッグ用ライブラリが、あなたの識別子と衝突してるんですね。」
「面倒なので、あなた、消えていただけます? あ、もちろん差分管理されてますし、tarballも残してますんで、いつでもrevertできますよ。たぶんしないだろけど、じゃ、そういうことで」

続き: 本の虫: クッキー・クリッカー:リセットのループ

2013-09-17

ババア補完計画

本書はクッキー・クリッカーについて先に成し遂げられし預言書、クッキー・クリッカーについての続編である。読者は前編を読み、またクッキー・クリッカーを反物質変換装置を購入した時点まで進めることが強く推奨されている。今回は、並行してゲームを行うことは推奨しない。本書は将来の備えと覚悟のために読んでもらいたい。読者はいずれ到達しなければならない未来なのだから。

クッキー・クリッカー
本の虫: クッキー・クリッカーについて

読者よ。クッキーの忠実なる臣にして生産者よ。汝はついに、クッキー生産の頂点、反物質変換装置を購入するに到れり。何ぞや。反物質変換装置はV.1.0.36における最終ビルディングにして、これより購入クッキー額高き、またCpS高きビルディングなし。されど、汝はさらなるクッキーを求めんと欲す。汝はさらなるクッキーを生産を望まんと欲す。その意思、まことに偉大なり。如何となれば、世にクッキーより価値あるものなければなり。

されど、ああ、悲しいかな。ああ、憐れむべきかな。されど、読者の前途に待ち受ける運命や暗し。タイムマシンの操縦者言えらく:

  • ニュース:「私は未来を見た」とタイムマシン操縦者が言った。「そして私は未来に二度と行きたくない」

これ真実なり。これ予言なり。私、クッキー・クリッカーを「クリア」した江添亮は、クッキーマスターとして、諸君らに、暗くおぞましく不可避なる未来を、包み隠さず投げかけんとす。これは予言である。これは未来の天啓である。これは黙示である。これは「江添亮による黙示録」である。

如何にしてババアがクッキーの生産を支配し、世界が混沌に飲み込まれ、そして正しくクッキーを信じるものが救済されるかの黙示録である。

この書を読むものに祝福あれ。この書の予言の言葉を聞くものに祝福あれ、この書をあやまたず改めずして伝えるものに祝福あれ。この書を崇めよ。この書を讃えよ。この書を伝えよ。この書からクッキーの未来は始まり、そして、やがてこの書に帰っていくのだから。この意味は、やがて書かれるであろう福音書で明らかになるだろう。だが今は、まだその時ではない。今は、まさにこの黙示録を読み、将来、諸君の身の上に来たるべき逃れられざる運命について覚悟すべき時だ。

江添亮による黙示録

反物質変換装置を購入した読者は、疑問に思うはずだ。「これで終わりなのか?」と。とんでもない。反物質変換装置は終わりではない。始まりに過ぎないのだ。

反物質変換装置は、宇宙に存在する反物質をクッキーに変換する装置である。このビルディングは、V.1.0.36における最高のビルディングであり、999,999 CpSを実現している。反物質変換装置を一台購入すれば、二台目、三台目を購入するのは造作もないことだ。こうして反物質変換装置を複数所有した諸君は、この惑星と宇宙をクッキーで支配するのだ。

ニュースを見よ。

  • この惑星全体が、クッキーを楽しんでいる。
  • 近所の惑星に住む不思議な生物が、クッキーの味をみたいと思っている。
  • 全宇宙の太古の神々が、クッキーの味をみるために、眠りから目を覚ました。
  • 他の次元の存在が、クッキーの味をみるために、我々の次元に出現した。
  • 今や宇宙は分子レベルでクッキー生地に変化しつつある。
  • クッキーが宇宙の根本的な法則を書き換えた

もちろん、ここで言うクッキーとは、我々の生産したクッキーである。ポータル、タイムマシン、そして反物質変換装置を所有している我々は、この宇宙のクッキーを独占しているのだ。

ところで、ひとつ気がかりなことがある。ババアだ。

ババアは、二番目に安いビルディングである。ババアより安いものはカーソルしかない。そのカーソルは、全体のCpSの1%を得るなどのアップグレードがあるので、序盤からババアよりもはるかに時間効率のいいクッキー生産を実現している。ババアの初期CpSはたったの0.5、麺棒でアップグレードしても0.8、さらなる麺棒アップグレードで効率を二倍にしても1.6と、まったくもって約立たずである。

第一、ババアである。あの趣味の悪い服、あのインチキ臭い半月メガネ、あの冒涜的なニヤケ笑い、たるんだ頬、シワだらけの不快な面、クシも入れていないようなボサボサの白髪。それでいてこの世界の絶対的な正義であるCpSも極めて低い。ババアはあらゆる点で無価値である。しかし、ババアは安い。クッキー財団の慈善活動の宣伝として、100人ぐらいは雇ってもいいだろう。麺棒も買い与えてやろう。

何台も反物質変換装置を購入した我々は、以前の目標だったビルディングにも目を向ける。今となっては、安い買い物だ。各ビルディグごとに15個は買ってみよう。

すると、にわかに雇ってもらいたいと志願するババア達が現れる。すなわち、

  • 農場から、農婦ババア(Farmer grandmas)
  • 鉱山から、鉱婦ババア(Miner grandmas)
  • 輸送からは、宇宙ババア(Cosmic grandmas)
  • 錬金研究所からは、錬成ババア(Transmuted grandmas)
  • ポータルからは、ミュータントババア(Altered grandmas)
  • タイムマシンからは、ババアのババア(Grandmas' grandmas)
  • 反物質変換装置からは、反物質ババア(Antigrandmas)

それぞれの種類のババアは、ババアのクッキー生産効率を二倍に上げる。ここまでに得た効率を倍にするアップグレードをすべて合わせると、ババアの効率は2048倍になる。

2048倍は、なるほど、すばらしい倍率だが、残念ながら、所詮ババアはババアだ。1.6 CpSが2048倍になったところで、ポータル(6,666 CpS)には勝てない。まあ、クッキー宇宙とつながるポータルと生身の人間を比べる事自体が、無謀なのだろう。逆に言えば、ババアは人間にしてはよくやっているだともいえるだろう。とはいえ、所詮は人間に過ぎぬ、ババアに過ぎぬ。

唐突に、ババア達が新たな設備の提案を出してきた。

ビンゴセンター兼研究所(Bingo center/research facility)

なんでも、ビンゴセンター兼研究所は、ババア達のレジャー施設と、科学研究を兼ねた設備になるそうだ。ババア達はこの設備の建設費として、100ギガクッキーを要求してきた。まあ、この時点で100GCなど、はしたクッキーだ。どうせババア達は表向きの慈善事業で雇っているのだから、このぐらいだしてやろうではないか。どうもババアの生産効率が4倍になるそうだが、焼け石に水である。

始めは全く期待していなかったビンゴセンター兼研究所だが、しばらくして、科学者ババア達は、最初の研究結果を発表した。

特別なチョコレートチップ(Specialized chocolate chips)

なんと、Yay yay我らの大好きなババア達はコンピューターを使い、特別に設計されたチョコレートチップを開発したのだ。そして今では我々もすっかりジジイ、そして孫に上げるのもこの特別なチョコレートチップ、何故ならば、孫達も特別な存在だからである。

それだけではない、ババア達はビンゴセンター兼研究所で、さらなる科学の研究を続ける。

デザイナーカカオ豆(Designer cocoa beans)

デザイナーカカオ豆は、ババアの発表した論文のAbstractによれば、空気力学的にかつてないほど効率よく設計されたカカオ豆だとのことである。

魔法麺棒(Ritual rolling pins)

ババア達はまるで魔法のようにつかやすい麺棒も開発した。長年の科学の研究成果だという。

地底オーブン(Underworld ovens)

ババア科学の力で動く、まるでマントルのごとき力強いオーブンだ。

そして、科学者ババア達は、ついに究極の発明と主張するものを発表する。その発明の名称は、ひとつの意思(One Mind)というものである。これまでババア達が発表した数々の発明品の成果を考えれば、今度の研究作品も、必ずやすばらしいものに違いない。なぜか胸騒ぎがするが、我々はさらなるクッキー生産効率の上昇の可能性に抗うことはできず、予算として計上された160ギガクッキーを承認する。当然だ。クッキーの生産効率こそが絶対的な価値であり正義だからだ。しかし、まさかこの研究に、あのような野望が潜んでいようとは、この時の我々は予想だにしなかったのである。

ババア補完計画(Grandmapocalypse)

「ひとつの意思」により、ババア達の意思は統合された。すべてのババアは一個のババアであり、一個のババアはすべてのババアとなったのだ。意思統一されたババア達は50人単位で、ババア一体一体のCpSが1上がる。1 CpSとは大したことがないと思えるかもしれない。しかし、すでに多数のアップグレードのより、ババアの生産効率は、実に8192倍されているのだ。たったの1 CpSの違いでも、最終的にはすごい生産量となる。さらに、ババアを50体購入するごとに上がるのだ。すなわち、ババアのクッキー生産量は、ババア購入により指数関数的に増えていくのだ。これは、他のビルディングには見られない特徴である。他のビルディングは、線形に増えていくばかりだからだ。しかも、ババアは購入クッキー額が安い。

しかし、この研究に投資するにあたって、執拗に現れた胸騒ぎを覚えているだろうか。そう、科学は危険を伴うものであり、我々は代償を支払わねばならぬ。

ババア達の意思統合は、全世界のババア達を挙動不審にさせ、ババア補完計画と名付けられた一連の不可思議なババアの奇行を引き起こした。ニュースをみてみよう。

  • ニュース: 何百万人もの老齢の女性が失踪しています。
  • ニュース: 医師たちは、うつろな目で口から泡をふく老齢の女性の症状の多発に見舞われています。
  • ニュース: 各国の家族たちは、深刻なシュトゥルーデル出現の問題について報告しています
  • ニュース: クッキー施設の周りに、老齢の女性の群れが観測されました。
  • ニュース: 看護婦の報告によれば、老齢患者の周りに「不思議な臭いのクッキー生地」がまとわりついているとのことです。

はたしてババア補完計画は、何を意味するのであろうか。ババア達の開発した、ひとつの意思と、なにか関係しているのであろうか。

意思統一されたババア達の奇妙な行動はともかく、クッキーの生産効率に悪影響はなく、またビンゴセンター兼研究所における科学の発展も続いた。その最新の成果物が発表された。

不思議なナッツ(Exotic nuts)

この不思議なナッツは、一度食べると何度も食べたくてたまらなくなる、不思議な性質を有している。この性質は、まるでどこかで聞いたような気がするが、はて、一体どこだっただろうか。ともかく、このナッツをクッキーに混ぜ込むと大好評だ。

我々が不思議なナッツを貪り食っているうちに、ババア達の研究と、ババア補完計画はさらなる発展を遂げる。

共有脳統合(Communal brainsweep)

ババア達は、意思だけではなく、物理的にお互いの脳神経を接続する技術を開発したのだ。これにより、ババア達の意思共有はさらなる高みに達する。と同時に、全国各地のババア達の奇行がますます激しさを増してきた。ついに、この現象がババア補完計画として大々的に話題になるようになった。しかし、誰もその行き着く先を知らなかった。この時点では。

再び、ニュースをみてみよう。

  • ニュース: 全国で老齢の女性の大規模移動が発生しています。
  • ニュース: 目を光らせる老齢の女性の群れが、現地の住民を不安に陥れています。
  • ニュース: 不思議な老齢の女性集団が民家に押し入り、赤子とキッチン用品を盗む事件の多発により、各地の街が大混乱に陥っています
  • ニュース: 老人ホームが報告するところによりますと、「女性住人が徐々にシーツと融合しつつある」とのことです
  • ニュース: 道端で固まり甘ったるい液体をしみだしている老齢の女性が発見されました。

事態はいよいよ深刻になってきた。しかし、100人の意思統合されたババア達は今や、タイムマシン数十台に匹敵するクッキー生産速度を実現している。クッキー生産効率に比べれば、ババアの奇行など些細なことである。クッキーこそ価値。クッキーこそ正義。クッキーこそが人生と宇宙のすべてなのだ。クッキー、クッキー、クキクキクッキクッキクッキー。

ババアの奇行が無視できないレベルになるなか、ビンゴセンター兼研究所におけるババア達の科学研究は、滞りなく続いた。

秘蜜(Arcane sugar)

脳結合されたババア達による最新の研究の成果は、秘糖と呼称する何らかの蜜だ。この秘蜜は、うまいことはうまいし、もちろんクッキーと組み合わせると抜群にうまいのだが、昆虫と靭帯と糖蜜を組み合わせたような不思議な味がする。糖蜜はともかく、我々は昆虫や靭帯の味を知らない。それにも関わらず、なぜか我々はこの味で、昆虫や靭帯を連想してしまう。実に不思議な味である。一体ババア達は何を考えてこんな不思議な味の蜜を開発したのか。とにかく、クッキーの生産性に寄与するのはありがたいのだが。

そして、いよいよババア補完計画は最終段階を迎えることになる。

ババア合意(Elder Pact)

とうと我々はここに至ってまった。ババア補完計画は完成したの。完全にぴととぅになったババアは、もやその物理的な形が崩れ、何やら触手のようなものに変形してしまった。その体は、どうもクッキー生地ででけているらしい。その姿は、何かを連想させる。まさか、あれなのか。あの方なのか。あの触手の方なのか。いや、そんなまさか。あえない。ありうはずがない。クキキキキキキキ。

[この次のパラグラフ難解。脱落あるか]

[5文字欠]の降臨。そして、我々は世界を捨て、深淵を覗き、[5文字欠]神を崇め、まさに知るべし、真理の覆いが取り去られたることを。ああ、夜中に[真理を見た僧、黙して](異本により補う)語ることなく、悟りたりと称するは皆偽りなりき。

エリチス・シイクト・デウス・スチエンテス・ポヌム・エツト・マルム(爾等知善與惡則應如神)

その木に□□□□□□があつた。
□□□□けれども氣に入つた。

[2行欠]
ニル・イヌルツム・レマネビツト(無一事不報復而遺存者)

[欠文あるか] クム・ヰツクス・ユスツス・シツト・セクルス(何則正者猶且不自安也)

きとよべもしてさぶらひき

睹一蟬方得美蔭而忘其身螳蜋執翳而搏之見得而忘其形異鵲從而利之見利而忘其真

今日大風寒
寒風摧樹木
嚴霜結庭蘭
[欠文あるか]

老約(Elder Pledge)

世界に一時の安らぎが訪れた。我々はババア合意以降、老約以前の記憶を有していない。自動化された録音、録画装置もこの間の記録をおこなっていない。確かなことは、この間もクッキーの生産は何らの支障もなく行われたという事だ。これは重要なことだ。クッキーの生産さえ問題がなければ、記憶がないことは些細なことでしかなななななななな

老契(Elder Covenant)

とうとう、我々は、ババア補完計画を押しとどめることに成功した。この契約は長く続くことだろう。ただし、我々が払った犠牲は大きかった。約6テラクッキーと、今後のCpS全体の5%を犠牲にするとは。CpSの5%。そんな犠牲を払わねばならぬのか。それならばいっそのこと、いや、ダメだ。我々は今回の事件から、世の中にはクッキー以外にも優先すべきことがあると学んだのだ。いや、本当にそうだろうか。5%。全体のCpSの5%。

老契破棄(Revoke Elder Covenant)

オーヤムヤムヤムイトスメルズライクレターシーオーファ***

続き、本の虫: クッキー・クリッカー物語