2016年06月の日記です

目次

06日 テトリス完成(1984)
07日 アラン・チューリング命日(1954)、ドナルド・デービス誕生日(1924)
09日 8086 発表日(1978)
16日 Jewels 2017
16日 Scratch の舞台裏
20日 顔文字 (^_^) の生まれた日(1986)
21日 コンピューターが初めてプログラムを実行した日(1948)
24日 【訃報】長谷川五郎さん
30日 Comet


テトリス完成(1984)  2016-06-06 13:52:45  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日は、テトリスが完成した日。


1984年の今日、最初のバージョンが完成した…のだそうです。

最初のバージョンは、ソ連製コンピューター、エレクトロニカ60の上で動いた、白黒のものでした。

エレクトロニカ60 は PDP-11 のクローン。


しかし、どうも証拠らしいものが見当たらない。

25周年の際にロイターがそう伝えた、という記事があって、それがほぼ唯一のソース。



ソ連の計画経済の中で、「仕事」の一環で作られたものなので、作業日誌でもつけていた可能性はあります。

でも、心理学の実験で使う予定のプログラムだから、必要ならいつでも手を加えたはず。

特定の日に「完成」なんて、決められないように思います。


だから多分、パジトノフがそう言ってたよ、って程度の世間話。

まぁ、1984年のこの頃に最初のバージョンが作られた、というのは事実だと思います。




当時は「対共産圏輸出統制委員会」(ココム)が存在していて、共産圏に 16bit 機は輸出できません。

ファミコンは輸出できるけど、メガドライブはだめ、なんて話もあったし、ソ連で MSX が普及した理由も同じ。


でも、翌年 1985年には、IBM-PC に移植されます。パジトノフはちゃんと IBM-PC を持っていた。


そして、夏ごろに知人にこのコピーをあげたら、いつの間にかヨーロッパ中の IBM-PC で遊ばれていた。



…ここからの話が、驚くほど壮大。

秘密のベールに包まれたソ連と、イギリスで暗躍するメディア王…ユダヤ人で、家族を虐殺された苦い過去を持つ男が強大な力をふるいます。


ATARI と、当時親会社だったナムコも絡み、セガと任天堂のテトリス権利問題も勃発する。


その一方で、日本の BPS 社長は孤独な戦いを始める。

彼は作者であるパジトノフと交流し、信頼を得ます。

ソ連政府も彼を信じて一計を案じる。



…そして、事態は急展開を遂げます。

ソ連の崩壊。メディア王の没落と、謎の多い死…



最後はパジトノフの手にテトリスの権利が戻ってくる。

壮大で、ハッピーエンドな物語。


くわしい話は、パジトノフの誕生日に書いていますので、そちらをご覧ください。




この話、すでにBBC作成のドキュメンタリーはあるのだけど、映画化の話も出ているみたい。


リンクした BBC のドキュメンタリーは、英語力がないので僕は見られていません。

映画化した際には、字幕でいいから日本語版を作ってほしい。ぜひ見たい。



テトリスの映画、と言っても SF映画とは違いますよ!

(これはこれで興味あるのだけど)




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

別年同日の日記

02年 晴天の霹靂

02年 Home Brew

04年 そう来るとは思わなかった

04年 77の手習い

04年 怪我

11年 PC購入

13年 次女のぬいぐるみ

14年 フェルディナント・ブラウンの誕生日

17年 キャベツ料理

18年 凄腕プログラマ


申し訳ありませんが、現在意見投稿をできない状態にしています

アラン・チューリング命日(1954)、ドナルド・デービス誕生日(1924)  2016-06-07 14:34:11  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日は、アラン・チューリングの命日(1954)で、ドナルド・デービスの誕生日(1924)


この二人、関係が深いので一緒に紹介しましょう。

といっても、チューリングは誕生日の時に詳しく書いている。今日はデービスを中心とします。



チューリングはコンピューターの基礎概念を作った、と言われるのですが、計算機と概念はどちらが先か、微妙なところです。


計算機の自動化がある程度進められた時代背景があり、そこで「計算するとはどういうことか」を、仮想的な計算機を用いて説明しただけ。

この結果、どういう計算機を作れば汎用性が高いかが示され、それを目指して実際の計算機が作られていく…という流れ。


すでに職人芸で作られていたものに、学問的なお墨付きを与えたとでも言いましょうか。

チューリングマシン(1936)は重要な概念ではありましたが、「そのアイディアを基礎として計算機が作られた」わけではないのです。


#ツーゼZ1の開発は1935年から、ABC の開発は 1937年から。

 タイガー計算機は 1931年にはすでにあったし、その原型となるオドナー計算機は1874年に公表されている。




さて、時代的に計算機が作られ始めていましたから、チューリング自身、コンピューターに関する仕事もやっています。


1946年2月、チューリングはイギリス国立物理学研究所 (NPL)に、コンピューター製造計画の論文を提出します。

Automatic Computing Engine … ACE と名付けられたそのコンピューターは、人工知能を目指す計画でした。


これは、8月の ENIAC 公開よりも前に計画されたことでした。

もっとも、ENIAC は作成期間も長く、噂くらいは耳に入っていたのではないかと思いますが。



ACE は国家プロジェクトとなり、チューリングはその最高責任者でした。


そして、計画参加者の中にドナルド・デービスがいました。


デービスは、チューリングがチューリングマシンを想定した論文に、重要な誤りがあることを指摘しました。


詳細は、残念ながら僕は知りません。

「チューリングマシン」に与えるアルゴリズムによってあらゆる数が計算できることを示す部分で、アルゴリズムに穴があったようです。

「世界初のバグ」とも呼ばれています。


多少の穴があっても、そこは論文の本筋ではありませんが、「最高責任者」としての権威が揺らぎます。

重箱の隅をつつくようなことを言うデービスに対して、チューリングは不快感を示しました。



しかし、これは二人の性格の違いを示す、重要なエピソードのように思います。




ACE プロジェクトは、計算機にとって重要な「本質」を追い求めすぎ、肥大化します。

しかし、まだ当時の技術では、そんなに構想が肥大化したものは作れないのでした。


プロジェクトは頓挫しました。

チューリングは失望してプロジェクトを去りました。


しかし、これは国家プロジェクトです。止めるわけにいきません。

「作成技術」という現実を見ずに夢を膨らませて、うまくいかずに逃げ出したチューリングは無責任です。


その後、ジェームズ・ウィルキンソンが ACE プロジェクトを引き継ぎ、規模を縮小した「Pilot ACE」を作り上げます。


ドナルド・デービスは、Pilot ACE のプログラムを担当しました。

天才の論文に対しバグを指摘し、厳密さを重視する彼は、適役だったように思います。


デービスは、ロンドンの交通状況シミュレーションなどのプログラムを作っています。


Pilot ACE は後に量産され、1950年代に一番売れたコンピューターとなったそうです。




1950年ごろ、MIT でタイムシェアリング・システムが開発されます。

これにより、コンピューターに電話回線などでテレタイプを接続し、「時間貸し」ができるようになります。


また、コンピューター同士のネットワークも考案されていました。

コンピューター A にコンピューター B が接続するときは、時間貸しの端末と同じように、電話線を使って接続します。

A と C が接続するためにも電話線が必要で、B と C が接続するのにも電話線が必要です。


コンピューターがこのまま増えると、必要な線はどんどん増えることが予想されました。

コンピューター自体が高価なものでしたが、通信コストが馬鹿になりません。


しかも、これらの回線のほとんどは、「いつ通信があるかわからないので接続している」というだけで、ほとんどの時間、なんのデータも流れていないのです。


多数のコンピューターを、もっと少ない回線で結ぶことは出来ないか?

回線の利用効率をもっと高めることは出来ないか?


ドナルド・デービスはこの方法を考えます。



彼がたどり着いたのは、「パケット通信」と名付けた方法でした。

先の例でいえば、3台のコンピューター A B C が通信するには、 A-B 間、A-C 間、B-C 間の3つの回線が必要でした。


でも、A と C は、ともに B に接続しています。A-B と B-C の2つがあれば、B を介して A から C に通信ができるはずです。


それまでは、電話線の先にあるのが1台のコンピューターだったので、通信したいデータだけを送っていました。

でも、パケット通信では、一定のサイズのデータに区切り、それぞれのデータに「通信相手」を明記して送ります。


A から C に送るとき、途中で B が受け取りますが「C 宛」と書かれたデータはそのまま C に向けて再送信します。

もちろん、「B 宛」と書かれていれば受け取ります。


コンピューターが3台なら、3つの回線が2つに減っただけです。

でも、もっと多数のコンピューターがあったら…?


直接通信だと、10台で45本の回線が必要になります。

パケット通信なら、9本で十分です。



この通信方法は、現在のインターネット技術の基礎となっています。

ドナルド・デービスは、「パケット通信の父」なのです。


詳しい話はポール・バランの誕生日に書いていますので、そちらも読んでみてください。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

別年同日の日記

02年 カエル


申し訳ありませんが、現在意見投稿をできない状態にしています

8086 発表日(1978)  2016-06-09 12:01:30  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日は 8086 の発表日(1978)。


16bit 時代の覇者です。

僕としては、1980年代はまだ 8bit の時代だったイメージがあるので、70年代末にはすでに開発されていた、ということが驚きです。


8bit 時代の覇者は Z80 。

これはインテルの 8080 をベースに改良されたものですが、インテルからスピンオフした技術者が作ったザイログ社のものでした。


インテルとしては、あくまでも 8080 の「上位互換プロセッサ」として 8086 を作成します。




上位互換とはいっても、バイナリレベルでの互換はありません。


1978年の時点では、まだパソコンは普及しておらず、ソフト資産もないからね。

自分が作ったプログラムを、自分が作ったのだから理解していることを前提に、「ちょっと改良したら動く」で十分だった。


8bit から 16bit になっているのだから全然違うのですが、アセンブラのソースプログラムがあれば、レジスタ名や命令などを一括置換して再アセンブルすれば、8割がた動く、というあたりを目標に設計されたようです。

現実的な落としどころのように思います。


8bit CPU と互換性を持たせるため、メモリの構造に特徴があります。


8bit CPU では、8bit のレジスタを2本くっつけた 16bit のレジスタで、メモリアドレスを指定するのが普通でした。

この方法だと、64KByte のメモリ空間を持つことができます。


そして、8086 でも、16bit のアドレスレジスタでアドレスを指定します。

ただし、別のレジスタで「64KByte の起点となるアドレス」を指定できました。


これで、1MByte のメモリ空間の中から、任意の 64KByte を自由にアクセスできる、という構造を作り出しています。

ベースアドレスはプログラム中で変更可能なので、多少工夫すれば 64KByte を超えるデータだって扱えます。


8bit 資産も引き継げますし、16bit らしい大容量も扱える。

非常にうまい方法でした。




1978年の時点ではメモリも高価で、64KByte を超えるようなメモリを搭載する、ということがあまり現実的ではありませんでした。


1981年に発売された初代 IBM-PC は、16KByte のメモリしか搭載していません。


でも、あっという間にメモリは安くなり、大容量を搭載できるようになります。

90年代に入ると、64KByte 以上のメモリに連続アクセスできない、というのは足枷にすぎなくなります。


…もっとも、これはインテルだけの責任ではありません。



1985年には、後継の CPU 80386 が作られています。

8086 と、その後継の 80186、80286 までは、互換性を持つ 16bit CPU でした。


しかし、80386 は新規設計の 32bit CPU で、8086 互換モード「も」持っています。

互換モードでは、単に高速な 16bit CPU として動きます。


本来の能力を発揮すれば、メモリ空間も 4GB の連続アクセスが可能となりました。


インテルとしては、時代の要求に応えたものは作った。

これを使ってくれれば問題解決、というわけです。



でも、ここで「互換性」の問題が現れます。

8080 から 8086 に移行した時は、互換性とは「移植しやすければよい」という程度のものです。


しかし、時代は変わり、ソフトは買ってくるものになりました。

今までお金を払ったソフトを捨てないと 80386 には移行できないのです。



80386 を搭載したマシンは徐々に発売されていきますが、過去の資産を活かすため、単に高速な 8086 として使われていました。




ここで登場するのが Windows 。


3.0 の登場を覚えている人はいるでしょうか?

サポートする CPU 80286 以上でした。つまり、3.0 はまだ「16bit」で、8086 の呪縛を引きずっています。



アプリケーションを作るにも、16bit の呪縛が残っています。

だったら、Windows よりも普及している MS-DOS 用に作ったほうが、多くの人に使ってもらえるだけマシです。



それが、3.1 になった時に、80286 のサポートを打ち切り、80386 専用になります。

見た目はあまり変わらないのですが、80386 の性能を活かせる OS として作り直されていました。

アプリケーションを作りやすくなったのです。



#勘違いがありました。指摘感謝。

 僕は日本語版しか使ったことが無かったのですが、3.1が386以降専用となったのは、日本語版だけだそうです。

 英語版では、8086で動かなくなったものの、80286でもまだ動きました。



ところで、Windows 3.1 は、まず MS-DOS を起動し、MS-DOS 上から Windows 3.1 を起動する、という構成でした。

内部に MS-DOS を持っているのです。


これを利用し、Windows 3.1 のアプリケーションの一つとして、仮想的な MS-DOS を実行することができました。

互換性は完全ではありませんでしたが、最悪の場合、Windows を終了すれば MS-DOS に戻れます。


先に書いた「過去の資産」問題への対策もできているのです。


このために、Windows 3.1 は大ヒット。

見た目の上ではあまり変わりませんでしたし、バージョン番号も 0.1 しか違いません。

しかし、やっと 8086 の古い設計から逃れられるようになったのです。




現在は、8086系統の CPU は、さらに改良されて 64bit になっています。

とはいえ、基本的に互換性を確保しながらの改良なので、設計が古いところは多数あります。


メモリが貴重だった時代、命令の必要性に応じて、データの量を可変にする「可変長命令」はいいアイディアでした。


しかし、現在となっては可変長命令は命令の取り込みをややこしくし、実行速度を低下させます。

Intel の CPU では多くの工夫によって速度低下を防いでいますが、「互換性」さえ気にしなければもっと簡単に速くできるのです。


命令セットも、時代に合わせてつぎはぎに拡張を繰り返した結果、複雑怪奇になっています。



スマホなどでは、過去の資産がないところから始まったため、8086 系の CPU を使う理由もなく、主に ARM が使用されます。

設計が簡素で強力…だったから使われ始めたのですが、こちらもすでに拡張を繰り返し、複雑化しつつあります。




8086 の設計は、すでに 40年近くも前のものです。

今のプロセッサに 8086 互換機能はないのですが、基本部分はバイナリ互換性を保ちながら拡張されてきました。


2016.8.3追記


まだ完全互換を取り続けていました。指摘くださった方、ありがとうございます。

言い訳ついでに説明すると、リアルモードと呼ばれる動作モードに入ると、8086完全互換になります。

ただ、この機能を使うと最新の CPU の機能(たとえば膨大なメモリ空間)も使えなくなるため、普通は仮想 86モードを使用します。


仮想 86モードは、基本部分は互換なのですが、完全互換ではありません。

Windows では、MS-DOS のソフト資産を仮想 86 モードで動かし、完全互換でない部分に関しては、ソフトウェアで違いを吸収していました。


しかし、WindowsNT が導入されたとき、この「ソフトウェアによる 8086 互換の努力」は無くなりました。

Windows 95 系列との互換性のほうが重要になったためです。


このときに、すでに完全互換ではない、という記事を読んだ記憶が、最近の CPU は 8086完全互換ではないのか、というふうに記憶の中に残っていたようです。


現在の Core i7 でも、8086互換のリアルモードは残っていますので、8086 互換機能はまだあります。


そして、8086系列は今もまだ主流であり続けています。

おそらく一番「長寿」な CPU アーキテクチャのように思います。





公開後すぐに追記

IBMのメインフレームのほうが長く互換性保ってますよ、と教えていただきました。


メインフレームは使ったことないので不勉強でした。

IBM なんだから、途中で POWER に移行しているのだとばかり思っていた。


1年前の記事ですがIBM のメインフレームが50年間互換性を保証している、と書かれていますね。


インテルの CPU と同じように改良・拡張もあるのだろうけど、PCほど激しい競争のある世界でもないから、それほど汚いことにはなっていないのかな…と予想。


インテルの CPU は、誰もが言うけど汚い。

ただ、どんなに罵られようとも、実用性が高いのも事実です。


汚くなっているから設計コストだって馬鹿にならないだろうし、事実インテルは過去に何度も「新設計の CPU に移行」を試みては失敗しているので、もうやめたい気持ちだって大きいのでしょう。


それでも続けているのは、ある意味立派だと思います。



#マイクロソフトも過去製品のサポートを続けていて立派だと思っていたのだけど、Win10 への移行で「もうサポートしたくない」という態度をはっきりさせた。


 インテルもいつか「非互換です。嫌なら使うな」という態度をとるかもしれない。

 というか、一度そういう態度をとったら AMD に美味しいところかっさらわれて、慌てて追いかけたのだけど。


 いつかインテルが互換性を取るのに限界を感じた時、混乱なく事態を収拾できるだろうか?


▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

別年同日の日記

02年 最終戦略

05年 spring has come

05年 3ヶ月点検

13年 WEB上でのドット絵の拡大

17年 計算機の同人誌

19年 新マシンセットアップ中

23年 大学時代の夢日記


申し訳ありませんが、現在意見投稿をできない状態にしています

あきよし】 ところで、間違えていたことは申し訳ないとお詫びしつつ、間違った駄文はこれからもどんどん書く予定です。
書かないことには何も始まらないから
勉強は精進しますが、限界もありますし、間違い指摘があれば素直に受け入れます。
 (2016-08-03 12:11:31)

あきよし】 気付くのが遅れましたが、各種指摘ありがとうございます。
80386サポートは、当時僕が98版しか知らなかったための勘違いでした。
また、8086互換性について、仮想86モードが完全互換ではないことと混同がありました。
以上、記事中にも追記しています。
 (2016-08-03 11:38:28)

【名無し】 Windows 3.1は80286もサポートしています。80386以上専用になったのはMSKKが販売していた日本語版では? (2016-06-19 00:50:35)

【6809】 初めてコメントを書かせて頂きます。他の方も軽く指摘していますが,思い込みや知識不足によると思われる誤りが散見されます。 多くの誤りがあるのでいちいち指摘はしませんがせっかくこうして書かれるのであればx86とWindowsについてきちんと勉強をして書き直しをされたらいかがでしょうか。このままではちょっと恥ずかしいです。 (2016-06-17 21:39:43)

【G-SHOES】 あれ、今のプロセッサにも8086の互換機能はあると思いますよ。 (2016-06-10 09:57:13)

あきよし】 メインフレームはあまり知らなかったのですが、互換性保ち続けていたのですね。
IBMだから、POWERに変わっているのだと思っていた。不勉強でした。
http://japan.zdnet.com/article/35065282/
 (2016-06-09 13:17:52)

【m.ukai】 長寿なのはIBMメインフレームでは? s/360から現役のzまで互換を保ちつつ拡張されてますよね。(s/360 と 370 の互換の程度は実は知らないんですが s/370 以降は上位互換) (2016-06-09 13:13:27)

Jewels 2017  2016-06-16 18:46:35  コンピュータ

▲目次へ ⇒この記事のURL

子供が Scratch を楽しんでいる。


時々プログラムの処理について相談されるのだけど、だんだん質問が高度になってきた。

以前は、プログラム一般の話で答えられたのだけど、だんだん処理系依存の話が混ざり始めたのだ。


じゃぁ、ちょっと自分も詳しく知っておかないといけないな、と思っていた。



それとは別に、IchigoJam で何か作ってみようと思った。

1KByte しかフリーエリアがないから、小さなゲームがいい。


ちょっと考えて、テトリスを組んでみようと思った。

途中まで作っていたのだけど、中断。いろんな都合で IchigoJam をつかえる日は限られてしまう。



上記二つのものがくっついて、Scratch でテトリスを作ってみよう、と思った。

でも、テトリスは案外作っている人が多いんだよね。今更作っても面白くない。

じゃぁ、コラムスだ。



というわけで、作ったものがこちら。


スマホの人は見られないかもしれない。

Scratch は Flash で動いているから。



最初に限り、画面クリックだけでゲームが始まる。

ゲームオーバー後の再ゲームは、上にある「旗」のマークをクリックする。


プロジェクトページに行けば、画面拡大機能も使える。

Scratch のアカウント持っている人は、下にある星マークとハートマークも押しておくといいだろう(笑)



矢印キーとスペースキーで操作できる。

同じ色を3つ並べると消える。


それ以上の説明はいらないと思う。



「コラムス」はセガの登録商標だと思うので、名前を Jewels にしてある。

この名前で作られたコラムス類似ゲームは多い。


ベースはコラムス 97 だ。Jewels 2017 とした。

まだ 2016 年だけど、構うものか。コラムス 97 だって発売は 1996 年だ。


今後も手を加えるかもしれないけど、とりあえず現時点では、ゲームのコア部分しか入っていない。



BGM も効果音も、 Scratch で最初から使えるサンプル曲からそれらしいものを選んだ。

グラフィックは GARNET という、宝石をレンダリングする専用フリーソフトを使わせてもらった。


タイトルも違うし、コラムス 97 からもらってきたものは、ルール以外には何もない。

そして、ルールは著作権を主張できないから、類似物を作っても問題ない



Scratch は一度公開してしまうと、作業中も公開しっぱなしになってしまう。

もし動かなかったら作業中だと思ってほしい。




というわけで、この日記はゲームの紹介のみ。


これを作る間に、Scratch の動作が理解できた。

そのことは次の日記で。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

Unity【日記 18/06/25】

Unity【日記 18/06/25】

7 Billion Humans【日記 18/11/09】

【訃報】シーモア・パパート【日記 16/08/03】

【訃報】シーモア・パパート【日記 16/08/03】

別年同日の日記

02年 ロールパン

05年 成長記録

05年 バードウォッチング

10年 料理

11年 続々・新PCのこと

13年 雨のお散歩

15年 アスペルガー症候群


申し訳ありませんが、現在意見投稿をできない状態にしています

Scratch の舞台裏  2016-06-16 19:00:22  コンピュータ

▲目次へ ⇒この記事のURL

先の予告通り、Scratch の技術話。


Scratch は初心者向けの言語だけど、この話は初心者向けではない。

だって、Scratch の上でプログラムをする話ではなくて、Scratch というプログラムの話だから。


そういうわけで、Cやアセンブラでゲームなどを作ったことがある人を対象にさせてもらう。


Scratch というプログラムの話、といっても、いろいろ実験してその動作から推察しただけだ。

Scratch 処理系のプログラムを読んだわけではないので、間違えていたら申し訳ない。



▼並列動作と垂直同期待ち


Scratch は、多数のプログラムを書いて、それらが並列に実行される。


多数のキャラクターを動かすゲームでも、キャラクターごとのプログラムを個別に作るだけでよい。

これが、ゲーム作成には非常に役立つ。


キャラクターは動き続けるのだから、永久ループ(もしくは、ゲームオーバーになるまでの長期ループ)の中にプログラムを書くだけでいい。


これで、不思議と思い通りに動いてくれる。

たくさんのプログラムが同時に動くだけでなく、よく気を付けてみると、動くプログラムの数に関わらず一定の速度を保っている。


並列動作と、垂直同期待ちが自然な形で言語仕様に組み込まれているのだ。

しかし、永久ループなのにどうやって並列実行し、表示速度を保っているのだろう?




実は、Scratch はイベントドリブンマルチタスクだ。

MacOS 9 以前とか、Windows 3.1 の頃とかがそうだった。


OSによって稼働時間を与えられたプログラムは、ある程度の時間動いたのち、処理をOSに戻さなくてはならない。

処理を戻されたOSは、次のプログラムを呼び出す。これを繰り返せば多くのプログラムが並列動作できる。


「クリックされた」とか「キーが押された」など、特別な事象は「イベント」という形で呼び出される。

通常の時間割り当てと違い、特別なことが起きたので、それに対応するプログラムを書く必要がある。


逆にいえば、通常の動作の中ではこれらを考慮しなくてよくなり、プログラムがすっきり書ける。




Scratch では、「ループの末尾」で処理をシステムに返している。

次に処理の割り当て時間が回ってきたときには、もちろんその続きから実行される。


#2016.6.20 追記:

 ループ末尾でシステムに処理を返すのは、「ループ内に画面を変更する処理がある場合」に限られるようです。

 詳細はこの日記の末尾に。



メッセージの送信という「イベント」は、内部的にはキューに入れられる。

この操作自体は即座に行われるが、実際のイベント呼び出しは、システムに処理を返した後で行われる。


クローンの生成も、変数領域などのコピーは即座に行われるが、そのクローンに「クローンされた」というイベントを送るのはシステムに処理を返した後だ。



すべてのプログラムを動かし、イベントも処理し終わると、普通の OS なら、また最初からプログラムの実行を開始する。

それが一番時間を無駄にしないからね。


でも、Scratch は「垂直同期待ち」に入る。

全部のキャラが動いた後は、垂直同期待ち。

(実際には垂直同期ではないのだけど、ここではそう呼ばせてもらう)


コンピューターを「計算機」と考えるなら、待ち時間は無駄となる。

でも、ゲームを作ったりアニメを作ったりしたいのなら、この動作は非常に理に適っている。



▼高速化


ゲーム中に、大量のデータ処理が必要でループを回すと、上に書いたように垂直同期待ちを入れられてしまう。

データ処理をゲーム進行と並列に行う…というのでは動作がおかしくなってしまうだろう。


並列実行を前提としたプログラム環境…たとえば、Java なんかでは、一定の操作の中に割り込みを入れないことを保証する記述方法がある。

共有している変数を複雑な方法で書き換えている最中に、別のプログラムが関連する変数にアクセスするようでは困るからだ。


そして、Scratch にも割り込まれないことを保証する記述方法がある。

指定された範囲のプログラムには、ループ末尾で垂直同期が入らなくなる。これで大量のデータ処理が瞬時にできる。



この指定には「ブロックを作る」を使う。

ブロックとは、Scratch の命令のことだ。

自分で命令を作れる。つまり、サブルーチンのことだ。


ブロック作成時にはいろいろなオプションがあるのだけど、「画面を再描画せずに実行する」にチェックを入れる。

再描画とは、つまり垂直同期だ。ブロック中には垂直同期待ちをしない、と指定できる。



以上。方法としては非常に簡単だ。

以降の説明では、この技法を「高速化」と呼ばせてもらう。



注意点として、垂直同期待ちをしない、というのはシステムに処理を戻さない、という意味なので、イベントも発生しない、ということを忘れてはならない。


メッセージを送ったり、クローンを生成することは出来る。

でも、ブロックの中にいる限り、そのメッセージを他のプログラムが受け取ることはないし、「クローンされた」イベントも起こらない。


どういうことか、次に詳細に述べよう。


▼クローン処理


ループ内でクローンを使って多数のキャラクターを作り出していたとしよう。


クローンされたキャラクターを好きな位置に配置するために、座標をグローバル変数で渡していたとする。

「クローンされた」イベントが起きると、クローンは座標をグローバル変数から取り出し、自分自身の位置を変更する。


次々グローバル変数を書き換え、クローンを生成したとしても、ループ末尾ごとにシステムに処理は返され、「クローンされた」イベントが起きるので問題なく動作する。



ここで、多数のキャラクターを作るのに時間がかかるので、高速化したとする。


ループ末尾になってもシステムに処理は帰らず、次々とグローバル変数を書き換えながらクローンを作り出す。

いよいよすべての処理が終わり、ブロックが終了した後に、まとめてすべての「クローンされた」イベントが実行される。


最後のグローバル変数の位置に、作り出したすべてのクローンが移動してしまう。

高速化するためのオプションを入れただけでプログラムは変えていないのに、さっきまでは起きなかったバグが起きる。


単純なゲームを作る程度なら高速化する必要はない。

普通はクローンとループはセットになっているだろうし、何も気にせずに作っても、結構うまく動く。


でも、高速化が必要なくらい複雑なゲームを作りたいのであれば、相応に複雑な Scratch の内部構造を理解しなくてはならない。


▼クローン時の変数


さて、Scratch ではプログラムはスプライトに属するもので、そのスプライト自身の挙動を記述する。

他のスプライトの挙動を制御することは出来ない。


でも、クローンは例外的な命令で、自分自身をクローンするだけでなく、指定したスプライトをクローンすることもできる。


ここで、スプライトを指定してクローンすると、そのクローン後の挙動を制御することが難しい。

出現位置を変えたり、何らかのパラメーターを渡すには、上に書いたようにグローバル変数を介在させる必要があるだろう。

そして、高速化で悩むことになる。


もし「自分自身」のクローンで事足りるのであれば、こちらの方が多くのことを制御できる。

というのも、クローンは、クローン命令時点でのクローン元のローカル変数内容をコピーして引き継ぐからだ。


グローバル変数を介在しない。

「クローンされた」が実行されるまでのタイムラグもない。

命令実行時点でパラメーターを受け渡す、唯一の方法だ。




ただし、自分自身のクローンで何もかも済ますことはできない。


パラメーターを受け渡したい、という唯一の理由で、それ以外のすべてのプログラムも受け継ぎ、全く挙動が違うのに処理を振り分ける…なんていうややこしいことをする必要はない。


全く挙動が違うのであれば、全く違うスプライトにしたほうがいいだろう。

その分パラメーター受け渡しがややこしくなるかもしれないけど、全体が複雑化するよりは簡単だ。


パラメーター受け渡し用に、リストを用意するといいだろう。

「追加」すると、リスト末尾にデータが入る。

「1番目」から取り出した後で「1番目を削除」すれば、FIFO キューが出来上がる。


これで値を受け渡しすれば、多数のクローンが一気に作られても問題は出ない。


#「クローン」命令の発行順と「クローンされた」イベントの起こる順が一緒である保証はないので、種別の違うスプライトをクローンする際には、違うキューを用意しておいた方が無難。

 先に書いたように、一つのスプライトですべてを済ませてしまえば、キューが多数になるような複雑さは防げる。

 どちらにするか、自分の良いと思うバランスを考えてプログラムするしかない。



▼プログラムテクニック


動作詳細としては、以上だ。


Scratch 、という言語処理系が、ゲーム作成に必要な技術を自然な形で取り込んでいるのがわかると思う。

だから、Scratch はゲームが作りやすい。



とはいえ、やっぱり初心者向けの言語なので、すでにプログラム経験が深い人には使いづらいかもしれない。


たとえば、関数を作れない。

BASIC でいうサブルーチンは作れるのだけど、返り値は戻せないし、ローカル変数も使えない。


一応引数は渡せて、それはローカル扱いになるのだけど、この引数は参照のみで変更禁止。

Javascript Code Golfer がやるような、引数を使ったローカル変数定義テクニックとかは使えない。



オブジェクトは作れる。

Scratch は Smalltalk 由来なので、C++ 的なオブジェクトではなく、Smalltalk 的なオブジェクトだ。


このオブジェクトは、ATARI 用語的なオブジェクトと若干の混同が見られる。

オブジェクトは、必ずスプライトなのだ。もちろん、わざとやっているのだろう。



スプライトだから必ず画面表示用の画像が付くし、暗黙の内に座標などの変数が定義されている。

でも、画面から「隠す」ことは可能だし、いらない機能は無視すればいい。


オブジェクトなのだから、その内部だけで使える変数も定義できる。

サブルーチンではローカル変数が作れないが、オブジェクト内でローカル変数が使えるのだから、良しとしよう。




オブジェクト間ではメッセージを介して通信ができるが、先に書いたようにメッセージ送信は即座に行われるわけではない。

オーバーヘッドが大きいので、「オブジェクトが通信しあいながら協調動作する」という、Smalltalk の理想には程遠い。


まぁ、ゲーム用なので、「次の画面までに解決できれば良い」程度のことは、メッセージで処理できる。


今回コラムスを作ったのだけど、フィールドを一つのオブジェクトとして扱おうと試みて、断念した。


結果として、フィールドは配列(リスト)構造になった。

落ちてくる宝石を操作するオブジェクトでは、このフィールドを覗きながら、積み上がっている宝石に当たらないように操作を行う。


