※ここは、フリーウェア／シェアウェア作りにいきなり挑戦した作者のナマの喘ぎ声（笑）をお届けするコーナーです。自分もフリーウェア作家になりたい！と思う人の参考になれば…。（ならないか）
■ フリーウェアの近況（？）とアマクリウェアの経緯
(株)ベクターのダウンロード報告による近況を報告しておこう。一番ダウンロード数が多いのは相変わらず「Color Crown」だ。毎月、コンスタントに400件前後のダウンロードがある。僕のサイトからのダウンロード数も足せば、500以上になる。「おちがめ」は200／月程度なので、ほぼ２倍の差がついてしまった。
実は、この他にも１本、「Color Crown」並みに400／月のダウンロードがなされているものがある。それは、１月に公開した「アマクリ・ソリティア」。なぜか、こいつがけっこう静かに遊ばれているのだ。
アマクリ・ソリティアは、「アマクリウェア」としてリリースしたフリーウェアの一つだ。今年に入ってから現在まで、僕はアマクリウェアのフリーゲームを４本リリースしている。今回は、これらに書こうと思う。
アマクリウェアは、要するに僕が所属するユーザーグループ「アマクリ」の宣伝を兼ねたものとして作ったフリーウェアだ。まあ、少なくとも僕はそのつもりで作ってる。ただ、モノとしては、単にフリーウェアにアマクリの宣伝（？）が書いてあるだけで、基本的にはそれまで作っていた普通のフリーウェアと変わりはない。
ただ、「アマクリ・ソリティア」は、一つだけ他とは違う点があった。それは遊ぶだけでなく「自分で作れる」という点だ。――一応、ゲームボードを自作する機能が用意されているのだけど、そういうことをいってるわけじゃない。文字通り、REALbasicを持っていれば「アマクリ・ソリティア」を自分で作れるのだ。
前々から僕は、単に「遊んでおしまい」というのでなく、もっと作る方向へ人を引っ張っていけるようなフリーウェアが作れないかと思っていた。自分で作るとなると、まず思い浮かぶのはプログラミング入門のようなコンテンツである。それなら僕の本職だしお手のものだ。だけど、そうしたコンテンツは、最初から「作ってみたい」と思う人しかわざわざ読んではくれないだろう。
そこで、アマクリに自分のページを持つ時、考えた。ゲーム作りの連載記事をアップしよう、ということは決めてあった。そして、その連載で作ったゲームをフリーウェアとして広く配付しよう、と思ったわけだ。フリーウェアには、もちろん「このゲームはこの連載で作ったものです。これを読めばあなたもREALbasicでこのゲームが作れます」というようなことを記述し、URLも入れておく。要するに、フリーウェアとゲーム作りのコンテンツを車輪の両輪にして平行して広めよう、と思ったわけだね。
多くの（プログラミングに無縁な）人は、何かソフトを使っても「その中身がどうなっているか」なんて考えない。最初から「自分には無縁のことだ」と割り切って考えてるようなところがある。それは、「ソフトの中身なんて見られない」からだ。見ることができないから、余計に「きっと難しいに決まってる」と思い込んでしまう。
だから、ゲームをプレイした時、「このゲームがどうやって作ってあるのか見られますよ」とあれば、ちょっと覗いてみたいと思う人はけっこういるんじゃないかと思う。そして、どうやって作ってあるのだろうと思って見てみると、なるほど難しそうではある。だけど、理解できないほど難しいわけでもないようだ。そういう、想像ではなく現実の「難しさのレベル」がはっきりと見えれば、プログラミングに対する見方も変わってくると思う。もちろん、「やっぱり自分には無理かも」と思う人もいるだろう。けど、「頑張ればオレにもできそうだ」と思う人もいるに違いない。
山屋の言葉にこういうのがある。「山は、登る前が一番怖い」――自分の家で机に座ってあれこれ想像している時が、実は山は一番怖い。どれぐらい怖いかわからない時が一番怖いのだ。現実に直面すると「怖さのレベル」がはっきりとわかるので、意外に怖くない。プログラミングも同じじゃないだろうか。想像だけで考えている時、プログラミングは一番難しい（笑）。「現実の難しさのレベル」がはっきり見えれば、意外に難しくはない。
正直、この企画がうまくいっているかどうかはわからない。だけど、連載を楽しみにしてくれる人や、実際に自分でフリーウェアを作ったという人もいるから、無駄ではなかったと思う。
■バグ発生に関するマーフィーの法則
アマクリウェアは、その後も着実に出てまして、「アマクリ・リバーシ」というオセロゲーム、「Amacre Color-rise」という色合わせのパズル、そしてゴールデンウィークには「つーちゃん」という、初めて「アマクリ」と名前につかないソフトをリリースした（笑）。なんだかんだで、数だけは出してるね。
フリーウェア作りってのは、プログラミング以外のところに落とし穴がけっこうあるんだなあ、と思う。アマクリウェアで一番「やられた！」と思ったのは、リバーシ。これをベクターに登録する際、Read
meに「オセロ」という名前が１ケ所あったのが問題になった。オセロはツクダの登録商標なのでまずいらしい。また、デフォルトが緑色の盤面だったのだけど、これもツクダの意匠登録にひっかかる可能性があるとのこと。で、急遽差し換え。
まあ、オセロという名前をソフト名につけられないというのはわかるのだけど、Read meの説明などで「オセロ」という単語が使われただけで問題になる、というのは、いくらなんでもやりすぎじゃないだろうか。更に、「緑の盤面」とか「白と黒のコマ」というのもまずいかも知れないといわれると、「それじゃあ囲碁はどうすんだ、あれはオセロより遥か前から白と黒だぞ！」とか「バックギャモンやルーレットの緑の盤面はいいのか？」という話になってくる。
まあ、実際にそれで問題になるかどうかは疑問だ。けど、それだけ神経質になるってことは、それまでオセロに関してツクダからかなり圧力を受けた経緯があるのだろう、と邪推したくなる。少なくともオレ的には、ツクダの企業イメージは猛烈に低下しました。もうおたくの製品は絶対買いません、はい。
また、最新作「つーちゃん」で焦ったのが、ver. 0.0.2をアップした際、クリアしてない状態だとゲームがスタートできないというとんでもないバグ付き版をアップしてしばらく気づかなかったこと。0.0.2ではクリアするとメニューから各ステージが直接選べるようになるのだけど、このメニュー関係の操作を最後にちょっとだけ変えてみたのね。ところが、このメニューはクリアしないと現れないので、本当は「クリア状態かどうか」を示すフラグをチェックして、クリアした時のみメニュー操作をしないといけない。
それまでずっと普通に動いていたので、最後にちょっと修正をした時、このチェックを忘れてしまったらしい。自分の環境は既にクリア後の状態になっているから気づかなかったのだね。で、いわれて慌ててチェックしてみたら、ゲームスタートと同時にエラーが起きて終了してしまった。慌ててコードを調べ、問題のフラグチェックが抜けていることに気づき、再度コンパイルして動作チェックをして再度アップ。その間、約４時間。あれほど焦ったのはフリーウェア公開して以来、初めてだ。
どうも、フリーウェア作りに慣れてきたせいか、動作確認が甘くなっていたようだ。通常は、何か機能変更すれば、想定し得る全ての状態で問題なく動くかどうかチェックするのに、最後のメニュー関係の変更は、たいして重要な変更でもないので、ざっとチェックして問題ないとしてしまったらしい。人間、「慣れ」というのは恐ろしいものだなと改めて痛感しました。
最大のバグは、常にマスターアップの後に発見される。（マーフィーの法則か？）
エッセー（1999.09）
■なんと！CCPGが人気とは（笑）
(株)ベクターのライブラリサイトに作ったソフトを登録して１ヶ月ちょっとになる。ここは、ダウンロードランキングを掲載したり、毎月ダウンロード数などの情報をメールで作者に連絡してくれたりしてくれるので、作ったソフトがどれぐらい人気があるのかがわかってとても参考になる。
今回どどっと公開したソフト４本は、ほとんど同じような期間に作られた。ほぼ10日おきぐらいに連続公開した感じになると思う。その後、何度か細かなバージョンアップをしたりしたけど、まあだいたい公開の条件は一緒だ。で、どのぐらい人気があるものか、ちょっと調べてみた。
毎週更新されるダウンロードランキングに載ったのは、「おちがめ」「Color Crown」の２本だけ。「おちがめ」は新作Macゲームのランキングで16位までいった。ただし、２週間ぐらいで20位以下の圏外に落ちてしまった。「Color Crown」は、やっぱり15位程度だったが、３週間ほど20位圏内に残っていた。
ダウンロード数を見ると、「おちがめ」は１ヶ月に1000ちょっとぐらい。「Color Crown」は、公開が遅かったので３週間ぐらいの集計だったけど、それでも1000を超えていた。
「おちがめ」のほうは、公開からどどっと反響があったんだよね。公開して数日間は、うちのホームページのカウンタは通常より１日当たり1000以上も増えた。ハイスコア競争も苛烈で（笑）、ほとんど毎日のように「おちがめ」コーナーを更新し、マイナーバージョンの変更に明け暮れる毎日が続いた。いくつもの電子メールマガジンや雑誌から、紹介をしたいとのアポが入ってきて驚いたもんだ。
「Color Crown」は、公開してちょっとは反響があったものの、あんまりダウンロード数は多くなかった。ところが、ある程度時間が経過するに従って、じりじりとダウンロード数が増え、反応が返ってくるようになった。リクルートの雑誌「あちゃら」から１年間の雑誌収録をしたいとのアポがあったのは、「おちがめ」ではなく「Color Crown」だった。ふーむ。
「おちがめ」は、いわゆる「さめがめ」タイプの亜流だ。だから、「さめがめのアレンジ版ですよ」といえばすぐにわかるし、みんな飛びついてくれた。だけど、結局はオリジナルには勝てないんだよね。やっぱり、一番面白いのは「さめがめ」や「まきがめ」という元祖のゲームなんだ。
「Color Crown」は、どうも紹介の仕方に失敗した気がする（笑）。なにしろ、「オセロタイプの思考型ゲーム」だからなあ…。「オセロみたいなやつ」という時点で、なんとなく想像がついて「なんか面白くなさそう」と思われてしまったのかも知れない。「相手のコマを自分のコマに変える」という点で「オセロタイプ」としたんだけど、Color Crownは完全なオリジナルゲーム。オリジナルは、広まるのに時間がかかるけど、「これ、面白い」ということがわかってもらえれば長く遊んでもらえるみたいだ。
ただしオリジナルは、面白くないと、ハナも引っ掛けてもらえない（笑）。そのへんがつらいとこだねえ。
■ダウンロードの多いものが評判がいい…わけではない
ベクターのランキングを見ている内に、なんとなく人気のあるゲームがどういうものかわかってきた気がする。それは「見た目」だ（笑）。ビジュアルがカッコイイ、かわいい、変、というものは、公開してすぐにどっとダウンロードされる。はっきりいって、くやしい。
が、そういうものは数週間すると、きれいに駆逐されてしまう。そしてまた、次の新しい変なやつ（笑）が上位を独占するというわけ。要するに、みんな「変なもの」が好きなのだ。だけど、すぐに飽きるのだな。そうやって、次々にソフトウェアは消費される。
作る側に回って、一般大衆の飽きっぽさ（？）というものをじっくり考えるようになってしまった。せっかく時間をかけて作った愛しいソフトたちだ、長くみんなに可愛がってもらいたい。けれど、たとえほんの一時的なものでも人気者になって欲しい（笑）。このへんは難しいところだ。
実は、ダウンロード数はそう多くないけど、とても評判がいい、というのがある。「My時計Maker」だ。これは、公開してから１ヶ月でベクターでのダウンロード数はせいぜい200程度。うちのホームページでも、そう極端なカウンタの伸びはなかった。けれど、「とても面白いです」というメールなどがちょこちょこと返ってきつつある。
ぼくはもの書きだけど、解説書の類いにもこれと似たようなことがいえる。ものすごく売れるけど評判の悪い本。あんまり売れないけど、評判のいい本。どうも、ぼくの場合は「これはよくできたな」と思った本は、評判はいいのだけど売れない（笑）。「くそ、どうもイマイチ出来が悪いなあ」と我ながら失敗したと思う本は、売れる。どうも一般読者と感覚的に乖離している部分があるらしい。もの書きとしては致命的な欠点だな。
で、話を戻してMy時計Makerなんだけど、面白いのは、作る側からの感想がけっこうあるということ。それまでのものは、みんなユーザーからの意見ばかりだったけど、「My時計Maker」では「自分もREALbasicをやってみようかと思いました」というような感想があったりする。つまり「自分でも作ってみたい」と思う何かがあったみたいだ。
もともと、この夏にどどっとソフトを作って公開したのは、「フリーウェア作家になりたい」ということもあるけど、REALbasicの布教の意味もあった。ひさびさに、普通のユーザーが使えそうな安価な開発ソフトが登場したのだから、みんなで作って遊べるようになって欲しい。そのために、いろいろソフトを公開して「そうか、こんなものもREALbasicで作れるんだ」というのを肌で感じてもらえれば――という思いもあった。
そういう意味では、「My時計Maker」は、いいソフトといえるのかも知れないなあ、と思う。下のエッセーで書いたように、自分としてはイマイチ複雑な心境なのだけど、多くの人が「自分だけのアプリケーションを作る」ということが実はかなり面白いものなんだ、ということに気がついてもらえたとしたら、作った甲斐はあった。
…まあ、作った後の評判についてだらだらと書いたけど、ぶっちゃけていえば、作った後なんて実はどーだっていいのだ（笑）。「作っている最中」こそが、何より楽しい時間であり、作った後でみんながどう使おうが実はあんまり関係なかったりする。「おちがめ」や「Color Crown」で遊ぶより、それを「作る」というほうがはるかに面白いのだから。できあがったソフトというのは、ぼくが散々楽しんだ後にひり出された、ウンコみたいなもんだ（笑）。
なんて書いたら、楽しく遊んでくれた人にはショックだろうなあ。すまんすまん。でも、実際そうなんだよ。だから、あなたもフリーソフトばっかり集めてないで、自分で作ってみなさいってば。今なら、ほんとに誰だって作れるんだから。REALbasicなら大丈夫！
ちなみにアスキーより「初歩からはじめるREALbasic」、絶賛発売中（笑）
エッセー（1999.09）
■時計を作ろうと思うまで
ことの発端は、知人から「面白いWDEFがあるみたいよ」ということを聞いてからだった。WDEFというのは、ウィンドウ定義リソースといって、ウィンドウの形とか機能を定義するリソース。これを作ってやることで、オリジナルのウィンドウを表示させたりすることができるというものね。
で、そのWDEFは「odo」といって、PICTリソースでグラフィックとして持たせたデータを元にウィンドウを作るという不思議なウィンドウ定義リソースだった。グラフィックだから、どんな形状でも作れる。「こりゃあ面白い！」というんで、何か作ってみようと思い立ったわけだ。
が、自由な形のウィンドウが作れるとしても、そのウィンドウの形状に意味がないと不定形のウィンドウを作る必要性がなくなってしまう。つまり「これ、普通のウィンドウでも別にいいじゃん」とユーザーに思われたら、その時点でおしまいなわけだね。
で、結局スタンダードに「時計」を作ることにした。時計って、やっぱり丸いものじゃない？ 四角いウィンドウだとなんかアナログの時計って感じがしないからね。丸いウィンドウが作れれば、時計らしくなると思うんだな。だけど、ただの時計じゃ、作ってもあんまり面白くない。やっぱり、「へえっ、これは面白い！」って思ってもらえる時計を作りたい。
いろいろ考えたんだけど、結局どんなに形が面白くても、時計は時計。形状で時計の良し悪しが決まるわけじゃない。ユーザーにとって一番「これがすてき！」というのは、それぞれのユーザーによって違う。…それじゃ、自分だけの時計が作れるようなカスタマイズ機能を作ればいい。そこから「My時計Maker」の発想が生まれた。
もともとは、時計アプリケーションに、表示を変更するカスタマイズツールをちょこっとつけたというだけのものだった。それが、カスタマイズの部分が次第に強化され、0.0.3では、「オリジナル時計アプリケーション制作ソフト」みたいなものになった。「新規My時計」メニューで、新しく時計アプリケーションを作っていろいろ組み込んだりできるわけね。開発当初の予定から、作っている過程でずいぶんと方向が変わり、全然違うものになってしまった。
■君は他人のふんどしで相撲をとれるか？
この「My時計Maker」の評価はとても難しいものがある。実をいえば、今まで作った中で一番評判がいいのは、この「My時計Maker」なのだ。「自分の思った通りのグラフィックの形をした時計が作れる」というところが、そういうものの好きな人にはけっこうウケたのだろうと思う。
が。この「自由な形のウィンドウを作る」という一番根本の部分は、ぼくの功績ではない。「odo WDEF」というリソースを作った人の功績だ。ぼくはただ、それに味付けをしたに過ぎない。
作っても作っても、「このソフトの本当の作者は自分ではない」という意識が常につきまとう。他人のふんどしで相撲をとっているような心苦しさ。これは、今後どんなにバージョンがあがっても消えることはないだろうと思う。
このソフトも、もちろんREALbasicで開発した。REALbasicでは、さまざまな方式で機能を拡張することができる。HyperCardなどと同じXCMDというリソースを組み込む方式、プラグインという特殊なファイルを追加する方式等など…。インターネットを検索すると、こうした機能を拡張するためのファイルがあちこちでフリーウェアとして公開されている。
ぼくは、どうもこうした他人の作ったファイルで拡張するというやり方が好きになれない。そうしたものを使ってソフトを作っても、「これは、他人のふんどし」と思ってしまうのだ。もちろん、大勢に自由に使ってもらうためにこうしたファイルをフリーで公開している人はたくさんいるし、今回使ったodo WDEFなどもそうしたものなのだけど、どうも個人的に「これは100%ぼくの作品です！」と呼べない気がしてすっきりしないんだね。自意識過剰というか、そのくせ100%自分で作れるだけの技術もないのだから困ったもんだ。
どこまでが自分の作品で、どこからが他人のふんどしなのか。その切り分けは難しい。が、少なくともそういう部分に鈍感でありたくはない。「まあいいや、おれの作品ってことにしちゃえ」というところから何かすてきなものが生まれるとは思えないから。
■クリエータの問題
ちょっとプログラミング的なことを書くと、今回、最初のバージョンで時計アプリケーションとツールが分かれていたのは、「アプリケーションの内部のリソースを書き換える」という作業をするための苦肉の策だった。普通、アプリケーションの細かな設定は、初期設定ファイルなどを作ってそこに保存する。が、今回は「アプリケーションそのものをカスタマイズする」ということをさせたかった。そうすると、この方式は使えない。そのアプリケーションをどこに持っていき動かしてもカスタマイズされたものが動作するようにしておくためには、やっぱりアプリケーション自体を書き換えないといけない。
が、起動しているアプリケーションのリソース自身を変更するというのは問題がある。そういう危険なことはできないし、なによりREALbasicでは起動しているアプリケーションのリソースフォークは既に開かれている状態なので読み込みはできても書き込みはできなかった。そこで、別アプリケーションを用意することにしたわけ。
最初のうちは、時計を作るときは時計のアプリケーションをコピーしてカスタマイズして下さい、というスタイルだった。しかし、これはどうもスマートじゃない。そこで、My時計Makerで「新規」メニューを選ぶとその場でアプリケーションが新たに作られ、それをカスタマイズするように変更した。これでずいぶんと使いやすくなったと思う。
この「アプリケーションを新規に作る」というのは、実はかなりトリックがある（笑）。「アプリケーションのコードをプログラム的に生成してるんだろうか？」などと高度なことを考えてはいけない。秘密は、My時計Makerの「ClockData」フォルダにある「MyClock.data」というファイル。実は、これがアプリケーションの「素」なのだ。
このファイル、My時計アプリケーションのファイルタイプとクリエータタイプを変更しただけのもの。つまり、ファイルタイプがアプリケーションではないので普通のファイルになっているだけで、中身は完全にアプリケーションなのだ。というわけで、これをコピーしてファイルタイプとクリエータタイプを変更すれば、新しいアプリケーションのできあがり、というわけ。タネを明かせば簡単でしょ？
あと、細かな使い勝手の調整などは苦労したけど、基本的にはプログラム自体はそう難しいことはしてない。ひたすらリソースを書き換えるだけのものだ。あんまり苦労してないので、余計に「他人のふんどし」が気になるのかも知れないな。
|
その３ 『Color Crown - Pazzle Game.』開発記
|
エッセー（1999.08）
■実はこれが第１作目なのだ（笑）
ヒマらしいね、オレ（笑）。「おちがめ」からわずか１週間。更に新作のフリーウェアゲームを公開してしまった。それが「Color Crown Pazzle Game.」だ。これは、オセロタイプ（？）の思考型ゲームだ。
見ればわかるけど、全体の雰囲気はどこか「おちがめ」に似ている。それも道理で、インターフェイスなどはほとんど両者とも共通しているのだ。コードなども共通で、再利用したものがけっこうある。例えば、ガイド機能や、コマの表示／移動処理、盤面サイズの変更などといった処理はどちらも共通のサブルーチンを使っている。オブジェクト指向というのは、こういう再利用が実に簡単にできて便利だ。
実をいうと、一番最初に手をつけたのは、この「Color Crown」なのだ。けれど、思考型ゲームというのはコンピュータが相手をする。この「コンピュータの思考回路」がどうも作れないなーと思って、半ばブン投げてあったんだな。それが、「おちがめ」で画面表示やブロック移動などの基本ルーチンができあがり、これらが全て「Color Crown」で再利用できそうなことがわかったので、「それならこれも仕上げてしまおう」ということで制作を再開した、というわけ。
折しもちょうど世間は御盆休みに差し掛かった頃で、この時期は印刷所も止まり、さすがに編集部から飛び込みの仕事が入ることもない。急ぎの仕事は御盆前に全てあげていたので、期間中はプログラミングに没頭することができた。
■ミニマックスとの戦い
既に、基本的な操作などのコードは「おちがめ」でできあがっている。唯一にして最大の問題は、「コンピュータの思考ルーチン」だった。これができなければ「Color Crown」は完成しない。これさえできれば後は全て作れる。そういう状況にあった。
オセロやチェス、将棋といったゲームの思考ルーチンでは、「ミニマックス演算」という処理を行なう。これは平たくいえば、「それぞれの手を数値化して総当たりで計算する処理」だ。全てのコマを１つずつ調べ、そのコマの動ける先をこれまた全て調べ、それによって得られる利益と不利益を数値化して全て書き出し、そこから一番数値の高い手を選びだす、というものだね。
こう文章で書くと短いけれど、これを実際にコードで書くとなると大変なことになる。基本的な考え方は、こんなふうなものだ。
１．まずマス目を１つずつ調べ、自分のコマであったら、チェック用のサブルーチンを呼び出す。
２．そのサブルーチンでは、調べるマス目の上下左右斜の移動できるマス目を調べ、そこが空白かどうか、その２つのマス目の間にジャンプできるコマがあるかどうかをチェックする。
３．ジャンプしてそのマス目に移動できることがわかったら、そのマス目について、またチェック用のサブルーチンを呼び出す。
４．そこから移動できるマス目があれば、更にそこからチェック用のサブルーチンを呼び出す。
５．その移動できるマス目があれば、……（以下略）
見ればわかるように、調べるサブルーチンは、その中から更に自分自身を呼び出すようになっている。こういうのを再帰処理というんだけど、これが作れれば、ミニマックスは完成のメドがたったといってもいい。
サブルーチンのアルゴリズムはなんとなくわかってきたのだけど、ここで落とし穴が待ち構えていた。それは「調べる時のボード全体の状態をどうやってサブルーチンに受け渡すか」だ。
こういうゲームでは、盤面の各マス目に誰のコマがあるかといった情報を、配列というやつに入れて管理する。配列ってのは、いくつもの値をまとめておさめておける特別な変数のことね。
ミニマックスのサブルーチンでは、現在の盤面の状態でどれが動かせるかだけ調べて終りではない。動かせるものがあったら、それを動かした状態で次にどこに動かせるか、その次はどこに動かせるか…といった、２の手、３の手を調べていくことになる。となると、現在の状態からコマを動かした次の状態を用意し、これを元に更に次の手を調べる、ということになる。
が！ サブルーチンを呼び出す度に、盤面の状態を示す配列を新たに作って受け渡すとなると、とんでもないことになる。１つの配列がわずか数百Byteしかなかったとしても、ミニマックスではすぐに数百回、数千回、場合によっては数万、数十万回とサブルーチンが呼び出されることになる。その度に新しく配列を用意したら、あっという間に必要なメモリ量は数十Mbを超える。
そこで、配列は１つだけですませるようにしないといけない。つまり、あるコマが動かせることがわかったら、配列を次の手の状態にしてサブルーチンを呼び出す。そしてそのサブルーチンから処理が返ってきたら、変更した配列を元の状態に戻して次の処理へ進むようにするわけだ。
このあたりの整合性をとるのが、実に厄介だった。まあ、本職のプログラマからすれば「たかがあの程度のゲームの思考ルーチンで何を大袈裟な」と思うことだろう。けれど、この種の処理を書いたことがない一介のアマチュアプログラマにとっては、かなり荷の重い作業だった。
なんとか完成したミニマックスのコードは、大小あわせて６つのサブルーチンからなる計700行のものになった。一番長いサブルーチンは300行を超える。「Color Crown」のver. 0.0.3の全コードが約1200行ぐらいだから、半分以上がミニマックスの処理で占められていることになる。
実は、もっと整理してきれいにまとめれば、500行以下ぐらいになりそうに思うんだけど、面倒臭い（笑）。けれど、初めてこれが動いて、コンピュータが自分で次の手を動かし始めた時は、さすがに感動したものだ。何が感動的かって、コマを動かしているのはコンピュータだけれど、それは全てぼくが命令したものなのだ。
コンピュータが全てぼくの考えた通りに計算し、次の手を確実に選びだして人間とゲームをしている。それを考えたのはコンピュータじゃない、ぼくなのだ。コンピュータはぼくの指示通りに動いているだけなのだ。
一瞬、脳裏を「マッドサイエンティスト」という言葉がよぎる（笑）。
■出来の悪い子ほど可愛いのか？
おそらく、ゲームとしては「おちがめ」のほうが支持されるんじゃないかと思う。単純だし、中毒性があるし（笑）、やっぱり「さめがめ」タイプというだけで知名度的にも違いが出てくる。――だけど、実をいえば、今まで作った中で一番愛着を感じるのは「Color Crown」の方なのだ。
「おちがめ」は意外と苦労しないでできてしまった、という感じがある。ムック用にちょっと作ったゲームが、あれよあれよという間にちゃんとしたゲームになってしまった、という気がする。それだけ作るのは楽しかったけれど、「立派なフリーウェアを作るぞ！」と意気込んだ割にはあっけない感じがあった。
が、「Color Crown」は、本当に久々に「苦労して作った」という感じが強い。本職のプログラマではないぼくとしては、これだけアルゴリズムを組み立てるのに苦労したことは近来なかったといってもいい。それだけに動いた喜びは大きい。
でも、地味だもんなあ（笑）。こぎれいにはまとまっているけど、おとなしいゲームはあんまりみんな遊んでくれないんだよね。それがわかっているだけに、よけいかわいいのだ（笑）。でも、次のバージョン（0.0.4）では「おちがめ」のブロックデータを使えるようにするなど改良をして、この子をもっとみんなに可愛がってもらえるようにしてやるぞ！
エッセー（1999.08）
■今度はフリーウェア作家になりたいっ！（笑）
「かりぐら博士」をアップして以後、なにかうずうずとする部分が心のどこかに澱のように残ってるんだな。これは一体なんだろう？ …そう思いながらも、今度はREALbasicのムックの原稿を一気に一週間ぐらいで書き上げるという怒濤の仕事モードに巻き込まれていった。
ムックというのは、薄い雑誌タイプの書籍だ。単行本と違い、原稿の分量も少ないけど雑誌感覚で大量にはけるので入門以前の紹介には適している。細かな説明をする文章量はないので、テクニカルな部分はばっさり切り捨て、「こんなに楽しいよ」という雰囲気を伝えよう、と思った。そこで、一通りの説明をしたら、簡単なアプリケーションをいくつか作っていこうということになった。その中で、「やっぱりゲームもないとね」ということで作ったのが「おちがめ」の原形となったゲームだ。
この「おちがめ」は、「さめがめ」「まきがめ」タイプのパズルゲーム。マウスで同じ色のブロックを消していくのだけど、同じゲームではつまらないのでちょっとアレンジし、重力の向きを上下左右に変えてゲーム展開ががらりと変わるようにしてみた。これが意外に面白い。それで「ムックの記事で消費してしまうのはもったいない」と思い、ムックの出版元である(株)ASCIIの人に許可をもらい、フリーウェアとして本格的に開発しなおしたのが、フリーソフト版「おちがめ」だ。
そう！ そこに至って、初めてぼくは、自分の中に沈澱していたモノがなんだかわかったのだ。「かりぐら博士」はシェアウェアであり、ツールであった。ぼくは、「フリーウェアのゲーム」を作りたかったのだ！ 誰もがタダで手に入れて、自由気ままに楽しめるライトな感覚のゲーム。そういう、誰もが楽しんでもらえるプログラムが作りたかった。
シェアウェア作家もフリーウェア作家も似たようなものだと人は思うだろう。甘い。両者は（ぼくの中では）厳密に分けられているのだ。シェアウェアだと、一歩間違えば「こんなソフトで金とろうと思ってんのかよ、おいっ」という批難のまなざしに晒される（ような気がする）。態度はでかいが気は小さいぼくとしては、やっぱりフリーウェア作家という立場のほうが気持ちが楽だ。
そして実際、自分の作ったフリーウェアが多くの人に遊んでもらえるようになると、「フリーウェア作家ってのはこんなに楽しいものか」ということを改めて実感したのだ。とにかく、楽しい。多くの人から感想や意見のメールをもらい、多くの人と接点が生まれた。とかく雑誌や書籍というのは一方通行になりがちだけど、フリーウェアは双方向だ。インターネットのおかげで、多くの人の声がぼくに届く。
それよりもなによりも、「多くの人が自分の作ったソフトを使っている」ということそのものが、なんとも言えず嬉しいものなのだ。――「ああ、今、この瞬間も、世界のどこかで、自分の作ったゲームで遊んでいる人がいるんだなあ…」と思うと、なんともいえない幸せな気持ちになる。これは実際経験してみないとわからないことだと思う。
自分が世の中に必要とされていることを感じるとき。そういう「とき」って、君にはあるだろうか？ 自分が確実に誰かの役にたっている、と感じる瞬間。たかがフリーウェアのゲームで何を大袈裟な、と思うだろう。けれど、自分の作ったプログラムが大勢に遊ばれ、みんなに安らぎを与えることができたとしたら。「とても楽しい時間をありがとう！」と多くの人に思ってもらえたとしたら。
…ほら。君も、「フリーウェア作家になりたい！」と思い始めてきたでしょう？（笑）
■「おちがめ」はわずか150行のコード？
「おちがめ」の開発は、実をいえばその大部分は一週間かそこいらですんでしまった。従来のプログラミングのイメージだと、毎日こつこつとコーディングをして１ヶ月でようやく完成！みたいな雰囲気があるけれど、これはムック版のベースは半日で作ったという代物だ。これを元に２日ほどでほぼ概略を作ってしまった。そして残る数日はデバッグと細かい使い勝手などの調整である。ほぼあがったところでアマクリBBSとホームページでベータ公開をしてバグレポートなどを募集したので、大きなバグはほぼ数日でとれた。
これだけのスピード開発は、REALbasicという開発ソフトに負うところが大きい。これは荒削りだが実に短時間で本格アプリケーションが開発できる。ほんっっと、REALbasicさまさまだ。もしこれがなかったとしたら、「おちがめ」はWindows用にVisual Basicで書かれていたかも知れない（笑）。
この「おちがめ」のプログラムはどれぐらいの規模のものか。――最新の0.0.5では、おちがめの全コードは約1,000行ほど。ベースになったムック版のものは、約150行だった。これを長いと見るかどうかは人それぞれだろうが、HyperCardで全く同様のゲームを作ったとしても、ほぼ同程度のコードは必要となるだろう。コードのほとんどはブロックの描画関係とゲーム自体のアルゴリズムで、他にアンドゥ機能やaboutメニュー、ハイスコアの登録と保存といったものが意外に手間取った。なぜaboutなんぞに手間取るかというと、もちろん隠し機能を組み込んだためだ（笑）。
1,000行といっても、それがずらーっと一覧で出てくるわけではない。REALbasicでは、コードはそれぞれの機能に応じて細かく分けられ、必要なところに分散して書かれる。従って、１つのかたまりとしては、長くともせいぜい100行程度。大半のものは30行以下だ。１つ１つのサブルーチンは、誰でも作れるレベルのものだろう。別に、ぼくが特別REALbasicに詳しいわけではない（いや、本書いたぐらいだから普通の人よかわかるけど（笑））。「おちがめ」のベースを収録したムックは９月末に出る予定なので、興味のある人は見てみるといいだろう。ちゃんとしたパズルゲームにしてはずいぶんとあっさりしたコードなのがきっとわかるはずだ。
■大変なのは公開後のメンテナンス
「おちがめ」開発の本当のポイント（？）は別のところにあった。それは、著作権の問題だ。「おちがめ」は、基本のルールを「さめがめ」から借りている。もちろん、ルールはアレンジしているし、全てのコード類は完全にオリジナルで他から再利用したものは一切ない。けれどフリーウェアとして世界中に流す以上、著作権などで問題が完全にクリアされているという保証がないといけない。
そこで、さめがめ／まきがめの原作者とされる森辺さん、高橋さんの両名と、商品版の著作権保有者である(株)ハドソンに連絡を取り、それぞれ問題がないことを確認してもらった。このあたり、ほとんど気にしないでフリーウェアを作っている人も多いけれど、「ただのソフトだから」といってなんでも許されるわけではない。何かのアレンジであれば、必ず原作者に確認をしておいた方がいい。
そして、完成後は「いかに宣伝するか」だろう。ぼくの場合、「新しもの好きのダウンロード」というページと、(株)ベクターというライブラリソフトに登録した。これだけでもずいぶんと違う。「新しもの好き…」は、登録すればその日の内に掲載され、どっとアクセスが増える。ただし、あっという間に更新されていくので、１週間もするとそこからのアクセスはぐっと落ちるようだ。ベクターのほうは登録までに２週間ぐらいかかるが、一度登録されると長期間に渡ってダウンロードされる。
また、ホームページに専用のコーナーを設けて、そこでブロックデータを募集したり、ハイスコア認定を行なったりしたせいか、けっこうたくさんの人からメールをもらったりして、なかなか楽しい毎日を送らせてもらっている。公開するホームページをどうするかというのも、意外と重要なのかも知れない。何度も定期的に見てみようと思ってもらえるようなページ作りができると、リピーターが増え、口コミやメールコミ（笑）でフリーウェアも広まっていく、ということだろうね。
この他、Macintosh WIREというメールマガジンから「おちがめ」を紹介させて欲しい、と連絡が来たり、MacFanなどの雑誌で取り上げたいという問い合わせが来たりしたので、雑誌などが店頭に並べば、遊んでくれるユーザー数もぐっと増えるだろう。
ちなみに、MacFanのフリーウェアのコーナーを担当しているのは、ぼくの連載の担当者だった（笑）。だからといって、こっちから掲載してくれ！と圧力かけたわけではないぞ（雑誌関係には実は内緒にしていたのだ）。
まだ公開したばかりなので、もうしばらくしてみないと「おちがめ」がどういう方向へ進むかわからないけど、ともかくもこれで晴れて「フリーウェア作家」の仲間入りとなったわけだ。いやー、やっぱいいねフリーウェア作家って（笑）。
エッセー（1999.08）
■シェアウェア作家になりたいっ！
ともかく最後まで完成したソフトがない。HyperCardの頃からいろいろ作ってはきたけれど、きちんとした形でフリーウェアあるいはシェアウェアとしてリリースしたものは一つもない。プログラミングの書籍なんぞを書いている人間として、これはちょっといかんのではないか、許されないのではないか。
そう思い立ったのは、REALbasicの入門書を書き上げてしばらくぶりにぽかんと時間のあいた日のことであった。そこで、入門書を作る過程で制作したいくつかのちっぽけなプログラムの中から、「これはいけそうだ」と思ういくつかのプロジェクトをベースにして１つにまとめあげ、きちんとしたアプリケーションとして完成させようという超安直開発計画がスタートした。この計画により、遂に完成し一般公開に至ったのが、かの有名（になる予定）な「かりぐら博士」である。実に構想２時間制作４日という壮大なるプロジェクトであった。
「かりぐら博士」は、筆タッチのグラフィックソフト。当初は、単に描く図形の太さを機能キーで変化させて筆っぽくみせるというだけのものだったが、たゆまざる機能強化、屋上に屋を重ね続けて、シェアウェアとしては割と面白気なものに仕上がったと自分では思う。筆をベースにしてはいるけれど、「紙」という概念を重視して、いわゆる書道ソフトとはかなり違う使い勝手のものになったんじゃないかな？
さて、「かりぐら博士」を作る時、一番悩んだのは「立派なアプリケーションに見せるにはどうすればいいか」という点だ。立派なアプリケーションというのは、すなわち「立派なMacのソフト」ということだろうと思う。いかにもMacらしいアプリケーションでないと、Macユーザには受け入れられない。
いろいろ検討した結果、次のような点が「Macらしい」ということではないかという結論に達した。
１．メニュー、ウィンドウ、ダイアログなどで全ての機能が整理されていること。まあ、これは当たり前だね。オリジナルのアイコンなども当然サポート。
２．機能キーとの合わせ技で使い勝手が向上すること。意外なことに、全てマウスで操作する方がMacらしくないソフトになる。マウス＋機能キーという操作が一番Macらしく感じられる。
３．カット＆ペーストは当然として、ドラッグ＆ドロップに対応していること。これができるとかなりMacっぽくなる。
４．隠し機能がそれとなくあること。「実はこんなこともできるんだぜ」という部分があるとMacユーザーにウケる（笑）。
５．ユーザーインターフェイスは完全にMacのガイドラインを遵守する。もし少しでも守れないものがあれば、いっそ全く違う形にしてしまうこと。
■クリエータタイプの問題
フリーウェアのアプリケーション開発で注意しておきたいのは、「オリジナルのアイコン」だ。Macのアプリにはみんなオリジナルのアイコンが表示されているけど、これは、実をいうと簡単に作ることができないんだ。なぜかというと、アプリケーションとその作成ファイルにオリジナルアイコンを表示させるためには、オリジナルのクリエータタイプを設定しなければいけないからだ。
よく、フリーウェアなどでオリジナルなアイコンの表示されていないアプリケーションとかがあるよね？ あれは、要するにクリエータタイプを設定していないものなのだ。まあ、自分で作って遊ぶ分にはこれでも全然かまわないと思う。友だちにちょっと配るとか、そのぐらいのものならね。
けれど、フリーウェアやシェアウェアとして広く配付しようと思うなら、クリエータタイプの登録と設定は絶対に不可欠のことだと思って欲しい。広く配付し自由にコピーして使ってもらうものは、それがインストールされたシステムに悪い影響を与える要素は極力避けなければいけないと思う。
が、だからといって、適当なコードを勝手につけてはいけない。なぜって、もし万が一、つけたコードが他のアプリケーションと同じものだったらどうなる？ Macのシステムは両方を同じアプリケーションとみなし、アイコンが化けてしまったり、ファイルをダブルクリックすると全く見当違いのアプリケーションが起動してしまうようになったりするだろう。これは避けないといけない。
ではどうするのかというと、米Apple社のデベロッパー向けのサイトにあるクリエータタイプ登録ページ（http://developer.apple.com/dev/cftype/）にいき、自分のアプリケーションで使うクリエータを登録する必要があるのだ。ぼくも初めて登録をしてみたけれど、Webだと意外に簡単だった。まず検索ページで自分の登録したいコードが既に登録されているかどうかをチェックし、まだ未登録であることを確認したら、登録のフォームに記入して送信するだけだ。
しばらくすると、アップルのデベロッパーサイトから登録確認のメールが届くので、後は登録したクリエータを設定すれば、晴れてオリジナルアイコンが使えるようになる！というわけ。それほど難しくないので、フリーウェアを作る人は挑戦してみよう！
■開発１日、デバッグ１週間…！
今回、開発に使ったのはREALbasicだ。クリップボードによるカット＆ペーストやドラッグ＆ドロップ、標準的なPICTやJPEGの読み書き、印刷といった「Macらしいソフト」に必要な機能は、ほとんどがREALbasicにサポートされている機能のお世話になっている。もし「ToolBoxをコールして作れ」といわれたらお手上げだっただろう。REALbasic様々といったところだ。
ただし、機能が用意されているからといって「簡単に作れる」というわけではない。REALbasicのおかげで基本部分を作るのは１日だったけど、バグ取りには数日を要した。特に、いくつかの機能が組み合わせられた状態になると、どんなバグが発生するかわからない。１つ１つの機能は正常に動いても、それが組み合わせられたときまではなかなか思い至らない。例えば、カット＆ペーストやファイルの保存など１つ１つはきちんと動いたとしても、「カットした直後にペーストして選択を解除せずに保存したらきちんと保存されるか」なんてことは実際に試してみないとわからない。
こうした「複合バグ」というのは、つぶすというより、発見すること自体にかなりの手間がかかる。一番大変だったのが、実は一番基本ともいえる「カット＆ペースト」だった。結局、一部問題を残したまま公開に踏み切らざるを得なかった。
バグ取りと共に時間がかかったのは、インターフェイスの整理だ。メニューの並び方、どの項目をどう整理するか。メニューの名前はどうするか。この機能はどこに整理すべきか、あの機能は別の機能と一緒にすべきではないか。どうするのが一番使いやすいかは実際に試行錯誤していくしかない。Macは「ファイル」と「編集」メニューはほとんど並び順やショートカットが決まっている。このことが、どんなにありがたいことかつくづくと実感した。少なくともこれらについては迷うことがないのだから。
一通りバグもつぶし、いよいよ一般公開だ！となったら、どのような形で公開するかを考えなければいけない。最初、自分のWebサイトで公開すればいいやと思っていたのだけれど、なるべく広く使ってもらえた方がいいので、(株)ベクターというフリーウェア／シェアウェアのライブラリWebサイトに作家登録し、シェアウェアとして公開することにした。当初は冗談半分に料金十億円以下ってことにしようと思ったのだけど、そういうのでは登録してくれないことがわかったので（笑）、この時点できちんとしたシェアウェアとして公開する方向へ路線変更をきめる。
ベクターへの登録を決めたのにはいくつか理由がある。１つには「果たしてアマチュアのシェアウェアに対して、実際にどれだけお金を支払うものなのか」を体験してみたかった、ということがある。いわゆる定番ソフトというようなものであればおそらく相当な数の登録があるのだろうが、その他のごく在り来たりな（かりぐら博士のような）ものに、一体何人がお金を払うものなのか？
ベクターの場合、「シェアレジ」という支払いシステムがある。これはWebからカードでシェアウェア料金を支払うシステムで、ベクターに作家登録していれば利用できる。銀行振り込みなどだと面倒だけど、これなら支払う人はけっこういるのかも知れない、と思ったのだ。ただ、ぼくは一度もこれで支払いをしたことはない。なぜって、カードもってないからね（笑）。
■シェアウェアの登録システムの問題
さて、無事作家登録も行なったのだけど、ちょうどベクターが新しいサービスを始める関係でシェアレジの登録が数日間遅れることがわかった。この間に、新たにやっておかなければいけないことが発生した。それは、「シェアウェアの登録システムの組み込み」だ。
御存じのように、シェアウェアはお金を払って登録すると、キーをメールなどで送ってくる。これを登録すると正式登録したソフトとして使えるようになる。一般に、登録しないとなんらかの機能制限などがあり、解除キーによって全機能が使えるようになることが多い。シェアウェアはフリーコピーのソフトとはいえ、お金をもらう以上は商品だ。となると、お金を払った人にはそれなりのメリットがないと払う意味がない。そこでこうした機能制限が設けられるわけだね。
で、「かりぐら博士」をどうすべきか？でいろいろと悩んだ。いくつかの「ウリ」の機能を使えなくするというのでもいいのだけど、もともとたいしたソフトではないから、面白い部分が使えなくなるとよけいにつまらなくなる（笑）。全部の機能が使えて、しかもお金を払った人にはそれなりにメリットがあるという方法を考えないといけない。――いろいろ検討した末、次のような制限を設けることにした。
１．登録していないと、起動時にaboutダイアログが表れる。これは10秒間はOKボタンが選択できないようになっており、未登録の場合はそれが現れるまで待たなければ先へ進めない。登録すればすぐに起動する。
２．保存、印刷、ドラッグ＆ドロップを行なうと、グラフィックに「かりぐら博士（未登録）」という印が書き込まれる。
３．カット、コピーができない。
要するに、使うのはできるけれど、データを残したり他にもっていこうとすると未登録の刻印がされるようにしたわけだ。まあ、このあたりは割と妥当な線でないかな？と自分では思う。
これらの機能制限と、解除キーの登録システムを組み込むのに丸１日がかかった。システム自体は単純だけど、キーの情報をどのように保存し、チェックするかが一番の問題点だったと思う。プレファレンスファイルに保存したのでは、そのファイルをコピーすれば違法登録（？）できてしまう。まあ、このあたりは企業秘密（笑）だけど、入力されたキーが正しいものかどうかをチェックする部分とそのデータの保存さえうまく作れれば、機能制限自体はそう難しいものではない。それに、たかが千円のシェアウェア使いたさにプログラムを解析するような人間もいないだろうしね。
ただし、登録前と登録後で全ての機能がきちんと思い通りに動くかどうかはよーくチェックしておかないといけない。特に、登録したのにうまく動かない、などということだけは避けなければいけない。そのバグチェックにまたもや数日。「開発とはバグ取りと見つけたり」の心境に至る。
そしてシェアウェア作家登録が再開されてまっ先に申し込みをし、数日後にベクターから契約書が届く。シェアレジは金銭的な契約なので、オンライン申し込みだけではすまず、紙の正式な契約書を交さないといけない。契約書を返送し、数日して確認のメールが届いたら、晴れてシェアレジ登録完了となるわけ。そうしたら、いよいよソフトウェアの登録を申請し、向こうでの審査にパスしたらようやく公開となるわけだ。なかなか面倒ではあるな。
というわけで、ベクターに作家登録し、シェアレジと制作ソフトの登録を行なってから約２週間後、ようやくベクターにて「かりぐら博士」が公開された。はたして、どうなることやら？ いつか、その後の経過についても報告したいと思う。とりあえず、皆さんもインターネットがあればダウンロードして遊んでみて下さいませ。
※このコーナーへのご意見・ご感想はtuyano@mac.comまで！