目次
前のページ
2018-06-11 スプラトゥーン２のフェス勝敗の確率
2018-06-12 ゲームの作り方
2018-06-25 Unity
2018-07-04 続・Unity
2018-07-12 メモリアドレス
2018-08-06 Ｃ言語で会話
2018-10-01 台風24号
2018-10-06 WEBページの検索順位をあげる方法(1/2)
2018-10-06 WEBページの検索順位をあげる方法(2/2)
2018-11-09 7 Billion Humans
2018-11-19 なにもしてないのにこわれました
2018-12-03 ノートパソコン修理
2018-12-16 新サーバー購入
2018-12-20 メインマシンに Win 再インストール
2019-01-07 シュガーラッシュ：オンライン
2019-02-21 ファミリーベーシック V3(1985) ディスクシステム(1986)の発売日
2019-02-25 2D-APT II 発表 (1959)
2019-03-13 デヴィッド・カトラー誕生日(1942)
2019-03-19 ジャングルウォーズ２ 発売日(1993)
2019-03-27 電気で計算する方法
次のページ
時々スプラ２のフェスの話を書いているのだけど、今回は勝敗結果の話。
ありていに言えば「結果がおかしい。対戦が正しく行われていないのでは？」という内容。
話を始める前に、スプラ２のフェスを詳しく知らない人のためにざっくりと解説。
スプラトゥーン２は、オンラインの対戦バトルゲームです。
４対４で、水鉄砲を持って戦います。
この手のゲームは「殺し合い」で勝負するものが多いのですが、スプラトゥーンシリーズは「陣取り合戦」です。
水鉄砲（「インク」を撃つことになっています）で相手を撃ち倒してもいいけど、最終的な勝敗は、自分のチームの色に塗った面積で競われます。
だから、必ずしも相手を殺すことが勝敗に結びつかず、逃げ回っていてもチームに貢献できます。
対戦ゲームが苦手な、僕ような人でも楽しめるゲームです。
で、時々「フェス」と呼ばれるイベントが開催されます。
あらかじめ、２択の質問で２グループに分けられ、そのグループ同士で対戦するのです。
この対戦も、１人で参加した人をランダムに組み合わせる「ソロ」と、２人、または４人であらかじめチームを組んで参加する「チーム」の２つの参加枠があります。
さて、フェスの「勝敗結果」ですが、24時間続けられるフェスの後に、得票率、ソロ戦の勝敗率、チーム戦の勝敗率、の３つで評価され、２つ以上の率が高かった方が勝者となります。
2018.9.21 追記
9月23日開催の第16回フェスから、ルールが大幅変更となりました。
ソロ・チームという区分はなくなり、レギュラー・チャレンジとなります。
また、勝率で勝負するのではなく、対戦によって獲得されるポイント合計で勝負するようになりました。
以下のこの日記の趣旨は、日記執筆時点でのフェスルールは破綻していて、多少の調整でどうにかなるものでもなく、任天堂も困っているのだろう、というものでした。
それに対する回答がルール大幅改定なのだと思います。
この日記は情報としての意味を失ったわけですが、日記ですので書いた時点での事実として残しておきます。
過去の戦績をここで書こうかと思ったけど、このページの趣旨ではないし、まとめている人もいるので他のサイトに譲ります。
今日の話は、この「結果」に、おかしいくらいの偏りがある、ということ。
ゲーム中では、ナビゲート役として、ゲーム内の「アイドルバンド」である２人組、ヒメとイイダが登場します。
フェスの時には、それぞれが各チームを代表する形になります。
それぞれの過去の勝敗結果は公表されています。
昨日の第１３回までで、ヒメ５勝、イイダ８勝です。
ネットでは「イイダの勝率が高い」ことに着目し、常にイイダに投票する、と宣言する人も出ています。
勝率…高いと言えば高い。でも、この程度なら誤差範囲のようにも思います。
実は、ヒメかイイダかというより、冷静に成績を見ると「得票率の少数派の勝率がやたらと高い」です。
少数派９勝、多数派４勝です。
フェス前のアンケートでは、２択を選択するためのカーソルが、最初は「ヒメ」側についています。
どっちでもいいや、という人はヒメに入れやすいのかな、と思います。
だから、ヒメが多数派になり、負けてしまうことが多い。
「イイダ派が強い」ではなく、「少数派が強い」のですね。
でも、これでも先ほどと１勝しか変わっていない。
２倍の差となると誤差と言いづらくなりますが、サンプル数も少ないですし、まだ決定的ではないように思います。
では、多数派が勝った４回を詳細に見ましょう。
そのうち３回は、ソロ戦を多数派が勝ち、チーム戦は少数派が勝っています。
得票率での勝ちと合わせて「多数派の勝ち」となりました。
残る１回は、ソロ戦もチーム戦も、多数派が勝利した「完全勝利」です。
実は、「多数派がチーム戦で勝利した」のは、この１回のみです。
少数派が勝った９回の内容は、すべて「ソロ戦・チーム戦とも少数派の勝ち」です。
得票率で負けているのですから、これ以外では少数派の勝ちになりません。
というわけで、ソロ戦・チーム戦の通算では、少数派が２１勝、多数派は５勝です。
少数派は、多数派の４倍も対戦で勝っている。
ここまで違うと「誤差」で済ませられるものではなく、有意な差があると考えてよいかと思います。
先に書いた通り、マッチングは基本的に「同じくらいの強さの人」を集めて行われます。
そのため、勝負は五分五分。片方が４倍も勝つ、なんてことが起こるはずはありません。
結果発表の勝率を見ると、戦績は僅差です。
具体的に…７回終了時点までで、一番の勝率が 51.34% です。
多くは、勝っている側でも 50.xx% という小数点以下の勝負で、一番の僅差の時は 50.04% での「勝ち」でした。
これが、８回目で少し崩れます。
７回までの戦績が偏ってしまっていて、イイダが連勝していること自体を、フェス前の予告のネタにしていました。
そして、ヒメが ソロ 51.50% 、チーム 51.51% で勝利するのです。
それまで決して出ることのなかった、半数(50%)を 1.5% 超える差での勝利。
それを、あらかじめ予告したタイミングで、ソロ・チームとも叩き出す。
おそらくは、ここは運営側で調整が入り、マッチングが少し変わったのだと思っています。
このあと、９回目ではゆり戻しが来たように僅差の勝負となり、１０回目でたった１度の「多数派の完全勝利」。
この時は、チーム戦で 52.25% という高い勝率が出ています。
そのあとの１１回目、大騒ぎとなった「マッチングバグのあるフェス」となりました。
本来、同じくらいの実力の人がマッチングされるはずなのに、大きく実力差のある人が組み合わせられます。
阿鼻叫喚、としか言いようのない一方的な試合が繰り返されました。
このような試合では、負けた側はもちろん、勝った側もあまり楽しめません。
後に任天堂公式に「バグがあった」ことの謝罪が出るのですが、この時も少数派が勝ち、 54.39% という高い勝率が出ています。
その後、現在のところフェスは２回行われていますが、元に戻す努力があったようで、あまり大きな勝率の差は出ていません。
＃書いてから気づいたけど、ゲーム中は勝率を小数点以下まで出してなかった。
先にリンクしたページを見ても、細かなことはわからない。
連動したスマホアプリを使うと、小数点以下まで確認できる。
さて、この話は「任天堂が手ごころを加えている」とか、そういう話ではありません。
ゲームとしては同じ実力の人が真剣に戦うから面白いのですし、任天堂もマッチングシステムで、できるだけそうなるように努力しているように見えます。
にもかかわらず、差が出ている。
おそらく一番困っているのは任天堂の人で、修整のための努力を続けているのに「なぜか」治らない…というように見えます。
スプラ１は遊んでいないのでよく知らないのですが、勝率もソロとチームを特に分けておらず、別の集計方法で勝敗を決めていたようです。
つまり、今のフェスのシステムは、純粋に１３回しか遊ばれていません。調整をするにしても、十分な機会がまだ得られていない、とも言えます。
マッチングで使用される「同じ強さ」の指標としては、過去何戦かでの、チームの勝敗、その時のチームの平均強さの格差（格上に勝つようならかなり強いと考えられる）、殺した数、殺された数、塗り面積…などなど、ありとあらゆる、計測できる要素が使用されているように見えます。
また、スプラトゥーンは非常に「ブキ」の種類が多いゲームで、ブキ同士の相性もあります。
同じ強さをマッチングしたとしても、相性が悪ければ勝負になりません。
ですから、マッチングの際には同じタイプのブキがチームに偏らないように、かつ、対戦チームも同じようなブキ構成になるように…というようなことをインタビューで答えていたように思います。
とはいえ、マッチングの際にあまり万全を期して、ユーザーを待たせるようではいけません。
来るかどうかわからないユーザーを待つ「完璧な解」よりも、今いるユーザーで妥協して早くゲームを始める方が良いのです。
フェスの際には、「所属するグループ」も考慮する必要があります。
ただでさえ、難しい条件をできるだけ満たすような組み合わせを見つけないといけないのに、２グループに分かれることで組み合わせに「使える」素材が、半分になってしまうのです。
こうした複雑な事情をすべて潜り抜け、なんとかフェスを成立させた先にあるのが、「なぜか少数派が強い」という現象なのかな…と思っています。
システムが複雑すぎるので、何が起きているのか、当の任天堂運営チームにもわからない。
それを何とか修正しようと実験するうちに、バランスを大きく崩してしまったり、「マッチングバグ」を引き起こしてしまったりしているのではないかと。
マッチングバグは、多数解決しないといけない制限の中の「同じくらいの強さの人を組み合わせる」という部分を緩くした結果ではないかな…
と思っています。
同じくらい、というのが難しくて、少し緩くすれば組み合わせやすくなる、と考えてやってみたら、ひどい結果になった。
で、今は「同じタイプのブキがチームに偏らないように」という部分を緩くしているように思います。
昨日のフェスは、ローラー多数対チャージャー多数、みたいなひどい組み合わせがあって、あまり楽しめなかった。
（ローラーはチャージャーのカモです。ただし、誰かがチャージャーを倒してくれれば、ローラーが一気に塗りつぶして勝利できます。
ローラー多数対チャージャー多数では、一方的なゲームになってしまい楽しめません）
先に、少数派が勝ちやすいのは任天堂も理由がわからないのでは…と書きましたが、「わかっていて、故意にそうしている」可能性もあります。
というのも、投票が偏りすぎて多数派と少数派の人数が偏りすぎると、そもそも対戦のマッチングがしにくくなり、試合不成立が増えてしまうためです。
＃一応、同じグループ同士の対戦が発生するので、ゲームは遊べる。
でも、結果はそのグループの「一勝一敗」になるので、最終戦績には関係がない。
これが、「少数派に所属すれば勝てる」と噂されれば、アンケート時点で「どちらが少数派になるか」を予想して投票してくる人が現れ始めます。
読みが当たるかどうかはともかく、この結果少数派の人数が増えれば、少数派と多数派の人数差は少なくなり、試合が成立するようになります。
だとすれば、すでにこの効果は出ているように思います。
ここまで「読んで」遊ぶのは、勝ちにこだわるガチ勢だけなので、少数派側にガチ勢が大量に流れ込んで強さを底上げしている…という可能性もあるのです。
昨日のフェスでは、僕は少数派に属していました。
昼間遊んでいて、グループ内の対戦にはなりませんでした。
（少数派は、多数派とのマッチングが成立しやすい）
しかし、夜中に遊んでいた妻によれば、夜中は少数派にもかかわらずグループ内対戦が多かったそうなのです。
夜中でも寝ずに遊んでいる人はガチ勢が多いと仮定すると、夜中はむしろ少数派と多数派の人数比率が逆転している可能性があります。
また、バグありだった１１回目、少数派は非常に高い勝率で勝ちました。
マッチングが単に「バグ」だったのなら、少数派だけが高い勝率に…とはならないはず。
でも、少数派に強い人が多く、その分多数派に弱い人が多くなったとしましょう。
ここでバグが出て、強さと関係なくランダムに組み合わされたとしたら…
当然、少数派が勝つ試合が増えるはずです。
これも、すでに少数派にガチ勢が流れ込んでいると考える根拠です。
マッチングは、本来「同じくらいの強さの人」で行われます。
でも、全く同じということは難しいですし、少数派に強い人が多いのであれば、常に少数派が「ちょっと強い」試合が多くなってしまうかもしれません。
システム的には、なんの手ごころも加えずに五分五分の勝負になるようにしていたとしても、実はガチ勢によって前提が崩れていたら…
任天堂が調整を繰り返しても、なかなか理想通りにならずに苦労しているように思います。
なんか話がいろんな方向に発散してきました。
最後に、全然違うのだけど経験話を。
過去に、仕事で携帯電話向けのチャットサイトを構築したことがあります。
気軽におしゃべりを楽しんでもらうために、さまざまな指標でユーザー同士の「マッチング」を行うのですが、このプログラムの混乱ぶりがすごかった。
一応 NG ワードとかも持っていて、あまりに酷い言葉は入力させないのですが、そうでなくても緩くペナルティポイントを加算していました。
で、あまりひどい話になっていそうな部屋は、新たなユーザーが入るのを禁止します。
ユーザーごとにも「話の傾向」フラグを持たせていて、同じような傾向のユーザー同士をマッチング。
一方で、フレンド登録とかブロックとかあって、フレンドはできるだけマッチングしたいし、ブロックした人がいる部屋には入れるわけにいかない。
いい会話がないなー、と思ったら、一人で新しい部屋に入ることもできるのだけど、そのユーザーさんを延々と待たせるわけにもいかない。
そういう部屋は、他の人にできるだけお薦めしていかなくては。
新しいユーザーが来るたびに、「今お薦めの部屋」をいくつかピックアップし、その中で選んでもらうのですが、その舞台裏は細かな調整の連続でした。
考慮すべきことが多すぎて、どんなに調整しても満足いく状態にならないのね。
で、スプラ２のマッチングって、これと同じことを…もっと高度なレベルでやっているのだな、と思うのですよ。
勝率がおかしいのは、おそらく「気がする」ではなく、事実です。なにかシステムがおかしい。
でも、多少うまく行っていないからと言って、怒る気にはなれない。
多分、現在のマッチング自体がギリギリのバランスで成り立っているから。
願わくば、勝っても負けても楽しめるフェスにしてほしい、と思います。
マッチングにバグがあるとか、ブキが偏りすぎるとかは、あまり楽しめなかったよ。
以降、2018.9.21追記
最初のほうに追記した通り、第16回フェスからルールが改定になりました。
上の日記では、第13回終了時点まででの結果で論じていたのですが、せっかくなのでその後の2回分について記録しておきます。
第14回も第15回も、少数派の勝ちでした。
最終的なソロ戦・チーム戦の通算では、少数派が２５勝、多数派は５勝だったことになります。
おそらくは、何らかの都合で少数派のほうが「強い」状態でマッチングされることが多かったのかと思います。
そこで、新ルールでは、単純な勝敗を競うのではなくなっています。
1) チーム戦。塗った面積の合計を指標とし、勝つとさらにボーナスポイントをもらえる
2) 個人戦。同程度の強さ指標を持つ人が集められ、勝つと相手の強さの平均値をポイントとしてもらえる。このポイントの合計で競う。
チーム戦では、負けた側もポイントはもらえるため、勝負で差がつきにくくなります。
個人戦では、強い側が勝ってももらえるポイントは少なく、弱い側が勝てばポイントが多くなります。
これにより、マッチングした「強さ」のばらつきによる差がつきにくくなります。
さらに、ランダムに「10倍マッチ、100倍マッチ」という、獲得ポイントに倍率がかかる勝負が行われることもあるようです。
…全体として負けている側を「ちょっと」強い人たちでマッチングすれば勝つことが多いだろうし、その際に大量ポイント与えると、常に互角の勝負を演出しやすくなるよね。
勝負を拮抗させる力を介入させすぎると、「努力が報われない」ことにもなってしまいますが、お祭りなんだから勝負の行方が分からないほうが楽しいと思います。
よい改定なのではないかな。
…まだ新ルールで遊んでいないのですが、期待できそうです。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
最近は次女（小３）が熱心に Scratch をやっている。
長男（中２）も相変わらずやっているのだけど、学校に塾にと忙しくなかなか時間が取れないし、わずかな時間でスプラ２も遊びたい。
でも、時々急に「プログラム作りたい！」ってなって、短時間でそれなりに面白いものを作り、満足している。
長女（小５）は、長男も次女も Scratch をやっているのでやりたいと思っているようだが、二人にパソコンを取られてしまう形であまりやらない。
というか、どちらかというと時間があるならスプラ２か、DS の「どうぶつの森」をやってしまう。
パソコンを開くときもあるが、他の人がスプラ２を遊んでいて、ぶつ森でもすでにやることがない、というような場合だけだ。
いきなり話がわき道にそれているが、次女の話なのだ。
まだ論理性が怪しいながらも、プログラムの技術は覚えつつあり、どういうときにはどういう命令の組み合わせ、というのはすぐに出てくるようになっている。
そして、次のステップでつまづいた。
プログラムは作れる。じゃぁ、いったい何を作ればいいのだろう？
ある程度プログラムを覚えた初級者が、必ずぶつかる壁だ。
先日、新聞に Scratch の記事が出ていた。
そこには、取材したワークショップで、子供が簡単なゲームを作ったということと、そのゲーム画面、プログラムの一部が出ていた。
「これ作ってみる」と言って次女は作る。
プログラムが載っていない部分に関しては、画面を見ながら想像で。
ネズミを操作して、ネコから逃げながらチーズを目指す、というゲームが完成した。
ネコの動きルーチンを作れるほどの技術はないので、二人対戦だ。ちゃんと動くようになって喜んでいる。
でも、ネコを動かす人が本気を出すと、絶対にネズミが負けてしまう。
そこでネズミの速度を上げたが、今度は絶対にネコが追い付けない。
一応勝ち負けがあってゲームのプログラムにはなっているのだけど、「面白くない」という致命的な問題があるのだ。
「どうすればいい？」と聞いてくる次女。
ゲームを面白くする方法だったら、いくらでも思いつく。
しかし、そのアイディアを僕が出すわけにはいかない。
僕がアイディアを出して、それをプログラムするのであれば「技術は」上がるだろう。
でも、プログラム学習っていうのは技術訓練ではないのだ。
ここで考えないといけないのは「ゲームを面白くする方法」なんかじゃない。
そんな漠然としたものを考えていても、何も思いつかない。
そこで「何がつまらないのだと思う？」と聞いてみる。
自分の作ったものを「つまらない」と認めるのは勇気がいることだ。
最初のうちは、次女は「ちゃんとゲームになっているから、つまらないところはない」とか言い訳していた。
でも、ついには「絶対ネズミが勝っちゃう」と認めた。
何でそうなるのだろう？ と聞くと、チーズに向かって一直線に進むと、ネコが追い付けない、との答え。
じゃぁ、その部分をどうにかしてみれば？ と言ってみる。
しばらく考えて、「チーズは最初ランダムな位置に置かれるが、見えない。近づくと見えるようになる」というプログラムを作ってきた。
ネズミはチーズを探すためにうろうろする必要があり、探している間にネコが勝つチャンスもあるかもしれない、という考え。
なるほど、悪くない改良だ。
…でも、面白くなかった。
画面の広さは有限で、近づきさえすればチーズは表示されるのだから、ネコから逃げつつも画面をじぐざぐに進むと効率よく発見できてしまう。
今度も、何が面白くないのか考え、「自由に動けるのがよくない」という結論にたどり着く。
壁を設置して、ぶつかったらスタート地点に戻される、というプログラムを追加した。
壁はある程度ランダム位置に置かれるが、ネコもネズミも影響を受ける。
この「ぶつかったら」の判定は、ちょっと納得のいかないものだった。
Scratch で単純にあたり判定を行うと、絵の透明ではない部分がわずかでも重なると「ぶつかった」判定になり、厳しすぎるのだ。
でも、ゲームとしてはどちらが勝つか予測のつかないものになった。
これ以上掘り下げるのは本人の技術力を超えそうなので、改良点が見つからなかったら完成でいいんじゃない？ ってことにする。
ひとつゲームが完成したので、今度は「風船が出てきて、クリックして割るゲーム」を作り始めた。
実は、先のゲームを作る際に参考した画面に、風船が出ていたのね。
元々なんで風船を出していたのかは知らないけど、次女は「ゴールすると風船が下から上にたくさん飛んでいく」という演出として取り入れていた。
今度は、この風船をクリックするゲームにしたい、というわけだ。
まずは、ランダムな位置に、ランダムな大きさの風船が出るようにした。
最初は１秒ごとに追加されたけど、早すぎて画面が埋まってしまう、と５秒ごとにした。
でも、それでは遅すぎるからと、「最初は５秒で、以降 0.5秒づつ早く」表示されるようにした。
お約束の、最終的に 0秒ですごい勢いで表示されてしまう、というのを経験して、最高速度を１秒に制限。
「なんかゲームっぽくなった」とご満悦なのだけど、何か物足りないらしい。
クリックするごとに１点追加で点数表示つける、とかやり始めたのだけど、風呂入る時間になったのでひとまず終了。
長女、次女、妻がお風呂入りながら話をしている。僕はその間食器洗ってたのだけど、少し話声が聞こえる。
どうやったら面白いゲームになるか、という話。詳しくは後でお父さんに聞いてごらん、とか言っている。
で、風呂上がりに妻から質問。
ゲームを面白くする４要素、物真似と競争とめまいと…後何だっけ？
後の一つは「運」だね。
面白くする、というより、すべての遊びはその４要素に分解できる、という話。
面白いゲームを分解して考えるのは勉強になるけど、４要素を知っているから面白いゲームが作れるわけではない。
子供の知っているゲームで解説する。
ぶつ森は生活を楽しむごっこ遊びで、物真似。
スプラ２は勝ちを目指すゲームで、競争。
テトリスやぷよぷよは、ランダムなブロックをどう組み合わせていくか考える、運。
メイド・イン・ワリオは、次々と目まぐるしく変わるゲームのルールを楽しむ、めまい。
もちろん、ゲームのすべてが１つの要素で作られているわけではなくて、いろんな要素が組み合わさっている。
そう解説したら、すぐに長女から「ぶつ森では、住民にすぐに『魚釣りで勝負だ』とか言われる」と具体例が出た。
そうだね、それは競争が入ることでゲームらしくしている。
ゲームらしく、というのが大切で、この４要素はあくまでも「あそびの」要素に過ぎない。
ゲームは勝敗がつくことが必須条件なので、競争が必ず入る。
トランプの一人遊びの場合、運との勝負で「成功・失敗」になるけど、これだって勝敗のある競争だ。
競争がないものをゲームとは呼ばない。
ぶつ森は突発的に競争が起きることがあるけど、全体としてはゲームの要素を満たしていない、と知り、軽い衝撃を受ける長女。
僕は、ゲームを考える時に「目的」と「目的を邪魔するもの」で考える。
目的があるけど、簡単には達成できないとなれば、これだけでゲームが成立する。
先ほどまで次女が作っていた、風船をクリックして割るゲーム。
「風船を割る」という目的はあるが、それを邪魔するものがない。
どうしたらいいだろう？ というと、次女は風船が上に上がっていくようにしたいらしい。
最初に書いたけど、もともとそういうゲームを考えていたからね。
そして、単に風船を割った数ではなく、点数をつけたいのだそうだ。
クリックしづらい、小さくて動きの速い風船は高得点。
考えていたのはここまでだったみたいなのだけど、邪魔が必要と言われて「時間切れまでに何点取れるか」というアイディアを出した。
なるほど、ここでは「高得点」が目的となり、「時間」が邪魔するものとなる。
長女は、触ったらダメなものを出したらどうかという。
風船をクリックしていくのだけど、時々マウスカーソルが触れただけでゲームオーバーになるものを出す。
なるほど、その場合は「触ったらダメなもの」が邪魔するものになる。
最後にまとめ。
ゲームを作る時に決まった方法はない。
思うがままに、目的と、その目的を邪魔するものを設置すればいい。
それでとりあえずゲームになる。
でも、面白いかどうかは別問題。
どうすれば面白くなるだろう…なんて考えてもうまくいかない。
「つまらないところ」を見つけて、なんでつまらないのかを考える。
なんでつまらないのか、がわかれば、それを解消する方法も思いつく。
これを繰り返せば、ゲームは面白くなっていく。
途中で「あそびの４要素」の話を挙げたけど、入れたからと言って面白くなんてならない。
でも、面白くするためのアイディアの引き出し、くらいには役立つ。
いろんなゲームを遊んでみて、面白いと思う部分の要素を分解してみよう。
作っているゲームがある程度形になったら、「完成」ってことにして、次のゲームを作り始めるもの大切。
同じものを作り続けていると飽きるし、だんだん改良の「成果」よりも、「手間」のほうが大きくなっていく。
それよりも、どんどん新しいものにチャレンジしてみる。
たくさん作りちらかしていれば、時々とても面白いアイディアが出てくる。
初心者の内は、思いつくままに、たくさん作ってみるのがいい。
そうすれば技術も上がるし、どうすれば面白いかもわかってくる。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
最近 Unity を触ってみている。
「使ってみた」的な記事が流行したのはもう何年も前の話で、そろそろ Unity を使うのは「ゲームプログラマなら当たり前」になりつつある。
でも、僕は仕事柄、興味は持っていても Unity に触る機会が無かった。
ゲームプログラマじゃなくて、WEB プログラマだったから。
セガ時代に一緒にゲームを作った友人と会うと、「Unity やらないの？」的なことをたびたび言われた。
そいつも今はゲーム以外の仕事をしているのだけど、時々無性にゲームが作りたくなるので、なんか一緒に作ろうよ、って。
僕もゲームを作りたいと思うことはあるのだけど、なかなか暇がないのだな。
それで Unity に興味はあっても、手を出せずにいた。
でも、先日書いたように、仕事にしていた柱の一つを辞めることにしたので、少し時間に余裕ができた。
元々時間比率は少なくなっていたので、それほど暇になるわけでもないのだけど、ちょっと気になっていた Unity をインストールし、触り始めてみたというところだ。
ファーストインプレッションとしては、「売り物品質のゲームを作れる Scratch」というものだ。
Scratch は「あんなの本物のプログラム言語じゃない」と強烈な拒否層がいる環境なのだけど、Unity を使ってみた第一印象は Scratch と凄く似ている、というものだった。
これは、Unity を低く見ているのではないよ。
僕は Scratch を非常に高く評価している。
それが、結構多くのプログラマに支持されている Unity と類似だということに感心したのだ。
Unity は絶賛している人も多いのに。
Scratch は拒否感を持つ人も多いのに。
でも、両方使ってみると、非常によく似ていることがわかる。
どちらかといえば、Scratch で批判されている部分…データ調整だけでそれらしい形が作れてしまうので、「あんなのプログラムじゃない」と言われる部分を、さらに推し進めたのが Unity 、という言う印象だ。
とはいえ、どちらかが真似をしたというようなものではなく、自然な流れだと思う。
あえて言うなら、NeXT の Interface Builder とか、Win3.1 のころの VisualBasic が源流にあるだろう。
VB などは、GUI 時代の「アプリケーション」を作りやすいようにした環境だったのだけど、それをゲームに特化し、用途を限定することで扱いやすくしたのが Scratch と Unity 、という感じ。
どちらも、時間管理の概念をシステムで持っていて、個々の要素について、独立して「時間による変化」をプログラムしていけば、全体を構成できるようになっている。
もちろん、ゲームを「作りやすいように」特化したというだけで、ゲーム専用ではない。
画像表示を伴うインタラクティブなものなら守備範囲。
これって、結構応用範囲が広い。
とはいえ、まだ本当に「触ってみている」程度の段階。
せっかくなので、３Ｄでいくつか試作して、動作と「プログラミング作法」に慣れてみた。
最初はピンボール的なものを作ろうとして、３Ｄのモデラが無いと曲線などが作れないことに気付いて辞め、ビリヤードに変更した。
ビリヤードも、ちゃんとしたものを作るのは難しいので、適当に玉ががんがんはじかれているのを見て「気持ちいい」って感じただけ。
普通の言語で、物理エンジンを利用した３Ｄプログラムをしようと思うと、たとえライブラリを使っていてもそれなりに面倒くさい。
Unity なら画面を見ながらパラメーター設定するだけで、大体の枠組みが出来上がってしまう。
後は、どうしても必要なプログラムをちょっと作るだけ。
で、適当にゲームにもならないものを作り散らかした後で、やっぱり僕は２Ｄゲームのほうが好きなので、コラムスなど作り始めてみている。
本当はこれが完成してから「Unity いじってみた」って記事を書こうと思っていたのだけど、本格的に作り始めたら、やっぱりすぐには完成しない。
Scratch よりも若干生産性が落ちる感じだ。
もっとも、Scratch は不得意な処理を書く際にはとことん面倒くさいが、Unity 環境のほうが不得意部分が少ない。
生産性が落ちるのは、単に「あれもこれもできてしまうので、あきらめどころがわからなくて頑張ってしまう」結果による。
なお、コラムスが完成するかどうかは不明。途中で飽きるかもしれない。
まぁ、僕にとってはコラムス作るのは Hello World みたいなもんなので。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
少し前に「Unityの勉強始めた」って話を書いた。
仕事とは無関係に、全くの趣味として。
でも、趣味なので週に２時間程度しか時間を割けず、遅々として進んでいなかった。
今日、時々仕事でプログラム保守をしている会社の人と、打ち合わせ会議があった。
保守しているプログラム、見ず知らずの前任者が作ったものから、求めに応じて僕が随分と拡張している。
WEB 上で動作する Javascript のシステムなのだけど、前任者は「その時の仕様」でうまく動くように、非常に美しいプログラムを組み上げていた。
…美しい、というのは良いことばかりではない。
当時の仕様での動作としては問題ないのだけど、後から手を加えようとした時に改造しにくかったのだ。
ネットワークからデータを受けて表示するプログラムだったのだけど、無駄が排除されていて、受け取ったデータを集計し、表示した後はデータを残していなかった。
これが、後から「操作によってデータの絞り込み表示とかできると良い」という話になった時に、データが残っていないのだ。
仕方なく、根幹部分での「データ集計」は残したまま、送られてきたデータを溜めておく別部分を作り、絞り込みの際には別途集計を行って、それまで表示していたデータを「リセット」して、集計したデータを今送られてきたように流し込んで…
という、複雑怪奇なプログラムになっていた。
＃根本部分から作り直せばいいのだけど、それができない理由があった。
このプログラム、どこかで根本的に手を入れないと、今後の拡張難しくなっていきますねー、なんて話を以前にしていた。
実は、僕は「WEB 表示部分」を作っていたのだけど、システム全体としては、別の人が作った Android アプリと iOS アプリもあった。
さらに、別用途で使われる Windows アプリもあった。
目的が違うものなので画面なども違うのだけど、表示される内容は同じ…にしたいのだけど、少しづつ違って同じになっていない。
で、今回、「すべて Unity で作り直せないか」という相談。
各種表示プログラムがあるわけだけど、今一番使われているのは僕が作っていた WEB 画面なのだそうで、これをベースにして Unity で作り直したいらしい。
Unity なら、iOS / Android / Windows / MacOS / WEB など、各種環境向けにコンパイルできる。
それぞれに必要な UI などは微妙に異なるが、共通化できる部分は出来るだけ共通化していきたい、という意向らしい。
で、「Unity 使えますか？」と聞かれたわけだ。
ごめんなさい。使えません。
でも、ちょうどいま勉強中で、勉強のためにゲーム一本作ってみている最中でした。
そんなわけで、趣味でやっていただけだったのだけど、ちょっと勉強を急がなくてはならない状態。
今日は会議後、５時間ほど作業していた。
まだ「上から３つ並んだ宝石が落ちてくるだけ」だったプログラムが、「フィールドの配列を持ち、落ちてきた宝石が積み上がり、それらの宝石に落ちてくる宝石がぶつかると通り抜けられないような判定」までは出来た。
これを作ることが目的ではないのだけど、ゲーム一本仕上げるのって、ある程度システムを理解していないとできないからね。
実践的な勉強、というつもり。
実際に作り直すとしても、おそらくは秋から作業開始になるようだ。
その時に備えて「API マニュアルと首っ引き」でないとプログラムできない今の状態から脱出したいところ。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日、僕のページを参照しながらツイッターで話をしている人がいました。
＃時々エゴサーチしてますよ
話の内容は、「コンピューターのメモリアドレスはいつから使われ始めたか」。
この話のきっかけが、僕が書いた「バベジの解析機関」の話だったのです。
実際はパンチカードは２組有り、１つはプログラムを、もう一つはデータを格納した変数を示します。これは、現在のコンピューターと違い、メモリに番地を割り振ると言うアイデアがなかったために、常に変数を指示する必要性があった事に由来します。
上は僕の書いた記事の抜粋。
もう20年も前に書いた記事なので、いま読むと恥ずかしい、説明不足な部分があります。
実際には、メモリは番号で区別されてはいます。
ただ、現代的な「アドレス」とはちょっと違うものなのです。
数学のアルゴリズムには、計算対象を変えながら、同じ計算を繰り返す、という操作は頻繁に現れます。
例えば、行列の掛け算とか。
「掛け算」なんて基本的なものなのに、計算対象を変えながら繰り返すという複雑な操作が必要なのです。
今のコンピューターは、プログラム内蔵式です。
プログラムはメモリに保存されていて、いま注目しているアドレスの命令を実行したら、注目している部分を次のアドレスにずらし、順次実行していきます。
しかし、バベジの解析機関は、プログラムはパンチカードで供給され、読み込みながら順次実行されました。
カード送り機構があり、次々と新しいカードが読み込まれるために、順次プログラムが実行されていきます。
そこに「アドレス」という概念はありません。
プログラム実行に、アドレスは必ずしも必要ないのです。
バベジの解析機関は、データ保持用のメモリ（バベジの用語では「ストア」）を多数持ち、プログラムで命令でデータの取り出し・保持が指定された際には、もう一組のカードから「使うべきメモリ」を読み込みました。
つまりは、使用するメモリは、プログラムとは独立していて変更可能です。
プログラムを「ループさせる」ことは可能だったので、適切に２組のカードを設定すれば、計算対象を変えながら行列計算を行うようなことも可能です。
しかし、このカードは変数が必要になるごとに読み込まれ、変数自体を計算によって求めるようなことはできません。
Ｃ言語風の書き方になりますが、
A1 + A2
と
A[1] + A[2]
の違い、と言えばわかってもらえるでしょうか。
前者の 1 2 は、区別するための記号にすぎません。連続した数値ではないのです。
しかし、後者の 1 2 は、記号ではなく数値です。連続したメモリの中の位置を示す「アドレス」です。
それぞれのやり方で、10個のデータの合計を求めようとすると、こうなります。
SUM = A1 + A2 + A3 + A4 + A5 + A6 + A7 + A8 + A9 + A10;
for(i=0;i<10;i++)SUM += A[i];
前者のやり方で、データが 100 個に増えたら大変です。
しかし後者なら、わずかな変更で対応できます。
もう少し根源的な言い方をすると、「アドレスが計算対象か否か」です。
コンピューターは計算のための道具ですが、その計算に使用するメモリのアドレスすら、計算の対象とできるかどうか。
メモリに区別のための番号が割り振られていたとしても、計算対象でない場合には、「アドレス」とは呼べないように思います。
ではいつからメモリにアドレスが割り振られたか、というと、実は話は簡単で、プログラムがメモリ内蔵型になった時だと思われます。
ENIAC(1946) は、配線によってプログラムを行いました。
そもそも、現代的な「プログラム」のイメージですらありません。
それ以前のハーバードマーク１(1944) では紙テープでプログラムを行いますが、まだアドレスの概念はありません。
データを保持できる場所…メモリと言っても差し支えない場所は 72個あるのですが、実はすべてが「カウンタ」で、それぞれがタイガー計算機だと思ってください。
タイガー計算機ですから、足し算・引き算だけ出来ます。
72個のカウンタの、どこからどこに足し合わせるか、というデータの流れをひたすら記述することがプログラムになります。
この 72 個は、番号で区別されていますが、ただの区別の記号です。
この番号を計算対象として、配列を実現するようなことはできません。
最初にメモリ内蔵型を提唱したのは EDVAC(1951) です。
この際に、「メモリには、プログラムとデータを一緒に入れてしまう」という決断をしています。
しかし、さすがにこの二つは別物だろう…ということで、1bit の区別フラグがつけられています。
プログラムからは、データを読み書きすることはできるのですが、プログラムを読み書きすることはできません。
EDVAC は命令を「５つ組」で示します。命令と、アドレス４つです。
アドレスは、演算対象となるデータが入っているアドレス２つ、結果格納アドレス、次の命令のアドレスです。
現代のコンピューターから見ると、「次の命令アドレス」が随分と奇異に見えます。
自動的に次のアドレスの命令を読み込むのではなく、いちいち次の命令のアドレスを指定する必要があるのです。
これは、「メモリに割り振られたアドレスは、識別用の記号であり、連続した数値ではない」という設計思想のためです。
もちろん、演算対象・結果格納用のアドレスも、連続した数値ではありえません。
ここには直接数値を入れてあり、アドレスと見なされるため、配列アクセスのように「アドレスを計算する」ことはできないのです。
EDVAC の設計論文を見て、先に完成させてしまったのは EDSAC(1949) です。
この際、回路を簡略化し、素早い完成を目指す中で、データとプログラムを区別するビットが省略されています。
これは、うっかり間違えてプログラムを破壊しないための、保護機構でした。
逆にいえば「うっかりミス」が無いように人間が注意すれば、機械として作りこむ必要はないと判断したのでしょう。
用意された命令は、EDSAC のものとそれほど変わりません。
ただし、「次の命令アドレス」は不要で、連続したメモリの命令を順次実行していきます。
おそらくは、「次の命令アドレス」を無くせばその分のメモリが不要になる、という簡略化のための判断です。
しかし、これにより「メモリアドレスは連続している」という設計思想が生まれています。
とはいえ、データアクセスの際には、固定値でアドレスを示します。計算できません。
これが当時としては標準的なやり方だったためです。
ところが、ここにうれしい誤算が生じます。
プログラムの保護機構を省略したことが、非常に柔軟なプログラムを可能にしていました。
保護機構が無いということは、プログラムもまた、同じメモリに置かれたデータに過ぎないということです。
プログラムの置かれた特定のアドレスを演算対象として、書き換えてしまえば…
アドレス部分を書き換え、「順次アクセスする」ようなプログラムが可能になるのです。
当初の設計に織り込まれたものではないとはいえ、手法に気づいたら積極的に利用した節があります。
プログラム自身を演算対象とできる…これはコンパイラなどが作れるということですし、実際簡易なアセンブラ兼ローダー兼 BIOS である「ブートローダー」が作られています。
EDSAC では、メモリアドレスを計算対象とし、配列演算ができるようになったのです。
蛇足ながら、EDSAC よりも完成の早かった、The Baby(1948) でもプログラムの自己書き換えは可能だったように思います。
しかし、これは実験機のため、極端にメモリが少ないマシンでした。
小さなプログラムを書いたらメモリいっぱいで、自己書き換えなどのテクニックを駆使して配列操作するような余裕はありません。
現代の CPU では、「レジスタに入っている数値をアドレスとしてメモリにアクセスする」というような機能があります。
レジスタは計算のための特殊メモリですから、この数値をアドレスとする、というのは、アドレスを計算対象とすることにほかなりません。
EDSAC では「自己書き換え」で実現されていた方法が、今では CPU の命令で普通に用意されているのです。
冒頭の話題に戻りましょう。
コンピューターのメモリアドレスはいつから使われ始めたか。
この質問の裏には「今のように」という観点があるでしょう。
その元祖は、EDSAC だと思います。
先に書いた通り、EDSAC とほぼ同時期のコンピューターでは、メモリアドレスを計算対象とは「しない」のが普通でした。
その中で異質だった EDSAC のやり方が現代に残っているのは、このやり方が非常に強力だと皆が認めたからでしょう。
2018.7.17 追記
ツイッターで、こちらの掲示板で同じ質問が出ていた、と教えていただきました。
話の冒頭で「先日」と書きましたが、６月下旬の話だったと思います。
その掲示板の日付は６月２３日。
僕の該当ページも参照されていますし、1) ツイッターで話題にしていた人たちが質問した 2) この質問を読んだ人がツイッターで話題にしていた のどちらかではないかと思います。
掲示板でも、「ノイマン型あたりだろう」と正しい認識なのですが、「チューリングマシンから」と言っている人がベストアンサーになっています。
あまりにも的外れなので、ちょっと突っ込み入れたくなった次第。
チューリングマシンは、紙テープが最新のメディアだった時代の発想なので、基本的には「無限に長い紙テープに、検索キーとデータを書き込んでおく」という発想で考えられています。
いわば、キーバリューストア。アドレスはないです。
そもそも、今ではコンピューターの元祖のように言われていますが、もともとは「ゲーデルの不完全性定理」という、数学上の大問題を証明するための道具にすぎません。
ここら辺、詳しくは過去に書いたことがあるので、興味がある方はそちらをお読みください。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
1998年の夏の暑い時期だったと思います。
韓国から、セガの下請けになった、というプログラマーが研修に来ました。
で、「教えてやって」と、僕に仕事が丸投げされました。
韓国語なんてわからない。英語すらできない。
そもそも、教えてやってと言われても、何を教えればいいのかも聞いてない。
当時の韓国の世相を説明しといた方がよさそうだな…
韓国は、1961年にクーデーターがおこり、軍事政権になっています。
軍事政権下では、国民の権利などは抑圧されていた一方で、強引な（一部の人を泣かせるような）政策によって経済成長も遂げています。
が、1979年に民主化デモがおこります。そして大統領暗殺。
これにより民主化が行われるか…と思われたのですが、1980年にふたたびクーデターがおこり、軍事政権は続きます。
それでも、経済的に急成長を遂げた韓国は、1988年のソウルオリンピック誘致に成功します。
しかし、1987年、再び民主化運動がおこり、IOC は「治安が維持できない場合は、オリンピックをロサンゼルスで行う」と決定。
軍事政権は、経済成長した韓国を、オリンピックで世界に誇示するつもりでした。
これは、軍事政権を続けるより重要なことでした。
そこで、民主化宣言を行います。
これにより軍事政権は終わりました。
1988年、ソウルオリンピックの年には海外の渡航も自由化されました。
これ以前は、日本と韓国の関係は冷たい物でした。
しかし、徐々に民間レベルでの交流は増えていきます。
韓国でも、同じアジアの発展した国として、日本にあこがれる若者が増え始めます。
軍事政権の時代には、娯楽は「不要なもの」という扱いでした。
テレビゲームも発売されていません。
（パソコンである MSX は発売されていましたし、そのゲームも売られていましたが）
1989年、「ファミコン」と「セガマスターシステム」のライセンス品が登場。
ちなみに、スーファミは日本で 1990年登場。メガドライブは 1988年登場です。
「あこがれ」でもある日本のゲーム機は、家電各社が日本の会社からライセンスを取得し、製造・販売します。
直接日本のメーカーが輸出販売しないのは、日本企業が直接活動するのが許可されていなかったため。
民間レベルでの交流は増えていましたが、韓国と日本の関係はまだ冷たい物でした。
僕がセガに入社後も、いくつかのゲームの「韓国版」を作るのを見ています。
1996年くらいだと、テレビゲームはすっかり人気の商品で、業務用も売れていたのです。
ただし、厳しい決まりがあって、どこか一カ所でも日本語が入っていると、韓国での販売は許可されませんでした。
当時は、日本にあこがれる若者も多い一方で、反日の動きも強かったのです。
文字テキストなどを変えるだけでなく、画像なども細かくチェックして、とにかく日本語を完全になくさないといけません。
実は、こんな苦労をしてゲームを作っても、それほど売り上げがよかったわけでもないのです。
それでも韓国版を作ったのは、これから韓国が伸びそうな国だと考えられていたからでした。
そして、1997年。アジア通貨危機が起こります。
アジアの小さな国の経済は、欧米の強大な資本の前では簡単に翻弄されてしまいます。
欧米の投資家が、アジアの通貨を空売りし、売りが多いので値が下がったところで買戻す、というテクニックを使い、儲け始めたのです。
投資家が儲かるということは、「誰かが」損をしているということ。
その誰かが、この場合はアジアの小国でした。
具体的には、タイ、インドネシア、韓国。
マレーシア、フィリピン、香港もターゲットにされています。
さらに、直接のターゲットにされなかったものの、これらの国の不景気の影響で、中国、台湾、日本なども影響を受けています。
韓国では、経済が完全に破綻し、国際通貨基金（ＩＭＦ）の管理下に入りました。
ＩＭＦにより、次々と、韓国内の巨大企業が解体されていきます。
…と、これが 1998年当時の韓国の様子。
この状態の韓国から、プログラマーが研修にやってきたのです。
ちなみに、上に書いた「当時の状況」ですが、当時の僕は認識してませんでした。
今調べて知ったの。
ただ、韓国ではゲームは結構人気ある、ということと、経済的に今なんかやばいらしいよ、程度には知っていたかな。
ちなみに、完全な余談だけど、日本と韓国の関係が急に改善するのは、2002年のワールドカップサッカー共同開催がきっかけ。
今でも日本を嫌っている韓国人、韓国を嫌っている日本人は多いのですが、総体としてはおおむね良好な関係だと思います。
さて、話を戻して韓国からの研修生のこと。
彼らは、韓国版のプリクラを作るために、フレームなどのデータを差し替える方法を学びに来たのでした。
プリクラは当時の大人気ゲーム。顔写真シール自販機ですね。
さまざまな「フレーム」がありました。プログラム内容は同じでも、画像などの差し替えでいくらでもバリエーションが増やせる、ということですね。
特に ST-V になったプリクラ２からは、このフレームにフルカラー画像を使えるようになったため、観光地の綺麗な風景をフレームにして写真を撮れるとか、大人気アイドルと並んでいるかのような写真が撮れるとか、多様な展開を始めていました。
＃と書いていて思い出した。たしか当時大人気だった SMAP 版を作ったら、とんでもないインカムを叩き出したはず。
5人それぞれが別バージョンで、並べられた５台それぞれが「朝から晩まで、途切れなく稼働」しないと出ない収入となった。
で、プリクラはアトラスの開発したゲームでしたが、販売はセガ。
例によって、業務用外注作品はＡＭ１研を通しています。
そして、フレーム変更などのバージョン変更も、ＡＭ１研でもやっていました。
こうしたデータ差し替えはセガ…ＡＭ１研のほうでもやっていました。
このやり方を学びに来た、ということね。
えーと、僕はプリクラチームではないので、実際の作業内容は知りません。
でも、それ以前の「ST-V 開発機材の扱いに慣れる」部分から話を始めなくてはならず、そこなら確かに僕が教えられます。
プログラマの人は韓国語しか話せなかったのですが、一緒に来ていた営業の人が日本語が出来ました。
そこで、機材の説明、セッティング方法などは通訳してもらう形で、お二人に説明します。
たしか、セッティングは１日。
プリクラのソース一式を展開し、コンパイルし、開発機材で動かし、デバッガでメモリなどを覗く…
というのが翌日の作業じゃなかったかな。ここまでは順調。
さて、問題はここから後です。
「この後は技術的な話だから」と、営業の人は別の仕事でどこかに行ってしまいました。
韓国語しかわからないプログラマに、日本語しかわからない僕が、「フレーム画像の変更方法」を教えなくてはなりません。
そもそも、僕がやり方を判っていないので、プリクラチームの人に聞きます。
画像データをディレクトリにいれて、それをデータファイル化するツールを起動。
その後、データへのポインタをこの構造体に入れて、いくつのデータがあるかをこちらのメモリに入れて…という感じ。
で、いよいよ教えるのです。
韓国プログラマの隣に座って、UNIX のコマンドラインを操作します。
「あー…、ふれーむぴくちゃー、せっと、ぢす、でぃれくとり」
そういいながら僕が cd コマンドでディレクトリに入ると、プログラマがパス名をメモします。
「あんど、らん、ぢす、こまんど」
そういいながらデータファイル化するコマンドを実行すると、やはりそれをメモします。
「ちぇんじ、ぢす、ふぁいる」
構造体が書かれたファイルをテキストエディタで開くと、ファイル名をメモします。
「ちぇんじ、ぢす、でーた」
構造体にファイル名を書き込むと、構造体の名前をメモします。
一部始終こんな感じ。ブロークンイングリッシュと、Ｃ言語のファイルを見ながらの「ちぇんじ、ぢす」の連続。
向こうから質問が来るときも似た感じ。
でも、「プリクラのフレームを変更する方法を学びたい」という目的ははっきりしていますし、Ｃ言語はどちらも使える共通言語。
多少もどかしい部分はありましたが、実際にＣのソースを書き換えて「ぢす」と言えば通じる。
ブロークンイングリッシュで、というよりは、Ｃ言語で会話していました。
set LANG=C です。
書き換え方法を学んだあと、実際に適当なデータを使って一通り作業をしてみて、その間にもわからないことがあれば質問を受け付けました。
結局、ＡＭ１研での研修は１週間程度ではなかったかな。
その後、「仕事のために借りたアパートで以降の作業を行う」というので、機材を貸し出す手続きをし、機材を持ってアパートを訪れました。
…驚きました。８畳程度のワンルームではなかったかな。
そこに、４人で生活していました。研修に来ていたプログラマーは「チーフ」で、部下が２人いたのね。
狭い中に４人分のパソコンがすでに置いてあり、さらに開発用の大きな機材を持ち込みます。
ここは「仕事場」ではなく、滞在中の住居でもあるそうです。夜になると機材の隙間に潜り込むように眠る。
夏で暑いのにクーラーもなく、扇風機が１台回っていました。
びっくりしていると、日本語のできる営業の人が
「日本物価高いですからネー、これでも出せる額ギリギリデス。
彼らは本国ではエリートだから期待されてマス。
日本で暮らすため、たくさんお金もらってマス」
とのこと。
期待されて、精いっぱい出してもらっても、冷房もないワンルームで４人暮らしがやっとなのです。
それでも、期待を背負ってきているので、一生懸命ゲーム作成のノウハウを吸収しようとしているのです。
このハングリー精神、今の日本では、とても真似できない、と思いました。
＃ここでの「今」は、1998年当時のこと。
その後も、何度か、電話で質問に答えたりしていました。
日本語のできる営業の人経由だったと思います。あのプログラマーと電話越しに話せたとは思えないから。
しばらくして「一度韓国に戻ります」という連絡が来ました。
当時の韓国では就労ビザを取るのが厳しくて、観光ビザで日本に来ていたのだそうです。
で、さらに後に「また戻ってきました」という連絡。
それからしばらくして「ゲームが完成しましたので、韓国に帰ります」という連絡。
帰る前にお別れ会をやろう、ということになり、セガ近くの居酒屋で一緒に飲みました。
久しぶりに会ったプログラマーの人と、たどたどしい英語でゆっくり話をしました。
難しい話は出来ないのだけど…
日本の文化が大好きで、漫画とかも好きだけどゲームが特に好き、と言っていました。
でも、韓国では日本の文化は規制されていて、なかなか触れることができない。
今回の日本滞在では、色々見られてよかった、とも。
そして、ゲームが好きだから、いつかヒットゲームを作りたい、と言っていたと思います。
当時の韓国では、まだゲーム制作者という職業は珍しくて、大きな夢だったようですが。
今では、韓国はゲームの輸出大国です。もちろん、世界的なヒット作も出ています。
彼は夢をかなえられたのでしょうか？
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
まずお詫び。
今朝未明、深夜１時40分ごろから、今朝７時20分ごろまで、当ページのサーバーが死んでました。
で、原因。
台風 24号は昨夜深夜に神奈川県に最接近し、大規模停電を引き起こしました。
我が家も停電しました。
停電は、深夜 ０時半ごろに２分程度、その後復旧しても、再度２分程度の停電。
たしかもう一回くらい短い停電があった気もしますが、ともかく最終的には長期停電に入りました。
おそらくそこらじゅうで架線が切れ、そのたびに経路が切り替わって復旧、を繰り返したのだと思います。
ついにうちに通電する経路がなくなったのだろう…と想像しましたが、だからと言ってどうしようもない。
念のためにサーバーシャットダウンするか考えましたが、主に閲覧用のサーバーです。
書き込みが多くないなら、急に電源が落ちても被害は少ないはず。ジャーナルファイルシステムだし。
というわけで、ほっときました。
短い停電は、UPS （無停電電源装置）の働きで影響が出なかったのですが、さすがに長期停電は無理。
けっこな時間アラート音を響かせ、さすがにもうだめだ、と音が変わり、最後に電源断を知らせる音（断末魔）になって、静かになりました。
で、やっと静かになったので寝ました。
サーバーのログを見ると、１時４０分ごろの動作を知らせるメッセージが最後でした。
なので、停止もそのころです。
朝５時半に起き、枕もとのスマホの充電状態を見て、まだ停電が続いていることを確認します。
停電の情報を調べよう…と思い、「神奈川」まで入れたら、Google さんが「神奈川 停電」とサジェスト。
サジェストされるくらい、大変なことになっている？
神奈川県全域で、１７万戸が停電中だそうです。
あまりにも停電戸数が多いので、復旧にどれくらいかかるかは不明、とのこと。
起きてまずとった行動は、水を汲むことでした。
我が家は災害に備えて、３０本くらいのペットボトルに水を汲み置きしていますが、普段から使うローリングストックです。
この時は、この数日で使った１０本くらいが空でしたので、これに水を汲みました。
水道は、ポンプで水圧をかけていないと水が出ません。
このポンプは、通常は送電される電気で動いていますが、緊急時にも水の供給ができるように、水道局には非常用電源も備わっています。
でも、停電が長引いた場合はどうなるかわかりません。それが水を汲んだ理由です。
今日は中学生の長男は休みですが（理由は後述）、小学校はあります。
電気がないと料理はできませんが、幸い、食パンの買い置きがありました。
最悪の場合、これで朝ごはんにできます。
しかし、そもそもそんな大変な状況だと、休校になる可能性もあります。
庭に出ます。
自転車が全部倒れているのは、想像通りで問題ありません。
昨夜は想像を超える暴風雨だったので、わずかに開けてある車の窓から雨が入っていないか心配でした。
（日差しで車内が蒸れないように、ほんの少しだけ窓を開けているのです）
しかし、さすがにそれはありませんでした。
どの程度の雨か、実験してみようと思って置いといたバケツは、風で転がっていました。
雨は降るが風が当たりにくいような場所に置いていたのですが…
一晩立ったら雨水が満杯に…って予想していて、昨晩暴風になる前に、ある程度溜まっているのを確認していました。
水が入っているバケツを、風当たりが強くないところでひっくり返すのだから、暴風の強さがわかります。
で、庭にはさしたる被害なし。
朝刊が来ていたので取って室内に戻ります。
明け方なので室内は暗いです。当たり前ですが電灯はつきません。
窓から入る光で新聞を読んでいたら…
ピピッ て電子音がして、いろいろな家電が動作を開始します。
時計を見ると、６時２５分ごろ。どうやら停電から復旧したようです。
そこからすぐに、サーバーの電源を入れに行きました。
普段サーバーにはディスプレイを接続していないので、十分な時間を待ってからアクセスしてみます。
…アクセスできません。
なにかトラブルが起きているようだ。ディスプレイとキーボードを接続してみます。
なんか、起動中に止まっているようだな。
リセットしてみます。
しばらくして、再起動に成功しました。
これは、家庭内用のサーバー。
仕事の実験などで使っているほか、家庭内の DNS などを受け持っています。
DNS が動き始めたので、家庭内の LAN が使えるようになりました。
でも、もう一台の公開用サーバーがリセットを繰り返しても起動しない。
なぜか、ディスプレイを接続しても画面が出ない。壊れたか？
仕方ないので一端リビングに戻ります。
７時１５分。小学校あるから、子供に朝ご飯作らなくちゃ。
そしたら妻が「私朝ご飯作るから、サーバー復旧しておいでよ」と言ってくれました。
サーバーの前に戻ると、LAN のアクセスランプがちかちかしていました。
さっきは点いてなかったのに。
アクセスしてみると、問題なくアクセスできました。
ただ起動に長い時間がかかっていただけらしい。
fsck でも走っていたのかもしれません。
というわけで、サーバーは朝７時２０分ごろには復旧しました。
さて、時系列がおかしいけど、昨日昼の話。
最初のほうに書いた、長男の中学校が休みの理由です。
長男の中学では、この週末文化祭でした。
金曜日は、文化祭行事の１つである、合唱祭。
小さいとはいえコンサートホールを借りて行うものです。
金曜日は、小学校はお休みでした。前週の土曜に運動会をやった、代休です。
そこで、この合唱は家族で見に行きました。（長男のクラスの部分だけですが）
土曜日は、文化祭の準備。そして日曜日は文化祭。
こちらも一般開放されるので、やはり家族で見に行きました。
で、この日曜日が問題なのですね。
台風が来る、とわかっているので、延期する場合と、延期はしないが時間短縮する場合の２通りの「特別スケジュール」が予定され、詳細は当日朝の判断まで引っ張ることになりました。
で、当日は「１５時までの予定を１３時までに繰り上げるが、決行」という判断に。
ところが、朝方降っていた雨はやみ、文化祭が始まる９時ごろには空は晴れます。
そのまま良い天気は続き、むしろ暑いくらいで…
内容は去年と同じく中二病で楽しかったです。
ちなみに、長男は自然科学部で、調べたものをポスター展示。
昨年は何かキノコ調べてたのだけど、今年は珍しい鳥を調べてました。
去年のキノコは、猛毒を持つものだったらしい。そして今年の鳥も猛毒を持つ鳥。
そうか、長男の興味を持つキーワードは、「猛毒」か。
…普通に調べものしてるな、と思ってたけど、長男もちゃんと中二病でした。
いい天気は、終了する１３時まで続きました。
これなら普通にやっても大丈夫だったのでは、と思いますが、それは後知恵。
大型の台風が来ているのは事実ですし、早く切り上げた判断は正しいと思います。
この穏やかな天候は、１８時ごろまで続きます。
台風だから、と冷凍コロッケを買ってきてあったのに、全然台風らしい気候ではない。
コロッケは揚げておいしく食べましたけど。
＃いや、そもそも台風コロッケってそういうことではないだろう。
で、案外大丈夫だなー、って思っていたら、２２時ごろから急に暴風雨になり、最初に書いた事態となるわけです。
ちなみに、雨雲レーダー画像をしょっちゅう見てましたけど、我が家のある鎌倉市付近がたまたま大丈夫だっただけで、神奈川県でも平塚のほうなどは凄い雨降ってました。
＃当日 21時ごろ追記。
神奈川県内はいまだ６万件以上の停電が続き、特に鎌倉の隣、藤沢ではいまだ 9200軒が復旧していないようです。
鎌倉市でもいまだ 600軒が停電中。
我が家は早朝に通電して助かりましたが、大変な台風でした。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
さて、先日夏の旅行記をまとめたのだが、この中に JS オートレンタカーという章がある。
このレンタカー屋さん、３か月前にオープンしたばかりで、まだあまり知られていない。
知ってもらう手段として WEB ページを作っているのだが、そもそも検索されない。
Twitter とフェイスブックで、何かしらの情報を毎日書くようにしているのだが、人が来ないという。
で、ページを検索上位に持っていくコツを話したのだけど…
旅行記には会話内容を書かなかった。旅行と関係ないから。
それどころか、その時実際話した内容も、時間がなくて全然詳細を教えられてない。
そこで、ちょうどいいケーススタディーとして、検索上位を目指すための方法を書いてみようと思う。
ただし、僕はＳＥＯ専門家ではない、と最初に断っておく。
ＳＥＯって、「検索エンジン最適化」の略語ね。検索サイトで、自分のページを上位に持ってくるテクニック。
僕はある程度 WEB 関連の仕事もしているし、ＳＥＯ関連の知識も人よりあるとは思うが、素人にすぎない。
もしかしたら細かな話は間違えているかもしれない、と覚悟しておいてほしい。
まずは一般論から。
ここで言う検索エンジンとは、現状ではほぼ Google だ。
実際には他にもいろいろあるのだけど、使用頻度のシェアで Google が 3/4 を占めている。
そして、残りの 1/4 は、Google の「発明」した方法を真似たものだ。
各社工夫を凝らし、少しづつ違う特徴を持ってはいるものの、基本的な概念は変わらない。
ここでは、各社ごとに少しづつ違う特徴の部分まで踏み込むつもりはない。
また、Google ですら、時々細かな部分の計算方法を変える。これにも踏み込むつもりはない。
なぜなら、それらの部分に踏み込むのは、手間のわりに効果が少ないからだ。
目指すのは「今よりも検索されやすくする」ことであり、「世界でトップクラスを狙う」ことではない。
また、検索されるにしても、「どのような目的で検索されたいのか」という問題がある。
単に検索されやすくするのではなく、検索してきた人に対して何をやりたいのかによって、手法が細かく異なるのだ。
商品を売りたいＥＣサイトなのか、記事で人を集めて広告収入を狙うサイトなのか、WEB 自体を広告媒体としたいのか。
商売っ気抜きにして、趣味で作ったサイトを見てほしい、という需要だってあるだろう。
最初にケーススタディーと書いたのはそのためで、目的を決めないと話が発散してしまい、無意味になるのだ。
ここでは伊豆大島のレンタカー屋さんとして、伊豆大島への観光を考えている人にお店の存在を知ってほしい、というのを最終ゴールと考えてみる。
▼検索され、読んでもらう
検索上位に来るためには、まず検索されなくてはならない。当たり前の話。
まずは、ここから考えていこう。
そもそも、検索エンジンは何をやっているのだろう？
「伊豆大島 レンタカー」と検索した時、検索エンジンは、伊豆大島のレンタカー屋さんを探しているわけではない。
単に、検索に使われた単語を含んでいるページを探しているだけだ。
逆に考えれば、検索に使用された単語を含んでいないページは、検索しても表示されない。
検索されるためには、多くの単語を含んでいるページを作る必要があるんだ。
文章を書くというのは大変な作業で、苦手としている人も多い。
だから、そもそも短い文章しか書けない Twitter とか、写真だけでいい Instagram とか、「文章を書かずに」交流できるサイトが流行する。
でも、多くの人に検索してもらうための武器は、文章なのだ。
文章をほとんど含まないページは、検索してもらえない。
文章が長ければ、そこに含まれる単語の種類も増え、より多くの検索に引っかかる。
◎長い文章を書こう
検索エンジンのプログラム的にはともかく、長すぎる記事は読みにくいのでは…という考えもある。
ほんの数年前は、だから記事は短いほうが良い、とされていた。
しかし、今はこの考え方は間違っているとされる。
検索エンジンは、やっぱり文章を相手にしている。長い文章のほうが検索されやすい。
とはいえ、どんなに長い文章を書こうとも、ありとあらゆる単語を含むことなんてできない。
そこは、文章の数でカバーしよう。ここでは、文章の数を「記事数」と表現することにする。
たくさんの記事を書けば、WEB サイト全体として使われる単語の数は増える。
多くの記事があることは、もっと重要な別の効果をもたらせてくれるのだけど、これはまた後で書こう。
◎たくさんの記事を書こう
もう一つ、大切なポイント。
検索エンジン最適化、なんて言っても、最終的に文章を読むのは人だ。機械ではない。
順位を上げるために、なんて小細工した文章は読みづらい。
誠実で読みやすい文章を心掛けるべきだ。
文章を読む人を想定して、その相手に伝わるように、情報を整理して書くこと。
読む人の想定って、結構大切。
伊豆大島に観光旅行に来る人、という想定をしただけでも、「観光客だから、大島のことに詳しくない」という前提が出来上がる。
じゃぁ、観光地の場所を教えても、土地勘がないからわかりにくい。
バスなら待ち時間含めてどれくらい、車なら街から何分くらい、ということも書くと、観光地に行ってみるかどうかの判断基準になる。
（ついでに、レンタカー借りたほうがいいよ、ってアピールもできるかもしれない）
情報を整理するというのは、こうした「対象読者に向けての」情報整理だ。
観光客だから必要な情報もあれば、観光客には不要な細かすぎる情報もある。
何が必要で、何が不要かを吟味しないといけない。
とはいえ、考えていても始まらない。一度文章を書いてみることだ。
そして、一回書き上げたらその文章を破棄して、もう一度書く、くらいの心構えだと良い文章が出来上がる。
文章を書きあげるって、自分の中で情報を整理しているということなのね。
でも、そこで書きあがった文章って、情報を整理しながら、同時に伝え方も考えていたものなので、実は出来が悪い。
もう一度書くと、頭の中で整理できている情報を、今度は「どう伝えよう」ということだけに集中できる。
こちらのほうが良い文章になる。
実は、さらにもう一度書くと、伝え方も決まった後なので、テンポよく読める文章にしようとか、また別の部分を改良できる。
書くたびに良い文章になる。
◎想定読者を決めて、その人に伝わるように情報を整理しよう
▼ページランク
では、検索に引っかかったとして、どうすれば上位に表示されるのだろう？
ここからいよいよ、上位表示のための話になる。
Google では、すべての WEB ページに、「ページランク」と呼ばれる点数をつけている。
これは順位を出すうえでの指標の一つに過ぎないのだが、とても重要な指標だ。
ページランクを上げることが上位表示の方法の一つになる。
ちなみに、ページランクは内部的な情報であり、現在非公開だ。
ページランクを上げるといっても、どのように上がっているかを確認する方法は、ない。
では、どうすればページランクが上がるのか。
これは、ある種の人気投票になっている。
投票権を持つのは、Blog などの WEB ページを作成している人。つまりは「情報発信」する能力のある人。
情報を受けるだけの人と、自分でも発信する人は、観点が違う。
発信する側の人は、情報をまとめることの難しさを知っている。
そして、それらの人が「良く情報がまとまっている」と思ったページに投票する。
投票方法は、自分が作っているページから、ほかのページをリンクすることだ。
リンクされる、というのが「投票された」ということで、ページランクが上がる。
ちなみに、リンクは１つ１票ではない。
ページランクが高いページからのリンクは得点が高く、低いページからのリンクは得点が低い。
ページランクが高いということは、多くの人が「良く情報がまとまっている」と感じているページだ。
作っている人の審美眼が高い、ともいえる。
そして、審美眼の高い人が選んだページというのは、それだけ良いページだと考えられるのだ。
リンクは HTML の基本的な機能だ。
HTML とただのワープロ文章の、決定的な違いだといってもよい。
だから、WEB ページにはリンクがたくさん使われている。
これを「投票」と考え、良質な文章を探す手掛かりにしよう、という発想。
実際の検索結果の表示位置は、ページランクだけでなく多くの要因によってきめられている。
しかし、ページランクは最も重要なものだ。
▼リンクを得る
ページランクを上げるのにリンクが必要だということはわかった。
では、運よくリンクされるのを待つ以外にないのだろうか？
まずは、自分のページから、自分のページをリンクしよう。
WEB サイトには、複数のページがある。そのページ間でリンクを作るのは自分でできることだ。
特にリンクを作らなくても、Wordpres などの CMS を使っていれば、トップページや各コーナーへのリンク、時系列で前後の記事へのリンクなどが作られるだろう。
しかし、それだけでなく、記事中でも関連記事などへのリンクを作るように心がける。
先に「たくさんの記事を書こう」と書いたが、それらの記事それぞれが投票権を持ち、サイト全体のページランクを上げることができる。
機械的に作られたリンクは票を均等に配分してしまうが、記事中のリンクにより濃淡を作ることができる。
多少なりともページランクが高くなった記事は、検索などで上位に表示されやすくなる。
そこが足掛かりになって、サイトに人が来てくれれば、外部からのリンクをもらうチャンスも増える。
◎自サイト内でのリンクを活用しよう
Google はちゃんと「サイト」を認識していて、同一サイト内でのリンクではそれほどページランクが上がらない。
これを「内部リンク」と呼ぶことにする。
他のサイトからリンクをもらった場合は、「外部リンク」だ。こちらのほうがページランクを上げる効果が高い。
サイト内のどこかのページが、外部リンクをもらったとする。
そのページはページランクが上昇するだろう。
すると、そのページからのリンクの価値は高くなり、内部リンクによりサイト内の他のページもページランクが上がる。
つまり、外部リンクをもらうと、もらったページだけでなく、周囲のページにまで波及効果が及ぶんだ。
ところで、SNS では自分のプロフィールを書くことができ、WEB ページの URL にリンクすることもできる。
こういう、自分で作り出せる「外部リンク」も活用すれば…と思うかもしれない。
実は、これはできない。
SNS や掲示板を提供している各社と、検索エンジンを作成している各社は、協議して「ユーザーが作ったリンク」を明示する方法を決めた。
こうしたリンクは、検索エンジンにはリンクとして認識されない。
そうしないと、気軽に自分に向けて外部リンクを作れてしまい、不正な順位操作が行われるからだ。
SNS への投稿に URL を入れた場合も同様だ。見た目の上ではリンクが出来上がるが、検索エンジンとしては外部リンクとみなさない。
SNS を使って宣伝…というのはよく聞く文句だし、間違っているとも言い難いのだが、検索上位を狙う、という点においては効果は低い。
◎ SNS には検索順位を上げる力はない
一般には、サイト内部でのテーマを絞り込むことが大切、ともされている。
記事を読んでくれた人がいたときに、同じテーマの記事がたくさんあれば、そちらも読んでくれるかもしれないから。
それで情報の宝庫だと感じれば、リンクしてくれるかもしれない。
…とはいえ、Wordpress とか使っていれば、適切なタグ・カテゴリづけで関連話題は簡単に探せる。
テーマは絞ったほうが良いかもしれないが、あまり窮屈に考えないで、書きたいことを書いてもよいと思う。
◎テーマは絞ったほうが良いが、窮屈に考える必要はない
ちなみに、広告収入目的で WEB ページを作ろうと考えている人は、テーマをちゃんと絞り込むこと。
窮屈に考える必要がない、というのは、広告収入目的ではない前提だ。
ＳＥＯとは違うので詳細は書かないけど、広告システムはサイトの内容に合わせた広告を出す。
テーマがしっかり絞れていないと、場違いな広告が出て、当然読者の興味を引くことができず、収入に繋がらない。
話が結構長くなってきたので、いったんここで区切ろう。
関連ページ
WEBページの検索順位をあげる方法(2/2)【日記 18/10/06】
WEBページの検索順位をあげる方法(1/2)【日記 18/10/06】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
検索上位を目指すための WEB サイト作りの話、の後半。
前半記事では、そもそも検索とは何か、何をもって順位を決めているのか、などの話をした。
基礎知識としてはそれで十分なのだけど、概念だけではわかりにくいので、ここからケーススタディに入ろうと思う。
▼当サイトの場合
まず、実例としての当サイトだ。
はっきり言って、検索順位はそれほど高くないので、偉そうなことが言える実例ではない。
とはいえ、「個人が趣味を書きなぐっているだけのサイトとして」という但し書きをつければ、結構悪くないと自負している。
非常に古くから作っているページなので、サイトの作りそのものが、検索エンジンに最適化されていない。
だから、今から Wordpress などで同じようなページを作る人がいたら、もっと上の順位を狙えるだろう。
…と言い訳しながら書くが、現在の当サイトのページ数はおよそ 2000。
２２年やっているので、平均して４日に１記事は入れ続けてきたわけか。
飽きずによく続けたな、自分。
そして、本来のメインコンテンツである「古いコンピューターの話題」は、全く人気がない。
いいんだよ。自分の趣味で書きたいだけなんだから。
比較的人気があるのは、料理ページ、旅行記ページ、日記。
日記は雑多な内容を詰め込んでいるのでさらに細かく書くと、人気があるのはやはり旅行記と料理。
それとコンピューター雑学。今書いている、検索エンジンの順位を向上させる方法というのも、コンピューター雑学だな。
見事なまでにバラバラのジャンルで、検索エンジン対策としては良くない。
まぁ、広告収入を目指して作ったページではないので、あまり気にしていない。
当サイト、記事がやたら長い。
長すぎるページは読者が飽きてしまう。
文章は 1000文字～2000文字程度でまとめよう、とされていた。
しかし、今では常識が変わっている。
2000文字は最低ラインで、長くしたほうが良いとされる。僕にとっては追い風だ。
でもね、実のところ、長さは問題ではない。
みんな、そもそも関係ない「長さ」を気にしているから迷走するのだ。
重要なのは、読んだ人が感心してリンクをくれるかどうかだ。
この基本に戻って考えよう。
短くても人の心を打つ文章は書けるし、長くても苦も無く最後まで読めて面白かった！ と言える文章もある。
実際のところ、短い文章を書くというのは難しい。センスが必要とされる。
星 新一 をご存じだろうか。短い文章で楽しませる小説形式、ショートショートの名手だ。
2000文字というのは、その作品群の中でも短い部類に入る。
センスあふれる人でも、2000文字では厳しいのだ。
僕はそんな才能はないので、長い文章を書く。
文字数ではなくて行数で考えているのだけど、200行が目安。
これを超える文章はさすがに長い。調べると、大体 6000文字のようだな。
どうしても200行では書ききれない場合は、複数に記事を分割する。
ただ機械的に分けても意味がないよ。分割するときは、話題が変わる部分で記事を分けるようにするんだ。
この記事の場合も、２つに分割している。
前半が仕組みの話で、後半が具体論だ。
過去には４つくらいに分けた記事もあるのだけど、その記事は今でもよく読まれる人気記事だ。
乏しい経験則から、人気の出る記事のパターンをいくつか書き出してみよう。
まずは、個人の体験を書いた記事。
僕のサイトだと、
このあたり。
１番目は、ちょっと珍しい風邪をひいたので、病状変化をまとめてみたもの。
２番目は、ごく普通のお菓子のレシピなのだけど、失敗しやすいポイントを詳細に解説したもの。
３番目は、家族旅行記。ただし、旅行記とは別に、旅行先の施設の様子を細かくレポートしている。
お菓子のレシピが「体験」なのかと思われるかもしれないけど、作るのが難しくて何度も失敗したからね…。
大抵、レシピっていうのは成功する前提で書かれているので、失敗体験をもとに書いてみた。
世の中、公式見解や客観的な記事はいくらでもある。
でも、そういう記事って、良い面は伝えても悪い面は隠していたり、失敗は隠して成功部分だけまとめていたりする。
情報としては半分欠けているわけだ。
本当に情報を求めている人は、悪い面も、失敗しやすいポイントも、包み隠さずすべてを知りたい、と思っていることが多い。
だから、個人の体験した、そういう悪い部分も含めて伝える記事は人気が出やすい。
これは僕のページでの経験則だけでなく、「クチコミマーケティング」と呼ばれて、重視されている現象だ。
◎主観的で、思い入れたっぷりな個人の感想のほうが人気が出やすい
次に、「自分が知りたかったのに、検索しても出てこなかった」情報。
実は、上に書いた３つとも、これにも当てはまる。
１番目は、風邪をひいて辛いから情報を探しても見当たらなかった。
２番目は、お菓子作ろうと思ってレシピを調べたが、いい加減なことを書いてあるページを多数見かけた。
（にもかかわらず、それがいい加減であることに気づかずに従い、失敗した）
３番目は、子連れ旅行で準備が大変なので調べたのだが、知りたいことを書いてあるページがなかった。
そのあとで自分が体験したり、正しい理解にたどり着いたりしたので、記事としてまとめたものだ。
どこにも情報がなければ、自分の書いた記事が唯一の情報源となり、重宝される。
自分が苦労して解決したことは、必ず誰かの助けになる。
まぁ、どの程度の人の助けになって、どの程度のリンクをもらえるかはわからないのだけど。
◎探しても見つからない情報は狙い目
自分が知りたかったのに、というのは、言い換えれば「疑問を持つ人がいた」ということだ。
誰かが疑問を持ったなら、同じ疑問を持つ人は他にもいると思っていい。
というわけで、「人が質問していたことに答える」というのも、人気が出る記事のパターン。
この辺りは、質問に答えたものが、その後も人気を維持しているページ。
ファミコンの話が２つあるけど、１つめの後半部分が質問に答えて後から追記したもの。
それが人気があったので、調子に乗って派生させたのが、２つ目の記事。どちらも今でも人気がある。
僕はコンピューターが専門なので、質問に答えるのは、多くがコンピューター記事の雑学記事になる。
コンピューター雑学だから人気がある、ということではない。
誰でも自分の得意分野はあると思う。
その得意分野の記事を書けば、人が持っていない情報となり、人気が出るだろう。
◎質問が出たら、同じことを考えている人が多数いると思おう
あと一つだけ書いておこう。
これも自分の体験を書く、ということなのだけど、非常に高価なものを買った時の「人柱レポート」はそれなりの人気がある。
ただ、これらの記事は読まれることは多いものの、リンクされることは少ない。
そういった意味では、検索順位の向上効果は低いかもしれない。
＃ページランクは順位を決める上で重要な指標だが、実は「検索結果の中で、最近よく読まれる記事」というのも検索順位を向上させる。
高価なものを買うときって、だれしも慎重になると思う。
すでに買って使っている人のレポートを読んでみたくなるのだ。だから人気が出る。
でも、それは比較検討のためであり、わざわざほかの人に教えてあげるようなことではない。
だから、リンクするまでには至らない。
僕のページで言えば
・新車購入
あたりが人気記事。
少し前は、スマホ P10 plus を購入した記事なんかも人気あったけど、後継機種の P20 が発売されてからは人気なくなりました。
新車購入も、先日書いたばかりの記事で、検討した最近の車種名が並んでいるから読まれているだけでしょう。
この手の記事は、しばらくしたら人気なくなります。そういうもんです。
◎人柱レポートは人気記事
失敗談なんかは特に人気。他人の不幸は蜜の味。
高価な買い物で失敗したなら、せめてウケを狙って元を取ろう。
▼ケーススタディー
では、最初に書いていた通り、伊豆大島のレンタカー屋さんのページ検索順位を上げる方法を考えてみる。
あくまでも、「僕ならこうする」というだけで、レンタカー屋さんに強制できるものでもないし、やってもらった時の結果も保証できない。
すでに、商売のための WEB ページは持っている。
CMS である Wordpress で作られたもので、記事を増やすだけで検索上位に来やすい状況は整っている。
でも、Blog 部分には記事が全然投入されていない。数件の「お勧め飲食店」の情報だけ。
そのほかのページも、店舗の位置やレンタルしている車のタイプ、値段などがあるだけ。
商売上の必要な情報は書いたから、ページとしては完成。
…ということだと思うのだけど、これでは検索順位が上がらない。
レンタカー屋さんによれば、宣伝のために SNS に力を入れている…とのことだった。
WEB のトップページには、Twitter / Facebook / Instagram の最近の投稿が並ぶ。
今は、SNS で日々のレンタカーの空き状況などを紹介している。
しかし、これは使い方としてあまり良いと思えない。
SNS は基本的に、近況報告のメディアだ。
短期間しか滞在しない観光客が、「毎日のレンタカー状況」を知るためにフォローするとは考えられない。
情報の出し方として筋が悪い。
さらに、すでに書いたように、SNS でどんなに人気を得ても、WEB ページを検索上位に押し上げる力はない。
毎日更新、という労力を割いているが、このままでは後に何も残らないように思う。
労力を使うのであれば、まずは後に資産が残る WEB ページに力を入れるのがよいと思う。
その上で余力があるなら、 SNS で WEB ページの宣伝をするといいだろう。
WEB ページを更新しましたよ、こんな情報書いてますよ、という内容なら、フォローして情報を得る意味が出るからだ。
（もちろん、日々更新する情報が良い内容だというのが前提だ）
商売はレンタカーなのだが、そこは一番最後。
WEB で宣伝につなげることはあってもよいが、SNS では控えめにしたほうが良いだろう。
多くの人にとってレンタカーは日常には使わないもので、その話をされても面白くない。
それでも、サイトの検索順位が上位になれば、自然に商売ページの宣伝にもなる。
Instagram の記事は、島内の観光地などのきれいな写真が使われていて、見栄えが良い。
写真は、ご自身…もしくは、近い知り合いの撮られたものではないかと思う。
同じ写真を探しても、インターネットには見つからないオリジナルのようなので。
せっかく持っているこれらの美しい写真を使い、WEB ページの Blog 部分で記事を増やすと良いだろう。
Instagram の投稿では、写真は載せているのに、その写真に対する説明が、ほとんどない。
あるのは、レンタカー屋としての宣伝と、関連しそうな語句をハッシュタグにしたものだけだ。
挙句、フォロワーから「どこの写真ですか？」なんて質問が来ている。
質問が来るというのは、その情報を欲しがっている人がいる、ということだ。
本文中にその情報を書いておくのが望ましい。
全体に、読者が想定されているように思えないのが、一番の問題だ。
読んでくれる人を想定して、その人に届くような文章を書かないといけない。
商売に結び付きやすいのは、「伊豆大島の観光客」だろう。
だから、観光案内をするつもりで、先に挙げた伊豆大島の美しい写真を使って、その写真にまつわる情報を書いていく。
お店の情報なら、どういう料理が中心で、平均単価がいくらくらい、お勧めのメニューは何か、などが欲しい。
読者を想定しただけで、ずいぶんと良い内容になるはずだ。
想定読者は、サイト全体で一貫する必要はない。
記事ごとに想定読者が決まれば、それで構わない。
当たり前の話だけど、レンタカーの紹介ページは、車を借りる人が想定読者だ。
値段やタイプだけでなく、車種や装備がわかればうれしい。
情報はとにかくありがたいので、装備が「ない」のであっても、隠さず書いておいたほうが良い。
基本が守れていれば、どんな内容でも気軽に書いてもよいと思う。
先に書いたように、なにが検索に引っかかるかわからないから。
多くのテーマを書いておけば、どこかで誰かからリンクしてもらえるかもしれない。
自分の趣味があるなら、積極的に書こう。
それが商売と無関係でも、自分のよく知っていることなら記事も書きやすい。
もっとも、どのような文章を書くかは商売の姿勢にもかかわることなので、強要はできない。
商売とプライベートをキッチリ分けたい、という商売人もいる。
それができていないような商売人は信頼できない、というお客さんもいる。
そういう人たちにとっては、個人の日記のようなことが書かれている商売のページ、というのは許容できないかもしれない。
僕は正反対のタイプで、人柄が見えている、人間臭い人でないと、裏で何を考えているかわからない…と警戒してしまう。
そういう人は商売人として信用できない。
まぁ、どちらに転んでも、ちゃんとついてくる人はいるし、その人たち相手に商売もできる、ということだけど。
ここは、やりやすいほうで良いということだな。
話としては、以上。
いわゆる「ＳＥＯ対策」としては、もっと細かな技術的なテクニックも多数ある。
でも、しつこく書くが、基本はリンクをもらうことだ。
そして、リンクをもらうためには、読んだ人が感心するような、いい情報を提示することだ。
「良い文章を書く」ではないことを忘れないように。
つたない文章だって、人に情報を伝えることはできる。
「特別な情報」ではないことも忘れないように。
個人の体験とかが「いい情報」であって、国家機密のような特別情報である必要はない。
こうした基本を忘れなければ、WEB サイトは誰でも作れるし、そこそこ人気が出る。
「そこそこ」よりも上を目指すには、もっと努力が必要なのだけど。
関連ページ
WEBページの検索順位をあげる方法(2/2)【日記 18/10/06】
WEBページの検索順位をあげる方法(1/2)【日記 18/10/06】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
少し前に Nintendo Switch で発売になった「7 Billion Humans」を遊んでいる。
購入直後は「あれ？ 思ってたのと違う…」という感じだったので特に日記ネタにしなかったのだが、ステージが進むにつれて期待通りの内容になってきた。
しかし、このゲーム、遊んでみるまで内容がわからない。
事前に紹介ムービーとか作成者インタビューを読んでいても、どんなゲームかさっぱりわからなかったのだ。
そんなわけで、僕と同じように迷っている人のために、どんなゲームか書いてみようと思う。
一応、Human Resource Machineの続編ではある。
どちらも「プログラムゲーム」だし、インターフェイスや画面構成もほぼ同じだ。
だから、同じようなゲームかというと、全く違う。
プログラム言語が違うのだ。
プログラムを中心とするゲームなので、「言語が違う」というのは、かなり違うものだと思っていい。
前作、Human Resource Machine では、「アセンブラ」を使ってフィルタを作るゲームだった、と考えていい。
部屋の入口・出口にベルトコンベアがある。
入口からは「データ」が次々入ってくる。
これを、アセンブラプログラムで「加工」して、出口のベルトコンベアに乗せる。
結果が課題通りであれば、ステージクリア。
こういう、次々と入ってくるデータを適切な形に加工し、出力するプログラムを「フィルタ」と呼ぶ。
だから、Human Resource Machine は「フィルタを作るゲーム」だったんだ。
たとえば、次々入ってくる数値データを、0 を区切りと考えてそれぞれの合計を出し、出力する、という課題があったとする。
そのプログラムを、非常に低機能なアセンブラで作成する。
できた、と思っても、結構入力データが意地悪だ。
0 が2連続する部分があったりする。
0 が区切りなのだから、2連続ということはデータが空っぽ。
この時、合計を出力するのだから「0」を出さないといけない。
でも、うっかりしているとおかしなデータを出力して、上司に怒られたりする。
そう、このゲームの主人公は「おじさん」で、上司が課題を出す。
おじさんは、アセンブラに従って、ちょこまかと移動して働き、正しければ上司に褒められるし、間違えていたら怒られる。
このおじさん、あくまでも CPU の動作を「面白く表現」しているだけで、ゲームの主体はプログラムのほうにある。
おじさんの動きはかわいいが、おじさんを動かすゲームではない。
さて、今作 7 Billion Humans の話に入ろう。
タイトルは「70億の人々」という意味だな。全世界人口。
このゲームは、人をプログラムして動かし、課題をクリアしていくゲームだ。
前作のように、おじさんの動きは飾りではなくなった。おじさんの動きのほうが主体で、それを動かすためのプログラムを組むのだ。
8方向のどちらに進むか、命令パネルを並べ、おじさんが行った先で pickup で置いてあるものを拾う。
そして、指示されたところに移動して、drop で持っているものを置く…
最初のほうの課題は、そんなのばかり。
あ、これ、ダメな奴かもしれない。プログラム教育の悪い例だ。
…そう思ったから、購入してもすぐに日記ネタにしなかったのだ。
Hour of Code という活動がある。
子供にプログラムを教えよう、と頑張っている組織だ。
子供に人気のキャラクターが、そのキャラクターに合わせた「課題」でプログラムを教えてくれる。
たとえば、「アナと雪の女王」を使ったチュートリアルがある。
ここで、「前に n ピクセル動く」とか「右に n 度曲がる」などを駆使して、スケートの跡で綺麗な模様を描いてみよう、という「プログラム学習」が行える。
たしかに、わかりやすい。そのわかりやすさは「与えられたとおりにすればいい」からだ。
結果として、課題はクリアしていくのだけど、プログラムを理解できないまま終わってしまう。
一応、順次実行や繰り返しなどの、プログラムの基礎は学べることになっているのだけど、プログラムってそういうことではない。
「どうすればいいんだろう」って悩んで、解決方法を自分で組み立てていくのがプログラムだ。
まぁ、Hour of Code のすべてがこういう課題だというわけではない。
（以前はすべてだったのだけど、今見に行ったら、現在は「上級課題」としてもっとまともなものが用意されているようだ）
悩むにしても、知識ベースがないと解決方法がわからない。
その知識ベースを与えるために、こういう学習方法もありだとは思うのだけど、これだけで終わってしまうのは面白くないというか、もったいない。
で、7 Billion Humans もそういうゲームなのか、がっかり…と思いながらも先に進めたら、途中からどんどん変わってきた。
今作では、「おじさん」が一人ではない。多数の人々が協力して課題を解かないといけないようになっている。
でも、ここで大切なのは「プログラムは１つだけ」ということなんだ。
多数の人がいて、協調動作を求められているにもかかわらず、その指示を行うプログラムは１つしか作れない。
だから、工夫しないといけない。
プリンタから出てくる書類を、人々が順次閲覧して、最終的にシュレッダーにかける問題がある。
このプログラムで真っ先にやらないといけないのは、「自分の位置を認識させる」ことなんだ。
プリンタの前にいる人は、プリンタからの書類を受け取らないといけない。
シュレッダー前の人は、書類を受け取ったらシュレッダーに入れないといけない。
でも、それ以外の人は、「隣の人から書類をもらう」という動作以外をやってはいけない。
自分が何をすべきか、周囲の環境から判断し、処理を振り分けるプログラムを作らないといけない。
UNIX などの OS では、fork を使って並列動作ができる。
その際、プログラムは同じものになるのだけど、自分が「親」か「子」かを判断して違う動作をさせる必要がある。
このゲームでは、そういう高度なプログラムと同じものを求められるんだ。
さらには、途中の課題から「メモリ」が使えたりもする。
前作では、「入力」されたデータを床に置いたりすることができ、それがメモリだった。
今作では、一人の人は、4つのことを覚えられる。これがメモリだ。
覚えられるのは、データの値だったり、その値を計算した結果だったり、部屋の中の「位置」だったり、文脈によって自由に変わる。
さらには、「最寄りの社員の位置」とかを瞬時に見つけ出して、その位置をメモリに入れたりもできるようになる。
位置は、「その位置まで移動」という形で使える。
８方向に１マスづつ異動ではなく、一気にその位置まで移動できる。
メモリが出てくると、ゲーム内容が一変する感じすらある。
ただし、メモリはあくまでも「個人の記憶」であって、共有メモリのようなものはない。
だから、協調動作の際に、共有メモリを使って指示、みたいなことはできない。
（これ、並列プログラミングでは結構やるのだけど）
だから、個々人はそれぞれ独立にプログラムを実行しているだけで、協調動作などのようなことはできない。
…この時点までは、まだ。
さらに後の課題で、listen と tell というコマンドが増える。
listen した人は、tell されるまで動作を止めてしまう。
これを使って、やっとタイミングを合わせて協調動作させることが可能になる。
tell するときは、「全員に」聞こえるように大声を出すこともできるし「隣の人に」話しかけることもできる。
これも、他の人の動きを待とうとして、全員一斉に listen したりしてはならない。
何らかの周辺環境を判断して、最初に動く人を決め、その人以外が listen するようにプログラムを組む。
たとえば、床一面に広げられた「数値データ」の平均を取る課題がある。
７×７にデータが並び、その下に７人の人がいる。
それぞれを上に進めながらデータを合計していくのだけど、これだと「各列の合計」しかわからない。
一番上まで行き、列の合計が出た後が問題だ。
人々のスタート位置は異なっていて、わざと一番端の人のスタート位置を下げてある。
逆に言えば、端の人は最後に上まで到達するように作ってある。
そこで、端の人以外は、上に到達したら listen して待つ。
端の人は、到達したらそこのパネルに合計値を書き込んで、隣の人に tell する。
tell された人は、隣のパネルの値を自分の覚えている合計値に足し、パネルに書き込み、隣の人に tell する。
以下繰り返し。
これで、最後の人は「全体合計」を知ることができる。
49 で割れば平均値になる。
課題としてはこの平均値を「答える」ための操作でまたいろいろあるのだけど、大体目標は達成できる。
一応、この後「周囲の８マスを順に」という、ループ命令が出てくる。
このゲーム、前作に比べて課題が多く、まだ最後まで終わらせていない。
まだまだ新しいコマンドが登場するのかもしれない。
しかし、全体としては４つの段階に分かれているので、これで最後かも。
1段階目で基本命令、2段階目でメモリ、3段階目で listen と tell 、4段階目でループだ。
一つ不満を書いておくと、課題ごとに、不要と思われる命令は使えないようになっている。
多分迷いなく答えにたどり着くための「やさしさ」なのだろうけど、それまでに出てきた命令は自由に使わせてくれたいいのに、と思う。
課題が多いと書いたが、１個づつの課題の難易度は低めだ。
そりゃそうだ。「アセンブラで書け」と、「Scratch で書け」っていうのくらいの違いがあるのだ。
Scratch は子供向け言語だけど、並列プログラムも可能だし、今回のゲームの言語と似ているように思う。
今回のほうが、明らかに高級言語。その時点で難易度が低くなるのは当然。
そして、その分課題を増やしてある。だから、ゲームとしてのボリュームは同じくらい。
どのくらい難易度が低いかというと、前作のアセンブラは子供には理解しづらかったようで、中学２年の長男も少しやって投げ出してしまった。
今作は、小学校３年生の次女が「面白い」と言って楽しんでいる。それくらい難易度が下がった。
あ、もう一つ不満点あった。
まずは課題をクリアすること。プログラムが汚くても、力業でも構わない。
クリアすれば、次の課題が遊べるようになる。
だけど、課題ごとに「短さ」「速さ」で基準値がある。
もし楽しみたければ、それらを目指してもいい。場合によっては、基準値を超えたものも作れる。
ここで、前作なら短さを目指すと、それなりに「美しい」プログラムになった。
美しいっていうのは個人のセンスによるものなのだけど、少なくとも短くするために無駄がそぎ落とされている、という意味合いだ。
これが、今作では短さを目指すと、エラー処理を無視することが多い。
たとえば、一歩歩くごとに、とにかく「ものを拾う」ように作る。
そこに何もなければ「なにもありません」とおじさんが立ち止まる。つまりは、エラーが出る。
でも、「何かあったら拾う」と条件判断をするより、１行少ない。
短いとしても、エラーが出まくるのは美しくないように思う。
でも、それをしないと課題をクリアできないこともある。
速さに関しては、前作はループ展開したりすることもあったが、今回はどれだけ並列度を上げられるかが勝負だ。
エラーが出ると「立ち止まった」分だけ遅くなるというペナルティがあるので、１ステップ増えてもエラー処理は必須。
こちらのほうが、むしろ「美しい」かもしれない。
その一方で、条件判断していると速度が落ちるので、大胆な「決め打ち」をすることもある。
データはランダムに変更され、速度は「何回か実行した平均値」で測られるので、データに依存した決め打ちはできない。
でも、条件判断が省略できるところを探して、汎用性がない「決め打ち」のプログラムを入れ込む。
これがまた、美しいプログラムではない。
今回のゲーム、短さを目指しても、速さを目指しても、美しくないプログラムになることが多いのだ。
しかし、最適化が難しくて、後回しにしている課題も多い。
後回しにしている、というのも、簡単に思いつかないほど奥が深いということではある。
まだしばらく楽しめそうなゲームだ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
２か月ほど前に、新しいＰＣを検討中という話を書いた。
デスクトップＰＣも古いし、サーバも古い。買い替えたい。
でも、結局まだ買ってない。ＵＰＳは買い替えて、つなぎなおしたけど。
妻のＰＣは買いなおした。
ＰＣ仕事はしているが、僕より要求がシンプルだから機種を決めやすい。
実は、妻はすごくたくさんのＰＣを使っていたのだが、分散しすぎて使いにくい。
「全部一本化できるマシン」という要求で、調査したら１機種だけ目的にかなうものを見つけ、それにした。
妻の、購入前のＰＣ状況を書いておこう。
メインはデスクトップ。WACOM のタブレットをつなげて使っていた。
これとは別に、ノートマシン。妻には会社の会計もお願いしているが、会計ソフトを入れて使っていた。
そもそも、仕事用と会計用は使用目的が違うので分けたい、という用途でこうしていた。
ここまでは、まぁいいんだ。
最近、休日でも何となく作業をしたいときに、家族がいる居間で、ノートマシンで作業したりもしていた。
でも、やっぱりノートでは絵が描きづらいんだ。
絵に関係ない仕事を中心としていたけど、絵を描きたいときだってある。
そこで、半年ほど前に Raytrektab を買ってみたんだ。
Windows のタブレットなのだけど、CPU 性能を落として電池持続時間を延ばし、WACOM の液晶ペンタブ技術で直接絵を描けるようにしてある、というモデル。
これをノートマシンのサブとして使えば、好きな時に絵を描ける…というつもりだった。
でも、結局妻はあまり活用していない。
思った以上に CPU 性能が低いマシンで、絵を描くには最低限ギリギリラインではあるのだけど、アプリケーションの起動とかに時間がかかってしまって気軽ではなかったから。
ただ、画面はスマホより大きめなので、ニコニコ動画とか見たいときに使いやすい、とは言っていた。
（時々、作業の傍ら生中継とか見ている）
それで、新しいマシンを購入するのであれば、
・ノートマシンとして持ち歩ける
・現在メインのデスクトップ（７年前の機械）程度の CPU 性能は出る
・直接ペンタブとして絵も描ける
・必要なら、大画面の動画閲覧マシンにもできる
ようなマシンが欲しい、となった。
持ち歩ける、という時点で、ノースピンドルマシンがいい、という話にもなった。
スピンドル（回転軸）を持たない…つまり、ファンもなければハードディスクもないマシンだな。
でも、これはなかなか難しかった。
ＳＳＤのみのマシンでいいのだけど、上の要求を満たすマシンは高級機になってしまい、購入機だと必然的に、「安心の大容量」であるＨＤＤが、ＳＳＤとは別についてきてしまうのだ。
そこで、ＨＤＤが「ついてきてしまう」のは許容することにした。
そして選んだマシンは、HP Envy 15 x360。
キーボードを完全に裏側に回してタブレットにもなるマシンで、キーボードを画面の「スタンド」として使って動画を見てもいい。
画面はタッチパネル、かつ液晶ペンタブにもなっている。
標準付属のペンは傾き検知に対応していないが、別売りペンを買えば傾き検知もできる。
もちろん、ノートとはいえ、７年前のデスクトップより CPU 性能は上だ。
もう買ったのは２か月近く前で、徐々にこのマシンだけで作業が済むように、妻は移行作業を行っている。
で、今日の本題だ。
移行作業の多くは、デスクトップで使っていたアプリを新しいノートにも入れる、という作業だ。
でも、そろそろ前のノートで使っていた会計ソフトもこのマシンに入れようと思った。
そしたら、ライセンスの関係で、前のノートの会計ソフトを「ライセンス削除」してから出ないと認証できない、とわかった。
そこで、前のマシンを起動したら…起動しないんだ。
しばらく使っていなかった。以前、最後に起動したときはちゃんと起動できた。
その後いじっていないのだから、本当に何もしていない。
なにもしていないのにこわれました
妻が「起動できなくなった」というので、きっと Windows 回復環境で起動してスタートアップ修復すればいいだろう…と思ったのだけど、ダメだった。
一応、回復環境での起動はできる。
そこから、「トラブルシューティング」を選んで、システム回復を試みることができる。
「システムの復元」で回復ポイントまで戻そうとしたが、「失敗した」と言われて、もどらない。
「イメージでシステムを回復」…は、そもそもバックアップ取ってないとダメな奴だ。
「以前のビルドに戻す」も試してみたけど、もちろんダメ。
最後の手段だ…ユーザーのファイルは残したまま、Windows の再インストール、という項目があったので選んでみた。
しかし、「失敗した」と言われてできなかった。
ムムム…
これらの「回復環境」は、隠しパーティションに収められた Windows のインストールファイルを使っている、と認識している。
そちらのファイルが古くてだめなのか。
調べてみると、Windows 7 からアップデートしたマシンは、隠しパーティションのファイルが Windows 7 のまま、ということのようだ。
だから、Windows 10 を修復しようとしても、Windows 7 のファイルしかなくて失敗しているのだろう。
じゃぁ、Windows 10 のファイルを用意してやろう。
というわけで、回復ドライブを作る。
僕のメインＰＣもまた、Windows 7 からアップデートしたものだ。
そういう機種で回復ドライブを作ると、Windows 7 のインストールを始めてしまうらしい。
じゃぁ、買ったばかりの Envy から取ってみよう。USB を用意し、回復ドライブを作る。
一応、この回復ドライブは「そのマシンでしか使えない」ことになっている。
でも、ダメならダメでやってみるしかないだろう。
古いノートに USB を差し込み、そこから起動。
インストールメニューは開いた。しかし、「ユーザーデータを残したままインストール」はできず、クリーンインストールしかない。
これでは、古いマシンのデータは救えない。
まぁ、最悪クリーンインストールすることに問題はないのだけど、ある程度データが残ってしまっているのを拾い上げたい。
改めて、回復環境からコマンドプロンプトを起動する。
回復用の OS が、ドライブ X: として起動するのだけど、別のドライブを見てみる。
C: D: は、回復用の隠しパーティションのようだった。そして、 E: が普段の C: ドライブ。
どうやら、欲しいデータはちゃんと残っているし、アクセスできるようだ。
じゃぁ、Linux の LiveDisk 作ってサルベージするか。
手元に DVD-RW があったので、Ubuntu Remix を焼く。
DVD１枚にすべてを収めていて、そこから起動できる、日本語対応の Ubuntu 環境だ。
DVD は遅いので起動に時間がかかるが、無事起動できた。
そこから「ファイル」アプリで HDD を覗くと、ちゃんと目的のデータがあった。
じゃぁ、これをどこかにコピーしよう。
USB メモリはうまく認識できなかったが、ネットワークに接続できた。
家庭内の NAS にバックアップを取る。
データが大きかったので、６時間待ちだ。今コピーしている。
必要データが退避出来たら、Windows のインストールを試みるつもり。
その後は、あえて会計ソフトをインストールして認証したうえで、認証を削除してアンインストール、という無駄な手順を踏まないといけないだろう。
そのあとは…もう使わなくなるのだから、子供向けマシンかな。
古いマシンとはいえ、まだ十分使える性能を持っている。
少なくとも、今子供が使っている Chrome OS マシンよりは性能が高い。
同じテーマの日記(最近の一覧)
関連ページ
Lenovo Ideapad C340 購入【日記 20/08/22】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
壊れたノートパソコン、注文していた SSD が到着したので交換した。
ノートは、８年前の DELL Inspiron 15 N5010 という機種。
HDD の交換記事は、この機種がまだ新機種だったころに書かれたページがありました。
他のページも多数見つかりますが、みんなこのページを参考にしている感じ。
キーボードを外すところが、どのような形に外れるのかわからずに苦労しましたが、それ以外は特に問題なし。
で、ついでにもう一つ。
同じ趣旨で、去年書かれて、２か月前にも更新されているこちらのページ。
HDD の交換ついでに、WiFi モジュールも取り換えてしまうと良い、という内容。
有線 LAN でも 100Mbps しか出ない機種なのに、モジュール交換すると WiFi で 867Mbps 出るようになります。マジか。
こちらのページでは、別途ドライバインストールが必要、と書かれているのですが、最新の Windows 10 をインストールした場合はドライバ不要でした。
＃参照したページでは、N5010 のリカバリーディスクを使い、Windows 7 をインストールしている。
この場合別途ドライバが必要になるが、Win10 なら標準で入っている。
HDD 故障に気づかずにやっていた時は、全然インストールが進まずに悩んでいました。
しかし、新しい SSD に換装したら問題なく進みます。
しかも、SSD なので速い。
すぐにインストールが終わりました。
で、ライセンス認証。
Win10 では、以前に使っていた機種に新規インストールしても、インターネットで自動的にライセンスを見つけ出してくれます。
…「以前違うライセンスの Win10 を入れていたはずですが？」と怒られました。
あー、やっぱり。以前 Win10 Pro を入れていた気がしていたのですが、自信がないのでよりライセンスが安いほうの、Home をインストールしました。
やり直し。クリーンインストールしなおします。
で、今度は「お使いなのは、DELL N5010 NOTE ですか？」と聞かれます。
そうそう、それです。
…「ライセンスコード認証できません。お手持ちのコードを入れてください」という状態に。
＃文言は覚えてないので適当。
ここまで特定できているのに、なぜ。
HDD と WiFi モジュールを一気に変えたのはまずかったか。
しかしまぁ、Win 8 pro からのバージョンアップだったので、Win 8 pro のコードを入れたら、それで OK でした。
以前に日記に書いたけど、再インストールしようとして Win8 のインストールディスクも出していたので、ライセンスコードのメモもあったのね。
SSD と高速 WiFi モジュールで、８年前のマシンだけど快適に使える状態になりました。
今となっては非力なマシンだけど、スマホで WEB ブラウズするよりはずっと快適な感じ。
WiFi は、簡単なテストで 260Mbps 出ていました。
理論値の 867Mbps まではいかないけど、それまで理論値でも 65Mbps だったのだから、ずっと高速。
SSD は 512Gbyte のもの。
メモリは、すでに以前に最大である 8Gbyte にしてあります。
そんなわけで、おそらくこのノートとしては現状で拡張できる最良の状態。
SSD と WiFi モジュール合わせて、１万円ちょっとでした。
修理のコストパフォーマンスとして結構よいように思います。
しかし、これはもう使わないマシンなので子供用です。
最近、子供３人ともパソコンを普通に使うようになってきて、１台のマシンを奪い合っていたからね。
同じテーマの日記(最近の一覧)
関連ページ
Lenovo Ideapad C340 購入【日記 20/08/22】
メインマシンに Win 再インストール【日記 18/12/20】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
購入しただけで、まだ稼働してないけど。
３か月前にサーバー買い替えを計画中、と書いたのだけど、やっと買った。
まだインストール作業中。
入れてみても納得がいかなくて入れ直し、とか繰り返していて、いつ稼働を開始できるかはわからない。
買ったのは、ASRock J5005。
多分、省電力マシンとしては今一番バランスが取れているんじゃないかと思う。
あくまでも「省電力マシン」なので、非力。
でも、家庭内サーバーなんてその程度の性能でいい。
というか、今まで使っていた Atom D525 と比べると、Pentium Silver J5005 は、４倍ほどの性能を持っている。
今までだって困っていなかったので、この性能は十分すぎる。
そして、VT-x 対応だ。D525 は非対応だったので、Xen でしか仮想化できなかった。
これでやっと、現在の主流である KVM を使えるようになる。
＃家にはもう一台サーバーがあって、そちらで使っている Pentium N3700 は VT-x 対応。
だけど、互いに仮想化イメージをやり取りできるようにしていたので、N3700 でも Xen を使わざるを得なかった。
新しいマシンに、Ubuntu Server 18.04 を入れてみようと思った。
というか、インストール USB を作ってインストール開始した。
でも、インストール断念。今まで通りの CentOS で行くことにする。
世の中の流れは、サーバーも Ubuntu が流行している。
でも、致命的な問題に気付いたのだ。
Ubuntu のインストーラーは、HDMI で接続すると、1920x1080 のフルハイビジョンで、16x8 の文字ですべての表示を行ってくれる。
サーバー用に使っている小型の HDMI モニタは、フルハイビジョンに対応していないので、文字がつぶれて読めない。
なので、インストールしようにも、何が書いてあるのか読めないのだ。致命的。
Ubuntu Server が世の中の流行、と言っても、その理由の多くが、AWS (Amazon のクラウドサービス) で簡単に使えるから、という理由だと思う。
インストーラーを使ってベアメタル（クラウドではない PC）にインストールする人はほとんどいないので、インストーラーが十分にこなれていないのだ。
もう一つの理由。
Ubuntu Server では、LVM を使う時はさらに厄介な、設定項目が多い古いインストーラーを使わないとならないそうだ。
仮想化サーバーを使おうと思うなら、LVM が使えないと話にならない。
…というのは古い常識だと思って軽視していたのだけど、インストールを開始して、まだ LVM が必要だと知った。
LVM は、ディスクを仮想化する仕組みだ。
と言っても、仮想サーバーだから仮想的なディスクが必要とかではない。
そういう意味での「仮想ディスク」は、KVM などがちゃんと対応している。
LVM は、複数のディスクをまとめて１台に見せかけたり、ディスクのパーテションを仮想化しておいてあとで拡張可能にしたり、そういう仕組みを提供してくれる。
そして、この仕組みの一つに、「スナップショット」がある。
現在使用中のディスクを、他のプログラムなどを一切止めることなく、ある瞬間で停止して更新されないようにするのだ。
サーバーは、無停止運用が基本だ。
それと同時に、日々変化するデータをバックアップし、万が一の時にすぐに戻せるようにしないといけない。
ここで、変化するデータは、バックアップの開始時から終了時までの間にも変化してしまう、という問題が出る。
場合によっては、データ不整合で、万が一の時にデータをバックアップから戻してもエラーになって使い物にならない、ということになる。
スナップショット機能は、プログラムは稼働し、データ更新も行われている状態のままで、バックアップのために「ある瞬間で固定されたディスク」を作り出す。
スナップショット作成以降に更新されたデータは、ディスクの別の領域に一時的に書き込まれ、スナップショット終了時に正しくマージ（混合）される。
これ、サーバー運用するうえでは必須なのだ。
Ubuntu Server では、この技術が使えない…わけではないのだけど、使いづらい。
先に書いた、「古い常識だと思って軽視していた」というのは、実は KVM にもスナップショット機能がついているから。
厳密に言うと、KVM が使えるいくつかの「仮想ディスク」形式の中の、qcow2 形式はスナップショットが使える。
その代わりに、qcow2 は次のような問題があった。
・ディスクアクセスが遅い
・LVM のように「バックアップを取り終わったら元に戻す」形式のスナップショットを取るには、仮想マシンを一時停止する必要がある。
・仮想マシンを動かしたままスナップショットを取ることもできるが、その場合はマージできない。（どんどんファイル容量が増え続ける）
・スナップショット機能は全体に不安定。
…危なっかしくて使えたものじゃない。
スナップショットの必要性はわかっているが、まだまだ開発中、というところなのだろう。
Xen を使っているときは、仮想ディスクとしては「本物のディスクのパーテションを割り振る」のが一番パフォーマンスが出たので、その方法を使っていた。
そして、先に書いたように LVM でスナップショットを作っていた。
この方法はかなり複雑なので KVM では解放される！ …と喜んでいたのだが、まだまだこれが最良の方法のようだ。
で、とりあえずベアメタルのマシンに CentOS7 をインストールし、その上に仮に仮想化サーバーを入れてみた。
うんうん、KVM でもちゃんと動く。
でも、実験的に CentOS を仮想化サーバーにしてみただけ。
実際に使うのは Ubuntu Server にしてみる予定。仮想化サーバーなら AWS で使うのと変わらないから、最近の主流に寄り添ってみるつもりだ。
いままでは tinyDNS や qmail など、DJB のサーバー群を使っていたのだけど、これも最近の主流の方法に切り替えていこうと思っている。
「今までの方法で困らない」のも事実なのだけど、技術者としては流行の方法も知っておきたいから。
まぁ、何度か仮想サーバーをインストールしたり消したりを繰り返し、ある程度勉強してから、実際に使うサーバーを作っていこうと思う。
関連ページ
メインマシンに Win 再インストール【日記 18/12/20】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
メインマシンに、Windows を再インストールしてみた。
普段使っているメインマシン、もう７年前のものだ。
そろそろ買い換えたい、と３か月前にも書いた。
でも、３か月も放置していたのは、それほど不満がないからなんだ。
僕がこのマシンで普段何をしているかというと、WEB の閲覧とメール、テキスト書き、あとは ssh を使ったターミナル作業だけ。
この「ssh を使ったターミナル作業」が仕事のほとんどで、仕事で作るプログラムはほとんどサーバー上で vim を使って書いている。
以前は Emacs 使いだったはずなのだが、このところすっかり vim 使い。
で、作ったプログラムは PHP だったり javascript だったり、node.js だったりするのだけど、WEB ブラウザで見ることになる。
手元にあるのはほとんど「端末」に過ぎず、計算はサーバー上で行われているんだ。
そんなわけで、７年前の非力なマシンでも、特に不満がない。
とはいえ、そろそろ壊れてもおかしくないくらい使っているわけで、壊れる前に新マシンに移行したほうがよいだろうな…程度には思っている。
今のマシンは HDD で運用しているが、今から買うなら SSD だろう。
上に書いたように、作業ではほとんどデータを使わないし、家族写真などの大きなデータは NAS に入れている。
今のマシンは 500GB の HDD で、半分くらいしか使っていない。
じゃぁ、新マシンに SSD 搭載するとして…まぁ、今時 500GB の SSD なら高くはないよな。
と思ってマシンを探すと、案外そういうものは売っていない。
SSD 128GB もしくは 256GB に、HDD 1T のデュアルドライブ、というのがほとんどだ。
Windows って、UNIX みたいにディレクトリの接ぎ木できないし、別ドライブにデータ置くのって面倒くさくないの？
どうも躊躇していたところに、新サーバーを作ったので、それまで使っていた 128G SSD が余った。
これ、今のマシンに取り付けてみよう。
SSD + HDD の環境を試してみたら、案外買い替えの参考になるかもしれない。
先日ノートパソコンが壊れて Windows の再インストールをやったばかりなので、インストール USB はある。
昔… IDE のハードディスクを取り付けたりする時代は、それだけで大変な作業だったが、今時の SATA SSD は取り付けも簡単。
そんなわけで、昨日 SSD を取り付けてインストールし、起動させるまで 30分かからなかった。
仕事で使っているマシンをいじるのは怖かったので、万が一のために以前のディスクの Windows 環境もそのまま残してある。
２つのディスクにそれぞれ Windows が入っているので、起動時に「どちらを起動させるか」と聞かれる。ちょっと新鮮。
で、起動したらまっさらな Windows。
じつは、メインマシンは Windows 7 から 8 10 とバージョンを上げてきていて、ところどころに動作がおかしい箇所があった。
ログイン画面でも、なぜか Windows スポットライト表示されないし。あの綺麗な風景写真を僕も見たい。
（妻に、「あの画面、いちいち気にいったか聞いてきてむかつく」と言われているのだが）
あたりまえだけど、それまでインストールしてあったソフトは使えない。
Chrome と Becky!2 を入れる。
Becky!2 のメールデータディレクトリを、以前のディスクからコピーして…と思ったが、起動時の設定で以前のディレクトリを参照させればよい、と分かったのでそのままで。
Putty は、以前のディスクからコピーして持ってくる。
特にインストーラーがいらないソフトだったし、これで設定なども持ち越せたから。
普段テキスト書きには Sakura Editor を使っているので、これも入れる。
これで、だいたい仕事で使うソフトは整った。
たびたび使うソフトの中には、インストーラーがないものもある。
というか、むしろそういうソフトのほうが使うことが多い。
これらは、前のディスクの「ドキュメント」ディレクトリの中に、「プログラム」というディレクトリを掘って入れてある。
それをもってこよう。
で、コピーしようとして思いとどまった。
そもそも、「接ぎ木」を試してみようと思ったんじゃないか。
いつのころからか、Windows の「ドキュメント」ディレクトリは「ドキュメント」というディレクトリではなくなり、特殊なシンボリックリンクのような扱いになっている。
そして、「ドキュメント」が実際にどこのディレクトリを示すのかは、変更可能。
Exploler の「ドキュメント」とか「ピクチャ」とか書かれている場所で「プロパティ」を見て、「場所」タブでディレクトリ位置を指定してやればいい。
デスクトップを以前の場所に変更したら、見慣れたごちゃごちゃ感が戻ってきた。
調子に乗って、ドキュメントもピクチャもビデオもミュージックも、全部以前の場所にする。
うん、これでだいたい同じ使い勝手になってきた。
Quick Launch を使えるようにする。
Windows 10 ではすっかり「隠し」のような扱いだが、Windows 95 時代には便利だった機能だ。
（便利なものというのは、得てして「理解している人向け」の側面がある。
Quick Launch もそうで、Win95 の時から「便利だけど例外的なルール」に従っていた。
そのためか、Win 7 以降は、使えるのだけど隠し機能のような扱いになっている）
画面の隅にいつも時計を表示していたので、それがないと使い勝手が悪い。
この時計は何だっけ…前のディスクを見ていても思い出せない。
ネットで、Windows 用のデスクトップ時計を調べる。YTClock だった。入れる。
時計の下にカレンダーも表示。Chronus 。google calendar と同期できる便利な奴だ。
…なんだけど、google の認証が通らない。
google 側がずいぶん前に認証方式を変えたのに、ちゃんと追随できていないようだ。
古いディスクを探し、データディレクトリを見つけ出した。
コピーしたら、google 同期もできる状態のデータが復活した。
＃夕方追記。
Chronus が悪いのではなく、なぜか Google ２段階認証で、スマホから「はい」を送信したのが Windows に伝わらないようだ。
再インストールした都合かもしれない。要確認。
これで、普段使う環境としては、ほぼ元通り。
速度が速くなったのか？ …こちらは、まだ実感がない。速くなっているのだとは思う。
でも、普段使う Chrome も Becky!2 も Sakura Editor も、常駐するタイプのソフトなんだよね。
一度起動すると、その後はディスクアクセスしない。だから、使っていても SSD の恩恵はない。
しかし、これであまり快適になると、また買い替えが遅くなるかもしれない。
＃これを書いた直後、再起動してみた。明らかに速かった。
快適になってしまった。
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
家族で、約束していた「シュガーラッシュ：オンライン」を見てきました。
実は、長女はすでに友達と一度見ている。
年末に、長女の友達のお母さんが「みんなで見てらっしゃい」と焚きつけて下さったのだ。
小学校５年生で、友達と一緒とはいえ、子供だけでバス・電車を乗り継いで映画館に行き、映画を見たうえマクドナルドで食事までして帰ってきた。
もちろん初めての経験だ。
行く前の長女は、すごく緊張して気弱になっていて、戻ってきた後は「すっごく楽しかった！」と興奮気味に語り続けた。
初めての冒険って、こういうものだろう。
で、近所でやっている映画館はそこくらいだったので、同じところに見に行った。
（もう一軒あるのだが、そこはスクリーンがあきらかに小さい。同じ値段なら迫力のあるところで見たい）
前作、シュガーラッシュは見ていたのだけど、今作に関する前情報は一切なしでの鑑賞。
…ネタばれはしたくないので詳しくは書かない。
すごく面白い映画だった、というのは事実。
でも、前作のような「ゲームマニアが喜べる仕掛け」はほとんどない。
前作と同じようなものを期待するとがっかりする。
一応、映画の宣伝などで明かされている情報の範囲内で書いておけば、実在のインターネットサービスなどが実名で登場したりする。
だから、そうしたものに詳しい方が楽しめる。
でも…「アメリカで人気のあるサービス」が多数で、日本で人気のあるサービスとは、ちょっと違う。
僕はネットのサービスに係る仕事をしているので、使ったことがなくても「こういうサービスがアメリカでは人気」みたいなことを知っている。
でも、それを知らないとよくわからない部分もあるかもしれない。
全体としてはインターネットの「通信技術」をうまく視覚化している部分が面白い。
情報のカプセル化とか、回線により MTU/RWIN が異なることをうまく視覚化できている…とか。
もちろん、そんなややこしいことを考えないでも面白いのだけど。
回線に NETGEAR とか書いてあって笑いどころなのだけど…これも、アメリカではメジャーだけど、日本ではあまり知られていない。
（ネットーワーク機器を作っている会社名）
もう一つ、これも宣伝で明かされている範囲で、ディズニー映画の他のキャラクターなどがたくさん出てくるところがある。
ここらへんでは、ディズニー映画を多く知っている方が笑える。
…つまるところ、前作では「ゲーム」だけで話を組み立てられていたのだけど、今作は「ネットとディズニー映画」にネタが分散している。
そこらへんが、前作と同じではない、という部分。
やたらと細かなコンピューター技術に詳しい方が楽しめる映画、という意味では、トロンを思い出す。
というか、映画の序盤でトロンを意識しているとはっきりわかる演出がある。
（トロンもまた、ディズニー映画だ）
繰り返すが、お話は面白かった。見て損のない映画だと人に勧められる。
…でも、なんだろう。こう、もやもやが残るんだ。
作っている側も、人気があったから続編を、ということになったものの、どう作ってよいか迷ったのではないかな。
先に書いたように話が分散してしまって絞り込めていない感じがあるし、話のまとめ方も、どうもうまく着地できていない感じを受ける。
そういえば、前作は映画がすべて終わり、スタッフロールも終わった後の最後の５秒に「ゲームへの愛」を感じた。
今作では、スタッフロールの際の画面右端に注目。
…インターネットにありがちなものを、うまく表現できていると思う。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日、２月２１日は、ファミリーコンピューター向け周辺機器、ファミリーベーシック V3 (1985) と、ディスクシステム (1986) の発売日。
ファミコンのソフトは山ほどあるので、いちいちその発売日を「今日は何の日」で扱おうとは思わないのですが、V3 は思い入れがあるので別格です。
もっとも、本来ならいきなり V3 ではなく、ファミリーベーシックの発売日 (1984/6/21) を取り上げるべきですね…。
いろいろ探したのですが、２月２１日にいいネタが見当たらなかっただけでもあります。
ディスクは、たまたま同日だったので一緒に紹介。
まぁ、あとでファミベと絡めた話もしますが。
一応、取り上げたからには語りましょう。
この WEB サイトの、一番最初に作られたページが「ファミリーベーシック」の紹介だったのですが。
ファミリーコンピューター自体、1983年の発売なので、今となっては「生まれる前に流行したんでしょ？」という認識の人も多いでしょう。
任天堂は、今でも Switch でファミコンのゲームを配信していたり、ファミコンミニ作ったりしていますが、まぁ、昔遊んだ人の思い出補正がなければ、今更遊ぶほどのものでもありません。
当時は、「RAM」がまだ非常に高価だったんですよ…
ファミコンは、4Kbyte の SRAM を搭載しています。
SRAM と DRAM では、SRAM の方が高価なのですが、「安くしたい」はずのファミコンは、なぜか SRAM を使用している。
おそらく、ここで SRAM を使用することで、周辺回路を減らせるので、全体としてはむしろ安くなったんでしょうね。
DRAM は、安い代わりに「しばらくすると記憶した内容を忘れてしまう」 RAM で、時々読み出して書き込む、リフレッシュという動作が必要でした。
そして、この動作は、CPU のメモリアクセスとぶつからないように処理する必要がありました。
なので、リフレッシュ動作を行う周辺回路を作らないといけないことを考えると、高価な SRAM を使った方が安い場合もあったのです。
とはいえ、当時のライバルである、セガ SG-1000 とか、ソード M5 とか、MSX とかは、DRAM を使用していました。
これは、どういうことかというと、CPU に Z80 を使用していたから。
Z80 は、DRAM リフレッシュ回路を内蔵しているのです。
ファミコンの CPU は 6502 （のカスタム品）で、こちらはリフレッシュ回路を持ちません。
さて、4Kbyte の SRAM の内、半分の 2Kbyte は画面表示用の VRAM。
すると、残りは 2Kbyte ですが、CPU である 6502 の「決まりごと」により、256byte はスタック用。
そして、256byte は、計算の途中結果などを保持するワーク用。
先に、2Kbyte の VRAM と書きましたが、これは BG 用です。
スプライト用のメモリは、画面表示用の LSI 側に内蔵されていました。
とはいえ、これは「今表示している」分のメモリ。
ゲームを作るときというのは、今表示している画面用のメモリとは別に、「次に表示する」ためのメモリを用意するのが普通です。
そして、そのメモリは用意されていません。
なので、通常の RAM 上に、次画面スプライト配置用のメモリ確保が必須でした。
このために、256byte 必要です。
都合、2Kbyte のメモリの内、256byte * 3 は使用用途が決まっています。
自由に使えるメモリは、1280byte しかありません。
＃ 1Kbyte = 1024byte です。
たったこれだけのメモリの中で、あれだけ多彩なゲーム世界を作り上げていたのです。
称賛に値します。
…と、ファミコンの話ではなく、ファミリーベーシックの話でした。
この、たった 1280byte しか存在しないメモリの中で、BASIC のプログラムを記憶し、変数を記憶し、動作させることができるのか？ といえば、当然できません。
そのため、ファミリーベーシックでは、カートリッジの中に 2Kbyte の SRAM を搭載していました。
でも、これが全然足りない。
…というか、微妙な線で、ゲームを作ろうと思うと「それらしい」形にはなるのですが、作るのが面白くなってきたころにメモリオーバー。
もっとも、そうなったら仕方なく次のゲームを作り始めるしかないので、必然的にたくさんのゲームを作ることになります。
（プログラムが得意な子であれば）
僕の場合、これでずいぶん作り散らかして、プログラムの基礎を学べたように思います。
さて、標準の BASIC カートリッジは、まず、発売時についていた V1 。バージョン１ですね。
ゲームのプログラムと別に、背景をデザインすることができました。
先に、ファミコン本体に 2Kbyte の VRAM を持っている、と書きましたが、画面は半分の 1Kbyte で構成できるようになっています。
もう一画面は、「裏画面」。
ベーシックでプログラム中、当たり前なのですが、プログラムリストの表示に画面を使います。
しかし、２画面あるので、その間も「デザインした背景」は置いてあるのです。
そして、命令一発で、あらかじめデザインした背景を画面に表示できます。
裏画面から表画面にコピーする命令なのですね。
プログラムは 2Kbyte しか作れなくても、1Kbyte 分の画面を瞬時に表示できる機能があるのです。
これで、ちょっと華やかな見た目のゲームを作れました。
でも、この背景、ただの背景なんですね。
迷路を作ってゲームの中に活かしたりはできません。
そこで、改良されたのが V2 。背景に何が書かれているか調べる、という、たった１命令が追加されています。
たった１命令ですが、作れるゲームの幅がずっと広がりました。
この後、V2.1A というのもあるのですが、これはバグを修正したバージョンだそうです。
僕は、ファミリーベーシックは発売してすぐに買ったので、V1 カートリッジを持っていたのですが、後で V2 の存在を知って任天堂に電話したところ、片道送料負担のみで交換してもらえました。
これで入手したカートリッジは、2.1A でした。
そして、「別売り」になった、V3 の登場です。
ファミリーベーシックには、親しんでもらうために、ベーシック以外にも音楽演奏やバイオリズム占いの機能がありました。
これらのプログラムをなくし、空いたメモリに SRAM を増設しています。
それまでの 2Kbyte から、一気に倍の 4Kbyte へ。
先にか聞いた通り、当時はまだ SRAM は高価でした。
V3 は、カートリッジだけで 9800円しました。
＃ファミコン本体が 14800円、ファミリーベーシックも 14800円でした。
RAM が増えただけでなく、命令も増えています。
特に、プログラム「作成」を支援してくれる命令が増えたのはありがたいものでした。
（それまでは、デバッガも、まともなエディタもなしにプログラムを作っているようなものでした）
…でも、4Kbyte なんて、すぐに「少ない」と思うようになる程度のメモリなんですけどね。
当時でも、MSX は 32Kbyte 使えましたから。
＃もっとも、セガのゲーム機用にも BASIC はあって、こちらは最低 512byte だった。
4Kbyte を狭いなんて言うと、セガユーザーに怒られてしまう。
さて、「4Kbyte が狭い」と感じていたら、翌年にはディスクシステムが登場します。
ディスクシステムのカートリッジ内には、32+8Kbyte の RAM を持っています。
これをディスクのデータで書き換えながら動作する仕組み。
32Kbyte はプログラム用で、8Kbyte は画像用ですね。
ファミリーベーシックでは、キャラクタは ROM で、書き換えられませんでした。
しかし、ディスクでは当然のことながら、キャラクタも書き換えてゲームを作れます。
そして、ファミリーベーシックとディスクシステムを駆使して、「ディスクベーシック」を作ってしまった人がいるのですね。
当時の雑誌（バックアップ活用テクニック）に掲載されていました。
ファミリーベーシックで小さな簡単なプログラムを作ります。
このプログラムは、ベーシックのシステムプログラム(ROM)領域を、カセットテープに保存します。
＃当時は、カセットテープにデータを保存するのは普通で、ファミリーベーシックにもその機能がありました。
次いで、ディスク用の「トンカチエディター」（非ライセンス商品ですが、市販品）を使います。
これは、ディスクシステムに読み込ませて「ディスク内容を好きなように書き換えられる」プログラム。
普通はゲーム改造して遊ぶのに使うのですが、16進数を延々と入力し、小さなプログラムを作ります。
これは、カセットテープからデータを読み込み、ディスクに書き込むためのプログラム。
つまり、先にカセットテープに保存したベーシックのシステムを、ディスクに書き込むわけです。
これで、「ディスクシステム上で動くファミリーベーシック」が出来上がります。
ここから、さらに改造を加えます。
メモリ内容は BASIC でも書き換えられるので、ここからはファミリーベーシックで改造できます。
（トンカチエディタは、ファミコンのジョイパッドで 16進入力を行うので、とにかく使いづらいものでした）
たしか、プログラムで使えるメモリを 16Kbyte 程度に増やしたうえで、最終的に、ディスクにセーブ・ロードできるベーシックになっていました。
（ただし、セーブ・ロードできるプログラムは１つだけ）
さらに、この BASIC ではキャラクタ ROM の書き換えも行えます。
これ、ハードウェア改造なしで、ソフトだけで全部できてしまう、というのがすごいところ。
あこがれたなぁ。欲しかった。
でも、トンカチエディターをこれだけのために買う気はしなかったし、やりませんでした。
改造ベーシックでゲーム作っても、ベーマガに投稿できないしね。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日、２月２５日は、2D-APT II が発表された日です (1959)。
…まぁ、普通は「2D-APT II って何？」ってなりますよね。
知名度の高いものではない。でも、コンピューターの歴史の中では、大きな一歩なのです。
APT は Automatically Programmed Tool の略。
翻訳すれば「自動プログラム装置」です。
ごく初期のプログラム言語、それもいわゆる「高級言語」でしたが、プログラム対象はコンピューターではありませんでした。
コンピューターの歴史では、当初から「計算する機械」の仕組みは深く検討されてきました。
その一方で、計算する装置さえでき上れば、その装置に計算手順を教えるのは…まぁ、何とかなるだろう、程度に考えられていました。
この見通しが甘いものである、と認識されたのは、ENIAC が作られたときです。
諸説ありますが、「最初のコンピューター」ですね。
実際、理論上はどんな計算にでも対応できるように作ったはずなのですが、それを実際に「計算させる」ための手順がわからないのです。
その時は、数学が得意な女性が ６人集められ、彼女たちが必死になって計算手順を編み出しました。
この経験から、次に作られるコンピューターでは、もう少しプログラムのしやすさが考慮されます。
時代が過ぎるにしたがってプログラムしやすさは増していき…
といっても、「アセンブリ言語」でプログラムを作れば、「アセンブラ」が自動的に機械語に翻訳してくれる、というレベルには達しました。
そのころにはまだ、サブルーチンとか、スタックという概念がないんですけどね。
アセンブラがあっても、今のアセンブラよりも使いづらく、プログラムを組むのは大変な苦労でした。
計算機を販売しても、そのプログラムが作れないのでは話になりません。
計算機は高性能なのだから、計算機が自分自身をプログラムすればいい、というアイディアが出されたりもしました。
これは「自動プログラム」と呼ばれ、果たしてそんなことが可能なのか、議論となります。
議論に終止符を打ったのは、IBM が発表した FORTRAN 言語でした。
アセンブラではなく、「人間にわかりやすい、数式と、英語に近い言語」で計算の手順を示すと、自動的にコンピューターが実行可能なコードを作り出してくれる、というものでした。
さて、今日の話題、APT は、FORTRAN と似たような初期の言語です。
ただし、FORTRAN が「コンピューターの実行コード」を作り出すのに対し、APT は「工作機械の制御コード」を作り出します。
ここでの「工作機械」は NCMM と呼ばれる装置で、MIT で作成されたものでした。
制御コードデータを紙テープにパンチし、読み込ませることで形状を作り出します。
しかし、この形状データが人間には扱いにくいのです。機械を制御するための、数値の列ですから。
APT が作り出すのは、この制御コードデータの紙テープでした。
しかし、これがあれば金属を加工し、設計通りの形状を作り出すことが可能でした。
つまり、現在の ３Ｄプリンタの元祖です。
ただし、現在の３Ｄプリンタを使用する際は、普通はディスプレイ上で３Ｄモデルをモデリングします。
プログラムではありません。
当時は、コンピューターに接続されているのは「テレタイプ」が普通で、ディスプレイ上で…という概念が存在しませんでした。
プログラムで形状を示すのは、そのためです。
ただ、大きな問題が一つあり、２次元の図形は数式で表現することが可能なのですが、３次元形状を数式で表現することが、非常に難しいのです。
2D-APT II というのはそのための「暫定的な名前」で、まだ２Ｄ形状しか扱えないことを意味します。
工作機械は３Ｄ形状の削りだしも可能なので、なんとか３Ｄ形状をプログラムする方法を模索している途中段階でした。
この後、APT の研究は「コンピューター上で設計図を描くと、それがそのまま機械で加工される」というものに変わっていきます。
実は、「ディスプレイを使って絵を描く」というプログラム…サザーランドのスケッチパッド自体が、この研究の一環として生まれています。
以降は、とにかく示された方法論を、少しでも扱いやすくしようとする改良の歴史です。
NCMM は、さらに扱いやすい CNC になり、先に書いたように設計図から直接、加工が行えるようになっていきます。
現在では、素材を工夫することで、机の上に乗るような小さな機械でも出力が可能です。
APT の話は、過去に詳細を書いていますので興味のある方はそちらもお読みください。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日３月１３日は、デヴィッド・カトラーの誕生日(1942)。
伝説級の OS 開発者です。
かなりの変人らしいです。
彼のことを知るには「闘うプログラマー」を読むのが一番良いようなのですが、恥ずかしながら読んでおりません。
なので、彼自身については語れるほどの知識を持っておりません。
とはいえ、せっかくなので、ネット上で知りえる程度の話を、僕の得意な技術方面を中心として、まとめておきます。
まず、彼が手掛けた最初の OS から。
DEC で PDP-11 用の、RSX-11M というリアルタイム OS を開発したそうです。
…DEC PDP-11 から説明したほうがよさそうです。
DEC は PDP シリーズという「ミニコンピューター」を作っていました。
当時、コンピューターと言えば UNIVAC 。そして、IBM。
特に IBM は、プログラムや操作を行う「オペレーター」の派遣とセットで販売しており、コンピューターは自分で扱うものではありませんでした。
それを、あえて「自分でプログラムしてよいコンピューター」として販売したのが、PDP-1 に始まる PDP シリーズです。
ところが、PDP シリーズは、開発開始順に番号がつけられています。
それとは別に、大きく分けて３系統のシリーズがあります。
つまり、数字とシリーズに関連性がなく、非常にわかりにくいです。
PDP-1 は、18bit コンピューターでした。
18bit って、今見るとすごく中途半端に見えますが、当時は UNIVAC も IBM も 36bit で、安くするためにその半分サイズにしたものです。
PDP-7 は、最初の UNIX が作られたことで有名な機械ですが、18bit のシリーズでした。
そして、このシリーズの最後は PDP-15 。
他に、12bit と 36bit のシリーズがあるのですが、突然変異のように一台だけ、16bit の機械があります。
それが、PDP-11 。最終的に、PDP の中で一番売れた機種です。
PDP-11 は、それまでの開発経験をもとに、使いやすくなるように１から再設計を行ったマシンです。
このため、CPU の命令などが非常にわかりやすく、以降の多くの CPU のお手本となりました。
当初 PDP-7 で作られた UNIX も、のちに PDP-11 に移植され、大きく発展しています。
さて、PDP-15 で、RSX-15 というリアルタイム OS が作られます。
…リアルタイム OS 、というのも聞きなれない人も多いと思います。
普段使われている、Windows や Mac OS X 、Linux などは、複数のプログラムを同時に動かせます。
これは、１つのプログラムを少し実行したら、途中結果を保存して別のプログラムを少し動かして…という操作を、行っています。
CPU が十分に速ければ、同時に複数のプログラムが動いているように見えますが、基本的には、１つのプログラムから見れば「一定時間ごとに処理のタイミングが来る」ようになっています。
しかし、世の中には、わずかな遅れも許されないような処理内容もあります。
たとえば、コンピューターにセンサーをつなぎ、何かの状態を監視しているとしましょう。
この監視内容に基づき処理を行う必要があるのですが、「処理」に時間がかかったとしても、監視をおろそかにしてはなりません。
しかし、その「監視」よりも重要な作業もあり、非常停止キーが押された場合には、速やかに停止状態に移行しなくてはならない…など。
こうした場合には、Windows のような「一定時間ごとに順番に処理する」やり方では問題が出ます。
プログラムごとに、どの処理がより優先されるか、絶対に間に合わせないといけない「締め切り時間」などを指示する仕組みを作り、OS はこうした情報を基にプログラムに処理時間を割り当てます。
こうした OS を、リアルタイム OS と呼びます。
さて、その RSX-15 を、大ヒットマシンである PDP-11 に移植したものが、RSX-11 です。
RSX-11 は、派生バージョンが多数作られています。
まず、最初は紙テープからロードして使用される、RSX-11A。
シングルユーザーの OS でした。
これを拡張し、ディスクにアクセス可能とした B。
さらに、単にアクセス可能なだけでなく、ディスクから起動し、ディスクを前提とした D。
D は、マルチユーザーの OS に変化しています。複数人数が同時にコンピューターを使えるのです。
ところで、PDP-11 はアドレスも 16bit で、64Kbyte のメモリ空間しか持ちません。
当時としては複雑なディスク装置を扱う機能を持ちながら、複数人数が同時にアプリケーションを実行できる、という OS を、64Kbyte のメモリで実現していたことに驚きます。
＃注：PDP-11 は大ヒットマシンで、改良版も多数作られました。
このため、のちには 4Mbyte のメモリを搭載する機械もあります。
しかし、当時はメモリの値段が高く、実際に販売された PDP-11 には、搭載可能なメモリ量の半分しか搭載していない、32Kbyte しかないマシンが多数ありました。
RSX-11D を、32Kbyte でも動作させる…半ば無謀ともいえる派生バージョンが、RSX-11M です。
カトラーは、この RSX-11M の開発を指揮しています。
RSX-11M は開発に成功しました。1974 年に最初のバージョンがリリースされています。
D と同じ機能を持ち、より小さなメモリで動作するのですから、これ以降 D は使われなくなります。
M は、RSX-11 の中心バージョンとなり、1993年まで バージョンアップが続けられています。
僕は残念ながら PDP-11 を触ったことはなく、当然 RSX-11 のバージョンごとの違いも知らないのですが、Wikipedia によれば「洗練された半自動オーバーレイシステムを使用している」そうです。
オーバーレイというのは、プログラムを実行する際に、同時に実行される必要のない個別処理にプログラムを分割し、現在必要なプログラムだけをメモリに置く方法です。
こうすることで非常に小さなメモリでプログラムを動かせるのだけど、その処理の必要上、ディスクのようなランダムアクセスメディアが必要になります。
おそらくは RSX-11A から持っている機能ではなく、せいぜい D、おそらくはメモリが不足した M からつけられた機能なのでしょう。
普通は、オーバーレイするプログラムを作成する際には、プログラマがプログラムを分割し、小さなモジュール構成にして、複雑なメモリ管理をしながら作る必要があります。
しかし、「半自動」というのは、分割までやっておけば、メモリ管理などはシステムがやってくれた、ということのようです。
これは、プログラムコンパイル時に行われたようで、複雑なプログラムになると、オーバーレイの生成処理だけで数時間から数日かかったそうです。
…この「数日」も、おそらくは最大限に複雑なプログラム、OS そのものを生成するときなんじゃないかと思います。
OS そのものもオーバーレイしながら動作したのでしょう。
＃注：頻繁にディスクアクセスするようでは、真のリアルタイムにはならない。
本当にリアルタイム性が必要な時は、機能はサブセットだが完全にメモリに収まり、ディスクアクセスを行わない RSX-11S が使われた。
ところで、途中で書きましたが、PDP-11 には UNIX も作られていました。
この UNIX は AT&T ベル研究所によるもので、のちにカリフォルニア大学バークレー校によって拡張されています。
（いわゆる Syetem V と BSD）
これに対し、DEC が公式に「移植」した、Ultrix-11 という UNIX もあります。
さらに DEC 公式として、先に書いた RSX-11M もありますが、「世界初のマルチタスク OS」である、MIT の TSS に由来する、RSTS-11 もありました。
「マルチユーザーなんていらない」人向けに、RT-11 という、これも公式の OS があります。
さらに、MUMPS という OS をやはり公式に移植した、DSM-11 もあります。
公式 OS だけでも、５つあるのです。
これに加えて、PDP-11 は大ヒットマシンだったため、先に書いた UNIX をはじめとする多数の OS が作られていました。
もちろん、OS 毎に、その上で動かせるアプリケーションも異なります。
使いやすくするためには、統一した、決定版の OS が必要でした。
PDP-11 は、その後 VAX-11 という名称で 32bit 版が作られています。
初期のシリーズは、PDP-11 とも互換性を保っていました。
ここに、ふたたびカトラーが、RSX-11M を基とした OS を作っています。
VMS と名付けられています。Virtual Memory System の略で、仮想記憶を採用した OS であることを意味しています。
＃仮想記憶の概念自体は、VMS 以前から存在している。
UNIX もこの後 PDP-11 から VAX-11 に移植され、仮想記憶に対応した。
仮想記憶とは、単純にいえば、ソフトウェアで頑張ってメモリを節約していた「オーバーレイ」を、ハードウェアの支援で行おう、というものです。
ハードが面倒を見てくれるので、ソフトウェアを作る人は実際の搭載メモリを気にする必要はなくなります。
とはいえ、実際の搭載メモリを超えてしまうと、メモリをディスクにスワップし始め、速度が低下します。
VMS 自体は、ちゃんと RSX-11M の後継として、小さなメモリで動作するように工夫して作られていました。
「OS の決定版」として、UNIX よりも多くの機能を作り込んでありましたし、みんなが使うはずでした。
しかし、先に書いたように、VAX-11 にはすぐに UNIX が移植されています。
そして、UNIX の人気はより高まっていくのです。
先に、PDP-11 が多くの CPU のお手本となった、と書きました。
そのころの CPU は、今でいう CISC と呼ばれるものです。
プログラマーがアセンブラでプログラムを組みやすいように、豊富な命令がそろっています。
しかし、命令を大胆に減らす代わりに、高速な命令実行を可能とする新アーキテクチャ、RISC が台頭します。
DEC でも、RISC CPU を使った新マシンの開発に着手しました。
カトラーは、このプロジェクト全体を指揮しました。
RISC を使ったハードウェア開発と、そのマシンに合わせた新しい OS です。
RISC の高速性を活かし、UNIX とも VMS とも互換性のある、新しい OS となる予定でした。
当時パソコンでは Mac が GUI という概念を提示しており、GUI を中心とした操作にする…という考えもあったようです。
一説には、「VMS を進めたもの」という意味で、WNT という名称で呼ばれていた、とも言われています。
（VMS の文字を、それぞれアルファベット順で１つすすめると、WNT になる）
しかし、DEC は会社として「保険」をかけていました。
RISC マシンプロジェクトは、同時に３つが進められており、途中で判断して、一番よさそうなものだけを残したのです。
カトラーの率いたプロジェクトは、途中で中止となります。
失敗プロジェクトを率いた責任者に、その後の仕事は用意されていませんでした。
仕事を失ったカトラーに、マイクロソフトから引き抜きのオファーが来ました。
カトラーはマイクロソフトに移籍します。
この際、彼のチームメンバーの何名かは、彼を慕ってついていきました。
マイクロソフトは、彼に 32bit 版の Windows の作成を依頼しました。
当時広く使われていた Intel の 486 プロセッサではなく、MIPS,Alpha,PowerPC,i860 などの RISC CPU 向けに作ります。
しかし、のちに方針を転換し、従来の 16bit DOS、Windows と互換性を確保し、Intelの x86 にも対応させることになりました。
ここで、DEC で中止した OS の計画が再び動き出します。
UNIX 、VMS との互換性は不要ですが、DOS、Windows との互換性を持たせた、GUI OS です。
複数の OS と互換性を持った OS 、というのは、このころすでに実績がありました。
IBM は、DOS / Windows / UNIX / MacOS などのソフトをすべて動かせる「Workplace OS」の作成を表明し、実際に DOS / Windows だけに限定した形で完成させ、OS/2 という商品名で発売していました。
その仕組みは、マイクロカーネルという概念にあります。
従来の OS は、全体に必要な機能を考え、すべてを一体として設計されていました。
しかし、マイクロカーネルでは、OS は「各種機能の連絡方法」だけを用意し、あとはすべて別プログラムとしてしまうのです。
普通の OS なら絶対必要な、メモリ管理・プロセス管理・ディスク管理なども、OS 周辺の別プログラムとして用意されます。
このやり方だと、各種 OS との互換を取る際も、既存部分と違う部分だけを少しだけ作ればよいことになります。
流用できる部分は流用し、API （呼び出し方）の問題だけならそれを用意し、根本的に違う部分はそこだけ新たに作り…
当時の Windows は、ディスク管理を中心とした DOS の上に、プロセス管理やメモリ管理、グラフィックライブラリなどを積み重ねた形で作られていました。
もともと、DOS の機能が貧弱だったため、上に乗せた部分が肥大化しすぎ、非常に不安定になっていました。
それを、マイクロカーネルの手法を使うことで互換性は確保しつつ、安定性も高め、さらに先進的な機能まで準備したのです。
完成した OS は、Windows NT と名付けられました。NT は New Technology （先進機能）の略。
しかし、VMS を一歩進めた WNT でもあります。
互換機能はありますが、当初は十分な確認が行われていませんでした。
そこで、サーバー用途として NT を売りつつ、互換性を高めていきます。
2000 年発売の Windows 2000 で、デスクトップ用としても NT が導入されます。
とはいえ、この時は DOS ベースの Windows Me も発売されています。
そして、2001 年の Windows XP で、デスクトップも完全に NT 系列となります。
以降、今でも Windows は NT 系列です。
現在、Windows は 64bit 化され、16bit の DOS / Windows との互換性は失われています。
しかし、32bit Windows との互換性は相変わらず保たれていますし、新たに Linux との互換性が確保されています。
これも、当初からマイクロカーネルの設計が良かったからできたこと。
64bit 化の際には、デヴィッド・カトラーは、自分で 64bit のコードを書いていたそうです。
もう上に立って指揮するだけでいいような身分なのに、プログラムを書くことが楽しいのですね。
2008年ごろには、Windows Azure に参加していたようですし、2013年ごろには、Xbox One に参加していたようです。
現在かかわっているプロジェクト名などは明らかにされていませんが、77歳の今も現役で、マイクロソフトで働いているようです。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日、３月１９日は、スーパーファミコン用ゲーム、「ジャングルウォーズ２」の発売日(1993)
普段は個別のゲームの発売日なんて取り上げないのですが、今日はちょっと特別。
僕がアルバイトでお手伝いして、スタッフロールに名前を入れてもらったゲームなので。
市販の…広く一般流通したゲームに名前を入れてもらったのは、初めてでした。
＃これより前に、個人作成した X68k 用ソフト、「コメット」を全国販売してもらっているのだけど。
もっとも、雑用レベルで「お手伝いした」だけなんですけど。
スタッフロールでは、サブプログラマ扱いで入れてもらっていたはず。
そして、当時（というか今でも）僕はスーパーファミコンを持っていないので、せっかく名前を入れてもらったのに遊んだことがありません。
大ヒットゲームではありませんが、遊んだ人が口をそろえて「いいゲームだった」という程度には、良作だったようです。
せっかくなので裏話。
伝聞ばかりで申し訳ないけど、当時アルバイトしていただけなので深いことはわかりません。
マップデータとか、とても ROM に入りきらない広いもので、圧縮して入れてあるそうですよ。
メインプログラマの人が、ハフマン符号使って圧縮している、と言っていました。
ハフマン符号を使うと、任意の位置のマップデータをすぐに取り出すのは難しいわけですが、マップ全体データを荒く区切って、「代表的な位置」を示すポインタを持っている、と言っていたと思います。
任意の位置のマップデータが欲しい場合、近い位置のポインタから展開を始めて、目的のデータを取得します。
…ポインタがかなりの数になって、データは圧縮したけどそれほどメモリ効率は良くない、と言っていた気がします。
このゲームの BGM 、ジャングルっぽい雰囲気で、打楽器を中心とした音楽になっています。
最初は、打楽器をサンプリングして、それで音楽を作ろうとした…のですが、打楽器ってホワイトノイズに近い周波数成分のものが多くて、音階を出そうとしても出ない。
そこで、低いベースの音と打楽器の音を重ねることで、打楽器っぽいまま音階が出るようにしたのではなかったかな。
メインプログラマーの人は、もともと音楽好きが転じてサウンドプログラマーもやっていた人で、この「音作り」もメインプログラマーの手によるものだったはずです。
その音を使って楽曲を作るのは、別の人に任せていましたけど。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
たしか１月くらいの話だと思うのだが、小３の次女が、学校の理科で「電気」を習ってきた。
電池に豆電球を繋げると光る。
途中ににスイッチをつけ、回路を「切ってしまう」と光らなくなる。
他にも、回路の一部に10円玉をはさんでも電気が流れたり、消しゴムだったら流れなかったり。
「電気とはどういうものか」という、初歩の初歩だ。
で、こんな初歩的なことを学んだだけなのに、多くのことを知った気になって言うんだ。
「どうやって、コンピューターは電気で計算しているの？」と。
実はこのテーマ、以前に当 WEB サイトで書こうと思ったことがあるものだ。
古いコンピューターの話を調べるのが好きで、いろいろ紹介記事も書いている。
今のコンピューターと違い、初期のコンピューターというのはいろいろ単純でね。
思いっきり単純化した「動作原理」を説明したいと思ったことがあるんだ。
でも、その時は記事にしなかった。
ある程度「コンピューターの話」として書くと、どうしても難しくなるから。
思い切って、身近な別の話に置き換えて書くこともできる。
そうすると、ちょっとはわかりやすい話になるのだけど、コンピューターの歴史としては嘘になる。
で、自分で没にしたんだ。
没にする過程で、それなりの記事はまとめていたので、「思い切ってわかりやすくした説明」は頭の中にあった。
それこそ、小３で習う電気の知識で、十分に理解できる「コンピューターの基礎回路」だ。
現代の本当のコンピューターに使われている回路とは、いろいろと違う。
でも、「原理」を知りたいだけなら十分なものだ。
すでに頭の中に説明しやすい話があったため、次女にはすぐに説明してやることができた。
お風呂に入りながら概要を話して…でも、回路図があった方がわかりやすいため、風呂を上がってから回路図を描きながら説明しなおした。
それで、小３でもだいたい理解できる程度の話。
この話は、もう一度「書いておいてもいいかも」と思い直したのだけど、面倒くさくてほったらかしていた。
そして、数日前に小学校は春休みに入ってしまった。
「小３の次女に向けた話」として書こうと思っていたのに、あと数日で４年生に進級してしまう。
というわけで、一気に書き起こした。
面倒くさかった理由の一つは「回路図を描くのが面倒」だったのだけど、draw.ioという良いサイトを見つけた。
というわけで書いたのが、電気で計算する方法という記事。
技術記事のコーナーに入れておいたが、微妙に技術ではない気もしている。
２進数１桁の、掛け算と足し算を電気でやる方法を書いてある。
そして、それを拡張して、複数桁同士の足し算を行う方法の概要を示す。
さらには複数桁同士の引き算・掛け算をやる方法の「ヒント」までを示す。
複数桁同士の割り算は、知らない。そんな複雑な回路、僕がわからないから。
僕はソフト屋なので、回路は概要しかわからないんだ。
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |