目次
01日 あけましておめでとうございます
03日 親戚廻り
10日 原初のプログラム
23日 サターンポリゴンのゆがみ
25日 顔に傷
29日 テクニカルサポート
昨年末は忙しく、新年への備えもいい加減になった。
写真にあるおせち料理も、今年はいつもほど凝っていない。
一の重：
かまぼこ（市販品） だて巻き（市販品＋僕の） 練り切り（市販品）
二の重：
栗きんとん（僕の） 田作り（妻の） 松前漬け（市販キット：僕） コーヒー花豆（市販品）
三の重：
鶏ハム（僕の） 昆布巻き（市販品） イクラしょうゆ漬け（秋に僕が作った） ゴマ豆腐（市販品）
別皿：
豚の角煮（妻の）
ゴマ豆腐は唐突な気がするけど、今朝重箱に料理を詰めていたら場所が余ったため。
妻に「何入れよう？」と聞いたら、ゴマ豆腐食べたいと言われた。
おまけ：
さては南京玉すだれ。
— wizforest (@wizforest) December 31, 2017
ちょいとかえせば…
伊達巻の出来上がり。 pic.twitter.com/tqQm6x0xgh
忙しかったため、大掃除もいつもより簡単にしか行っていない。
窓ふきは行った。風呂掃除も行った。台所の換気扇とシンクも洗った。
でも、いつもは僕がやるトイレ掃除は妻にやってもらった。
台所の壁などの拭き掃除は出来ていない。
しかし、「手を抜いた」ことで、大みそかに余裕ができた。
去年から、子供たちが「年越しを見たい」と起きているようになった。
（以前は、許可しても起きていられなかった）
年越しそばは夕食だったので、１２時近くになると「おなかすいた」と言われた。
そこで、お菓子を出し、酒のつまみ的なものも出し、妻と酒を飲みながら、子供たちと笑いながらの年越しとなった。
これはこれでよい。
「ゆく年くる年」が終わったら、子供は「眠いー」とすぐに寝た。
戌年だ。
一回りした、１２年前の戌年クイズをリンクしておく。
１２年前なら微妙にわかってもらえた問題なのだけど、すでに古すぎてわからない人が多い気がする。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
親戚廻りというか、単に実家に帰っただけなのだけど。
そして、実家と言っても生まれ育った家はすでに引っ越していて、長男夫婦と母が一緒に暮らしているため、そこが「実家」扱いなだけだけど。
毎年恒例で正月には兄弟一同が集まるのだけど、昨年は長兄の娘が流行性の風邪をひいてしまい、急遽キャンセルとなった。
なので、集まるのは２年ぶり。
今年は、長姉・末妹の家族を除き、兄弟家族全員が集まった。
（長姉は北海道在住なので来れない。子供は東京に暮らしていたので２年前に来たが、結婚したため今年は欠席。末妹は愛知在住なので、こちらも来れない）
２年前は、うちの子供たちが「クリスマスプレゼント」にもらったボードゲーム（ミッドナイトパーティ）を持って行ったのだが、あまり遊ぶ雰囲気ではなかった。
今年もプレゼントのゲームを持って行きたい、というので、単純なものに厳選する。
しかし、今年はこのゲームが大いに盛り上がり、「もうちょっと複雑なのがあっても良かった」と言われた。
長兄の娘と、次姉の娘（ともに、うちの子から見ると従姉）が、多人数で楽しめるボードゲームを遊びたかったのだそうだ。
しかし、それぞれの家では人数が少なく、なかなか遊ぶ機会がない。
正月で集まったところに、ちょうど単純ですぐ遊べるゲームがあったため、大いに盛り上がった、というわけ。
ちなみに、遊んだのはキャプテン・リノ、赤ずきんは眠らない、街コロの３本。
うちの長男はドラスレも持って行きたかったのだけど、「複雑なのはルール教えて遊ぶ暇が無いと思うよ」と止めておいた。
結果的には、持っていくのが正解だった。
（過去の日記に書いていなかったが、街コロとドラスレは昨年のクリスマスプレゼント。
今年、長女は「うちに来るサンタさんは、いつも面白いゲームをプレゼントしてくれる。サンタさんゲームに詳しいんだね」って喜んでいた。）
事前に「スプラ２持ってく」と連絡して置いたら、次姉の娘が持ってきてくれた。
他には誰もやっていないようだ。
２台でスプラ対戦。
我が家では長女（小４）が一番上手なので、長女と対戦する。
数度やったが、社会人２年目の従姉に圧勝。
そのまま対戦していてもつまらないので、二人で「対戦ではない」遊びを始める。
というか、最近長女が良くあそんでいる「お絵かき」を披露。
最近は、ガチマッチでもお絵かきを披露している。
ハートや星を描いていると、面白がって敵でも攻撃せずに近くで見守ってくれることがあるそうだ。
…で、その間にチームの誰かが攻め込んで、勝つ。
ハートを多用する謎の攻撃により、相手を魅了して、何が何だかわからないうちに勝ってしまうこの戦法は、我が家では「プリキュア戦法」と呼ばれている。
で、同じ場所で二人でお絵かきをすると、枠を描いた中を別の色で塗ったり、顔を描くときに口と頬だけを赤くしたり、いろいろな遊びができる。
さらに、最近見た「バグ」を再現したりして遊び始める。
敵味方が完全に意思を疎通しないと遊べない…
例えば、インクアーマーで「爆弾一回分」の防御力を増したうえで、敵の爆弾によりふっとばされて、普通では行けない場所に入る。
長女はそういう遊び方もいろいろ知ってはいるのだけど、自分で試したことはない。
これを二人で行い、成功させたりする。
なかなか楽しかった。
ちなみにこの従姉（僕から見ると次姉の娘）は、３歳の時にゲームボーイと「ポケットモンスター・ピカチュウ」を買い与えられたことから始まり、ゲームオタク人生まっしぐら。
いや、ゲームオタクだけでなく、オタク文化全般かな。
高校の頃からはイラストを描いて発表し、コミケなんかにも同人誌を出していたみたい。
大学の頃はネットで人気のある、いわゆる「神絵師」扱いだったようだ。
社会人…といっても、いきなりフリーのイラストレーターになり、イラストだけでなく動画作成なんかもできるので、結構仕事が忙しいらしい。
うちの長女と、ゲーム中の「フレンド」にはなったのだけど、仕事が忙しいので遊ぶ時は深夜だそうで、ゲーム内で会えるかどうかは微妙な所。
＃彼女の絵は数枚見たことがあり、非常にかわいいイラストを描いていたのだけど、あまり深くは知らない。
親戚のおじさんに作品を見られるのも恥ずかしいだろうと思って詮索していないため。
実家の母は、以前よりボケが進んだようだ。
数か月前…母の誕生日にあった時は、時々急に昔の記憶がよみがえり、僕のことも認識できていた。
しかし、今回はどうも、自分の子供たちもよくわからないようだった。
話をしていても、３分前のことを覚えていられない。
しかし、どうも集まっているのが「親戚だ」ということはわかるようだし、親戚だから失礼が無いようにしないと、と思うようだ。
日が暮れてからは、たびたび「みんなが泊って行けるように、布団用意しないと」と心配していた。
そのたびに、今日はみんな帰るから布団の心配はいらないよ、と教える。
すると「帰る」と聞いて寂しいのか、また来れるかと聞いてくる。
実際、うちから車で２０分程度の距離なのだ。
だから、すぐ帰れるから今日は帰るし、また来るよ、と伝えておく。
長兄の家の都合もあるので頻繁に来るのは迷惑だろうし、来る予定があるわけでもないのだけど。
正月だ、ということはどうやらわかっているらしい。
ただ、今日が正月の１日なのか、それとも休みももう終わる７日なのか…ということはわかってない様子。
うちの子供たちも理解してくれていて、同じ質問を何度もされても、面倒くさがらずに答えてくれていた。
孫だという認識はないようだが、どうやら「親戚の子」であり、長男から中学生になりました、と聞くたびに、大きくなったねぇ、と何度も喜んでいた。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
長男が熱心だった Scratch プログラムだけど、この冬休み期間に、長女・次女も再チャレンジし始めた。
以前は難しくてやめてしまったのだけど、今の年齢なら楽しめるようだ。
で、長女（小４）から質問が出た。
Scratch は Flash という言語で作られていて、その Flash はＣ言語という別のプログラム言語で作られている。
…ここまでは、プログラム言語の多様性を知ってほしくて以前に教えている。
＃厳密に言えば、Scratch ver.2 が Flash の ActionScript 言語で作られていて、ActionScript は Ｃ言語の拡張である、C++ 言語で作られている。
ここからが長女の質問。
「では、このパソコンで動く一番最初のプログラムはどうやって作られたの？」
あぁ、なるほど。そこに疑問を持ったか。
同じようなことに興味を持っている人もいるかもしれないので、長女に答えたことを記して置こうと思う。
まず、目の前の疑問の答えは、クロスコンパイルだ。
すでに動いているコンピューターの上で、別のコンピューターのプログラムを開発する。
僕はテレビゲームの開発をやっていたけど、テレビゲーム機の上では、普通は「プログラム」を作れない。
長女も Nintendo Switch で遊んでいるけど、そこでプログラムは作れない。
プログラムを楽しみたいときは、パソコンで Scratch をやっている。
Switch でゲームを作っている人も、Switch を使って作っているわけではない。
パソコンの上でプログラムを作って、それを特殊機材で Switch に送って動かしているんだ。
新しいパソコンが作られる時も、同じように別のパソコンでプログラムを作ることになる。
今広く使われているパソコン…IBM PC 互換機、と呼ばれるものが出てきたときも、基本プログラムはすでにあったコンピューターで作られた。
＃それ以前の 8bit マシン…CP/M マシン上で開発されていたようだ。
長女はこの答えには納得できないようだった。
「このパソコンの」と言ったのは言葉のアヤで、真意は「最初のプログラム」にあったのだ。
そのプログラムはそれ以前のプログラムで作られたという。
じゃぁ、「それ以前」はどうやって作ったのか。もっともな疑問だ。
そのため、ここで話を切り替える。
コンピューターの中では、すべてを数値として扱っている。
計算をするときには、例えば「１番は足し算、２番は引き算」というように、命令も数値になる。
1 2 3
という３つの数値があったとしよう。
ここで、1 は足し算の命令で、2 3 が足すべきデータになる。結果は 5 だ。
一番最初のコンピューターでは、人間が直接この「数値」の列を作り出した。
もっとも、プログラムを作るときに 1 2 3 と直接書いていると、頭がこんがらがってしまう。
1 は足し算（英語で ADD）なのだから
ADD 2 3
のように紙に書いておき、プログラムが全部出来上がったら、命令を手作業で数値に直していけばよい。
そして、この数値を入力するには、ON / OFF できるスイッチを使う。
コンピューターの中では、数値は全部、電気信号の ON / OFF に置き換えて覚えられている。
ON なら 1 、OFF なら 0 として、寄せ集めるともっと大きな数値も表せるようになる。
＃いわゆる２進数だけど、この話では詳しく知る必要はない。
ちなみに、長女は以前教えて２進数を知っているので、この部分に疑問は持たなかった。
スイッチをぱちぱちやって数値を作り、「書き込み」スイッチを押すと、メモリに書き込まれる。
どんどん連続してメモリに書き込まれていく回路を作ると、これでプログラムを準備できる。
そして、CPU に対して「実行」を指示すれば、「最初のプログラム」が無事動き出す。
最初はこんな風にしてプログラムが作られた。
じゃぁ、最初にどんなプログラムを作ったか。
スイッチをぱちぱちやるのは、プログラム方法としてはかなり面倒くさい。
だから、最初に作るのは「タイプライターのキーを押すと、それが文字だと識別されるプログラム」だ。
これがあれば、もう「ぱちぱち」とはおさらば。タイプライターで効率よくプログラムが作れる。
次に作るのは、ADD なら 1 、SUB なら 2 …という、命令から数値への変換を、自動的にやってくれるプログラムだ。
先ほど「人間が手作業で命令を数値に直す」としていたけど、自動的にやってくれるプログラムがあれば効率が上がる。
＃一般には、数値化する作業を「アセンブル」（組み立て、の意味）と呼び、これを自動的に行うプログラムは「アセンブラ」と呼ばれる。
もし、この時点で新しいコンピューターが設計されたとしよう。
新しコンピューターでは、命令の数値なども変わるのが普通だ。
今まで使っていたコンピューターでは、ADD は 1 だったけど、新しいコンピューターでは 10 かもしれない。
そうしたら、アセンブラのプログラムを修正する。
ADD は 1、だったところを ADD は 10 、にするだけでいい。
これで、新しいコンピューター用のプログラムを作り出すことができる。
最初に書いた「クロスコンパイル」というのは、ただこれだけの話だ。
ここで話はひと段落。
スマホで情報を検索して、Altair 8800 の画像を長女に見せてみた。
Altair 8800 は、最初のコンピューターではないが、最初のパソコンとされる。
前面パネルには、ON / OFF のスイッチがたくさんついていて、結果出力のためのランプもある。
入力も、出力も、ON / OFF しかないんだ。
でも、タイプライター（厳密にはテレタイプ）を接続して使うのが普通だった。
電源を入れたら、RAM の中には何もない。
だから、まずはタイプライターからの入力を読み取るためのプログラムを、 ON / OFF スイッチで入れる必要があった。
このパソコンを使っている人は、それが毎日の作業なので、短いプログラムを暗記していた。
タイプライターの入力が読めるようになったら、タイプライターについている紙テープ読み取り機から、紙テープを読み込ませる。
テレタイプでは、入力内容を紙テープ化できた。そうすることで、同じ原稿を何度でも打ち出すことができる。
でも、ここでは紙テープに記録されているのは「文字」ではなく、プログラムそのものだ。
たとえば、テレタイプを入出力として、BASIC 言語を解釈するプログラム。
このプログラムが動き始めれば、タイプライターを使ってプログラムを作れるようになる。
時には、さらに「BASIC で作られたプログラム」を紙テープから読み込み、何らかの実作業に使ったかもしれない。
ここでは、タイプライターだから出力が紙なのだけど、キーボードで文字を入力して、人間にわかる文字で結果を返す、という、誰にでもわかりやすいプログラム環境が出来上がったことになる。
このときは、手っ取り早く Altair 8800 の画像を見せた。
でも、それ以前からコンピューターは存在する。
それらも、構造的にはほぼ同じだった。
うちのページでいえば、TX-0あたりを見ていただきたい。
Altair 8800 よりずっと古い機械だけど、トグルスイッチを使って２進数を入力するあたりも、ほぼ同じ構造だ。
もっとも、TX-0 は紙テープを読み込んでメモリにデータを配置する機能を、ハードウェアで持っていた。
そのため、毎回紙テープを読み込むプログラムを入れる必要はない。
さらに古く、電子計算機の元祖に近い EDSAC では、完成後の改造で「イニシャルオーダー」が備えつけられた。
抵抗とワイヤーで ON / OFF を表現することで、紙テープを読み込むプログラムを固定化したものだ。
必要に応じて取り外せるようになっていて、取り外すとその部分は普通のメモリとして扱われる。
ROM に準備され、コンピューターが起動するときに最初に読み込むプログラム…今でいえば、BIOS や UEFI に相当するものだった。
ともかく「手作業で」最初の小さなプログラムを作り上げ、そこからプログラム環境が整えられていく。
あとは、Scratch の話と一緒だ。
Scratch は Flash で作られ、Flash は C で作られていた。
Altair 8800 では、Scratch に相当するものが BASIC だった。
BASIC はアセンブラで作られ、そのアセンブラは、ON / OFF スイッチを駆使して入力されるものだった。
BASIC から C までの間は長女には説明しなかったけど、想像は付いたようだ。
より便利な環境を作るために、誰かが「その時使える」環境で、新しいプログラムを書いてきた。
その積み重ねの果てに、子供でも使える良く練り込まれた環境、Scratch が存在している。
Scratch も、そろそろ Javascript で書かれた Ver.3 に移行する予定だ。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
４年ほど前に、サターンのハードウェアに関して…いや、ハードに限らず周辺の噂話まで含めて、長大な記事を書いた。
嬉しいことに、今でも時々反響がある。
で、先日 Twitter で、「たしかに、プレステは大きく歪むが、サターンは歪まなかった」と言っている方がいた。
その言葉を読んで、ハッとしたのだ。
しまった。
サターンの大バグで、わざわざ「歪めて表示しないといけない」場合があったことを書いていない。
セガラリーチャンピオンシップは、サターンのプログラムがこなれてきたころに発表されたビッグタイトルだ。
非常によくできている。僕も当時、レーシングコントローラーまで購入してやり込んだ。
このゲームを遊んだことがある人なら、ゆっくりと走った際に、コースを表現するポリゴンの、一番「手前」…
説明しずらいが、画面の一番こちら側に来る部分が、妙に歪んで表示されていたことを覚えているかもしれない。
あの歪み、ソフトウェアでわざわざ歪めて表示している。
そうしないと、ハードウェアの別のバグにぶつかり、表示がおかしくなってしまうためだ。
サターンのテクスチャは方式上歪みが少なく、プレステのようには歪まない。
しかし別の部分のバグを回避するために、状況によってわざわざ歪ませるように表示しないといけない場合があった。
サターンのスプライト表示 LSI …VDP1 には、クリッピングウィンドウ機能というものがあった。
画面内の「上下左右」の辺の座標を指定することによって得られる四角形の中でだけスプライトを描画し、その外側には描かない、という機能だ。
通常は、この四角は画面の最大サイズになっている。
その外側にはメモリが無いから書き込んではいけないためだ。
でも、例えば画面を分割して対戦できるようなゲームでは、ウィンドウサイズを変えることで、それぞれのプレイヤーの画面の中だけを描くことができる。
車のバックミラーの中だけ別描画、というようなこともできるし、ゲーム内の背景にテレビ画面があってその中に別のものが表示されているような効果も出せる。
工夫次第でいろいろ使える便利な機能だ。
スプライトは「四角」で定義されていて、４つの頂点を自由な位置に指定することで変形表示できた。
これがいわゆる「ポリゴン」だ。
変形表示の際には、元の画像定義の「横１ライン」ごとに画像が転送され、このラインを重ねていくことで面が作られる。
南京玉すだれみたいなものを想像してもらえるといいだろう。
実際には、この「ライン」が送られる直前に、クリッピングウィンドウの処理が入る。
ラインの始点と終点がウィンドウの外にあるかどうかがチェックされ、外にある場合は、ウィンドウの辺とラインの交点を算出する。
交点はつまり「ウィンドウ内に表示される端の点」なので、ここからウィンドウ内だけを描けばよいわけだ。
始点側がウィンドウ外なら、交点を求めるとともに、テクスチャの読み出し開始アドレスをずらす。
終点側がウィンドウ外なら、交点を求めるが、テクスチャ読み出しアドレスは変えない。
（いずれも、テクスチャの読み出しスピードは、クリッピングしない際のラインの長さに依存する）
始点も終点もウィンドウ外なら？
その線は、全部がウィンドウ外だろう。描画の必要はなく、捨てられる。
…ここにバグがある。
おそらく、この処理は System32 の家庭用を作っていた際の名残で、スプライトは四角いまま拡大縮小する程度の前提だったのだろう。
変形しない、四角いスプライトを前提にすれば、始点も終点も描画外なら全体が描画外、は正しい。
しかし、サターンの変形スプライトでは、ラインの一部だけがウィンドウ内に入る、ということがあり得る。
ウィンドウの「角」の部分にかかるように、始点と終点が違う辺（例えば下辺と左辺）をはみ出して描画される場合だ。
この場合、先に書いたクリッピングアルゴリズムだと、ラインの描画全体が捨てられてしまうため、本来必要な描画が行われなくなる。
結果として、サターンで作ったポリゴンゲームの、画面の角の部分は描画が行われないことが多くなり、「穴が開く」状態となる。
レースゲームでは、コースを構成するポリゴンが画面の下左右角にはみ出る、という状況は当たり前に発生する。
そこで、セガラリーチャンピオンシップでは、２次元変換させた後のポリゴンの座標をさらに加工する。
具体的には、「左右」からはみ出さないようにプログラム内でクリッピングしてしまえばよい。
厳密に言えば、クリッピングによって表示が６角形になる場合があるのだけど、セガラリーではおそらくそのような状況にはならない。
クリッピングで５角形になる場合に限定すれば、外側の２頂点を適切に移動してやれば、見た目の上でポリゴンの「辺」の形状を変えないようにできる。
ただし、内部のテクスチャは大きく歪む。
これをどう誤魔化すかは、作る側のテクニックだ。
セガラリーの場合、路面のテクスチャは工夫されていて、多少歪んでもわからなかった。
また、極端に斜め線を作らなければ問題の状況は起きないので、ガードレールなどはポリゴン面が縦に分割されるようになっていたのだと思う。
そもそも、歪んでも十分に高速で動いていれば、一瞬で通り過ぎるためにあまり気にならない。
しかし、崖の斜面などの形状が歪んだ部分にぶつかり、ゆっくり動いたりすると、歪むのがわかった。
このゲーム、そんな下手なプレイしているようじゃダメなので、慣れるにしたがってそういうことは起きなくなるのだけど。
他のゲームでも、よく見ると画面端は歪んでいる場合が結構あった。
描画が破綻するというのは最悪の状況なので、回避のために工夫したのだろう。
初期の SGL には、自動的にゆがめることで破綻しないようにする機能、というのはなかったように思う。
でも、もしかしたらバージョンアップの過程でつけられていたかもしれない。
申し訳ないが、この辺りはちゃんと覚えていない。
この記事、書き上げてからネットで SS のセガラリーの動画探してみたのだけど、思ったような歪みが見つけられない。
記憶で書いているので多少違っている部分もあるかもしれない、と断っておく。
本当は、自分で実機でセガラリー動かして検証すればいいのだけど、そこまでやっていない。
この話はサターン記事の中に追記するのが適切なのだけど、個別論に入った長い話を追記すると話の腰を折ってしまう。
なので、日記に書いたうえで、記事内からリンクしておくことにする。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
16年 iOSでtextのコピー・ペーストができないバグの回避
申し訳ありませんが、現在意見投稿をできない状態にしています。 【獣】 歪まないけど汚いっていう印象でしたね～デイトナなんかでは一番手前側にくる道路が、下に落ちていくような感じになっていましたが、あれも表示がおかしくならなくするための対策だったのでしょうか (2018-01-24 13:01:05) |
今週の月曜日、２２日は関東地方に雪が降った。
大雪…まぁ、関東にしては大雪だったのだと思う。
2008年の雪ほどではなかった、と思うのだけど、10年も前の雪と比べたくなるくらいではあった。
小学校は午後の授業をキャンセル、中学校も部活動は中止となった。
で、最初に帰ってきた長女（小４）、泣きながら帰ってきた。
泣いている理由を尋ねたら「傘が曲がった」と言っていた。
先日買ったばかりでまだ新しい、お気に入りの傘だった。確かに曲がって閉められなくなっている。
でも、そんなの大丈夫。多分治せるから…と言っても泣き止まない。
さらに聞けば、雪で滑り、転んだところに運悪く柱があって顔をぶつけたそうだ。
傘が曲がったのもその時。
家に帰ってきたので傘を閉じようとしても閉まらず、最初の言葉が「傘が曲がった」になってしまっただけで、痛くて泣いていたのだった。
その時は、唇を切ってしまって血が出ていたので本人も慌てていたようだ。
血はすぐに止まったのだけど、内出血もしたようで、青黒く腫れた。
ご飯を食べるときも唇に当たると痛いそうで、お腹は空いているのだけど食べられない、と言っていた。
翌日火曜日は雪も止み良い天気。気温も高かった。
今回の日記の本筋とは関係ないのだけど、長女のクラスの担任のこの日の「授業」が素晴らしかった。
１時間目は国語の時間だったらしいのだけど「予定を入れ替えて、理科のヘチマの観察に行きます」と言ったらしい。
ヘチマは、秋にできたものをあえてほったらかし、果肉を腐らせてスポンジ状にしているもの。
もちろん、雪が積もっている中で観察に行く必要などない。
理由をつけて子供を外に出し、雪で遊ばせようとしたのだ。
しかも、これを１時間目に急遽持ってきた理由が素晴らしい。
「今朝、職員室で子供に雪遊びさせてよいかどうか話し合いが持たれていた。
時間の都合で結論が出なかったのだけど、多分禁止させるから今のうちにやってしまおう」と。
子どもたちにもそう説明して、疑われないように派手に遊ぶな、と注意したというのだから…なんというか、教育者がやっちゃいけないよね（笑）
もちろん褒めているのだけど。
結局、遊んでいる最中に別の先生に見つかり、担任の先生は怒られていたそうです。
これで雪遊びは中止になったのだけど、先生の指示で「他の先生に見つからないようにこっそり」一人１つの雪玉を作り、教室に持ち帰ったらしい。
それは、教室の外にあるベランダに置かれ、「誰の雪玉が一番最後まで溶け残るか」の競争になったそうだ。
ちなみに、小二の次女のクラスでは、２時間目のアタマに「雪遊び禁止」の指示が伝えられ、その際に理由も伝えられた。
４年前に子供が雪合戦をして、雪玉の中に石を入れたやつがいて、目に当たっておおごとになったんだって。
この件は、投げた子に聞き取ったところ「わざとではなく、地面の雪を掻き集めたら石が入ってしまったようだ」ということになったらしい。
わざとだったら「そういうことをするな」と皆に注意して遊ばせることもできるだろうけど、事故であれば未然に防ぐためには禁止しかない。
雪遊びくらいさせてもいいんじゃないか、と思う一方で、禁止するにもそれなりの理由があるのだから仕方が無いように思う。
残念ながら、この日のうちに雪は７割がた溶けてしまった。
で、さらに翌日、というのは昨日の水曜日。
長女は体育の授業があったらしい。
クラスに一人、体が大きくてスポーツ何をやらしても上手な子がいるらしい。
その話は、以前から聞いていた。
この日はハンドボールをやったのだそうだけど、相手チームにその子がいて、長女はキーパーをやっていた。
で…思いっきり投げられたボールをガードしようとして、顔に当たってしまったそうだ。
ゴールは守れた、と言っていたけど。
普通なら「痛かった」で済むのだろうけど、先日顔を怪我したばかりのところに当たり、すごく痛かったらしい。
家に帰ってきてから弱っていて、布団で寝ていた。
そしたら今度は、中学校から連絡。
長男が喧嘩して、顔にずいぶんと傷を負ったらしい。
妻が慌てて学校へ向かう。
長男は普段喧嘩するような性格ではないのだけど、「からかって」売られた喧嘩を買ってしまったようだ。
そうしたら、喧嘩を売った方はまさか本当に喧嘩になるとは思っておらず、力任せに顔を、主に引っ掻いて攻撃してきた…ということらしい。
顔を引っ掻くとか、弱いやつのすることで、本当に喧嘩になるとは思っていなかったのだろう。
売られた喧嘩を買ってしまった長男にも問題はあるが、最初にタックルしたこと以外は攻撃していないそうだ。
そのため、学校からは傷の量と最初に喧嘩を売ったことで「全面的に相手が悪い」ことになってしまったらしい。
でも、こういうのはどちらが悪いというものではない。
後で親御さんから連絡があってすごく謝られたのだけど、中学男子なのだから喧嘩くらいすることもあるだろう。
子供同士がうまくやっていれば、親が口を出す必要はない。
…うまく、というのは、気に食わないから近づかない、というような対処も含む。
仲良しでいることだけが喧嘩を避ける道ではないのだ。そういうことを学ぶのも勉強の内だ。
眼鏡をかけていたので、逆に目は守られたようだ。
でも、目の周りにひっかき傷がたくさん。
最初は出血も多く、腫れてもいたので学校も慌てたらしいのだけど、家に帰るころにはすべて「小さな傷」になっていた。
すぐ治ると思うのだけど、当面は顔はばんそうこうだらけだ。
あと、眼鏡のフレームが曲がった。
これは昨日のうちに眼鏡屋に行って調整してもらった。
その眼鏡屋(Zoff)の商品については、調整無料なのでありがたい。
そもそも、成長期なので視力も変動する。
ちゃんと検査したうえで新たな眼鏡も作ってもらい、これは今日受け取りに行くそうだ。
長女、長男が顔に傷を負った。
２度あることは３度あるから、気を付けるんだよ、と次女には言っておいた。
注意を促したことで、冗談で済めばいい。
（もし冗談じゃなくなったらここでネタにします）
同じテーマの日記(最近の一覧)
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
1998年の年頭だったと思います。…正確に覚えていないのですが。
AM1件内に、テクニカルサポートチームが作られました。
一応独立した「課」に相当するのかな。
企画課、デザイン課、プログラム課に並列する形の「テクニカルサポート課」です。
でも、実際には課長に当たる人と課員１名の、２名だけ。
後で増員されるのですが、増えた時でも４名程度。
課というよりはチームでした。
で、創設にあたり僕に声がかかりました。
最初の課員１名、というのは僕のことです。
テクサポをやってほしい、と言われたときは、正直なところ左遷だと思いました。
プログラムが好きでプログラマーをやっているのに、一線から退くのですから。
実際この頃、左遷されても仕方ないような「身に覚え」がありまして…
新たに MODEL-2 ゲームのチームに入ったのですが、それまで ST-V を使っていたのでハードウェアの癖などがわからず、プログラムしていてもどうも「乗らない」のです。
頼まれていた「研究課題」が、どうもぼんやりしたものだったこともあって、２週間くらいいじっていたのですが何も成果を上げられていませんでした。
もっと私情を語れば、今の妻と付き合い始めた時期で、色ボケだったのです。
慣れてないハードとぼんやりした研究テーマ、さらには色ボケで、仕事に身が入っていなかったのは事実。
それで「左遷」なのだと思ったのです。
しかし、仕事を始めてみてわかりましたが、別に左遷されたわけではなく、「僕が適任」だったのでした。
テクサポの仕事は、大きく分けてふたつ。
部署内の環境整備と、サードパーティのサポートでした。
部署内ではネットワーク管理などが主な仕事だったのですが、詳しい人がテクサポ課長しかいなかったのです。
僕だって詳しくありませんでした。
まだ当時はそれほど知られていなかった「Linux」ってやつを、Towns にインストールしてみたことがあった程度。
もっとも、インストールなんて、インストーラーさえあれば誰でもできます。
そもそも、部署内では多くの人が UNIX を使っているだけで、詳しくはないのです。
仕事で使う、ファイル操作やコンパイラ起動などのコマンドは理解していても、その程度。
僕は awk や perl を使って、仕事に必要なツールをどんどん自作していました。
これなら UNIX 管理もできるのではないか…と思われたようです。
＃awk や perl などのスクリプト言語は、システム管理にもよく使われます。
サポート仕事の多くは「ST-Vのサードパーティサポート」でした。
僕としては ST-V を「普通に使っていた」程度で、それほど詳しいという認識はなかったのですが、部署内では一番詳しいと考えられていたようです。
…えーとね、過去にサターン関連の記事書いているけど、知識としてはその程度。
マニュアルを読めば大体のことは書いてあります。
SGL の動作がわからない時に逆アセンブルして内部構造解析するくらいはやっていたけど、自分で大規模ライブラリ組めるほどの腕はない。
ハードウェアに関しては、ST-V の BIOS 作った人が同じ部署内にいたので、多分その人のほうが詳しい。
（と、当時は思っていたのだけど、BIOS は必ずしもハードを叩かないので、その人はそれほど詳しくなかったらしい。もちろん BIOS には詳しかったけど）
また、サードパーティサポートは、当然ながらサードパーティとのコミュニケーションが必要となります。
これが…部署内の優れた技術者の多くが、いわゆるコミュ障なんですね。
僕だってそれほど人づきあい上手ではないのだけど…
少なくとも、部署内の優れた技術者と話ができる程度には技術がわかりますし、仕事上の話ができる程度にはコミュニケーション能力もあります。
結局、求められていたのは突出した能力ではなく、全方位にそこそこできること。
それを満たせる人が案外少なく、僕が適任だったというわけです。
といっても、仕事の多くは雑用でした。
本当の雑用って、企画課が中心になってこなしていたのですが、「技術的な」雑用というのも結構あるのです。
そういうのは企画の人にはできない。
技術雑用は、それまではプログラム課の人が、役割分担して分散することでやっていました。
役割を任された人を、課内では「奉行」と呼ばれていました。
例えば、基板奉行は基板の管理をしていました。
ゲーム基板も多数ありますし、開発用の特殊機材や PC も基板奉行の管理するもの。
ケーブル奉行は、山ほどある謎のケーブル類を管理していました。
当時は、シリアルケーブルでも RS-232C や RS-422 があり、そのコネクタ形状も複数ありました。
パラレルケーブルも、SCSI ケーブルもコネクタ形状が多数あり、両端の組み合わせにより膨大な数のケーブルが存在しました。
必要な時に必要なケーブルを取り出せるように管理しておくのは大変な仕事だったのです。
その他、マニュアル奉行、筐体奉行…仕事上管理しなくてはならない膨大な資材ごとに「奉行」仕事がありました。
全部雑用ですが、誰かがやらなくてはならない仕事のため、任された人が通常業務の合間にやっていたのです。
これらは、すべてテクサポの仕事として集約されました。
最初の頃の仕事は、山ほどあるケーブルを、現状で多数使用されているものを除き、１種類１本づつ残して捨てる、という作業だったと思います。
同じ種類かどうかを判定するだけでも大変で、他の作業の合間にやっていて、これだけで半月くらいかかったのではないかな。
ここまで、自分が開発に関与したゲームの話を書いてきました。
しかし、これ以降は直接的に関与したゲームはありません。
一方で、サポートで関与したゲームなどはありますし、プログラムとは違う形でゲーム開発に関与する形になりました。
今後は、そうした話を書いていきたいと思います。
同じテーマの日記(最近の一覧)
関連ページ
The House of the Dead 2【日記 18/12/28】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |