９６年７月　某Ｍ社製Ｃ＋＋コンパイラを買う
特に「ソフトを作りたい」などという気持ちはまったくなかった。ただＣ＋＋を勉強しておけば人に自慢できるかもしれない、などという容易な考えから生じた行動であった。

まずはＣ＋＋の勉強を始めた。テキストとして使ったのはコンパイラのパッケージに入っていたＣ＋＋入門書（非売品）である。この本はなかなか良くできており、もともとＣを使っていた私はわりとすんなり読めてしまった。
余談になるが、Ｍ社の言語の入門書はとてもよくできている。私はＤＯＳ時代もＭ社のＣコンパイラ（安いやつ）を使っていたのだが、私はやはりそのコンパイラのパッケージに入っていた入門書でＣを学んだのである。

さて、Ｃ＋＋の勉強が終わったら、今度はWINDOWSプログラミングの勉強である。知らない人のために書いておくが、WINアプリの制作はDOSのそれとはかなり様相が異なる。私はそれまでWINアプリの開発はまったくやったことがなかった。とはいえ、別にコンソールベースのアプリを作るのであれば今までと同じで済むのだが、せっかくWINのコンパイラを買ったんだから、やっぱりWINアプリを作ってみたかったのだ。
それで、例によってコンパイラのパッケージに入っていたチュートリアルの本を読み始めたのだが、これがまったくペケ。一応本の通りにやっていけば簡単なソフトを作ることができるのだが、なぜこーするとうまくいくのか、ということがまったくわからないのだ。どうもこの本は、WINアプリ開発経験者を対象とした本だったようなのだ。はっきり言って無謀だったのだ。

しかし入門書を買ってくるのはめんどうだったし、第一金がかかるのでいやだった。しかたがないので見よう見真似でチュートリアルにそって簡単なプログラムを作っていった。しかし・・・なんなんだ、このＭＦＣってのは！　勝手にコード作るんじゃない！！　俺は自分でコードを書きたいんだぁっ！！！　ハア、ハア、ハァ、いや、失礼。

ＭＦＣをご存じだろうか。これはＣ＋＋用のクラスライブラリで、要するにこれを使えば簡単にソフトを開発できるといったシロモノなのだが、WINプログラミングの経験がない者にとっては実にやっかいなものである。なにせメッセージループも知らない（＝WINアプリがどのように動いているのか知らない）者に、メッセージループを隠してしまうＭＦＣでのプログラミングを教えるのは、完全に毒である。経験者にとっては、ある程度コードを自動生成してくれたり、WINプログラムの決まりごとを勝手にやってくれるのでありがたいのかもしれないが、初心者にはサッパリである。しかも、たのみの綱のオンラインヘルプもまったく役に立たなかった（私は今でもメッセージハンドラの構造を知らない）。これはもう、ダメでしょう。

それでも私はＭＦＣでいくつか簡単なプログラムを作ってみた。その結果、とりあえずＭＦＣを使うのはやめた方が良いということが分かった。まずはWINアプリの構造をある程度把握することが重要なのだ（今にして思えば実に当たり前）。というわけで、書店へ出陣である。書店にはその手の入門書がいくつか置いてあった。ここで重要なのは、コンパイラ名をうたった本には手を出してはいけないということである。本来Ｃ、Ｃ＋＋は実に移植性が高く、大抵のコードはどのようなコンパイラでもコンパイルすることができる。これはWINのコンパイラでも同じで、コンパイラ特有の機能を使わないかぎりどんなコンパイラを使おうが問題ないはずなのだ（ただし、生成されるコードの質はコンパイラに依存する）。つまり、特定のコンパイラを指定している本というのは、そのコンパイラ特有の機能を用いてのプログラミングを解説しているわけである。WINアプリ開発初心者は、まずWINアプリがどういう仕組みで動いているのか知らなければならないのだから、コンパイラに依存するような事柄に頭を突っ込んでるヒマはないのだ。てなわけで、私はタイトルにコンパイラ名が入っていない本を購入した。

この本が実に目的通りの本で、メッセージループやらウィンドウの考え方、作り方やら基本的なことを丁寧に教えてくれる。そう、私はこれを求めていたのだあぁっっ！！

私はこの本でやっとWINアプリの本質を知ることができた。それまで真っ暗だった目の前が、一気に明るくなっていくような気がした。それと同時に、それまでの苦労がバカのように思えてきた。この怒りをどこにぶつければ良いのか！？

私がWINアプリの開発を行なう上でもっとも問題となるのは、慢性的な資料不足である。とにかく資料がないのだ。一応コンパイラのパッケージにはWIN32APIのガイドブックみたいなのが入っていたのだが、索引がないのが致命的である。どうやって必要なAPIをさがせっちゅうんじゃい！　しかも、掲載されているAPIが中途半端だし、説明もよくわからないものが多い。これではあまり役にたたん。次にコンパイラのオンラインヘルプだが、これはもともとＭＦＣに関するヘルプらしく、WIN32APIに関してはあまり説明がない。こんなのありか？！　買ってきた本は、入門書だけあって基本的なことしか書いていない。だからと言って分厚い専門書を買う気にもなれない（馬鹿高い上に失敗する可能性が高い）。これはなんとかならんのか！？

まあ、こんなことを言っていてもしかたなうので、先に進もう。
やっとまともにプログラミングできそうになったので、私は何かある程度大きなプログラムを作りたくなった。「ある程度大きなプログラム」−−市販のソフトレベルまではいかなくても、「使える」ソフトである。ちょっと無謀な感じもしたが、ひとつ大きなものを作ってしまえば、他のプログラムを作るときに応用がきくのだ。さて、何を作るか。ゲームだ。私はＢＡＳＩＣ時代から、「プログラムを作る」イコール「ゲームを作る」だったのだ。ゲームを作って自分で遊ぶのだ（なんか暗いな・・）。では、どんなゲームを作るか。麻雀だ。

なぜ麻雀なのか？　それは私が技術よりの人間だからである。
フリーソフトの作者には２種類ある。ひとつは「ソフトを作りたいから作る」人、もうひとつは「プログラムを書きたいから作る」人、である。前者の人にとってプログラミングは飽くまで手段であるのに対して、後者の人にとってはプログラミングそれ自体が目的なのである。私はまぎれもなく後者である。
私にとって「見た目」だの「小細工」だのはどうだっていいことなのだ。要は自分で納得できるほど「すごい」プログラムを作って、自己満足できればよいのである。

麻雀ゲームというのは、見た目ほど簡単に作れるものではない。たとえば点数計算のプログラムを考えただけでも、手牌をメンツに分けて役を当てはめて符計算を行なって、しかもメンツの分け方が幾つもある場合はそれぞれについて計算してもっとも点数の高いパターンを見つけなければならない。これだけでも結構大変である。

しかし、大変だからこそ、作りがいがあるしやる価値もある（＝自己満足できる）。だから麻雀ゲームを選んだ。対戦相手のアルゴリズムを考えるのだって、あもしろいと思いませんか？

もちろん、そう簡単には作れないと思っていた。しかし、途中で行き詰まってもそれはそれで構わないと思っていた。何よりこの計画（？）の第１目的は「ＷＩＮプログラミングに慣れる」ことなのだから。でも、多分なんとかなるんじゃないか、とも思っていたりした。

９６年１２月　制作開始
というわけで、年末になって作り始めた。いや、だからどうだってことはないんだけど・・・
さて、どこから作るか。難しいところから作ろう。難しいところをどうやって作り上げるか、ということに頭を巡らすのは、パズルゲームのように楽しい。それこそがプログラミングの楽しさなのである。では、どの部分が難しそうか？　点数計算、そして対戦相手のアルゴリズムだろう。では点数計算である。対戦相手の方は、ゲームの基盤がある程度できてないとどうにもならないので後回しにせざるを得ない。

てなわけで、点数計算のルーチンができた。そこで、ゲームの基盤をプロンプトベースで作っていった。というのも、ウィンドウベースで作っていくと、ユーザーインターフェースを作るのが面倒になってしまうからだ。だから、画面出力は文字だけで、入力はキーボードオンリーのシンプルなプログラムを作っていった。このときはまだ対戦相手のルーチンがなかったので、全てのメンツノ操作をユーザーがおこなうものであった。