落ちきったら、ゲームの流れを制御するオブジェクトが、フィールドを調べて消える宝石を消す。


宝石が消えたときは、「消えたよ」というメッセージが送信される。

でも、このメッセージは、表示されている宝石すべてが受け取ってしまう。


宝石は、メッセージをきっかけとして、各自が自分に対応するフィールドの中を調べる。

自分のいる位置の宝石が消えていたら、消えるアニメーションを実行して消滅する。


とにかく、「フィールド」の扱いがいろんなオブジェクトに分散していて面倒くさい。

オブジェクト指向の美しさなんて全くない。




これは「Scratch がダメだ」と言っているのではないよ。

泥臭い方法をとったけど、ちゃんと作りたいゲーム作れたもの。


世の中には結構ダメな環境があって、不満が出たら「あきらめる」しか選択肢がない場合もある。

ちなみに、不満が出ない環境というのは存在しない。


Scratch は、泥臭い方法を許容する。

それだけで十分だ。


2016.6.20 追記

Scratch 教室をやっている「ロジックラボ」さんが、このページ内容を子供向けに興味を持てる形に置き換えて、漫画で描いてくださっていました


そこで指摘されるまで気づいていませんでしたが、画面描画に関与するような変更がない限り、ループ末尾でシステムに処理を返すようなことはしない、とのこと。

確かに、実験してみるとその通りでした。


「リスト」の処理が微妙で、ループ中にリストをいじった時、デバッグ用にリストを表示していると、表示更新のために垂直同期待ちします。


しかし、デバッグ時でないと垂直同期待ちしません。

この日記を書く前、ゲーム作成時にどうも同期タイミングが理解できず、「デバッグのために」リスト表示したりしていたので、ループ末尾は常に処理が戻るのだと勘違いした模様。


#そもそも僕は Scratch の動作をあまり知らないので、調べて整理したかった、という動機です。

 プログラム経験は長いけど、Scratch に関してはまだまだ素人。申し訳ない。



ちなみに、変数は画面に表示していても、垂直同期を引き起こさないようです。

一貫性がないけど、変数は頻繁に書き換えるものなのでいちいち待ち時間を発生しないほうが良い、という判断なのでしょう。



2016.6.27 さらに追記


もう一本ゲームを作ってみてます。

近いうちに公開できると思うけど、システムに処理を返すタイミングがよくわからなくなって困っています。


状況次第で、画面描画しないループでも、システムに処理を返すことがあります。

「高速化」オプションをつけているブロックの途中で、システムに処理を返してしまうこともあります。


今作っているゲームでは、面クリアして特定の面に差し掛かったところで、後者のバグ(?)が出ることが多い。

必ずバグが出るわけではないけど、ある程度再現性があるので、特定条件でバグが出るのだと疑っています。


また、一連の無限ループスクリプト内でブロックを呼び出している場合、繰り返し呼び出されるブロックが、常に高速かオプションが無視されます。

ということは、このバグは「ブロック呼び出し」に付随するのではなく、そのブロックを呼び出すスクリプトのスレッドに付随するようです。


#面クリア時にスレッドを終了し、次の面で再度スレッドを起動する、というつくり方をしている。

 バグが出た面は、ずっとスレッド内で呼び出されるブロックの高速化オプションが無視される。

 (ゲームにならなくなってしまうので、クリアして次の面でどうなるかは不明)


スクラッチのタスクスイッチはまだまだ謎が多いです。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

Unity【日記 18/06/25】

Unity【日記 18/06/25】

7 Billion Humans【日記 18/11/09】

【訃報】シーモア・パパート【日記 16/08/03】

【訃報】シーモア・パパート【日記 16/08/03】

別年同日の日記

02年 ロールパン

05年 成長記録

05年 バードウォッチング

10年 料理

11年 続々・新PCのこと

13年 雨のお散歩

15年 アスペルガー症候群


申し訳ありませんが、現在意見投稿をできない状態にしています

顔文字 (^_^) の生まれた日(1986)  2016-06-20 09:42:31  コンピュータ 今日は何の日

▲目次へ ⇒この記事のURL

今日は、日本式の顔文字 (^_^) が生まれた日(1986)。


一応、欧米式の顔文字、:-):-(1982 年に提案されています。


アメリカでは、1960年代から、テレタイプ端末を電話回線でコンピューターに接続して時間貸しするサービスがありました。

その延長で、いわゆる「電子掲示板」も早くから普及しています。



1970年代の末頃には家庭用のコンピューターも普及し始め、電子掲示板を使用するユーザーも増えます。

そして、ユーザーの急増に伴い、それまで数の少ないユーザーの間では「常識」で済んでいたことが、通用しなくなり始めたのです。



簡単に言えば、冗談を書き込んだのに真に受ける人が出始めた。

これはいけない、と、冗談の最後には「冗談だよ」という意味で、笑い顔のマーク :-) をつけようという提案がなされたのです。





さて、今日は日本の顔文字の話。


日本ではアメリカと違い、電話は国営でした。電電公社だけに許されたサービスだった。

その電話回線に接続する「電話機」もまた、電電公社の所有物で、レンタルでした。


電話料金と共に、毎月のレンタル料を支払う制度。

そして、その電話機以外の機械を電話回線に接続することは許されなかったのです。



この制度が変わったのが、1985年。

電電公社が民営化されてNTTとなり、同時に電話機自体も、認可があれば別の会社が作れるようになります。


日本の「パソコン通信」時代の夜明けはこの後で、300bps のモデムとかで通信ができるようになります。

まだ漢字を使えるマシンも少ないころで、アルファベットとカタカナだけで通信をやっていました。


#と書いているけど、僕がパソコン通信を始めたのは 1990年代なので、この頃の話は伝聞。

 一応、これ以前からも、通常の電話機にマイクとスピーカーを密着させる「音響カプラ」でのパソコン通信は行われている。


さて、1985年には、パソコン雑誌で有名だったアスキーが主催する形で、パソコン通信の「アスキーネット」がいち早くサービスを開始しています。



日本式の顔文字が生まれたのは、1986 年、アスキーネットでのこと。

お祝いメッセージの中で、喜びの表現として (^_^) という組み合わせが使われました。


この時点では、自分の気持ちを表現するものなので、文末に自分の署名とともに入れる形です。

でも、「顔文字」という概念もないので、誰も顔だと気づいてはくれなかったとか。


その後は、「自分らしい署名」の一部として使用されます。

欧米での使われ方のような、感情表現とは違うものです。



しばらく後には爆発的な普及を見せ、各自が工夫したバリエーションが増えていきます。




ここら辺、考案者である「わかん」さんに、メールでお伺いしたことがあります


当時は日本ではパソコン通信は「新しいもの」で、海外のパソコン通信を知っている人はほとんどいません。

存在程度は知っていても、実際使ったことはない、という意味ね。



だから、海外の顔文字は全く知らず、無関係だったそうです。


1980年前半のパソコンはグラフィックが使えないものも多く、ゲームなどを作る際に文字の組み合わせで形を作る「アスキーアート」を駆使していました。


これらは、ベーマガなどを読んでいた人にもお馴染みだったと思います。

しかし、わかんさんは視覚障碍をお持ちで、当然ながらこれらのゲームも知らないし、雑誌のプログラムを読んだこともないそうです。


つまり、全くのオリジナルアイディア。



今では、海外でも日本式の…横倒しになっていない顔の書き方は人気がありますし、Unicode によって文字のバリエーションも増えたため、驚くほど多くの表情を作り出せます。


時々、凝りすぎていて使い道がわからない顔文字も見かけますけど。




僕は文章の中に顔文字を入れすぎるのは好きではない。読みにくくなるから。