なんだか、一気に飛ばしたような感じだが、この間にもいろいろ試行錯誤があった。ただ、それらをウダウダと書いていってもつまらないので書かないだけである。

まあ、なんだかんだで土台ができた。次は対戦相手である。

ついでなので、ここで「まうじゃん」の対戦相手のアルゴリズムについてちょっと触れておこうと思う。
実は「まうじゃん」の対戦相手のアルゴリズムは、わりとシンプルにできている。アルゴリズムを簡単に説明すると、まず手牌の”良さ”を評価する評価関数を設定する。捨て牌に関しては、手牌の内のすべての牌に対して、その牌を捨てたときの手牌を評価して、もっとも評価の高い捨て牌を捨てるのである。はっきり言って、マシンパワーにものを言わせた力技であるが、もっとも簡単で且つ確実な方法である。ペンティアムには軽い仕事だろう。
「まうじゃん」には対戦相手が複数いるが、評価関数を変えたり、鳴き方を変えたり、リーチのかけ方を変えたりはしているが、基本的にすべてこのアルゴリズムで動いている。実はプログラムは、対戦相手ごとにアルゴリズムを設定できるように作られているのだが、面倒なので流用して使っているのだ。困ったものだ。

話はもとに戻って、まずはひとつだけつくった。これがわりとうまく動いたので、今度はウィンドウベースに変えていった。

プロンプトベースで作ったプログラムをウィンドウベースに変えるのは、一般的に大変な作業だといわれる。というのも、ウィンドウベースのプログラムは、基本的にイベント駆動型にしなければならないからである。どういうことかというと、ウィンドウシステムでは、アプリケーションがどのような状態であっても、終了ボタンが押されたら即座に終了しなければならないし、最小化ボタンが押されたら即座に最小化しなければならない、つまり、いかなるときでも、ユーザーの要求に即座に反応しなければならないのである。そのため、考えられる全ての要求（イベント）に対する応答を、あらかじめ決めておかなければならない。これがイベント駆動型のプログラミングである。それに対し、コンピュータにやらせることを順に書いていくのを、手続き型プログラミングという。プロンプトベースのプログラムでは、外からの要求がかなり限られているため、手続き型のプログラムにするのが普通である。

それまで作っていった「まうじゃん」の土台のプログラムも、バリバリの手続き型プログラムであった。だが、ウィンドウベースに移行するのは、それほど難しくはなかった（面倒だったけど）。

いくらウィンドウズがイベント駆動型を基本としているといっても、そのイベント駆動の仕組みを作っているのは、やはり手続き型のプログラムだからである。これは当然のことで、現在多く使用されているコンピュータ（ノイマン型コンピュータ）は、本来手続き型のプログラムを動かすモノだからである（これがコンピュータの原点とも言える）。つまり、ウィンドウズが”どのように”イベント駆動型のマネをしているが分かれば、あとはどうとでもなるのである。

で、あとは対戦相手を増やしたり、細かいところを調整していった。
実は、このころのプログラムはWIN32sでもある程度動いていたのだが、ウチのWIN3.1マシンがあまりにも貧弱なのでサポートするのはやめた。そのかわりDirectSoundを導入して、声がでるようにした。

９７年４月　ver.0.80リリース
というわけで、初リリースは４月（だったと思う）。今から考えると、バグだらけだった・・・。
このころは、まだホームページを持っていなかったので、VectorSoftwarePACKのサイトに登録した。というのも、ここに登録すると、オンラインソフトをたくさん収録したＣＤ−ＲＯＭ誌PACKforWIN（買うと何千円もする）がタダでもらえるということを知っていたからだ。なんか、目的がずれているような気もするが、もらえるものはもらっておくのだ。

とまぁ、この後も何回かバージョンアップして現在に至る。その間、様々な人から感想や意見が送られてきて、とてもうれしかったことを付け加えておく。

ところで、これ全部読んだ人、相当なヒマ人ですね。