でも、時々 :-) や (^^; は使います。


前者は、英語的な表現と同じ「just joke」な感じ。


後者は、ちょっと照れ笑いを浮かべているような、なんと言ってよいか困っているような表現ね。

改めて説明しようと思うと的確な言葉が見つからないのですが、だからこそ顔文字で表現するしかない。



文章を書くプロであれば、微妙な表現でも的確な言葉を見つけないといけないでしょう。それがプロの仕事だから。


でも、今は素人でも書いた文章を人に見てもらえる時代。

上手い言葉を見つけ出せない時に、顔文字などで感情を伝えようとするのも、悪くないかと思います。

そこに「伝えたい」という気持ちがあるのであればね。


先に書いた「凝りすぎた顔文字」というのは、絵としての面白さはあるけど感情が乗らないようなものね。

絵を作り出した努力は認めますし、素直に面白いと思うものもある。


でも、顔文字が感情表現の一環であるならば、非常に使いづらい。




パソコン通信やメールでは顔文字が多用される、ということを前提に、DoCoMo が i-mode を作り出したとき、顔文字を1文字で表現するような「絵文字」が考案されました。


i-mode の初期の頃って、横幅が8文字分しかないんですね。顔文字の途中で改行されてしまう可能性は高いし、そんなことになったら絵として見られなくなる。


だから、1文字の幅の中で、笑い顔や泣き顔など、いくつかの顔を入れてしまった。

それでも、アスキーアートの延長だったので、絵としては非常に簡素なものでした。


その後、他社も真似して絵文字を入れていく過程で、完全に顔の絵になってしまった。

さらに表情も増え、それがそのまま Unicode に取り込まれた。



Unicode の策定に関わっている多くの人達が、「文字」ではないものを取り込むことに対して、強く反対したそうです。

そして、取り込むことを決めても、今度は日本生まれの「絵文字」が日本文化に根差しすぎていることが問題となった。


日本の文字なら日本文化に根差しているのは当然。

でも、絵文字は一見して「世界中誰でも理解できそう」だからこそ、その表現が日本文化だけに根差していることに問題があったのです。



非常に多くの議論が行われ、文字の形などが変更され、やっと取り込まれます。


実際取り込んでみたら大人気で、欧米のユーザーも喜んで使い始めた。

今では欧米からも、積極的に新しい絵文字の提案が出されています。



しかし、公式に「文字」の一部として顔の絵が使えるようになっても、なお新しい「顔文字」が作られ続けています。

組み合わせて自分で作る、という遊びが面白いという側面もあるのでしょうし、そもそも顔文字が「文字で表現できない微妙な感情を表現しよう」とするものだからでもあるでしょう。



公式にいくつかの顔が作られてしまえば、その中にない新たな表情を作りたくなる。

たぶん、顔の絵がどんなに増えても、「顔文字」が無くなってしまうことはないのだと思います。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

今日は何の日

別年同日の日記

02年 SOHOっていうものは

05年 2台のRoomba

12年 続・おたふく

13年 古いコンピューターを長持ちさせる

22年 防災訓練


申し訳ありませんが、現在意見投稿をできない状態にしています

コンピューターが初めてプログラムを実行した日(1948)  2016-06-21 12:50:21  今日は何の日

▲目次へ ⇒この記事のURL

今日は The Baby が初稼働した日(1948)。

ということは、ノイマンアーキテクチャマシン上で初めてプログラムが動作した日です。



プログラム可能な機械はこれ以前にもあるし、電子計算機もこれ以前にあります。


でも、ハーバードマーク1は電子計算機ではなかったし、ENIAC のプログラムは配線を繋ぎ変えるものでした。

SSEC は電子式だったし、柔軟なプログラムができたけど、パンチカードによる外部供給式でした。


当時はまだ、高速な計算機があれば膨大な計算力が手に入る、と考えられていた時代。

プログラムは、必要上作らないとならないものではありましたが、簡単に作れると思われていました。


ところが、実際に計算機ができてみると、プログラムこそが一番重要な問題だったと気づきます。




ENIAC を作成したエッカートとモークリーは、ENIAC 建造中にこの問題に気づきました。

そこで、次に作る機械ではプログラムを作りやすくする工夫を盛り込もうと計画します。


それが、数値などの計算に必要なデータと共に、計算手順も数値としてメモリに搭載するという方法です。

ENIAC プロジェクトは国防上の機密事項でしたから、この設計も秘密裏に行われています。



ところが、プロジェクトを視察に来た天才数学者、フォン・ノイマンが、このアイディアを気に入ってしまいます。

彼は、次世代計算機 EDVAC の概要を、自分の名義で公表してしまいます。


まぁ、国防の機密をいきなり公表してしまうほど彼は馬鹿ではありませんし、裏でいろいろあったようなのですが、その話は今回は置いときます。


ともかく、世界中で「ノイマン型」アーキテクチャのコンピューターの開発競争が始まります。




そして、完成第一号は、イギリスの The Baby


これは愛称で、正式名称は Manchester Small-Scale Experimental Machine 。SSEM と呼ばれます。

当時はまだ理論上のものだったノイマン型コンピューターが本当に動くことの確認と、そのために必要な新型メモリである「ウィリアムス管」の動作試験を兼ねた実験機でした。


実験は成功し、すぐに Manchester Mark I の設計が開始されます。

さらに、Manchester Mark I は量産され、Ferranti Mark 1 として市販されます。




さて、その The Baby ですが、新型メモリのウィリアムス管の動作確認が最大の目的でした。


当時のメモリはシーケンシャルアクセス…今のような「ランダムアクセスメモリ」(RAM)ではなく、非常に遅いものでした。


ウィリアムス管は、ブラウン管を利用したメモリで、ランダムアクセスが可能なうえ、理論通りで行けばビット密度が上げやすい、夢のようなメモリでした。



ただし、この時点ではまだ実験中のため、ビット密度が低いです。

そのため、搭載メモリは 32bit を 32word だけ。1024bit ですね。


命令は1ワード1命令。だから、たった 32命令のプログラムしか作れません。



最初に実行されたプログラムは、2の18乗の最大の真の約数を見つけ出すプログラムでした。


…ある整数 n があった時、この n を割り切れる数を「約数」と言います。

ただし、1 と n で割れることは当然です。そうではない約数を「真の約数」と呼びます。


その中で最大のものを見つける、というプログラムです。


…えーとね、2 の累乗だから、必ず偶数ね。半分に割れる。

だから、半分に割った数が最大です。電卓があればすぐ計算できる。


つまり、事実上 2で割るだけのプログラムなのだけど、実験用の機械なので割り算は出来ない。

引き算と、符号による条件分岐くらいしか命令がないんです。


そこで、ひたすら引き算を繰り返し、結果が 0 になれば「割り切れた」と判断します。

疑似的に書くとこういうことです。


for(i=(1<<18)-1;i--;i>0){
  j=1<<18;
  while(j>0){
    j -= i;
  }
  if(j==0){
    answer(i);
    exit();
  }
}


実際には、「符号を調べる」しかできないから、0チェックとかもややこしいのだろうけど。



このプログラムは、命令 17word、データ 8word の 25word で作られていました。

32word しかメモリがないのだから、これ以上複雑なことは出来ない、というギリギリレベル。


そして、52分かかって正しい結果を出したそうです。

ウィリアムス管という新しいメモリが、1時間近くも正常に動作した、ということでもあります。



これがノイマンアーキテクチャで実行された最初のプログラムです。

1948年の今日、6月21日の出来事でした。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

今日は何の日

別年同日の日記

02年 飲んだくれの日々

03年 なんだか色々入手

13年 「暗号の歴史」と、アメリカの盗聴問題

14年 ファミリーベーシックの発売日(1984)

15年 山歩き

17年 ゼルダ雑感

21年 3次元回転

23年 漫画紹介「続く道 花の跡」


申し訳ありませんが、現在意見投稿をできない状態にしています

【訃報】長谷川五郎さん  2016-06-24 09:24:46  コンピュータ 歯車 今日は何の日

▲目次へ ⇒この記事のURL

昨日の報道ですが、オセロ考案者の長谷川五郎さんが、20日に亡くなったそうです。

すぐに何か書こうと思ったけど、昨日は忙しくて書けませんでした。




僕は氏のことを全然知らない。


オセロの開発話は本やテレビで何度か見たことがあるし、それなりには知ってる。

でも、氏に対しての思いは特にない。


それで訃報を書くのもどうかと思うのだけど、オセロに関して思うところはいろいろある。

ちょうどよい機会だし、偉大な方だと思うので、自分の思い出を少し書こうと思う。




テレビゲームが子供の遊びの主役となる前、どこの家にも将棋やオセロなんかがあったと思う。


人生ゲームなんかもあるのだけど、あれは大人数で遊ぶ時用。

オセロなら、2人いれば十分で、しかも短時間で遊ぶことができた。


僕は兄弟が多く、兄や姉とよく遊んだのだけど、大抵は負ける。

小学校低学年の頃だったから、まだ論理性が身についていない。


オセロは、「多くとれる」ところを責めると、自分の色の駒がたくさん並んだ状態を作り出してしまう。

それは、とりもなおさず相手にとって「多くとれる」ことを意味する。


だから、闇雲に攻めちゃいけない。でも、そんなこともわからずに闇雲に攻めていたのだった。




小学校4年生の頃だと思うが、ゲームセンター向けにオセロのゲームがあった。

白黒画面で、○と×で駒を示しているやつ。


それを見たときは、「コンピューター相手にオセロができるんだ」とは思ったのだけど、お金を出してまでやろうとは思わなかった。

小学生にとって 100円は大金だし、オセロだったら家に持っているから。


#注:まだゲームセンターに小学生が行っても問題なかった時代。

 よく、金もないのにゲームセンターに入り、人のプレイやアドバタイズを見るだけでわくわくしていた。



そして、小学校6年の頃だったと思う。

オセロの販売元のツクダオリジナルが、オセロを遊べる家庭用テレビゲーム機を発売していた。


実はセガ SG-1000 の互換機で、カートリッジを入れないときはオセロが起動するようになっている。

おもちゃ屋の店頭に、遊べる状態で置いてあったのだけど、この「人工知能」に対して…確か、強さを選べて、一番弱い場合だったとは思うのだけど…必勝法を見つけ出した。


コンピューターは、こちらが同じ手を出せば、全く同じ手を出してきた。成長がなかった。

それで、5~6手進めただけで、すべて自分の色になってゲーム終了、という手順があった。

この手順を発見して、その店の店頭を通るたびに、わざわざ「完勝」して、誇示するようにその画面のままにして去ったのだ。


コンピューター相手にオセロをやったのは、たぶんこれが初めてなのだけど、「コンピューター、馬鹿だな」と思っていた。




中学生になり、ファミリーベーシックを入手した。

面白くもないゲームを作ることが楽しかったのだけど、ある日ベーマガに「オセロ」のプログラムを見つけた。


他機種用。でも、人工知能ってとても高度なもので、BASIC で簡単に組めるとは思わなかった。


興味を持って、プログラムを読んでみるのだけど、何をしているのかどうも意味が分からない。


プログラムのほとんどは、オセロのルール…挟んだらひっくり返るとか、ひっくり返せない場所にはおけないとか、そういう細々したことを実現するためのものだった。

人工知能らしい、高度な部分はない。



人工知能の思考ルーチンはと言うと、盤面の中で「駒を置ける場所」を見つけたら置いてしまう、と言うだけ。

ただし、置ける場所の順番は示されていて、単にマス目を端から見ていくのではない。



ふーん、すると、この順番に何か秘密が隠されているんだな。

ファミリーベーシックに移植して遊んでみる。


そのプログラムは、それほど強くはなかったけど、適当に相手をしても勝てない程度には強かった。


石を置く順番…取るべき優先順位は簡単な話で、盤面の四隅は最優先。

その隣は、最も優先順位が低かった。


オセロでは「駒を挟むとひっくり返せる」というのが最重要ルールだ。

でも、隅にあると絶対に挟めないから、自分の駒を置くと相手にとられない。

安全地帯なのだから、何よりも優先して確保しなくてはならない。


そして、相手の駒を挟む形でしか新しい駒は置けない。

隅の隣に駒を置かなければ、相手に隅を取られることはないことになる。

だから、隅の隣を迂闊に取るのは悪手。優先順位を下げないといけない。



でも、単純に優先順位をつけるだけでは、「多くとれるところ」を見逃すことにもなりかねない。


プログラムを改良して、位置の情報に「優先順位」フラグを付けた。

置ける場所が見つかっても、同じ優先順位のところがまだあるなら、そちらにも置けるか試す。


一番多くの駒をひっくり返せるところの位置は覚えておいて、同じ優先順位の場所が無くなったところで、「一番良いところ」に駒を置く。


ちょっとした改良で、ちょっとだけ強くなった。

これを友達に渡して遊ばせたら「何度か遊んだけど一度も勝てなかった」と言われた。


僕が遊ぶと、アルゴリズムを知っていることもあって、これでもかなり弱い。

一度も勝てないはお世辞じゃないかと思ったけど、そいつは思考ゲームは嫌いだったので、適当に遊んだら勝てなかったのかもしれない。




まがりなりにもオセロの思考ルーチンを考えたことがあったので、興味を持ってはいた。

その後、たしか雑誌の「ログイン」で、森田和郎さんが「森田オセロ」の解説をしていた。


森田和郎さんというのは、当時の有名プログラマで、オセロとか将棋を作るのを得意としたのね。


もっとも、ゼビウスに類似したゲームを、当時の非力なマシンで作り上げて、ナムコの許可を得て販売したりもしている。

アクションゲームも十分作れるし、複雑な思考ゲームも作れる。凄腕のプログラマだった。


話がそれたけど、森田オセロでは、もちろん「駒を置く位置」も考慮しているけど、それでいくつの駒をとれるか、置いた駒の周辺に空きマスはないか(空きマスがあれば、そこに相手が駒を置くことでひっくり返されやすい)、など、多くのパラメーターに点数をつけることで複合的に置く場所を決めているという。


そして、何より大切なのが「先読み」だった。


駒を置ける可能性のある場所はいくつもある。

その中でどこに置くかを決めるのに上に書いたように点数を使うのだけど、一番高得点のところに置けばいいというものではない。


そこに置いたとしたときに、次に相手はどんな戦略をとれるか。ここでも得点を出し、一番高得点のところに置くとする。


じゃぁ、それに対して今度は自分は…これを数手繰り返せば、先読みができる。

たくさんひっくり返したけど、その次の手でそれを全部取り返される、なんて間抜けな手を打たなくなる。



森田和郎さんの記事では、αβ狩りも説明されていた。

ややこしいので詳細は省くけど、先読みの範囲を絞り込んで、効率よく最善手を見つけ出すための方法。




実は、先読みまでするオセロを試作したことはあるのだけど、未完成なまま飽きた。


大学の時に Lisp 言語を入手したのね。

Lisp なら人工知能だろうって、当時の浅い知識で短絡してオセロを作り出した。


先読みルーチンを作るには、「今の盤面の状態」を記憶したまま、次々と「先読みした盤面」を作り出す必要がある。


具体的にいえば、先読みのために1階層深くサブルーチンを呼び出すたびに、新しいメモリを確保して盤面を保持した配列をコピーしないといけない。


関数に対して配列が渡せれば簡単なのだけど、C言語ではそのようなことは出来ない。

もちろん、BASIC でもできない。そもそも BASIC にはサブルーチンはあっても関数はない。


でも、Lisp は元からそういう言語構造だった。

データは呼び出しの際にコピーされる。だから先読みプログラムを作りやすい。



で、先に書いた通り、未完成なまま飽きた。

Lisp に慣れておらず、何か処理しようとするたびに方法を考えないといけなかったし、そもそも Lisp は「人工知能のアセンブラ」と言われるくらい、アセンブラのように命令が貧弱だった。

(…という考え方が間違っているのは、今ではわかっている。でも当時の僕はそう思った)



それ以降、こうした思考ルーチンは面倒くさくて作ってない。

興味はあるから、それなりに話を追いかけてはいるけれど。




もう、長谷川さんの訃報とはほとんど関係なくなっているね。

以上、オセロに関する僕の思い出話でした。




▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

歯車

今日は何の日

別年同日の日記

02年 DJB

13年 セミの幼虫

15年 若者の恋愛観

15年 結婚と経済

21年 温泉卵


申し訳ありませんが、現在意見投稿をできない状態にしています

Comet  2016-06-30 16:19:54  コンピュータ 業界記

▲目次へ ⇒この記事のURL

先日 Scratch でコラムスクローンを作ったのだけど、完成してすぐにもう一つの作品を作り始めた。


実のところ、ゲームのコア部分は2日でできて、すぐに公開していた。

でも、宣伝してないので一人見てくれただけ。


その後が…長くかかった。

仕事の合間に作っているので、実働できるのは週2日程度。


データ整理に時間がかかったり、バグがなかなか取れなかったり。

(これについては Scratch のバグを疑っているのだけど、再現方法がわからない。

 もっとも、「負荷をかけすぎた」のが問題で、これは自分のプログラムが悪かったので、修正して回避した)




で、ひとまず完成したので公開です。





まずは画面の緑色の旗をクリックして、プログラムを動かします。



彗星(comet) を動かして、黄色い星を囲んでください。

赤い星は倒せません。


まとめて囲むと高得点。


星の初期配置は星座の形。だから、全88面。


ただし、途中で3面ほど、星が出てこない面があります。

暗い星しかない星座なんだよね。ボーナス面だと思って。


プロジェクトページに行けば、大画面で遊ぶこともできます。

(画面左上のマークで拡大できます)


Scratch の ID 持っている人は、左下の星とハートのマークも押しておくといいよ(笑)



これ、僕が X68k を入手して最初に作ったゲームの移植です。

詳しくは X68k のページに。


画面サイズが違う (X68k は 512x512 、Scratch は 480x320) ので、初期配置の星の位置と星座名が重なっていたりしますが、ご愛敬。


キャラクターも、当時のゲームを知っている人には大きく見えるかもしれません。

同じ 16x16 なのだけど、画面サイズが違うので相対的に大きくなっている。




いい機会なので、思い出話を一方的に語りだす。

以前聞かれて簡単に答えたけど、まとまった形にはなっていなかったので。


中学の頃、ファミリーベーシックを使っていました。


そのころから、スプライトがしっぽのようについてくるプログラムが好きで、よく作っていました。


スプライト番号を +1 しながらどんどん置いていけばいい。

番号が最大値を超えそうなら 0 に戻す。

これで、スプライトが「再利用」されて、古いものは消えていくことになる。しっぽの出来上がり。



MSX ではマウスは標準ではないけれど、HALNOTE を使っていたので購入していた。

そして、マウスをぐりぐり動かすと、やっぱりしっぽが付いてくるプログラムを作っていた気がする。


MSX でスプライトを使っていたのか、LINE でやっていたのかは覚えていない。

両方作っていたかもしれない。


LINE で描く場合は、しっぽが付いてくるのを自前で管理しないといけない。

配列をもって、過去の座標を覚えておき、ある程度古くなったら消せばいい。



そして、X68k を買ったらマウスが標準装備だった。

最初の試作として同じようなプログラムを作ったら、MSX とは比較にならないくらい高速に動く。

これでゲームになるんじゃないか、って作り始めたのが Comet 。


線を引くルーチンを自前で用意して、点を打つ前に、そこの色を調べる。

すでに何か描いてあるなら「囲んだ」ことになる。


囲んだ時、最初は星から上下左右の4方向に向かってドットを調べて「囲まれた」判定をしていた。

でも、これは遅かった。あとで「座標で計算すればいい」と気づいて、判定ルーチンを高速化した。


といっても、やはり上下左右が囲まれただけで「囲んだ」と判定していて、まじめな閉鎖領域チェックをしているわけではない。

今回のプログラムも同じ。




Comet は、大学1年の時点での、自分のゲーム哲学を反映したものだった。

今回も基本的に「移植」なのだけど、今だったら違うように作るだろうというところもある。


キャラクターは、単に絵が描けなかったので記号的になっている。


でも、同時に「テレビゲームの本質は記号操作だ」と思っていた。

この頃、絵に凝ったゲームが増え始めていて、絵は良いのだけど面白くないものも増えていた。

それに対する反発もあった。



今でもこの流れは変わっていないと思うけど、「絵を見るのも楽しみのうち」だということは理解するようになった。


綺麗な絵があるなら、それに越したことはない。

また、絵を見ることが目的なら、ゲームは簡素でつまらないくらいでちょうどいい。


今のソシャゲとか、「面白くない」という人もいるけど、絵を見たくて遊んでいる人は面白さなんて求めていない。

それが理解できないで文句を言うのはお門違い。


ゲームの楽しみ方は幅広い。巧妙で奥深いゲームのルールなんて求めるのは、そういうのが好きな一部のマニアだけだ。




Comet では、敵をたくさん囲んだ時に、100、200、300 …と得点単価が上がっていき、1000点以上には上がらない。

これは、初心者でも楽しめるように配慮したつもりだった。


100、200、400、800 …と倍々で増えていくのが当時のゲームとしては主流だったように思う。

でも、それじゃぁゲームマニアと初心者の得点差が離れすぎてしまい、一緒に楽しめなくなる、と思ったんだ。


これは思い違いだった。

例えテクニックを使用した時の得点上限を低めに抑えたとしても「テクニックで得点が上がる」という仕掛けを入れている限り、マニアと初心者の得点差は大きく開く。


でも、テクニックを使える人は、それに対する見返りがなくては面白くない。点数が上がる仕組みは必要だ。

つまり、マニアと初心者が一緒に競えた方がいい、という考え自体が間違えていた。


comet でこのことを知ったので、その後のゲームでは得点を低く抑えないようにした。

そのほうが遊んでいて気持ちいから。




マウス(初お披露目した大学祭では、トラックボールを使用)を使ったのも、初心者が楽しめるようにだった。


マニアは、コントローラー操作に慣れている。

じゃぁ、慣れないコントローラーを用意すれば、みんな同じスタートラインに立てる。

初心者にも競い合うチャンスがあるはずだ、と思った。


でも、トラックボールは時々使われているゲームがあったし、やっぱりマニアは扱いがうまかった。


このときはまだ勘違いしていて、トラックボールじゃダメだったんだ、と思っていた。

翌年「マイク入力」のゲームを作ったら、ゲームマニアの友人は、すぐにゲームルールを理解し、最適な操作方法を編み出した。


この段階に至り、コントローラーを工夫すれば初心者でも同じ位置からスタートできる、というのも勘違いだと気づいた。

マニアはコントローラーの扱いがうまいのではなく、どんなゲームを見てもすぐにルールを把握する適応力に優れているのだ。


これ、ずっと後に任天堂が Wii を発売した時にも同じことを感じた。

全く新しい操作方法で誰もが一緒に楽しめる、ゲームの在り方をリセットする意欲作…だったはずなのだけど、マニアはやっぱり適応力が高かった。




大学時代の、まだ青臭かった自分が作ったゲームなので、ある意味では黒歴史でもある。

BASIC で組んだものだからね。処理が下手な部分がいっぱいあって、スマートではない。恥ずかしいものだ。


その一方で、広く遊んでもらった初めての作品だ。

雑誌に投稿した作品がたまたま流通業者の目に留まり、市販してもらえることになった。


これで「自分の作ったゲームを多くの人に遊んでもらえる」という喜びを知ったから、ゲーム業界を志すようになった。

人生の転換点だった。


記念碑的な思い入れがあるけど、出来が悪い恥ずかしい作品。

それが Comet だったので、いつかどこかでリメイクしたい、という思いはあった。


実際、手を付けたこともあるのだけど、面倒くささが先に立って完成しなかった。



先日、コラムスクローンを作ってみて Scratch の性能が案外高いと判ったので、作ってみようと思った。

コア部分を試作したら、2日でできてしまった、というのは最初に書いた通り。



まぁ、リメイクした、と言うだけで納得してしまい、完成度は高くない。

いつか本気でリメイク出来たら楽しいけど、当面はこれでいいや。


#夢を語るなら、88星座のイラストを入れたいし、星の動きをもっと多彩にしたい。

 今は初期配置が違うだけで、どの面も似たような攻略法になってしまうから。

 星座の線に従って動く星、というのがあれば、星座の形にしている意味も出てくるだろう。

 また、88面は長いので、季節ごとの4コースに再編したい。

 …などなど、改良したい点はいくらでもある。


▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

業界記

関連ページ

X68000Z【日記 23/04/02】

セガサターンモデム【日記 16/07/28】

別年同日の日記

09年 ハムスターその後

13年 TX-0エミュレータ作成中

14年 ヴァネバー・ブッシュの命日(1974)


申し訳ありませんが、現在意見投稿をできない状態にしています


戻る
トップページへ

-- share --

0000

-- follow --




- Reverse Link -