カテゴリー: 古いポエム

6月に入ってから禁煙を始めたこともあって、気を紛らわすために、ちょっと違うことに取り組んでみた。何をしていたかというと、部屋の隅で冬眠している、古いPCを再利用できないかを実験していた。ターゲットとなるのは6台ある。そのうちの新しい方の2台に絞ってやることした。一つはPhenom II X3、もう一つはCore 2 Quad Q6600のものだ。X3は2010年、Q6600は2008年頃にリリースされたもので、およそ15年ほど前のCPUだ。X3は家族が使用していたもので、Q6600は自身が過去に使用していたものだ。どちらも自作PC、つまり、パーツ単位で購入して組み立てたものだ。リフォーム前の状態では、Windows Vistaがインストールされていた。これは、最後に購入した、また最後に利用していたWindowsのバージョンでもある。それから完全にLinuxに移行してしまった。

まず、現状のVistaに入っているデータや、動作状況、パフォーマンスを確認してみる。Vistaは削除してしまうかどうか迷うところだった。Q6600の方で、1台は使えるようにしておくことにした。こちらは唯一のSSD (128GB)にインストールされている。動作はそこそこ軽快だ。しかし、Vistaでインターネットに繋ぐのも、何か生産的なことを行うのも、時間を浪費しているだけのようで気が進まない。一方で、最後のWindowsとして、残しておきたい気持ちもある。本当に必要になることには、まずならないだろうから、きっぱり消してしまった方が心理的にも物質的にも健全であることに違いはない。もし、万が一必要になったときは、そのときに再インストールするようにすれば良いとも思われる。やっかいなのは、インストールが非常に面倒だということだ。自動ライセンス認証に失敗すると、電話を通して30桁近くのキーを入力する手間が発生する可能性があり、そんなことはもうやりたくない。そういうわけで、一応残しておくことにする。その他のストレージとして、1TBのHDDが3つ接続されている。ここにLinuxをインストールしていくことにする。このPCのためにSSDを購入する気にはなれない。

Q6600の方は、事前に問題があることを認知していた。1年くらい前から、使用中に突然電源が落ちて、リセットがかかってしまう現象が発生している。Manjaroをインストールして、Vistaの問題で発生しているのかどうかを特定しようとした結果、そちらでも落ちるので、ハードウェアの問題だということが分かっている。今回、その原因を完全に特定できた。使用しているPCケースのファンが小さめで、騒音がうるさく、もう一つ、お亡くなりになったPCのケース、これもやはり相当古いものではあるが、が気持ち静かなので、そちらに移すことにした。その作業中に、CPUクーラーがぐらついていた。作業中にはずみで外れてしまったのかと思っていたが、なんと、4つの取り付けピンのうち一つの爪が折れてしまっていた。おそらく、そのためにCPUが冷却されず、MBの保護によって落ちていていたのだろう。これはありがたいことだった。おかげでCPUもMBもお亡くなりにならずに済んだ。その爪の折れたCPUクーラーは破棄することにして、代わりのものは用意がないので、購入する必要があった。Q6600はLGA775というソケットになっている。PCをショップに言ってみると、運良く一つ、手頃な値段で入手することができた。ヒートシンクが巨大で、ケースのスペースギリギリで、取り付けになかなか苦労した。無事取り付けることができたようで、適当な負荷をかけながら試運転してみると、もう落ちることはなくなった。

準備は整ったので、Linuxをインストールしていくことにした。ここでも厄介な問題に遭遇した。X3の方はインストーラーのライブ環境のブート中に停止する。Q6600の方は、ビデオの信号がなくなり、No Signalと表示され、ディスプレイが電源オフになる。それぞれ、別の原因を抱えていた。X3の方は、DVDメディアからインストールしようとすると失敗するようだ。USBスティックメモリからインストールすれば、大体はいける。MXとUbuntuをインストールすることに成功した。Q6600の方は厄介で、かなりの時間を費やした。古いハードウェアにも対応していそうなディストリビューションを片っ端から試していったが、同じ症状で一つとしてパスしない。諦めて、FreeBSDをインストールしてみることにした。こちらはうまくいく。FreeBSDのセットアップを続けていくと、Nvidiaのドライバをインストールするステップまで来た。FreeBSDでも、プロプライエタリなNvidiaのドライバがパッケージマネージャーで提供されている。取り付けてあるビデオカードはGTX460というものだ。2010年ごろに購入している。Nvidiaのドライバにはいくつかバージョンがあって、順番に試していくと、390というバージョンのものでうまくいった。これはかなり古いバージョンだ。それ以降のものでも以前のものでもうまくいかない。うまくいったといっても、完璧ではなく、仮想端末の表示がめちゃくちゃになる、悪い副作用もある。これの解決策は見つかっていない。ともかく、一応はFreeBSDが使える環境になった。ここで、一つ思い当たったのが、LinuxのインストーラーがNo Signalになるのは、ビデオカードのドライバが問題ではないかということだ。今回の最大の注意点はそれだった。Linuxのインストーラーのブートオプションにnomodesetというを加えてやると、見事に、ことごとく起動する。どうやら、インストーラーが使用するオープンソースのNvidiaドライバnovaeauが、このGTX460をうまく扱えていないのではないかと思われる。

nomodesetを指定することでインストーラーは使えるようになった。よってインストールも可能になった。インストールした後も重要な作業が残っている。まず、初回起動時には、GRUBのオプションで、やはりnomodesetをしてやらないといけない。その後で、システムにプロプライエタリのNvidiaドライバをインストールする。バージョンはもちろん390のものを使用しないといけない。厄介なのは、ディストリビューションによってそのインストール手順がまちまちであるということだ。何をやるべきか分かっていないとすぐに混乱する。Nvidiaのサイトで配布されているインストーラーを使用することもできるが、これは推奨される方法ではない。ディストリビューションによって提供されるものを利用するのが望ましく、利用できない場合の最後の手段としておく。

Q6600でやるべきことは明らかになった。面倒ではるあるのだが、もう迷うことはない。すでにいくつもDVDに焼いておいたので、それを利用したい。1TBのHDDのパーティションを100GB程度に細かく切っていく。8つ程度のOSをインストールする。実用的には、そんなたくさんのOSをインストールしても運用しきれないので、意味はないが、実験目的でやってみることにする。結果、2つは不完全な状態になったものの、ほとんどはきっちり利用可能な状態に持っていくことができた。最終的には、11個のOSが共存するシステムができた。

今回の体験を通して、GRUBの扱いと、ディスクの扱い方に少し自信が持てるようになった。通常の利用においては、1つのPCに10個もインストールする機会はそうあるものではない。扱いづらいシステムになってしまうし、あやまって他のOSの領域に干渉してしまい、いつ破壊してしまうかわからない、不安定な状態になる。完全に実験目的のPCだと割り切ってやらないといけない。そんな機会はあまりなかったので、GRUBもディスク管理ツールも最低限の利用しかしたことがなかった。実際に運用しているPCでは、現状を破壊してしまわないように、慎重に取り扱う必要があり、もともとそうあるべきツールではあるものの、その程度の利用だとあまり理解を深めるための体験ができない。きっちり理解するためには、破壊してしまっても、そんなに被害が出ない、隔離された環境で思い切った実験する必要がある。なおかつ、実際の利用では必ずリスクが伴うので、実験においてもそれを反映して、完全にリスク0ではなく、失敗したらやってしまった感を味わえるようにしておきたい。今回の場合、これまでの作業が無に期するなる程度のリスクがあり、ちょうどよい。なるべくならそんな失敗はしたくないけど、やらかしてしまったら仕方ないと割り切れる。

GRUBとディスクについて、そこそこの経験値を得ることができた。しかし、どちらも古いPCの環境でやったもので、レガシーなBIOSとMBRでの実験であった。現行のPCではUEFIとGPTであるのが普通だろう。こちらの経験値稼ぎもどこかでやっておきたい。

もともと、眠っているPCの再生を目的として始めた作業であった。古いPCではあるが、極めて古いわけではなく、なんとか利用できるくらいの性能をもったPCではないかと考えていた。インストール作業を繰り返しているうちに、そのような甘い期待は裏切られることとなった。すこぶる動作が重い。Q6600の方は、どのディストリビューションでも、軽量なantiXのようなディストリビューションでも、満足のいくレスポンスが得られない。特にFirefoxの起動が遅い。システムの起動も遅い。システムの更新も遅い。もはや約15年前の構成なので、仕方のないことではある。むしろ、まだ動くことに感謝をするべきなのだろうか。X3の方は、MXしか動かしていなけど、なかなか良いレスポンスが得られることに満足している。

以前はよく、古いPCにLinuxをインストールして再活用しよう、というような見出しの雑誌などを見かけたものだ。もはやそのような状況ではなくなっているのではないだろうか。現代のLinuxディストリビューションは、そのような古いハードウェアのためにチューニングされていない。確かに、軽量なディストリビューションを使えば、かなり古いPCでもデスクトップ環境が整う。しかし、重要なWebブラウジングに必要とされるスペックが上がっていて、15年前とは全く異なっているので、いくらデスクトップが軽快に動作しても、Webが快適でなければ、有用なデスクトップ環境とは言えないものがある。Q6600は15年前のCPUだが、もうひとつ古い、Pentium 4やAthron XPといったものもある。これらを引っ張り出してきて再利用を試みることに、実用的な意味はあるのだろか。どう頑張っても、Webブラウジングのレスポンスを満足するものにするのは無理だろう。また、電源効率も悪く、地球に優しくない。実験目的なら良いだろうという考えも改めたほうが良い。OSのインストールにかかる時間も耐え難いものがある。最新の安いモデルで構成したPCを用意して、そこで実験を行うほうが、遥かに効率が良い。あえて太古のシステムを利用する価値を上げるとするなら、ノスタルジックな気分を味わえることと、過去を振り返る目的と、どこまで動作するかテストを行うことくらいだ。そうでないなら、さっさと新しいPCを組んだほうが良い、という結論に達した。

 5月29日から禁煙を始めた。6月からのつもりだったところ、煙草のストックがなくなったので、前倒しで始めることにした。そんなに固い決意ではなく、できればいいかなという程度だった。そういう弱い意思であることは自覚していたので、たぶん無理なんじゃないかなと思っていた。ところが、いざ始めてみると、もう4日も続いている。禁煙の一番つらいのは最初の1日目であることには疑いの余地がない。2日目もまだ辛いだろう。3日目辺りから徐々に楽になっていくものだ。適当に言ってるけど、あながち間違いではないはずだ。

今、警戒しないといけないのは、1本くらいいいよなと油断して吸ってしまうことだ。まだ、吸いたいという衝動がなくなったわけではない。コーヒーを飲むタイミングで、ここに1本あったらどんなにいいだろうと思わざるを得ない。そういうのを、インスタントコーヒーや水道水を大量に摂取してごまかしている。ここで良いコーヒーやミネラルウォーターなどを使っていないところは、今の所、成功しているポイントかもしれない。もし、良いものを飲んでいたら、摂取量から換算していくらかかっているとか、計算に入れていることだろう。そうすると、ちょっと節約するかという気にもなるものだ。そんなことは考えずに、いつもだったら吸っているタイミングで、まずいコーヒーにする。ちょっとでも吸いたい気持ちが湧いたら、まずいコーヒーにする。締めは水道水で流して、何もなかったことにする。こんな感じでやっている。なぜこういうサイクルになったのかはわからない。自然とこうなった。

まだまだ油断はできない状況ではある。それでも、1日目に比べれば、ずっと楽になってきたのだから、まだまだ楽になれるはずだ。そう思いたい。

 5月は1本も書かなかった。これだけ継続できないとなると、もう抜本的にやり方を変えたほうが良い。まる1ヶ月間、まったく画面に向かう気になれなかった理由は、書くのが大変だからだ。一度書き始めたら、画面いっぱいに文字が埋まるまで、この目安が3000文字なのだが、何かしら文章をひねり出してこないといけない。画面を開くのが億劫になる。意味のない文章をでっち上げるスキルを身につけることを一つの目標ともしていた。そもそも、そんなスキルを本気で欲しいと思っていたわけではない。今となっては、投稿を滞らせる悪影響が無視できない。こんなものはさっさと撤去してしまえば良い。遅すぎたくらいだ。

そういうわけで、これから文章量の目安を設定せずに、思いついたことを、気ままに、書けるだけ書いていくことにする。今回のこの投稿はおよそ350文字だ。これくらいでも十分。その代わり、なるべく高い頻度で投稿するようにしていきたい。

 もう4月も終わりだ。4月1日に再開すると書いておきながら、この1ヶ月間、一本も書かなかった。いっそ、きっぱりブログはやめてもいいんじゃないかとさえ思える。しかし、そう慌てる必要もないだろう。まずは1日1本という目標を修正することにする。毎日やらないといけないとなると、1日遅れただけでやる気がなくなってきて、1週間も滞納すればもう取り返すのは無理だ、となって、いっそ完全に放棄するかという心境になる。なので、下方修正することにする。

土日に1本ずつくらいでどうだろう。1週間に2本、1ヶ月に8本くらいといったところだ。これなら可能なように思える。そもそも、毎日というと、書くことがない。1週間あれば何かしらネタができるだろう。それをストックしておいて、週末に一気に消化すると行ったスタイルだ。ネタがあればそれほど苦痛に感じることもなくなるだろう。実際のところ、今月、あ、これについて書きたいな、と思うことはちょくちょくあった。そう思ったところで、どうせもう今月は全然こなせていなから、と実行に移すことはなかった。

それだけが問題でもない。あまりにノルマにしている文章量が多すぎるのも原因だ。 4Kモニタで編集画面を開いて、画面いっぱい分を目安としている。これは大体、日本語の3000文字になる。400文字の原稿用紙にすると、8枚分くらいだろうか。結構な量となっている。数行で書き終わるところを、なんとか話を広げて文字数を稼がないといけない。だから、すぐに書いてしまおうという気に慣れない。でも、これは維持しておきたい。短い文章で終わらせてしまうと、あまり深い考察ができずに終わってしまう。文章を書きながら思考を展開するということに少しの価値を見出している。文字にするまで思ってもいなかったことがひらめくことがある。短くしてしまうと、そういう体験ができなくなるので、余計に価値がなくなってしまう。

まだ3分の1くらいしか書いていないのだけど、もうほんとに書くことがない。何を書くべきかというようなテーマではもう何回か書いてきていて、同じことを繰り返すのは避けておきたいので、書く範囲が絞られてしまっている。ふらふらと思考を揺らして、たまたま引っかかった方向へ向かうように進めていくというやり方ができなくなってきている。もうなんでもいいから、さっさと文字を埋めて切り上げてしまいたい。

いつもは何も書くことがないと言いながら、何かしら掘り出してきて広げることができていたのだけど、今回は本当に何もない。話題を変えてしまうのも一つの手だが、4月の終わりを飾る1本なので、今月は何も書かなかったということを強調するためにも、無意味な文章で終えたい。意味のないこだわりだ。プログラミングでは、悪いコードは悪く見えるようにしようとというプラクティスがある。それに無理やり当てはめると、何も意味のない文章は、意味のないように見せるのが良い。飾り立てるために興味深いテーマを持ち出してくるべきではない。こうして意味のない文章で、無意味さを強調するべきだ。

ソースコードと違って、文章はそれほど良し悪しがひと目で分かるほど構造化されていないところがある。要は、実際に読んでみないとその文章が良い文章なのかどうかわからないということだ。無意味な文章であっても、書いているときほど読むときには無意味であることが明らかとならない。今、書きながらこの文章はまったく無意味だな、とひしひしと感じている。しかし、おそらく、後から見たときはそうともならない可能性が高い。へえ、こんなことを考えていたのか、と、まるで真剣に執筆に取り掛かっていたような誤解を与える可能性がある。これは、とりあえず文字数が埋められているから、真面目に取り組んだのだと思わさせる効果があるためだ。ほんとのところは、全然そんなのではない。もう、とにかくさっさと文字数を稼いで、この作業を終わらせてしまいたいという気持ちしかない。そこに何かしら意味を見出そうとするのは、間違っている。早い話、文字数の制限がなければ、今日は何も書くことがない、の一言で終わる内容だ。3000文字というノルマのせいで、後で読み返したときに、過去の自分を大きく見せてしまうような、良くない効果がある。

それでも尚、3000文字のノルマは外したくない。一度やめてしまうと、もう長文を書けなくなるのではないかという不安がある。結果としてできた文章には価値がなくとも、文章を書こうとする姿勢は評価するべきところがある。そう考えると、たちの悪い学校が罰として与える反省文と同質な感じにも思えなくもない。長けりゃいいというものでもない。反省文などの劣悪な学校が与える課題には、健全な成長に対して悪影響しかない。今、この文章を書いているのは誰に指示されたものでもないのだが、もしかしたら自分で自分に罰を与えているのに等しいのではないかという気がしてきている。

そのような判断するのはちょっと早い。なぜなら、今回はたまたま何度も使いまわしているテーマである、このブログの文章を書くことについて書いているから、もう飽きてきていて、楽しみが見いだせないからだ。何かしらもっと面白い、興味のあるテーマであったなら、これほど苦痛には感じなかっただろう。楽しくなければ、やはり反省文にも似たような感情で文章を書かないといけなくて、それは悪影響にもなり得るだろう。

ようやく終わりが見えてきたところで、一つ答えが出たかもしれない。それはとてもシンプルなもので、楽しんで書かないといけない、ということだ。楽しいという感覚を軽視してはいけない。楽しくないことをやるのは、ほとんどにおいて非効率的になる。創作活動においてそれは特に顕著だ。楽しいイコール愉快とか笑えるというわけではない。楽しいと感じるのは、何かしら感情に触れるところがあるときだ。ちょっと解釈が広い気もするが、その方が正しい。楽しいの反対はつまらないだ。苦痛に感じるときがあったとしても、必ずしもそれは対極にあるとは言えない。確かに、今回の執筆は苦痛ではあったが、つまらないという感じではなかった。今の所、ブログを書くのがつまらないと感じてはいないので、まだ続行してもよい。できれば、苦痛からは解放されたい。なるべくそうならないようなテーマを選ぶことにも気をつけたほうがいい。理想的には、文章を書くのが楽しくてたまらないところまで上り詰めることができるといい。それはちょっと欲張り過ぎで、もうちょっと現実的なところから言うと、なるべく楽しそうなテーマを選択することから始めよう。今までの目標であった、1日1本では余裕がなさすぎる。選択の余地がないので、苦痛になるようなテーマを選択してしまっていた。これからはそれを正していけば、なんとか持ち直すことができるに違いない。

1日1本を目安に書いていこうと目標を立てて始めたブログだけど、最初の月、2022年12月の1ヶ月しか続かなかった 。年明けてしばらくは続いていた。その後モンハンワールドにはまって、また、同時に仕事が入って、全部終わっても文章を書く気になれず、他にやることあるだろうと、放置していた。忘れていたわけでもなく、4月になったら始めようと考えていた。早いもので、あっという間に4月になってしまった。もうこれ以上先延ばしにするくらいなら、きっぱりとやめてしまったほうがいいくらいだ。そこで、重い腰を上げて書き始めることにした。

 1月〜3月の間、全く文章を書かなかったわけではない。本の感想を投稿するサイトがあって、そこで、なかなか長文の感想を投稿していたりしていた。長けりゃいいってもんでもないが、よくわからん文書をでっち上げるスキルはちょっと上がってきた。そんなスキル必要ない気もするが、何も書けないより、何かしら感じたことを吐き出すのには便利だ。後で見返したとき、真っ白であるよりも、こんなんだったっけ、と記憶を呼び覚ましてくれる効果は高い。直近で読み終えて投稿した感想だと、コードコンプリートの下巻だ。この本は情報量が多く、密度も高いので、何も記録を残さずに読んだらおそらく数日後にはすっかり忘れ去っていることだろう。どちらにせよ、1回読んだだけで身につくような内容ではなく、年に1回位、ざっと読み直すくらいの気持ちでいたほうがいいかもしれない。そういえば、この本は今年の読書計画で、今年中に読み終える本の1冊に入っていた。今の所12冊中2冊クリアになった。ブログをサボっていたせいか、何もしてなかったような感じがしていたのだけど、まずまずの成果ではなかろうか。順調だったら3/12になっているはずだが、1冊くらいなら取り返せるだろう。計画の見直しはまだ必要なさそうだ。

再スタートと言ってもブログを書くこと自体が本分ではなく、これは1日の成果を記録するたのめもので、後で読み返して、この時期はこんなことをしていたのか、と思い出すためだけにある。記録と言っても、日記のようなものではない。なんでもいいから文章に吐き出すことで、そのときの状態を振り返る。出てきたものにはあまり価値がなく、文章をかく作業の方が意味がある。考えていたことを素早く形にするスキルを身につける訓練になるからだ。以前、似たようなことを書いた気がするので、これ以上は書かないでおくことにしよう。この2〜3ヶ月サボっていたのだけど、その間も、「あ、これブログに残しておきたい」というような風に思うことは結構あった。だけど、1回間が空いてしまうと、なかなか筆、というかキーボードだけど、を取る気になれなかった。やはり生活サイクルに組み込んでしまうのが重要だ。大体3000文字で1時間といったところになる。この負荷が結構高い気がする。めんどうくさいな、と思ってしまう。そういう感情がわかないように、もう機械のように決まった時間に自動で書き始めるくらいにしないとだめだ。別に3000文字も書かないといけないというわけでもないが、あまりに少ないと、負荷がかるすぎると、ちゃんと考えていたように思えないし、すべてを吐き出すトレーニングにもならない気がするので、妥当なところではないかと思う。

今後、ちょっと方針を変えたいなという気がしてなくもない。今、YouTubeに動画をアップしていたりするのだけど、全く再生されない。最近のだと、CrystalでPongを1時間で作った、というのをアップして、そこそこ興味深そうなものに思えるのだが、再生回数0という素晴らしい結果になっている。再生回数を稼ぎたいというような欲はあまりなく、適当に作った動画をなんとなくアップしているだけのつもりだった。それでも、以前は10回程度のアクセスがあったのだが、最近アップしたのはまったくの0、あるいは2、３となっている。このブログも似たようなものだろう。さすがにちょっとむなしいな、と思うようになってきた。中身がどうこう以前に、0というのは誰の目にも止まっていないことになる。 Pongできたので、今度はテトリスをやろうと考えているのだが、Crystalでやっても需要はないだろうから、需要の高そうなPythonでやったらどのくらい再生されるのか、実験をしてみたいと思っていた。しかし、おそらく似たような結果になるのではないかという気がしている。同じようなコンセプトの動画を見ると、かなりの再生回数を稼いでいて、目に止まりやすいのかと思っていたのだが、なにか別の要因が有るのではないかと勘ぐっている。

はじめは、1時間で作るということになにか意味があるのか、ゴミみたいなコードを1時間で書くより、3時間かけてきっちり作る方がいいのではないか、そもそも、1発で1時間で完成させることなど不可能で、念入りに準備をして、その記憶をもとに再生するだけの作業になってしまうが、本当にそんなのでいいのか、などとかなり否定的に見ていた。しかし、実際やってみると、なかなか興味深い結果が得られた。ひとつは、1時間というのは本当にきつきつなので、無意識にコードを書けるくらいコードを把握していないといけないということだ。暗記することなど不可能ではないにしても、非効率なので、プログラムの設計と意味を完全に理解しておいて、それをヒントに書いていくという作業になる。もちろん、少なくとも一度は完成させておかないと、いくら設計ができていたとしても、細かなコードをその場で考えていたのでは間に合わないだろう。暗記までいかなくとも、こんな風に書くというのを、ほぼ完全に、覚えるというか、身体に叩き込んでおかないと無理だ。これは、予め用意しておいたプログラムを自分でほぼ完全に把握していないとできないことで、無意味ではないかもしれないと思い始めた。もう一つは、エラーなく正確にコーディングするスキルが必要になることだ。何もプレッシャーがない（かつTDDを採用しない）状態でコーディングをしていると、とりあえず書く、ビルドする、エラーなら直す、というステップを踏むことに躊躇はない。しかし、きつきつの時間だと、ちょっと書きたすたびに、いちいちエラーを出して直していたのではとても間に合わない。なので、ある程度まとまってかきあげて、かつ、それを1発でビルドを通すくらいの心構えが必要になる。しかし、こんなスキルが必要になるのかどうかは疑問ではある。最近、TDDを身につけるためにできることはないか模索しているのだけど、一気に書いて運が良ければビルドが通るなんてのは、まったくそぐわない。今、書きながら思った、否定的な一面だ。

ともかく、YouTubeで再生されない問題がある。方針を変えたいというのは、ブログとと連動できないかということだ。しかし、このブログも相当誰の目にも止まっていないだろうからあまり効果は期待できなさそうだ。そもそも、現代においてブログというものは有効なツールなのかという疑問もまだ捨てきれない。結局のところ、何も期待しないというのが正しいような気がする。

 ちょっとしたきっかけでモンハンワールドをやりたくなった。1年くらい前にプレイしていたデータはアイスボーンの途中で止まっている。プレイ時間は280時間くらいになっている。全く操作を覚えていない。ちょっとやってみたいだけなので、最初から始めることにした。

 このブログでは基本的にプログラミングのポエムを書いていきたいのだけど、ここ1週間ほど大したことをしてなくて、ネタがあまりない。投稿も滞っている。今、1月14日で、まだ3つしか投稿していない。なんとか回収していきたいので何でもいいので今やっていることで書いてしまうことにする。そうはいっても、ゲームプレイについて文章を書くというのはあまりやったことがない。うまく字数を稼げるかどうかはまだ分からない。もうこの時点で結構きつい。それでも、いつものようにキーボードに向かってなんかカタカタやっていれば何とかなるだろうと見込んでいる。

 実を言うとモンハンシリーズにはそんなに思い入れはない。初めてプレイしたモンハンがワールドで、かつ唯一ちゃんとプレイしたモンハンでもある。PS2やPSPの過去のタイトルをプレイしてきていれば、ワールドでの進化にもっと感動を覚えるものであったのだろう。そういうのがなかったので、普通に単独のゲームとしてプレイすることになった。おそらくシリーズで継承されている独特のシステムに最初は戸惑うところがある。慣れてくれば普通に受け入れられるようになるもので、そんなに奇抜なものと言うわけでもない。肉焼きなんかはちょっとした遊びだろうけど面白くて好きだ。こういう要素が各所に散りばめられている。シリーズを通してプレイしてきたならもっとほわっとさせられるところがたくさんあったのだろう。 そういうのを感じ取れないのはちょっと損をしているのかも知れない。

 モンハンは、タイトルが言い表しているように、モンスターを狩るのが主な目的のゲームなのだろう。しかし、他にもやることはたくさんある。単に素材を回収しながらフィールドを探索しているだけでも楽しめる。やろうと思えばいくらでもやることが見つかる。武器がたくさんあって、別の武器を選択するとプレイスタイルががらっと変わるので、使い方を覚えようとするだけでも結構な練習が必要になってくる。プレイスキルを上げようと思うなら色々試さないといけない。全部の武器を強化しようとしたらどれだけ時間がかかるのか見当がつかない。最終的には、フィールドに精通して、装備を強化して、効率よくモンスターを狩るというところに行き着くのだろう。そこに行き着くまでにはいろんなルートがある。単に効率よく装備を強化していくだけではない。その過程でモンスターの特徴を覚えていって、プレイスキルも向上させていかないといけない。ときには何の成果にも繋がらない、だらだらとしたプレイも必要となってくる。そういう何の意味もない時間を過ごす余裕を持つことがこのゲームを楽しむコツなのかなとも思っていた。気になったものは全部チェックしながら、目的と外れたルートに進んでみたりすることはしょっちゅうだった。

 以前のプレイは、そんな感じで効率などは求めないでだらだらとプレイしていたら280時間にもなってしまった。時間が許すならばそれもいいのだろうけど、もう一度同じことをやろうとは思わない。今回しばらくプレイして学んだことは、目的を持って行動するということだ。もし、討伐のクエスト受けたなら、その他のことは無視してしまう。これまでのやり方だと、道すがらに見かけた素材や痕跡なんかに気を配りながら、片っ端から回収して回っていた。そういうのを省くだけでずっと負担は軽くなる。素材回収が目的なら、それだけを目的として探索に出かけるべきだと学んだ。ターゲットを追いかけているときは、途中に見かけるものはガン無視していく。こういうやり方は結構苦手で、他のゲームとかでも途中で落ちているものは片っ端から回収してしまうタイプだ。RPGだと、宝箱はすべて回収しないと気がすまないし、話しかけられる人とはすべて会話しないと気がすまないタイプだ。このプレイスタイルは現代のゲームではあまりに時間を食いすぎる。逆に、無視できるものを徹底的に無視していかないといくら時間があっても足りない。ゲームだけではない、現実においても当てはまる。今はコンテンツが大量に溢れかえっている。ターゲットを追いかける途中で、目に入るものすべてを回収していくのはすこぶる効率が悪い。効率だけを求めてるわけではないのだけど、ターゲットから狙いが外れて、本来の目的を忘れてしまう。ありきたりなよく知られた諺だと、二兎を追うものは一兎をも得ずだ。漁夫の利とか棚からぼたもちというのもあるけど、あまり当てはまらない。ゲームにも現実にもそこら中にそのような利やぼたもちは転がっていて、それらを回収していたらかばんはすぐにいっぱいになってしまう。そんなわけで、目的でないものは徹底的無視してしまう、強い意志を持つことが大事だ。これを鍛えることは今後のゲームプレイにも現実でも役に立つものになりそうだ。

 そんなわけで、モンハンワールドをプレイすることはただ楽しいだけでなく、なかなか実りのあるものになりそうなのだけど、懸念するところもある。それは、中毒性が高いということだ。ゲームとしては時間を忘れてプレイさせられるというのは大成功している証だとも言える。プレイヤーにとっては、現状のように、ブログの投稿を10日近くも怠るまでにプレイしてしまうというのは大問題だ。正しくは、プレイし始めたのはここ3日位前なので、全部モンハンのせいにするのは適当ではない。でも、少なくともその3日はモンハンしかしていなかった。今はまだ序盤で、ストーリーを進めている段階で、オンラインの要素はまるでない。それであってすでに現状のように、現実に支障が出るほど、というとちょっと大げさだけど、丸々1日を費やすほどまではまりこんでしまったので、制限をかけたほうがいいだろう。このゲームの厄介なところで、1日に2時間程度とかだと全然進まない、進んだ気がしない。進んだ気がしないと楽しくないので、楽しくなるまでやり込んでしまう。これは良くない。単純に、2時間やって終わりにするという制限をかけるくらいなら、いっそやらないほうがいい。2時間でなにか成果を得られるようにすると良いかも知れない。なにか得られれば、やってやったという感触から、楽しかったという気持ちも湧いてくることだろう。そんなことが可能であるのならばだが。そもそも、ちょっとやって見るだけのつもりで始めたものだ。年末に立てた計画で、今年中にプレイするゲームとして何本も後に控えている。このままの調子でプレイしていたら、確実に計画倒れになる。どの辺で見切りをつけるかもちゃんと考えておかないといけない。せめてアイスボーンのストーリーをクリアするところまでやりたいという気持ちがないでもないが、それだけでもかなり時間がかかることが予想される。早いうちに決めてしまったほうが良い。

 新しいキーボードを買った。少し前、1ヶ月くらい前に、US配列のキーボードとJP配列のキーボードが入り混じっていて混乱するのでどちらかに統一したいということを書いた。あのあと、ラズパイ用に用意していた1000円のJP配列の無線キーボードにして、JP配列に戻れるかどうか様子を見ていた。やっぱり打ち間違いとか、そもそもUS配列のが打ちやすいとかある。それでもなんとかなるかなという感触は得られたので、JP配列で統一することにした。1月5日木曜日に、良いのがあれば購入する予定でPCショップに行ってきた。大体は今使っているのと同じ、ARCHISSのMaestro FLというやつをもう1本買うつもりで行った。ただ、事前にアマゾンで相場がいくらか情報を仕入れてあって、以前同じ店で買ったときよりも1割程度安くなっていたので、今回その店に行ってもそれより安くなっていることはないだろうなと思っていた。それどころか、その商品にしてもおそらく店頭よりアマゾンの方が安いのだろうと思っていた。割高になっても店頭で買うのかどうかは、どの程度価格差があるか次第という気持ちでいた。

 行ってみて、まず本命のMaestro FLがいくらかを確認しようとしたが、置いてなかった。前回来たときはあったのだけど、なくなっていた。テンキーだけあったので、一時品切れと行ったところだろうか。アマゾンでも買えるので買い逃したという感じではなかった。一応、いくらぐらいなのか確認して、あまり価格差がなければここで購入という感じだったので、ないならないでよかった。この店はキーボードの品揃えはなかなか豊富で、前来たときはREALFORCEも置いてあったのだけど、それもなくなっていた。実用重視のだとFILCOがあったけど、同じくらいの価格帯なら気に入ってるMaestroのでいいやと思いパスしておいた。

 別に予定が狂ったと言うほどでもなく、他にも種類豊富なゲーミングキーボードを鑑賞していくことにした。 むしろこれが楽しみで来たとも言える。ゲーミングキーボードって何かと言うと、正確な分類基準は分からない。ただ、大体は無駄に光るやつがそうだと思っている。光らないのにゲーミングキーボードと謳っているのは見たことがない。中で一番目を引いたのは、ROCCATというブランドのもので、価格もそこそこで、かなり奇抜なデザインをしている。試しにちょっとキーを押してみると、よく分からない。実際にPCの前に置いてやってみないと、ちょっと押しただけでは分からなかった。打鍵感は、他のどのゲーミングキーボードもいまいちピンとこない。1万後半するようなのでも、こんなもんなのかなと疑問に思ってしまうところがある。使ってみれば値段相応なのかもしれないとも考えた。そこに、REDRAGONというブランドのが目に入ってきた。6000円くらいで、触ってみるとみると悪くない。変にダサくてかっこいいような微妙な名前なのが気に入ったので、これにするかと思ったけど、一応、もしかしたらマナー違反かも知れないが、アマゾンを調べると同型が2000円くらい安く買えるのでやめておいた。6000円中2000円はちょっとでかい。今調べてみると、セール中で4000円になっているようだ。どうもJP配列がないので選択肢からは外れてしまう。

 最終的に選択したのは、MSIのもので、キーボードとマウスがセットになっているものだった。去年末に組んだPCが、マザボとCPUクーラーがMSIのもので、ケースは白になっている。ケースのサイドパネルが透明で、ちょうどCPUクーラーにMSIのロゴでもあるドラゴンみたいなのがフルカラーで光って存在感を醸し出している。目をつけたキーボードとマウスも、同じような白にフルカラーで光って、示し合わせたようにピッタリマッチしているように思えた。マウスも前の使いまわしなので、ここらで気分良く買えておきたいとは思っていた。欲を言えばマウスは無線にして欲しかった。それでも、デザインと価格でこれだけ要求を満たすものに遭遇できたことは幸運だっただろうと、それに決めた。またマナー違反にはなるだろうけど、アマゾンを調べるとやはりアマゾンの方が2000円ほど安いので、申し訳なく心苦しいのだが、買わないまま店を後にして、自宅から購入した。6000円ちょうどくらいだった。キーボードの打ち心地がどうこうよりも、デザインと価格をみれば超お買得だったと満足した。

 数日して、昨日届いた。開封して鑑賞してみると、思ったほど美しくはない。白と言ってもプラスチックっぽい白で、あまり高級感がない。実際、高級ではないのだから無駄に光沢があったりして無理に高級感を出さなくても良いだろう。光り方はきれいだし、マウスも統一感があるし、PC本体との相性もバッチリだ。肝心の打ち心地なのだけど、これがすごく微妙だ。ある程度は許容できると思っていたのだけど、その許容ラインギリギリと行ったところだろうか。US配列で使っていたのも、高いものではなかったのだが、そこそこのうち心地で、それと同じくらいだったらいいなあと期待していたけど無理だったようだ。つなぎに使っていた1000円のよりはずっとマシなのは当然だとしても、決して快適とは言えない。ほんと合格ギリギリラインの感じだ。キーを押し込んだとき、最後にグニャッとしたような感じで、押し込んだという感触が弱い。慣れたら気にならなくなるのかどうか分からない。マウスは前のよりちょっと小さい感じがするくらいで、普通に使えそうだ。有線なのはちょっと気になるところではある。

 MSIは信頼しているブランドなので、たとえキーボードが本業ではなくとも、安くてもそこそこのクオリティを求めてしまっていた。もし、これをデザインや今のPCとの相性を無視して買っていたのなら、とても納得のいくものではなかっただろう。今回の特殊な状況においては、打ち心地の悪さを無視できるくらい、デザインと相性が良いので買って良かったと思えるものだ。もしこの機を逃していたら、ずっと買っとけばよかったと後悔していたことだろう。しかし、このうち心地でこれからずっとやっていかないのかと思うとちょっと残念な気持ちがないかと言うと嘘になる。できれば、少しくらい価格があがってもいいから、もうちょっとクオリティを上げてほしかった。デザインとPCとの相性が完璧なだけに惜しい。

 今回に限って言うなら、打ち心地よりも見た目が勝っているので、失敗だったということは全然ない。しかし、もし、ただお買い得そうに見えたからといって購入に踏み切っていたのなら、そうではなかっただろう。おそらく、あまり安いものを買うべきではないと、残念に思っていたことだろう。そう考えると、今回は公開することもなくして勉強代も回収できたレアなケースだ。物品そのもの以上に、さらにお買い得な買い物だったとみなすことができる。学んだこと、キーボードの購入時に忘れていけないのは、安いキーボードにうち心地を期待してはいけないということだ。その家心地が気に入る、気に入らないの問題ではなく、そこまでの段階に達していない。微妙な違いではなく、明らかに安物感のする感触になっている。目安としては、1万以下のものは避けたほうがいいだろう。それ以下のものを買うときは、それを分かっていて買うようにすることだ。もし分かっていて買うのなら、話は別となる。間に合せのものが欲しかったとか、メインで使うものではないとか、そういうものが必要な事情というのはいくらでもある。すべてのPCに高いものを用意する必要などまったくない。しかし、メインに使うもので、打ち心地を求めるのなら、決して安物買いはしないほうがいい。別に今回の買い物が失敗だったわけもないし、むしろ良い買い物だったのだけど、そういうことが学べた。

 毎日書こうと目標を掲げたのに年明けからサボってしまった。もう7日だ。正月は何をしていたのだろう。少し予定が入って潰れた日があった。とは言っても2日間だけで、今日を除けば4日間はフリーだったはずだ。何もしてなかったということはないだろう。ちょっとリハビリも兼ねて、また1日分稼ぐために振り返ってみる。

 結構寝てた。最近あまり経験してなかったけど、正月だということで結構遅くまで起きていた。明け方の4時とか5時とかまで起きていたりした。それで、昼の12時過ぎまで寝ていたりしてた。起きても頭がぼーっとして、またそのまま仮眠のつもりが夕方まで寝てたり、1日12時間くらい寝ていた。普通の休みの日だったら起きたら夕方だったとか、絶望的な気分になるが、正月はむしろ清々しい気分だ。思えば、去年はそんなのなかったな気がする。たまにはこういうのもいい。正月だけだったらいいんだけど、まだそういう気分が抜けていない。もう今日は1月8日で、日曜日といえどとっくに通常運転に戻っていけない日になっている。昨日なんかはひたすら寝ていた、18時間くらい寝ていたのではないかと思う。12月頑張っていたのが嘘のように無駄に過ごしている。ここらへんで気持ちを切り替えるためにも無駄に字数を稼ぐブログを頑張っていこう。これやっている間はなんとなく何かをやった気になれる。あとで見返したときに、なんかやってだんだな、という錯覚に陥ることができる。それって逆効果何じゃないかという気もする。1行だけずっと寝てた、とだけ書いて投稿していたら、ああ、何もしてなかったんだなというのがすぐ分かる。毎日の記録を書いていく目的であるなら、そっちの方が、わかりやすくていいかも知れない。でも、このブログではそれは目的としていない。そんな惨めな現実をみても、今日は頑張ろうという気にならない。錯覚でもいいので、後から読み返して、こんなに奇妙で面白いことを考えていたのか、今日はもっと面白いことを考えられるかも知れないと思わせてくれるとなれるほうが良い。ずっと寝ていた、だけでは後に繋がらない。 それに、単なる記録としては、別のとこで日記を書いていて、それがその役割を果たしている。寝ていたという情報はそこから得ることができる。ここでは、寝ていただけだけど、そこからどうやって文章をひねり出すかに挑戦してみたい。実際、寝てたというだけの事実から、投稿1本当たりのノルマの3分の1程度をもう書き出すことができている。今まではこんなことに挑戦したこともなく、文章を書くのは苦手としていたことだった。こうやって、無意味な文章をでっちあげることができるようになったのは、少しは上達していることとみなしてもよいのだろうか。

 年始の大半を寝て過ごした。その中でもなにかやったことはないだろうかを思い返してみる。

 とりあえず、Rustの本を1冊読み終えた。年末に立てた今年の読書計画の、2023年に読み終える13冊のうちの1冊だ。1週間目の時点で読み終えることができた。なかなか良い出だしではないだろうか。さっき書いたとおり、今年入ってからの1週間はほとんど寝ていた。そんな状況の中で、すでに1週間足らずで1冊読み終えることができたというのは、良いニュースだ。今年1年のボーダーラインとして13冊は必ず達成したいと計画。このリストに変更は加えないつもりだ。これにプラスする形で、読んででおきたい本を挟んでいくことが可能かも知れない。小説を除いて、本来なら70冊くらい読み終えたいのがあるのを、これまでの実績から不可能だと見積もって13冊までに減らした。13冊というのは不本意な数だ。読みたいもの、もっというとさっさと片付けてしまいたいものはもっとたくさんある。大体1冊1ヶ月をみていた中、1周間た足らずでさっそく1冊片付けられたので、13冊は十分達成可能であることが分かった。しかし、油断はできない。今回読み終えたものは、優先度が高いというわけではなく、去年末に中途半端な状態だったから、とりあえず読み終えてしまおうという感じでリストに加えたものだった。必読というような内容でもなかった、というのは予め分かっていた。 ただ、今年はRustを中心にやっていくので、仮にリストに入れてなくても読んでしまうことには変わりなかっただろう。そういう状況を考慮すれば、やはり必読とカウントしても間違いではなかったと言える。でも、やはり本番はこれからだろう。1000ページ近い重厚なのが5冊は控えている。逆に考えれば他のはそれほど重厚でもないということだ。ライトなのから攻めていくか、優先度が高いのから攻めていくか、あるいは並行して処理していくか、選択は自由だ。ともかく計画を立てて見直しながらやっていくことが重要だ。現段階では、まず小手調べの1冊を読み終えたというところだろう。

 目的を持って何かを達成しようとして取り組んだのはそれだけだったかも知れない。あとはなんとなく、気の向くままに過ごしていた。その中で、分類可能な活動は、YouTubeを見てたことと、ドラクエVIを進めていたことだ。面白いから悪い時間の過ごし方ではないのだが、どちらも計画して始めたことではない。ぼーっとしてたら、なんとなく手が動いてしまった。無計画なのは良くない。どちらも面白くて、気を抜いたら今後もついつい手を出してしまいそうに思える。有意義な時間を過ごせたと考えればいいんだけど、その他の活動にまで影響してしまうのは問題だ。ゲームは今年中に50本くらいプレイすることになっている。全部をクリアするまでやるというのは不可能な数だ。とりあえずプレイするだけで、その中で最後まで進めるかどうかを判断するまでが目標だ。いくつかは最後までやるだろう。ドラクエVIはそのうちのひとつにまず入るのは間違い。すでに25時間くらいプレイしている。ここで中断するという選択肢はない。だったら手を出してしまってもそれほど計画から外れているということはない。ただ、なんとなく手を出してしまったというのが懸念する行動パターンだ。費やした時間の量が問題なのではない。最初から、今日のこの時間はプレイする、と決めてやるのならば、マル1日やっていようが、そんなに問題とはならない。実際には、毎日23時から24時を使って書くはずだったこのブログをほっぽりだしてプレイしていた。時間を忘れるほど夢中でやっていたというわけではなく、23時だから書かないといけないな、と自覚しているのに、書くの面倒だなあ、もうちょっと進めたいなとだらだらとプレイしていた。これは良くない。今の早い段階で気づけたのは不幸中の幸いだっと言うことにしておこう。YouTubeはもっと深刻だ。普段は猫とBGMの動画くらいしかみない。どういう経緯か覚えてないのだけど、ある動画にたどり着いた。中毒性が高く、無限にみてしまう。たぶんこれからもちょっくちょく見ていくことは避け難いかも知れない。これもゲームと同じで、まったく予定に入っていない時間を使ってしまうのがやはりまずい。本音はあんまりまずいと思ってない。ドラクエみたいに25時間も費やしてはいないはずだし、少なくともPCに向かっているので、さっと作業を切り替えることも可能だ。それは楽観視しすぎだ。PC向かっていようがいまいが、手と思考を稼働させていなかったら関係ない。これもまた、早い段階で気づけてよかった。さくっと気持ちを切り替えて、今日から通常モードに戻そう。

今年はちょっと去年とは状況が違う。具体的なことは書かないでおくけど、これまでのようにのんびりとプログラミングをやっているだけではいけない。具体的な成果が求められる。具体的な成果ってなんなのかというと、何でもいいけど、特にほしいのは完成されたゲーム作品だ。いつものように、本を読んでそれをで学んだ知識を活かしたデモを作って終わりでは全然足りない。ちゃんとプレイして面白いと思えるようなものを作らないといけない。そのためには、絵とか音楽とかもちゃんと作らないといけない。アーティスト志望ではないので、あまりに高いクオリティを求める必要はない。でも、適当にマウスで書いたやつや、マイクを転がして録音しただけのような適当なもので間に合わせることはできない。絵など普段全く練習してないし、グラフィックスツールの使い方も、モデリングツールの使い方も覚えないといけない。ツールの使い方を覚えるだけならそれほど難しくはないと見込んでいる。しかし、基礎的な絵の書き方やモデリングの技術は問題になる。1日や1週間と単発的に練習した程度ですぐに身につくものではない。クオリティを求めないと言ったけど、できるだけのことをして、それなりに特徴のある、味のあるようなものにしたい。音楽はゼロからスタートというわけでもない。楽器をやってきていて、最近離れていたけど、そこそこ練習もしてきていた過去がある。毛の生えた程度に知識もある。その経験を活かして、ゲームに使えるような楽曲やサウンドエフェクトを作る工程は、絵に比べればイメージができる。機材も少しは揃えてある。こういう背景を考えると、プログラミング、グラフィックス、音楽とゲームの基礎となる三大要素のうち最もスキルが欠けているのはグラフィックスということにになる。

 それより大事なものもある。個々の部品だけでなく、ゲームデザインを軽視してはいけない。ゲームデザインが何を指しているか、一般的な解釈は知らない。今言おうとしているのは、ゲーム全体の出来上がりを考える工程のことだ。大体のゲームの完成予想図がないと、どれだけの量と質が絵や音に求められるのかがわからない。それでは、どれだけスキルが不足しているのかも分からない。無限に時間があるのならば、ひたすら練習してクオリティの高い絵や音が用意できるようになるまで頑張ることができる。現実はそうではない。これまでプログラミングの修行にかけてきた時間と同じように、絵や音に対してかけることもできない。ゲームデザインが重要なのは、ゲームを面白くするためという本来の目的に加えて、どれだけのスキルが要求されるかを先に把握しておくためだ。いわば目標値の設定が必要だ。スキルポイントがどれだけ不足しているのかを確認して、そのために必要なレベル上げを行って、得られたスキルポイントをそこに分配するという戦略だ。実際にはこんな機械的に行えるわけではない。絵や音のスキル値がどれだけなのかを視覚的に把握するのは難しい。そこで、ゲームの完成予想図を明確に持っていることが助けとなる。思っているよりひどい絵だったら、それしか用意できないのであれば、不足しているということだ。

 制作が進んでいって、最初に求めていたものより要求が高くなってしまったとしても、悪い傾向ではない。そういう場合の原因は、最初のデザインが思っていたほど良くなかったのかもしれない。もうちょっと工夫すればもっと良くなるというところが見えてきたということだ。少なくとも、スキル値としては要求していた値を満たしたということになる。自分の性格では、少なくとも全く経験のない絵という分野に置いては、最初にデザインするときには、あまりに無茶な要求をしないのではないかと思っている。いきなり、世に出回っている一級品のゲームのような美麗な絵を用意しようなどと計画するとは思えない。おそらくは、技術的にはかなり初歩的なところからスタートするのではないかと思う。そこから段階的に、もっと良くなるためにはどうしたらいいかを考えて、積み上げていく形になると思う。その都度、ゲームデザインを改良していくというステップを踏むことになる。

 ゲームデザインについてちゃんと学ぶ必要はあるだろうか。そんなに構えて形式的に学ばないといけないというふうには思っていない。ヒットするゲームを考えるとなると、また話は別になるだろう。戦略的に、徹底的にゲームを分析しないといけない。なんとなく面白そうなゲームを作るというのでは、宝くじを当てるようなものに等しい。これまでの過去のヒットしたゲームを調べて、現在のゲームの状況も調べて、それらを加味した上で、これから作られるゲームにどのように取り入れていくか、しかも、全く新しいプレイ感が得られるようなオリジナルの要素とどうやって融合させるのかが考えられて行けなければならない。プレイヤーのターゲット層や広告についても考えないといけない。ゲームをヒットさせるというのは、およそ不可能にさえ思える。

 ヒットするゲームを生み出そうなどとだいそれた考えは持っていない。じゃあどんなゲームを生み出そうとしているのかというと、よく分からない。少なくとも単なるプログラミングのデモ以上のものを作りたいとは思っている。また、ヒットと呼べるまではいかなくてもいいけど、誰もプレイしないようなゲームでは満足できない。誰かがプレイしたかどうかなど、どうやって把握するのだろうか。売り物にしようとは今の段階では考えが及ばない。将来的にはそうでありたいと思っている。例えばPS Storeに並ぶような、インディーゲームの市場はどうなのだろう。個人でできる、ゲームを世に送り出すという場所はそのくらいが限度ではなかろうか。他のルート、例えばスマホで100万ダウンロードのようなのは、宝くじに近いものを感じる。もっとも、スマホのプログラミングは余り楽しくないので選択肢にない。それはいいとして、どのくらいの人にプレイしてもらいたいか、という目標もある程度は考えておかないといけないだろう。まだ何も作っていないのにそんなことを考えるのは、妄想に過ぎないのだろうか。だいそれた考えを持つのは良くない。広告付きのゲームを作って100万ダウンロードを目指すなど、そんなのはどうでもいい。段階的にやっていくのがいいだろう。まずは、小さくても完成されたゲームを作ることだ。

 完成されたゲームを作るのと同時に、これまでやってきた、プログラミングのデモのようなもを作って修行することを中断することはしたくない。でも、同時進行というのは難しいのだろう。デモを作るのは局所的なスキルを磨くことにはなるのだが、プログラミング全体のスキル向上にはあまり役に立たない。現実のプログラムには、デモプログラムには現れない、現実を反映した複雑な構造が入り込んでくる。こういう複雑さに立ち向かっていかないと、現実のプログラムをプログラミングする能力は磨かれていかない。だから、今年は現実のプログラム、大体はゲームだけど、を作り上げることを中心に据えていくのを目標としよう。

 一昨日と昨日で、来年の読書計画を立てた。2023年中に読み終えたいものをピックアップして、小説を除くと12冊となった。十分少ないように思える。所有しているもので、未読のものがおよそ1000冊あるので、1%ほどにしかならない。このままペースで行くと、今所持している本を読み終わるのに100年かかることになる。未読の本が溜まっていると、精神衛生上も良くない。何らかの対策が必要だ。

 未読の本を減らす一つの方法は、速読と呼ばれる読み方で、次々にページをめくっていって、大体の様子を把握してしまうことだ。そうして、とりあえず読んだとマーキングしてしまう。何度かこの方法は試している。一旦読み終えたことにして、じっくり読む価値があるかどうかを判断する。読む価値があるなら完了とせずに、未読のままにしておく。そして、いつか読むと記憶しておく。この方法はあまりうまく行かなかった。ちゃんと読んでないのに、読んだとしてしまったものと、きっちり読んだものとが入り混じって、わけがわからなくなる。それに、眺めるようにしてページをめくっていっただけでは、本当に読むべき価値あるものなのかどうか、判断が使いこともある。それよりも、わざわざお金を払って購入しているので、そのときに少なくとも一度は読む価値があると判断しているはずだ。それを、未読の本が溜まっているからと読む価値がないとしてしまうのは、未読を減らしたいから無理にそう判断させられてしまっている可能性が高い。

 速読は合わない。数をこなすこと自体には意義を感じない。読んだからには何かを残したいと思う。しかし、今のペースでは来世まで本を抱えていかないと読み終えることは不可能だ。もう、思い切った決断をしてしまう方がいいかも知れない。思い切って、何年も放置しているような本には引退してもらうことだ。本を買うことよりも、捨てることは簡単なことではない。購入するときに選別しているので、不要なもの、無関心なものというのは殆どない。何かしら読みたい部分が残されている。それらを回収しないままに手放す決断をするのはなかなか難しいことだ。多分、人生の最後までずっと持ったままでいるんだろうなというようなものまで、吟味する必要はない。それらはそのままでいい。だめなのは、それらと同列に本棚にそこまでは必要ないと思うような本が入り込んでいて、同じ1冊とカウントされていることだ。これがおかしい。今、未読がおよそ1000冊あるという情報が利用している本棚サービスで分かる。この1000冊という数字に本当に意味はあるのだろうか。1回読んでお終いの本、1日で読み終わる本と、最後の最後まで手放さいであろう本を同じ1冊としてカウントするのはやはりおかしい。

 あと、未読をどうやって消化するかという問題ではないのだけど、本を持ちすぎるのは良くない。読み終わったら、一つの判断を下すべきかも知れない。もう一度読むことがあるだろうか、読みたいと思うだろうかという判断だ。未読の本が山ほどある中で、2回読みたいと思えるようなのは貴重だ。こういうのは持ったままにして、本棚に飾っておいても悪くない。大体、1冊の本を通して知っていることしか書いてないというような本は殆どない。最初に選択する場面でそういうのは除外しているはずだからだ。その情報が本当に価値のあるものだった、十分に良い形で入手できる情報なのかどうかを判断するのは結構難しい。もう一度その情報を読みたくなる可能性は捨てきれないことが多い。そのしがらみを振り切って、なんとかして別れを告げないといけない。決断ができないまま、ずるずると持ち続けてしまうのはあまり良くない。たとえ一度読んだので、消化できていると思えることがあっても、まだ持ち続けているのならば、それはまたどこかで参照することがあるかも知れないという気持ちがあるからだ。

 コレクションが目的になってはいけない。関心のある分野の本が本棚にあると、確かに安心する。必要ならばすぐに手を出して、その情報を仕入れることができるという安心感だ。簡単な情報ではなく、熟練度を必要とするものでも、すぐに習得できるようなものではなくとも、いつかは、ちゃんと時間をかけて取り組む準備ができていると安心できる。コレクションのようにどんどんと本が溜まっていくのは、その安心感を得るためだと思う。何も準備ができていないと、ガイドブック無しで海外旅行をするような不安がある。ちょっとした保険のようなものだ。いつからか、本を所有しているからその分野の入口に経っているはずだと思いこむような習性が出てきているように思える。

 本を持ちすぎることの何が悪いのだろう。 なにか弊害はあるのだろうか。まず、本棚のスペースを浪費する。本棚にいっぱい本が並んでいるのは、良い面と悪い面がある。きれいに、必要な本だけが並んでいるのならば良い。無秩序に、どうでもいいようなものまで乱雑に並んでいたら悪い。部屋のインテリアとしての効果を無視しないほうがいい。美的感覚に反するものが並んでいれば、多かれ少なかれ、何かしらその場での活動に影響をもたらす。必ずしも何もないのがベストというわけではないが、集中力を乱すような、見にくい状態にしておくのは良くない。また、脳みその記憶領域を浪費する。あの本は少有していたとかしていないとか、何かしらにつけてついて回ることになる。亡霊のようなものだ。もっといろんなことを知りたいと思うのは結構なことだ。しかし、やり過ぎは良くない。程々なところでとどめておくよう自己制御できないと、いつまで経っても本に頼って、自分で考えて答えを出すということができなくなる。記憶領域を浪費すると、本来は自分で考えれば良いものを、考えるのに使われる領域まで、本の所有状況を管理するプログラムに使用されてしまっていて、本来の自然な形で回答を出そうとしなくなってしまう。記憶領域はクリーンに保っておかなければならない。

 自分にとっって、もっと大事なことは、読書自体が目的になってはいけないということだ。読書家になろうとなどしていない。本を読むというのは、単に情報を引き出すというだけでなく、その行為自体が一つの体験として価値を持つ場合もある。それは貴重な役割ではあるのだけど、自分には必要ない。もっぱら体験をすることによって得られる結果の方が大事だったりする。ゲームをプレイするのと、本を読むのは全然違ってくる。ゲームをプレイしているときは楽しいと感じられないといけないけど、本を読むときはそこまでは求めていない。もちろん、楽しい読書であればそれに越したことはない。ただし、それが再優先事項ではない。楽しいの質も色々ある。内容自体は楽しいものを意図して書かれていなかったとしても、新たな情報が手に入る、高揚感のようなもので楽しいと解釈できるようなことも多い。そういう解釈を含めると、最初は読み終わったあとの結果を重視しているのだけど、読んでいると楽しいと感じるようになることは多い。そういう感覚の中毒にならないように気をつけたい。

 現在所有しているアイテムから2023年に読みたい本、プレイしたいゲームを大雑把に見繕った。本がおよそ150冊、ゲームが50本となった。本は文庫の小説から1000ページを超えるプログラミングの大著まで様々だ。ゲームは大体PS4のばかりになった。

 150冊というのは熱心な読書家なら不可能な量ではない。2〜3日に1冊読めれば達成できる計算になる。文庫の小説だけならできそうだ。しかし、1000ページ超の、気軽に読めるとは言えないような本まで含まれると、それだけで数週間〜数ヶ月はみておかないと厳しい。つまり、これは無茶な計画だということだ。少し下方修正しておこう。見繕った読みたい本のリストは、読破するのではなく、全編を読むべきか、切り上げてしまうべきかを判断できる程度までに読むところまでとしておく。これなら2〜3日あれば判断できる。本当は全部読みたいのだけど、無謀な計画は立てない。読む必要がないと判断できたら、ひとまず押し入れに入ってもらうことにする。

 書いてて思い直した。見繕ったリストは、どうも優先度が高い本ばかりのようだ。読まないといけないという本ばかりが選ばれているので、2〜3日かけなくても現時点で読むべきだという判断ができている。小説も同じだ。なので、数を減らさないといけない。半分くらいにしないと厳しい。それだと5日に1冊になるが、まだ厳しいかも知れない。小説のリストと解説書のリストに分けたほうがいいだろう。1冊当たりに必要な時間がかなり違ってくるので、同列に扱わないほうが分かりやすい。

 修正した。解説書が71冊で、小説が58冊になった。解説書はおよそ5日に1冊、小説はおよそ6日に1冊のペースになる。小説の方は割と余裕を持っていけそうだ。解説書はどうだろう。内容の濃さにも文量にもかなりばらつきがある。1000ページ超のを5日で読むのはほぼ不可能だろう。新書の200ページほどのものなら2日あればいけそうだ。あまり新書や文庫のはピックアップしていないので、余りを割り当てるとしても全然足りない。まだ下方修正が必要そうだ。絶対に読破したい本と、手を付けるところまでにとどめておく本の2段階にしてみよう。

 修正した。さっきの解説書の中から、2023年中に読み終える本を12冊だけ選択した。これなら十分達成可能に思える。1ヶ月に1冊のペースになるが、1ヶ月もかからなそうなのがほとんどで、1ヶ月で終われるかどうかというのが3冊ほどといった感じになった。とりあえずはこれでいってみよう。

 ゲームの方に目を向けてみる。50本を見繕った。ほとんどPS4のものだ。1本あたり7.3日の配分になる。1日中やってていいなら可能だろうけど、そんなことはできないし、たぶん苦痛になってくるだろう。そうなると、さっき提案したような、一度そこそこ手を付けてから、最後までやるべきかどうか判断するという方法を取らざるを得ない。ゲームの場合は本よりかは判断するのは簡単だ。本の場合は面白くないからやめるという判断は少し危険が伴う。最初だけで面白く感じられるかどうかがわからないし、必ずしも楽しみのためにやっているわけではない。ゲームの場合は楽しめるかどうか感じたままに判断しても、そんなに危険はない。後半になってじわじわと面白くなってくるというゲームもあるだろうが、最初の方でつまらないと感じたものを、そこまでやり込むことはできない。しかし、自分のゲームに対する評価は結構甘めだし、そんなに面白いと感じなくてもなんとなくプレイできてしまう性格なので、思い切って途中でやめる強気な判断ができるかどうかはちょっと不安だ。

 最初のリストよりはだいぶマシになった。それでも、計画通りに進めるのはやはり難しいだろう。読書やゲームにすべての時間を使えるわけではなく、かなり限られている。ちょくちょく計画を見直してリストを更新していかないといけない。できれば毎週くらいやったほうがいい。いっそ毎日やってもいいくらいだ。

 改めてこうやって来年の読書ゲームの計画を立ててみたあとに今年を振り返ってみると、なんとも無計画だったということが露わになった。今年新たに増えたアイテム数は159だ。そのうち30くらいはマンガだと思うから、130くらいだろう。コンプリートできたのは、マンガを除くと40くらいだ。約70%が未消化で、大体全体のアイテム数の未消化率と同じくらいになっている。これではいつまでたっても進歩しないわけだ。来年はアイテムを一切増やさない、くらいの決意がないと、同じことを繰り返しそうに思える。しかし、幸か不幸か、来年も出版が予定されている本で読みたいのがちょくちょく目についている。それらを入手しないという選択肢はない。なんとか増殖し続けるのに歯止めをかけたい。購入するのは新しい本だけという制限を課したらどうだろう。今年入手したアイテムの中で、今年に発売されたものは20くらいだ。雑誌のようなものも含まれているので、本はもうちょっと少ない。この程度なら増えても許容できそうに思える。でも難しいだろうなという気がする。

 必要なものを買わないでおくのと、未消化のアイテムが増え続けるのとではどちらが精神衛生上良くないのだろう。どっちもどっちに思える。表面上の消化率の問題よりも、必要だと判断してそれをちゃんと活用できたかということのほうが大事だ。いつか必要なときが来そうだから、という理由ならば入手しないほうがいい。金銭的な面でも無駄だし、脳にその本を所有していることを記憶させるスペースを浪費させてしまう。そもそも、本を読むこと自体が目的なわけではない。書いてあることを理解して、プログラミングの糧にすることが目的だ。本棚に本を並べるだけでプログラミングが上達することなど決してない。どこまで本に頼ればいいのだろう。もう、十分なだけの本を所有しているように思える。

 このままずるずると消化できたとかできなかったとか続けるくらいなら、いっそのこと、管理をやめてしまって、1年間くらい本を読まずにひたすらプログラミングだけをし続けるという荒業に出てはどうだろうか。プライベートなプログラミングではゲームプログラミングをやっているのだけど、どう考えてもこれまで作ったゲームの数も質も不足している。それは、必要な基礎知識や経験が不足しているからと言うよりも、ゲームを作ることそのものに取り組んでいる時間が少ないからのように思える。結局の所、ゲームを作れるようになるにはゲームを作るしかない。その時間を削ってまであの本を読んだとか読んでないとかに振り回されたり、精神をかき乱されて集中できなくなってしまうようでは、逆効果だ。そうはいっても、1年間何も読まずにいられるほど強い意志があるわけでもない。まだまだ修行が足りない。

一昨日、アマゾンで本を買った。本当に欲しかったのはUNIX Network Programmingの第3版だった。その他には、Introduction to Algorithm 第4版、Modern Operating System、Computer Networkなどが続く。大体欲しいのは英語の本ばかりだ。今は円安が続いているため、洋書は和訳書と比較して軒並み高くなっている。 原著とその和訳書が並んでいると、どうしても価格を比較してしまって、和訳書の方を買ってしまうことが多い。本当は原著のほうが欲しいことが大半だ。価格だけが問題ではない。洋書の新品も中古もマーケットプレイスでの海外の出品者からしか買えないことが多い。その場合、当然、手元に届くまで日数がかかる。それは仕方がない。それだけではなく、本当に届くのかと不安な気持ちで待たなければならないのが厄介だ。安心して変えるなら迷わず買っているというものがいくつもある。今回も、そういう理由で購入を見送った。

 必要としている本にかかる費用をケチるのは良くない。高いからと言って読まずにいたら、より多くの損失を出す可能性がある。費用をけちらないとしても、必要のない本を買うのも良くない。本棚のスペースと脳の記憶スペースも浪費する。脳の記憶スペースの浪費してくと、その本を早く読まないといけないと駆り立てられるような心理状態に追いやられる。スペースには限界がある。いつまでも放置状態のままスペースを所有していることはできない。あまりに長い期間放置しておくと、そのうち気にならなくなってくる。そうするとまた新しい本を受け入れるだけの余裕が出てくる。そして、またスペースを浪費して、とループに入る。もうこんなことをずっと繰り返してきているように思う。駆り立てられているのが通常の状態なのか、そうではないのかわからなくなっている。

 数年前に初めて電子書籍のサブスクリプションに加入した。必要のない本を購入しないようになる効果は絶大だった。ちょっとした分野の解説書は大体揃っている。例えば、Python入門とかDocker入門みたいな本はたくさんある。そのため、大量に出回っているそういった類の本を購入しようという気持ちは完全になくなった。その分本を買う量が減ったというのではなく、サブスクリプションでは提供されないような本に目が行くようになった。どんなのかと言うと、最初に上げたような重厚な本がそうだ。料金として支払っている分だけ回収しようという気持ちは不思議と湧かない。料金が安いせいもあるだろう。良いことなのか悪いことなのかどうかというと、良いほうだろう。必要ならいつでも読めるという安心感を与えてくれるだけでも料金分の価値はある。必要のない本を買って、無駄に駆り立てられるような状況になる機会はぐんと減った。

 ここ数年の間で、本とゲームソフトの買い物の仕方が随分変わった。以前は、大型の中古本屋によく足を伸ばして物色しに行ったものだ。今ではせいぜい月に1回、もしかしたら半年に1回とかそのくらいしか行かなくなってしまった。お店に入ってなんか気になるものがないかと物色すると、かならずちょっと気になる程度のものが目に入ってくる。そうなると、今買い逃したら二度と手に取ることはなくなると駆り立てられて、それまでは全く欲しいなどと思ってもいなかったものを買ってしまう。そうやって手に入れたものは、大体は本当に必要なものではなかったと後で気づく。そんなことをしばらく繰り返していた。全部が全部不要なものというわけではない。中には本当に自分にとって価値があって、買えて良かった、偶然出会えてよかったというのもいくつかある。でも、残念ながら多くはそうではないようだ。いくつかの中から一部を取得するための必要経費とも言えなくもないが、あまり回収効率は良くない。

 ゲームソフトもよく安くなった中古のソフトを買い漁っていたのだけど、もうそれも全然やらなくなった。それも、メインのゲームプレイ環境の中心を、PS4のダウンロード販売に完全に移行してしまったからだ。ダウンロード販売の場所であるPS Storeでは、常に何かのセールをやっていて、かなり安く買える。大体中古ソフトにつけられている価格と同じくらいになっている。セール中に買わないといけないと駆り立てられるのは、中古ショップを徘徊していたときとあまり変わらないかも知れない。実際、かなりの量のソフトを購入して未プレイのままだったりする。そう考えるとあまり買い物のスタイルは変わってないのかも知れない。本当にプレイしたいゲームを買うのではなく、セール価格を見て、今買わないともう買わないかも知れないと、自分で選択していると言うよりは買わされている感じがしないでもない。しかし、限定的にはなってきた。以前は中古ショップのラインナップを一通り舐め回していたので、所持している古いハードのソフトまで手を伸ばしていた。ショップに行かなくなったので、もう古いハードのソフトが増えることはあまりなくなった。PS4の中だけで完結している。

 所持している本、ゲームソフト、音楽ソフトはブクログで管理している。今の状況は、全アイテム数が2241ある。そのうち未消化のものは大体1600だ。およそ70%が消化できていない。ゲームはもっと顕著で562本中493本が消化できていない。およそ87%が未消化となっている。少しは手を付けたものは、予想ではは50%くらいだと思う。それにしたって半分は全く手を付けていないということになる。これは、買うだけ買って開封すらしていないのと同じ状態だ。音楽ソフト、大体はCDのことなのだけど、これはあまり買わなくなった。買ったとしても少なくとも1回は全部聴いている。そんなに悪い状況ではない。マンガもあまり買わなくなった。そして、買ったとしてもやはりちゃんと1回は読んでいる。問題なのは本とゲームソフトのようだ。

 来年は、本とゲームを消化することを頑張りたい。ゲームをプレイするのに頑張らないといけないというのはおかしなことに思える。でもそうしないと新しいゲームも買っても、また増えた、と思うだけで、ハッピーな気分になれない。しかし、1年で500本消化するのは不可能だろう。1年どころか生きている間に可能なかどうかも疑わしい。ここは思い切った決断が必要だ。処分しようという気にはならないけど、一度、最初だけやってみて、直感で面白いか、面白くなる可能性があるかどうかを判断してしまう。本当はちゃんとプレイしないと面白いかどうかはわからないものだけど、500本に対してそれを行うのは不可能だ。割り切るしかない。不幸にも合格ラインに到達しなかったものは、押し入れで眠ってもらうことにする。これでまずは100本くらいにまで絞ることを考えよう。本も同じように500冊くらいまで絞ろう。本の場合はゲームソフトほどには手放すことに抵抗はない。いくらかは手放すことも必要だろう。

 今年も残り2日となった。大掃除ということで、来年読むべき本とゲームを整理して、気持ちよく新年を迎えるようにしたい。

 停滞気味だ。ブログの目標に1日1本をを掲げた。これを書いている時点で、今日を含めてあと12本足りない。一昨日から他のことをほっぽりだしてブログだけに集中したが、4本しか書けなかった。1日1本、1ヶ月で31本をきっちりこなさないといけないわけではない。あくまで目安であって、数本不足しても特にサボっていたと責められることはない。10本不足するとちょっと多い。なぜこんな不足してしまったかと言うと、12月16日から26日の間に、集中して読書に時間を割り当てたためだ。その間がすっぽり抜けてしまった。それよりも前にも、1日か2日は空いたりはしていた。一昨日から2日で4本で、2日分回収した。それで現時点でぴったり10日分不足となった。

 10日分回収するというのはなかなかの大仕事だ。また、こっちに時間を使えば、別の日課の方にも影響が出る。そうすると、今度はそっちを回収しようとしてまたこちらに影響が出ると、行ったり来たりになる。並行して進めないといけない。並行処理は苦手だ。並行処理とまで行かなくても良い。1日の終わりにアイドル時間を使って、ちょいちょいと処理してしまえばいい。アイドル時間は確実に確保できるとは限らない。スケジュールしておくと良い。この時間に処理を開始すると決めておく。余裕を持って1時間くらいみておこう。23時から24時の間に、1日の振り返りとして投稿する。ブログといってもポエムだと前置きしているので、ポエミーになっても恥ずかしくない。それならば、思いついたことをサクサク書いていけるだろう。とにかく、あまりにビジーになっていないでもない限り、その時間にきっちり処理を走らせるようにすることだ。これは来年からの計画だ。

 計画通りにいかなかったときのことを考えよう。今のように10本も溜まってしまった場合をどうするかだ。単純な方法は、他のことに割り振っていた時間を削って、遅延している部分に割り当てるという方法だ。これは安直だ。何も考えずに他の時間を削れば、当然、そちらの方が止まってしまう。止まっても支障のない部分を削っておけば良いというのも難しい。止まってもいいものは、最初からやる必要もないことではないか。はじめから計画に入れる必要がない。計画を見直すべきだ。仮に計画に無駄なものが含まれていなかったとしよう。その場合はどこにも削ってしまっても良い処理がない。遅延は許されるかも知れない。その遅延はまたどこかで回収されなければならない。一つが遅延すれば、それを回収するためにまた別のところを遅延させなければならない。こうして連鎖して計画全体が遅延してしまう。

 もう一つ安直な方法について考えてみよう。それは、遅延させるのではなく、限られた時間内で不足した分を回収できるように、処理の負荷を下げるように、クオリティを落としてしまうことだ。ブログの場合、取ってつけたような、お茶を濁したような投稿をでっちあげることだ。こうして形だけ取り繕って、割り当てられた時間で、本来かかるはずだった時間を短縮して多くのタスクを処理していく。最初の計画のところまで到達したら、通常のクオリティに戻して、計画全体を通常運転に戻す。この方法はブログのような、クオリティを上げ下げすることで、必要となる処理時間も柔軟に制御できるような処理でのみ可能ととなる。他にそのようなことが可能な処理は、コーディングもそうだろう。クオリティを下げれば、悪い設計で良いのならば、必要となる時間を短縮することが可能だ。もちろん、コードのクオリティを下げるのは許容されるものではない。今、自分が書いているブログのように、クオリティを下げてもおそらく誰にも迷惑がかからず、何の影響も与えないようなものなら、少なくともコードのクオリティを下げるよりは許容できるかのように思える。このブログのクオリティを下げて処理時間を短縮して、数を稼ぐというのは、一見妥当な方法にも思える。しかし、実はそうではない。2つの点で考えてみることがある。

 まず、クオリティを下げても何の問題も発生しないようなブログは、もともとそれ自体やる価値のあるものなのだろうかという疑問だ。このブログは何かを求めて始めたわけではない。クオリティなど追求していなかったし、今も追求していない。それなのに、1日1本というノルマを課したせいで、毎日の計画の一部に組み込まれようとしている。大体、夜11時から12時の間に書こうと思っている。この1時間というのはかなり貴重に思える。もしやっていなければ、かわいい猫と遊んだり、気がかりなドラクエを進める時間が確保できる。この貴重な時間を削ってやっているのだ、いかに何の見返りも求めないポエムであったとしても、意識的にクオリティを下げても良いのだろうか。あまりにクオリティを求めすぎるのも問題だ。6時間かけてやるようなら、そんなものはやらないほうがいい。限度がある。1時間でやると決めたら、それだけでやるのが良い。その時間内でできるだけのことをやるという程度にとどめておけば良い。素早く文章にまとめ上げられるというスキルはなかなか貴重だ。だが、クオリティを落としてでっち上げるというスキルは重要じゃない。もし、ノルマを課したことによる義務感からでっちあげようとしているなら、そのブログには価値がないように思う。

 もう一つはより深刻だ。クオリティを下げて時間を短縮するというスキルが身についてしまうことが、逆に悪影響を及ぼす可能性がある。別のところの重要な処理、例えばコーディングでもブログと同じようなノリで、時間を短縮するためにゴミみたいなコードを書いて、とりあえず動くだけの取り繕ったようなコードを生産してしまうことに罪悪感を感じなくなってしまうことはないだろうか。否定できない。コーディングにかける時間も、ブログと同様に限度があるが、例えば、Hello Worldに10時間かけたらやりすぎだ。もし、目的がプログラムを動作することを確認するためだけというのなら、たぶんやりすぎだ。一方、目的がHello Worldを真に理解することであるなら、それでも全然足りない。その場合は、最初から目標をそこに設定しておく必要がある。時間がかかるからといって、分かったようになったつもりになってコードを書き続けるのは危険なので、十分な時間を確保する必要がある。もし、時間内で終わらせるためにクオリティを下げる悪習があると、時間をかけようとする気すらなくなってしまうことだろう。

 この2点の問題を考えると、数を稼ぐためにクオリティを下げるという選択肢は考えられない。 今月のノルマ達成は諦めるのが良さそうだ。反省点としては、計画の不完全さだ。ブログに対する優先度がかなり低かったのもある。それよりも、抜けてしまった日をどこで回収するべきかという、保険をかけていなかった。予備の時間を確保していなかった。また、12月16日から10日間、道を逸れて読書にハマってしまうという予想外の出来事があった。そのときは、後で回収すればいいかと思っていた。まさかポエムを書くのがこんなに大変な作業だとは思ってなくて、軽くみていた。厳密に計画通りに進める必要はないのだが、こまめに計画を見直して、重要なのが何かを確認していったほうがいいだろう。少なくとも1週間、できれば毎日がいい。

 Linuxでのゲームプログラミングについて書いてみよう。このテーマは自分にとって重要なので、定期的に考えてみるのが良さそうだ。

 ゲームプログラミングの前に、ゲームプレイについて考えてみることにする。一口にゲームといっても、その形態や規模や目的やによって様々だ。コンピューターを使わないゲームももちろんある。しかし、もっぱら関心があるのはコンピューターを使ってプログラミングで作ることができるコンピューターゲームなので、ここで単にゲームといったら、コンピューターゲームのことを指しているものとする。

 ゲームの需要や市場は昔に比べてはるかに拡大してきて、同時に多様化している。ゲームプレイヤーの数は増加しているように思える。一方、ゲーム開発環境が整備されてきたために開発の敷居がぐんと下がって、リリースされるゲームの数も増えてきている。どちらかというと現在は供給過多で、プレイヤーを取り合うような状況にあるように思う。その要因は何なのかということには触れないでおこう。ともかく、ゲームをプレイする人も作る人も増えてきていて、今も傾向は続いているという事実だけを受け止めておこう。このことは肯定的に受け止めることができる。昔はもっとよかったなどとは思わない。テクノロジーの発展によって、昔は技術的に実現不可能だったことが可能となったり、製作者の多様化によって思いもしないような発想のゲームが登場したり、プレイヤーの多様化によってその要求を満たすために、多様なゲームが作られたりする。一部のマニアだけに与えられた特権のような楽しみではなく、多くの人がゲームを楽しむことをできるようになるのは、良いことだ。

 ちょっとポジティブ思考すぎるかもしれない。それに、自分は何も貢献していないのに良いとか悪いとか語るのもおかしなことだ。しかし、ゲームをプレイする人が増えて、社会的にも受け入れられるようになったりする状況を好ましく思っているというのは本心だ。この場合は社会的という言葉に悪い含みは入れていない。社会的に受け入れられているという具体的な状況について、何をイメージしているかと言うと、例えばeスポーツを始めとする舞台でプロゲーマーが活躍している状況だ。なぜこれが社会的なのかというと、生産性があるからだ。生産性とは富を生み出すということだ。社会では生産性のないものよりもあるもの残そうという力が働いている。プロゲーマーのプレイを中心に、名誉と報酬を巡って生み出されるストーリーや演出は、ゲームをやる人はもちろんやらない人にも魅力的であって、惹きつけるものがある。これはアスリートや棋士が社会的に果たす役割と何の違いもない。それらのような伝統的な勝負師の世界の見世物のように完全に成功しているかどうかまでは知らない。少なくともファミコンしかなかった時代に、将来プロゲーマーになりたいと言う狂気じみた少年少女が拒絶されたほどには、現代で将来プロゲーマーになりたいと言っても狂気だとまではみなされないではないだろうか。

 eスポーツはゲームの中でも特殊な環境だと言える。もっと多くの人が楽しんでいるゲームは、プレイすることによって直接的な報酬を得たり名誉に繋がるものではないものが多い。極端な例をあげると、マインスイーパーでハイスコアを競っている人は、おそらく何も見返りは求めていないだろう。オンラインで世界ランキングがあったりすれば、もしかしたら話は違ってくるかも知れないが、あまり一般的ではない。大体は、デスクワークに飽きて眠くなったときに、気晴らしにプレイしたりして、ついついやり込んでしまうということが多い。戦略的にどのようにやれば上達するかということについて考えを巡らすかも知れない。それでも、そのことで報酬を得ようと考える人は、いたとしてもごくわずかだと思う。大体、それなりに長いゲームの歴史の中で、世に送り出されてきたゲームはこのようなものから発展してきた。このようなゲームの特徴は、失敗しても失うものが少なく、成功したときにはそれなりの達成感が得られる、という特徴がある。単純なゲームの場合、失うものというのは、大体そのプレイに費やした時間と作業のみになる。このリスクが0だと、成功したときの達成感というのが0に近くなってしまうので、望ましくない。ゲームをプレイするのは、クリアしたときの達成感だけがゲームの目的ではない。ただゲームの世界の中に入っていくだけで没頭できるというのがある。マインスイーパーの場合は、地雷原を慎重に探索するという、現実ではなかなか味わえない緊張感のある世界を味わうことができる。目の前の作業から逃れて現実逃避したい場合にマインスイーパーを起動してしまうのはそういう理由もある。

 ゲームの世界にどれだけ入り込んでいけるかを表す感覚は、没入感などという。ゲームの面白さを決める要因としては重要だ。古典的にはゲームのグラフィックスやサウンドがその大きな役割を担ってきて、よりリアリスティックに、あるいは表現豊かになろうとしてきたのは、それによって没入感を高めようという狙いが見られる。ゲームのハードウェアの進化は、より高い表現力を求める力に引率されてきた。現在のゲームはマインスイーパーのようなゲームとはかけ離れているように見えるのだが、没入感という点においては、根っこは同じところにあるとみなしてもいいだろう。その時代において、ゲームはハードウェアとソフトウェア技術の限界で世界を構築して、プレイヤーを引き込もうとする。他のゲームと差別化するためには、もっとこうこうしたい、という要望がうまれ、すぐにハードウェアの限界に達してしまう。そして、新しいハードウェアが生まれ、ハードウェアによって制限されていたソフトウェア技術が解放されて、新しい表現が可能となる。この繰り返しによって発展してきたわけだけど、どうやらこの進化モデルは大成功を収めているようだ。最近のゲームをプレイする人で、現在のゲームの表現力に驚かされたことのない人などいないだろう。しかも、この進化はまだとどまることを知らない。最先端のゲームの技術を研究開発しているリーダーたちは、おそらく、現実世界と区別がつかなくなるようなところまでを視野に入れているのではないだろうか。それには、ハードウェアとソフトウェアという技術的な進化だけで達成できるわけではない。いつかは、現実世界と区別できなくなるような表現が可能な技術が手に入ることは期待できる。そのとき、その世界に移り住むことができるかどうかはまた別問題で、現代社会ではまだ良しと見なされないだろう。先にゲームが社会的に受け入れられるようになってきたのを肯定的にとらえているという理由がそこにある。まだ、生産性のないゲームプレイに没入することまでを良しとする風潮ではないが、一部は良しとされるようになった。テクノロジーの進化と同様に、規範もゆるやかに進化していくのならば、いずれ受け入れられる時代が来るかも知れない。

 Linuxとプログラミングについて書くつもりが全然違う方向に行ってしまった。今から取ってつけたように書くのも、場を取り繕うだけになってしまうので、今回は書かないでおこう。またこのテーマは何度も再利用するだろうから、その時にとっておくことにして終わる。

 How Linux Worksという本の和訳版を読んだ。和訳されたタイトルは、スーパーユーザーなら知っておきたいLinuxの仕組み、というのだけど長いのでそうは呼ばない。色々と学んだことがあった。特にデバイスのようなカーネルに近い部分や、systemdによるサービス管理の方法などの領域に対するスキルポイント配分が完全に不足していたということを認識した。今後その不足分を補っていくように意識していかないといけない。別のところでは、ネットワークを扱っていて、そこは割と読みやすく感じたので、そこまでスキルポイントが不足していたことはなかったと認識した。積極的に割り振った記憶はない。日常的にネットワークの設定を行ったりするから、身近な話題であったというのが読みやすかった理由だろう。ネットワークの設定といっても、専門的なことではなく、インターネットに繋がらないと家族などに頼まれたとき様子を見にいったりする程度だ。それだけでも結構違ってくる。普段は自分のPCのLinuxでネットワークの設定をしたりもするので、それも影響していただろう。これも大したことしていない。ちゃんとインターネットに接続できるか、確認して調整したりするといった程度だ。その程度でもちゃんと話しについていけた。合格基準が低いように思われるかも知れないが、デバイスの章なんかは、全く意味不明だったので、それと比較してしまえば、遥かに合格だったとみなしている。

  デバイスがだめだったので、次やるべきことはデバイスについて強化するのが順当な学習プランだ。あとsystemdにもうちょっと親しんでおくというのも忘れてはいけない。その一方で、ネットワークについてもっと知りたいという欲が出てきた。これは良い傾向なのだけど、時間配分が難しい。デバイスをまず先にやるべきなのだが、ネットワーク程は関心がないというのが本音でもある。試しにやってみたらいいかもしれない。デバイスドライバのプログラミングが良い入口だろう。そもそもデバイスってなんなんだという疑問さえある。/devにあるデバイスファイルと、現実のデバイスとの繋がりが全くイメージできない。あとはカーネルだ。カーネルとデバイスは近いところにある。この2つについて学習する必要がある。全くやったことないのだけど、どういうわけか、カーネルやデバイスドライバのプログラミングの本を所有している。今、ちょうど必要性を感じたので、これを機に取り組んでみるのがベストタイミングだと思われる。ネットワークはどうするか。これも今やってみたいと思っているところなので、またベストなタイミングだと思われる。

 ネットワークプログラミングにはバイブルのような本が存在している。UNIX Network Programmingというタイトルの本がそうだ。初版を所有しているが、かなり内容が古いようで、第2版では大きく書き換えられて、原著は第3版まで出ている。しかし、残念なことにもう新品の入手が困難で、中古でもそれほど数が出回っているわけではないようだ。ただ、入手不可能と言うほどではない。これを期になんとしても入手しておきたいという欲が湧いている。

 書いている途中にAmazonを物色し始めた。やはり第3版の中古が割と安く出品されているので買ってしまおうと思ったのだが、他の出品と比べて異様に安いのと、レビューをみると不安が捨てきれなくて、断念することにした。信頼できる国内の出品もあるのだが、価格が1万円ほど高くなるので躊躇してしまう。その代わりにVolume 2の和訳版を中古で安く出品されているのを購入しておいた。今は円安ということもあって、どうしても洋書が高くなってしまう。高くなるだけならまだしも、事実上入手が難しいことすらある。もっとKindleで電子書籍化が進んでくれれば安心できる。UNIX Network Programmingのような、定番で重要な本はぜひ電子書籍化してほしいと願う。

 というわけで、目当てのものを入手しそこねた。今所持している初版でなんとか好奇心を満たそうかと思う。どの程度古くなってしまっているのかわからない。ネットで新しい情報と見比べながら読めば、なんとかなるだろう。そもそも、今はデバイスとsystemdをちゃんとやっておくべきだ。本格的にネットワークプログラミングを始める機会を失ったことは、ある意味好都合だ。自分で気の向くままに興味のあることばかりやっていたら、いつまでもバランスの悪い偏った不格好な装いになってしまう。定期的にちゃんと鏡を見て見た目を正す機会を設けることも必要だ。鏡と言っても、前に立つだけで姿を移してくれるような便利なものもないし、問いかけるだけで世界で一番美しいのは誰か答えてくれるような魔法の鏡もないし、テクマクマヤコンと謎の呪文を唱えるだけで変身できる秘密の鏡ものなどありはしない。今どんな見た目をしているのかは、何かの判断基準に沿って、比較してみることが良い方法だ。もし、その基準が歪曲されていたら、誤った判断をしてしまう。例えば、魔法の鏡に世界で一番美しいのは誰か答える鏡に問いかけるのは危険だ。そんなことをしてみても間違った感情しか生まれない。判断を鏡に委ねるのではなくて、できるだけありのままの姿かたちを移してもらうことだけを期待して、どこが不格好なのか、バランス良い見た目になるのはどこを修正すらばいいのか最終的な判断は自身が下すべきだ。そのような道具というのはあまりない。本はある分野に特化していて専門的であるのが普通だ。専門的なことを求める読者の要望に応えようとしていて、だからこそ価値がある。平均的なところにとどめておきたいという変わった要望に答えるような本はあまりない。

 この本に関して言うなら、タイトルが示す通り、Linuxの仕組みについての専門書と言える。もし、他のメジャーなプラットフォームである、Windows、Web、スマホなどについてもバランス良く身に付けたいと考えている読者にとっては、これはLinuxの専門的な内容であって、バランスを整えるための道具とはならないだろう。同じような本をそれぞれの分野にも見つけ出さないといけない。しかし、Linuxに限定して、その領域内でバランスをよく身に着けたいと考えているのなら、この本は専門的というよりも平均的にバランス良く解説した内容だと思える。どの章も平均的な水準で解説されていると自信を持って言うことはできないのだけど、そういう風にみなしておこう。そうしておくことで、もし、読んでみてどこかが難しすぎたり、逆に簡単すぎたりしたら、本の方に偏りがあるとみなすのではなく、それだけスキルポイントの振り分け方が偏っていたと解釈する。もし全部簡単すぎると感じたのなら、時間を無駄にしたと考えずに、十分に基礎を身に着けていると自信が得られたので有意義だったとでも思っておくのがいい。全部難しすぎると感じたら、スキルポイントよりもベースとなるレベルが不足しているので、経験値稼ぎが必要な兆候かもしれない。最も理想的なケースは、ある章は簡単だったけど、別の章は難しかったという感想をもつ場合だ。この場合は、難しかった章の分野にスキルポイントを振り分けるようにすることで、偏りを正すための道具となる。定期的にこういうもので見た目をチェックしておくことも悪くないという新しい視点が得られた。ちょっとばかし前向きで肯定的な考え方すぎるかも知れない。

 .NETをちょっとだけ触ってみた。きっかけは、Packtのライブラリを眺めていたら、新しい.NET 7の本がおすすめに表示されたことだ。.NET 6のころから、同じ本の前の版がおすすめに出てきていて、頭の片隅にその名前はちらついていた。それよりももっと前にから.NET Coreの名前は知っていて、クロスプラットフォームになってLinuxでも利用できるようになったことは前から知っていた。そうはいっても、基本はWindowsでVisual Studioを使って開発する環境だろうという先入観があるので、なかなか手を出そうという気にはなれなかった。今回も、本格的に取り組んでみようという気はまるでなくて、どんな感じか軽く味見してみるだけのつもりだった。.NET Coreに対する誤った先入観は、これまでの.NET Frameworkのサブセットであって、すべての機能を提供するものではなく、完全なものではないというものだった。そうではなくて、どうやら従来の.NET Frameworkに取って代わって置き換えてしまうロードマップが示されているようだ。そして、順調にその筋書き通りに進んできていて、もはや新規に.NET Frameworkをベースに開発を始めるような状況ではなくなってきている。とりあえず.NET FrameworkをmacOSやLinuxでも使えるようなオプション的な扱いではない。Windowsでも主流の開発プラットフォームとなっていくのだろう。もともと.NET Coreという名前で区別されていたけど、Coreの単語はなくなって、単に.NETだけに改名されたことからも、もう試験的な段階を終了して順次置き換えていく段階に来ていることが分かる。.NETが登場したのが大体2000年頃だっとすると、もうおよそ20年以上経過している。この時間はソフトウェア時間にするとかなり長寿だと言える。もっともWindowsやVisual Studioはもっと長寿ではあるが、それはソフトウェアというより製品として長寿であると捉えることができる。何にしても、この20年のという時間は十分に長く、ついに訪れた最も大きな転換期だと考えられる。

 ここまでで.NETがどうとか書いたけど、.NETの経験はほぼない。 経験もないのによくそんな偉そうに語れるなと、自分でも思わなくもない。なぜこうやって.NETを外観から眺めようとしているかと言うと、ただ大きな流れに身を任せたまま開発環境を乗り換えていくのは多少の危険が伴うからだ。逆に全く流れに乗らないというのもそれはそれで危険だ。少しは波に乗っていかないと、楽しくもないし、時代から取り残された古物になってしまう。やり過ぎはだめだ。大体、目に入ってくる、流布される情報は自然に発生したものではなく、何らかの意図が含まれている。大げさな広告には警戒する必要がある。何でもかんでも無警戒に新しいものに飛びついていったら、本当に自分がやりたいことは何なのかをすぐに見失ってしまう。たとえ広告に飛びついたとしても、もし、その対象が自分に合っていると判断できたのなら、それは悪いことではない。買い物をするとき、例えば新しいキーボードが欲しいとしたとき、店頭で買うにしろネットで買うにしろ、他の製品と比較したり、情報を仕入れたりして判断を下す。商品の情報には購入してもらおうという意図が含まれているし、店頭に並んでいるものも買ってもらおうと工夫して展示されているはずだ。それを全部否定する必要などまったくない。問題が発生するのは、判断を見誤らせるほどに過剰な広告が行われることだ。プログラミングに関連すると、昔だとJavaとオブジェクト指向は過剰だった。今ならPythonとAIやデータサイエンスがだろうか。これらの情報は、正しい判断力を失わせるだけの十分な誇大広告がなされているように思える。それでも、繰り返すと、判断力を失わずに冷静に接することができるのなら、全然悪いことではない。AIの技術やデータサイエンスがこれからのソフトウェアの領域で大きな位置を締めるようになっていく流れには逆らい難い。市場価値を高めるとか、自己ブランド化というくだらないものを無視しても、それらの技術を習得していることは、なかなかおもしろい経験になりそうだ。

 .NETに話を戻すと、そこまで過剰な広告は行われていない。どちらかというと控えめだと言っていい。これを使えばあなたはハッピーになれますとか、世界平和が訪れますみたいな怪しい文句は含まれていない。ちゃんと自己判断を下せるような情報だけを提供しているように見える。判断を開発者に委ねているように見える。今の時代に合ってはなかなか珍しいことにも思える。大量の新しい開発者を呼び込んで、一世を風靡するようなムーブメントを起こそうなどという意図はないだろう。警戒しておきたいのは、クロスプラットフォームになったことで、Windows以外のプラットフォームでの囲い込みを行おうとしているのではないか、ということだが、どうもそのような動きにも見えない。まったくないということはないだろう。誰にも使われないソフトウェアを開発したい企業などないだろう。しかし、Linuxのアプリケーション開発やWeb開発すべてを置き換えようなどという野心的な動きはないし、選択肢の一つして追加されただけに見える。むしろ、もっと積極的なサポートを期待する人も多いのではないだろうか。例えば、Windows.Formsに変わるクロスプラットフォームなデスクトップアプリケーションの開発環境などだ。もし実現してしまったらLinuxのデスクトップ環境に混乱をもたらすかも知れない。なので、あまり良いものではないかも知れない。それはちょっと保守的すぎるかも知れなが、そういう要因に加えて、企業によってもたらされる、言いすぎかも知れないが独占的な技術によってもたらされる変化は好まれないかもしれない。とにかく、一概に歓迎されたり排除されたり極端な反響をもたらすものではないようだ。あまり大きな反響がないのは、もはや、それほど革新的な技術というわけではないと言うのもあるのではないだろうか。.NETは言語を選ばない環境ではあるけど、中心になるはC#であって、それ以外の選択肢はオプション扱いだろう。C#が決して革新的な言語であるとは言えない。神の存在・不在を証明したり、世界平和をもたらしたりはしないだろう。そんな言語はこれまでも、おそらくこれからも存在しなかったが。

 肝心の開発環境を使ってみた感想はどうなのかというと、かなり良い感じだ。dotnetというコマンドラインインターフェイスを通して、プログラムのビルドや設定や管理を行うようになっている。コンパイラはこのdotetツールの裏側で仕事をする。もはやVisual Studioのような制約の多いソフトウェアに縛られることはなくなっている。いま主流となっている現代的なプログラミング環境のスタイルから大きな影響を受けた結果だと言える。Visual Studioは必須ではないが、もちろんサポートされているようだ。そして、その代替として、VSCodeに一極集中していく未来も見えるが、それは単にVSCodeが扱いやすく広く使われているから来る結果に過ぎないだろう。もし、VSCodeより扱いやすい開発ツールがあれば、自然とそれにシフトしていくことになる。

 今後、C#を中心にプログラミングをしたいとは全く思わない。しかし、.NETをツールボックスに入れておくことで、何かしら必要なときが来たとき引き出せるようにしておきたいとは思う。それに、なかなか楽しい。目眩のするような巨大なライブラリと言語仕様が組み合わさって絶妙なバランスで成り立っている。その中に飛び込んでみるのはなかなか新鮮な体験だ。

今日3本目の投稿。キーボードについて考えてみる。今、主に使用しているPCは2台ある。そのうち1つはUS配列で、もう一つは日本語配列のキーボードを使用している。この状況は良くない。ずっと日本語配列のキーボードを使ってきていた。そこそこ値が張る代物で、打ち心地も素晴らしいくてとても気に入っている。最近、といってももう1ヶ月以上経っているけど、新しいPCを購入した。そして、ひょんなことからUS配列のゲームミングキーボードが手に入ったので、それを利用している。打ち心地はそこそこだけど、無駄に光るのがなかなか良くて、しばらく使っていたらこれにも愛着が湧いてきた。そして、このUS配列のキーボードがメインとなった。このブログもそのPCから書いている。

 US配列にもだいぶ慣れてきた。最初はEnterや角括弧を何度も間違えていた。プログラミングでは多用するのでこのような基本的なタイプミスは思考が中断されて、効率が悪すぎる。さっさと買い換えればよかったのだけど、US配列のほうが良いところもある。@や引用符なんかの位置はUS配列のほうが良い。また、テキストエディタなどのキーバインドはUS配列が基本に考えられているので、そちらの方が自然に感じられる。そういう理由で、しばらく使ってみることにしていた。もうほとんど日本語配列のを使っていたときと同じような感じで使えるようになってきた。

しかし、今度は逆の問題が発生する。旧PCで作業をするとき、びっくりするくらいうち間違える。丸括弧や引用符などは、間違えずに打てることの方が少ないくらいだ。この混在した環境はとても良くない。日本語配列かUS配列かという問題が些細に思える。プログラミングでもそうだが、例えば、インデントは4にするか2のどちらが優れているかよりも、 どちらかに統一して、少なくとも同じプロジェクトの範囲では、一貫してそのスタイルを使い続けることのほうが遥かに重要だ。キーボードもそうだ。打ち心地がいいとかよりもずっと重大だ。まず、どちらかに統一できることが大前提になる。どちらかに揃えることできることが可能であって初めてどちらの配列のほうが良いかについて考えを巡らすことができる。

 今、所有しているキーボードの殆どが日本語配列になっている。ラズパイ用のワイヤレスキーボードが2つある。それにラズパイ400も日本語配列で、これは交換不可能だ。あとはあまり使用しない古いノートPCもやはり日本語配列だ。また、US配列のHHKを1つ所有しているけど、PS/2端子なので変換器をかまさないと使えないので使用していない。もしUS配列に統一するとなると、少なくとも3台買わないといけない。そして、今ある3台が不要品になってしまう。どうがんばってもラズパイ400とノートPCはUS配列にできない。こういう状況を鑑みると、日本語配列で統一するのが素直な選択肢のようだ。それならば1台を買い足すだけですむ。

 本当にそれでいいのかちょっと迷いがある。まず、見た目の問題で、どうみてもUS配列のほうがシンプルだ。日本語配列の変換や無変換やカタカナがない分、無駄がなくてスッキリしている。プログラミングで多用するスペースキーがとても広く取られているので、安心感がある。変換と無変換はまだ活用できる。しかし、カタカナキーは無理がある。PCを使い始めてから一度も活用したことがない。CapsLockが重要な位置に置かれているの同じくらい不自然なキーだ。使いみちがないので無視すればいいという考え方もできる。しかし、やはり美的感覚から受け付けがたい。各キーについているひらがなの刻印も無意味な感じがする。かな入力は使ったことないし、将来も使う可能性は極めて低い。何度か言っているけど、@のような使用頻度の低いキーがホームポジションに近い位置にあるのも微妙だ。そして、プログラミングで多用する二重引用符が変わりに@が適正だと思われる位置に押しやられている。美的感覚からも、機能性の面からも、US配列のほうがずっと優れていると思われる。日本語配列を選択する理由となるのは、ただ入手しやすいことと、今ストックがたくさんあることのみで、キーボード本体の設計が理由となるものではない。

 なぜ今こんなにキーボードについて悩まないといけないかと言うと、おそらく、今回下した判断によって、今後数年、下手したら数十年の間ずっとそれを維持し続けることになるだろうからだ。先に書いたように、キーボードそのもののどちらが優れているかよりも、統一して使い続けることのほうがずっと重要だ。統一されているという前提があって初めて、どちらがいいかを選ぶことができる。統一されていればどちらでもいいというわけではない。プログラミングと同様に、悪いスタイルを強制されるのは苦痛なものだ。はじめから苦痛なキーボードを選択する理由はない。

 別に日本語配列が苦痛なだと思っているわけではない。今までもそんなふうに思ったことはなかった。しかし、ここしばらくUS配列を使ってきて、少し考えが変わってきた。1ヶ月程度ではまだ試用段階だったと考えても良い。決断を下せるほど使い込んだとは言い切れないところがある。それを踏まえて、現時点では、先に述べたように、見た目と機能の両方に置いてUS配列のほうが優れていると思っている。ここで、すべてのPCに対して統一するために、今所持しているキーボードに引退してもらって、新たにすべてに対してUS配列を用意するほどまでの優位性があるかどうかを判断しないといけない。

 どうも話がループしている気がする。先に進むことを考えよう。

 今使用しているUS配列のゲーミングキーボードはなかなか気に入っている。これを手放すのはちょっと惜しい。そして、旧PCに接続してある、ちょっと効果な日本語配列のキーボードも、打ち心地の良さから気に入っている。どちらか一方を選べと言われるとちょっと難しい問題だ。しかし、どうにかしてどちらかを除去しないといけない。もし、ひょんなことから新しくUS配列のキーボードを入手していなかったら、こんなに悩むことはなかっただろう。一旦、元の平和な状態に戻してみてはどうだろう。しばらくUS配列ばかりでやってきていたので、日本語配列でプログラミングする感覚を忘れかけている。旧PCで作業するとにタイプミスを連発する原因はそれしかない。一旦戻して、それでもまだやっぱりUS配列のほうが良かったと思えるようなら、US配列で統一する。別に日本語配列でも問題なければ日本語配列で統一するということにしよう。

 10日ぶりにブログを書いている。出だしはなかなか良かったのだけど、やはり続けるのは大変だ。それでもやっていこと思う。厳密でなくてもいいので、できるだけ1日1つを維持したい。今月はもう無理だけど、今日から連投することで数だけ稼いで帳尻を合わせたい。今日時点で12本欠落しているので、今月はあと5日として、30、31日はおそらく使えないので、残り3日で、およそ17本投稿しないといけない。1日に5、6本になる。可能だろうか。かなり大変な仕事に思える。何しろ文字数が多い。今4Kのモニターで表示していて、大体これで、編集画面で上から下まで埋めることを目安としている。どうやら3000文字くらいになるようだ。それが6本なので18000文字必要になる。コードにしたら、1行40文字くらいとして、450行くらい。コードと文章ではまったく質が異なるので、あまり意味はないが、雰囲気はそんな感じになる。不可能ではないような量だ。ただ、こればっかりやっているわけにもいかない。1本30分で、3時間程度で終わらせられたらいいなと思う。ちょっと厳しいか。

 今困っているのは、ネタがないということだ。そんなはずはないのだけど、思いついたやつを下書きにキープしていって、まだ10本程度しかない。もういっそなんでもいい。コーヒーの話とか、ダイエットの話とか、禁煙の話でもいいんではないだろうか。とにかく数を稼ぎたい。

 数を稼ぐというと、プログラムをコードの行数で見積もって水増ししているようで、悪い習慣なのだろうか。そんなことはないだろう。さっきも書いたけど、文章とコードは全く質が異なる。無駄に長いコードは悪質だ。短すぎてもいけないが、十分に読みやすく保守しやすいコードである以上の冗長さは取り除くべきだ。文章の場合そうとも言えない。すべての文章は何かしら文学的な性質を持っている。情報が単に表示されているだけでは良い文章ではない。読み手に伝達したいという意図があるから存在しているのであって、そのためには、文章を工夫して、強調したり、繰り返したりしないといけないことがある。物書きになりたいとは全く思っていないし、このブログでは完成された文章を書こうという目標は立てていない。

 このブログで何をやろうとしているのかというと、前にも書いた気がするけど、何を考えているのか自分でも分からない、思考を書き出すためだ。文章にして初めて自分の頭の中が見えてくるような気がする。大体、こうやって書いていることというのは、常にそういう風に考えているわけではなくて、文章を書きながら思いついたことを書いていっている。文章にすると陳腐にみえるようなことは排除していっている傾向がある。それなりに見栄えのする文章に作り変えている。それって偽物の思考じゃないのかと言うと、そんなことはないように思える。普段、何もしていないときはおそらく何も考えていない。何か活動をしているときには何かを考えているのだろうか。それも怪しい。プログラミングをしているときは多分プログラミングの範囲内でしか考えられていない。そこに落とし穴があるように思う。プログラミングは、それ自体が目的になることもあるが、本来は現実の問題を解決するためのものだ。目の前のコードに集中したり、プログラム自体に集中したりするあまり、視野が狭くなっている可能性がある。一度、距離を置いてやるべきことを見直す必要がある。頭の中だけで整理をするのは上級者向けだ。こうやって文章にしたり、なんか別のツール、マインドマップとか有名だけど、そんなんでも、何でもいいからちゃんとした形にすると良い。

 今さっきちらっと書いた、ここに書いているのは偽物の思考ではないかという疑念をもう一度考えてみる。確かに、文章にする前の段階では今ここに書いているようなことを考えたことがあるという自覚はない。ただ、思いつくままにキーボードを叩きながら出てくる文章を吐き出しているだけだ。現在進行形で文章が作られている。この文章はどこから出てきているのだろう。かろうじて言えるのは、他人によって強制的に書かされているものではないということくらいだ。本当だろうか。どこにも公開するのでもない、秘密のテキストファイルとして書いているのならともかく、ここは一応パブリックな空間で、理由はどうあれ、誰かに読まれることを想定しているはずだ。すると、読み手がどのように解釈するかということを含めて文章が生成されているところもある。とても人に言えないようなことを書いたりはしない。

 このブログの場合、何かを伝えたいという意思はほとんど含まれていない。単に人の目につくところに文章を置くことで、モチベーションを高めようと利用しているだけに過ぎない。それは過小評価しすぎかもしれない。おそらく人の目につくところに置くことで、多少はマシな文章を組み立てようという力が働くところも少なからずある。むしろ願ったりだ。文章の構成は人の読める程度にうまくできている方がいい。これは表現の違い、表面的なところでの話となる。思考そのものの出力である、文章の中身がどこから来るのかをまだ書いている本人が理解していない。だんだん、自分で書いている文章が偽物の思考なのではない、ということに自信がもてなくなってくる。誰が読んでも無難なように、本心を偽っているのではないかという気がしてくる。それは現実のコミュニケーションで人間が当たり前にやることだ。社会性を持った生物は、属するコミュニティで培った習慣に従って、さしあたりのない範囲で活動するはずだ。いきなり誰でも出会い頭にプログラミングの話をしたりはしない。こんにちはとか言うはずだ。そのような、常識とでも言って良い範囲に縛られたからと言って必ずしも偽物の思考だと結論づけることはできない。

 何か思いもよらない方向に話が流れてきた。書き始める前は全くこのような内容にしようとは思っていなかった。なぜこういう方向に話が進んだのか、なかなか興味深い。思考はどこからくるのか、など、典型的な哲学の領域ではないか。今までそんなことを考えたことはないのだが、不思議だ。こうやって文章にしていくことで、全く自覚していなかった、新たな発見があることは少し前から気づいていた。今回の場合で言うと、思考とは何かだ。本気でこのことを追求しようとはあまり思っていない。でも、せっかく気づいたことなので、気には止めておこうと思う。予め用意された入口、今回の場合は哲学になるのだろうけど、そこの戸を正面から叩くのではなく、こうやって自分で掘り下げて発掘するという行為は面白いかも知れない。

 何も期待せずに書き始めた投稿だったが、新しい、ちょっと高等な目的ができた。それは、文章化することによって、今まで気づかなかったことを採掘するということだ。ただ、これは最初から求めてはいけないようだ。書き続けていくことで自然と見つかるもので、そのときを見逃さずに捕まえられればそれでいい。

 少し前に、コードコンプリート 第2版 (上)を読み終えた。この本を入手したのはもう随分前になる。ずっと放置したままだった。頭の何処かに、読みたいし、読まないといけない、という意識がずっとあった。それにも関わらず、なぜずっと読まずにいたのか。初めて目を通したときの、最初のいくつかの章のとっつきにくさが原因だったように思う。プログラミングの前段階、要求やアーキテクチャから始まるのだけど、まだプログラミングを始めたばかりの頃には、それらが一体何なのかを現実のプログラミングと結びつけることができなかった。そこをスキップしてしまえば、具体的なコーディングの話が始まって、それほどソフトウェア開発の経験がなくても読み進められる内容ではある。しかし、最初に躓いてしまって、読む気が失せたと言うか、まだ読めるだけの経験値が溜まっていないと判断して後回し後回しになってしまっていた。

 これまでこの本を読まずにいたことでどれだけの損失を出していたかを考えてみよう。読まなかったからといって、コードが全く書けなくなるわけではない。逆に、読んだだけですぐに効果が発揮されて、優れたコードが書けるようになることもない。そう考えると、読んでも読まなくても対して違いがないのではないかと捉えられなくもない。

 仮に、今まだプログラミングを初めて1週間目くらいで、何かの言語を使って簡単なプログラムが書けるような状態になったところとしてみる。さらに、能力的には平均にしておいて、なぜかこの本の内容を理解して吸収できるだけの驚異的な適正があったとしてみる。この架空のプログラマーがこの本を読んだときと読まなかったときで、どれだけコードを書く能力に差が出るかを比較してみる。

 まず、読んだ場合を検討してみる。まだ1週間目なので、ようやくifの使い方が身についてきたというところだろう。そして、ifを書くときに、どうやったら良い条件を作ることができるかというところにも意識が向いてくる頃だ。その状態でこの本を読んだところ、ifの条件をうまく作るための指針が書かれていて、その優れた理解力によって、なるほど、こうすればいいのかと知ることになる。さっそく実践に移そうとするだろう。しかし、まだプログラミング始めて1週間であるという縛りは有効だ。頭の中ではこうしたらいいと分かっていても、身体がまだ作れていない。単純に言うと、経験値が不足している。これからifを書くときには、この本の指針を思い出しながら、注意を払ってコードディングしてくことになる。それを繰り返していくうちに、意識せずとも自然と良いifが書けるようになってくる。

 次に、読まなかった場合を検討してみる。実験台になる架空のプログラマーは、先と同一の条件を備えた人物だとしよう。ifを書くときに、ややこしい条件を扱わなければいけない状況に遭遇したとする。先と同じ能力を備えていると仮定しているので、やはりどうやれば良い条件が作れるかに思いを巡らすことになる。しかし、指針が全く無いので、自分でなんとかならないかを試行錯誤することになる。その結果出来上がるコードは、この本に書かれているような優れたコードの性質を満たしていないかも知れない。最も優れたコードでないことは自分自身がよく理解している。だが、何とかして動作するようにしないといけないので、現状でできる最も良いやり方で妥協して先に進んでいく。その後も、何度もifを使うことになるので、その都度同じように試行錯誤しながら良い条件にならないかを模索していくことになる。そのうちに、自覚はできないかも知れないが、なかなか良いifが書けるようになってくる。

 前者は、先に目標を設定することができ、そこに向かって訓練していくというスタイルになっている。後者は、その場その場で目標を更新しながら、徐々に鍛え上げていくというスタイルになる。前者の優位なところは、最終的な目標に到達するまでの時間を短縮できるかも知れないという点だ。ダイエットをする場合に、最終的な目標体重を定めて、そこに向かって食事や運動を調整するほうが、効果が現れやすい。それは、レールが敷かれているからそこに従っていけばいいと言うだけではなく、目標を立てたのだから、達成できるように努力をするように意識が当たらくという精神論の効果もある。また、目標があると安心感が得られる。どこまで体重を減らせばいいのかわからないよりも、理想的な体重が分かっていた方が圧倒的に安心できるだろう。後者の優位な点と不利な点は、前者のちょうど反対だ。時間はかかるかも知れない、安心できないかも知れない。しかし、試行錯誤の中から自分で見つけ出したものを目標と定めて、それを繰り返していくことで、違った性質の経験値を得ることができる。単純な筋トレのようなトレーニングとは違った、発見的な経験、想像力を養うプロセスから、独特な能力を得ることができるかもしれない。

 もともとの問に戻ってみる。果たして、後者のプログラマーはこの本を読まなかったことで、より大きな損失があったと言うことができるだろうか。 まず、1週間目という仮定に現実味がない。1年目に読むとして、10年後の違いを考えてみよう。10年間読まずにいたプログラマーは、1年目に読んだプログラマーよりも損失はあっただろうか。全く同一の人物で、同じくらい量のトレーニングを行ってきたとするとき、10年目の違いはどこに現れるか。まず考えられるのは、読んだ方は、その後の反復トレーニングによって、目標の能力を完全に獲得しているという状況だ。読まなかった方は、目標そのものが絶えず変化していくので、安定した能力を獲得できていないかもしれない。しかし、目標を自ら変化させていくというまた違った能力が鍛えられていくことになる。時間的なところに目を向けると、読んだ方は、10年も書けずとも目標に到達してしまう可能性もあるだろう。その場合、また新たな目標を立てて、より高いところに進んでいくこともできる。もし損失があったとしたらそこではないだろうか。つまり、この本を入手した時点で読んでいれば、もっと早く良いコードの書き方の目標が定まっていて、そこに到達していたかも知れない。そして、もっと関心のある現実の問題を解決するソフトウェアを書くことに専念できたかも知れない。

 今回、この本を読んでみて思ったのは、それほどまでに新たな発見のようなものが得られたのではなく、これまでの経験と照らし合わせると、とんでもなく道を逸れて、変なところに来てしまったわけではないということだ。そして、ようやく入門者から一歩先に進んで初心者の手前くらいまでは来たかも知れないと、何か達成感のようなものを感じている。もし、1年目に読んでいたら、このような感傷的な感想は抱かなかったに違いない。そして、誰かに与えられた助言ではなく、自身の経験から獲得してきたことであるという事実は、なかなか貴重であるかも知れない。この本を読む一番の理由はそれじゃないだろうか。何か新しいことを身につけたり、いきなり優れたコードが書けるようになることを期待するのではなく、自分がどの方向に向かっているのか、今どのくらいの経験値溜まっているのかを確認するために読むことで、より先に奨めるようになる。

 しかし、まだ上巻なので、あと半分のこってるのに結論を出してしまうのはちょっと早い。でも、たぶんそんなに違った感想は持たないだろうとは思う。

 コードコンプリートを読んでいる。そのサブタイトルが「完璧なプログラミングを目指して」なので、完璧なプログラミングとは何かを考えてみる。何かを目指すにしても、その何かが何なのか分からないのでは目指しようがない。

 プログラミングとはソフトウェアを対象とした領域の活動と考えられることが多い。だいたいプログラミングを仕事としていると言ったら、コンピューター装置の前に座って、コーヒーとキーボードを携えて不可思議な文章を打ち込んでいたりする姿が想像させられることが多い。こうした典型的なイメージのプログラマが扱う領域は、ほぼソフトウェアに限定される。せいぜいハードウェアとのインターフェイスまでだったり、ハードウェアを制御するためのソフトウェアだったりして、直接ハードウェアを製造するものではない。それどころか、現代の最上位のレイヤーで作業するプログラミングは、一切ハードウェアに感知することがなかったりする。厳密には、コンピューターに命令を出していたり、ディスプレイモニターに表示させる画面イメージを制御しているという意味でハードウェアに接しているということができるので、完全に切り離されているというわけではない。しかし、コンピューターやディスプレイモニターの電気的な特性を考慮しながらWebサイトやスマホアプリをプログラミングすることは稀だろう。

 このように、ハードウェアから切り離して、ソフトウェアの領域だけでプログラミングをできるようになっていることは、 抽象化によってもたらされている。現代の複雑なソフトウェアが成り立っているのは、ハードウェアを直接扱わずに、その上に多段に構築されたレイヤーの上で、問題の領域だけを扱えるようになっているところが大きい。もし、今でも直接マシン命令しか扱うことでしかプログラミングができなかったら、現代社会を支えるの多くのソフトウェア基盤はもっと貧弱なものだっただろう。マシン語でプログラミングをするのは開発効率が悪すぎて、複雑な問題を扱うソフトウェアを構築するには時間がかかりすぎる。現実の複雑な問題を解決するだけの複雑さをもったソフトウェアを構築すること自体が困難だったりしただろう。 

 そういうわけで、今の時代、プログラミングとは主にソフトウェアの領域だけの活動を指して言うことが多い。しかし、ハードウェアだけでもプログラミングを行うことは可能だ。スイッチをたくさん取り付けた回路を組んで、手動でそのスイッチのONとOFFを切り替えることで、ソフトウェアなしでも機械の動作を制御することができる。現実に、天井についているライトや、電気スタンドなんかは物理的なスイッチで動作する、ハードウェアだけで構築されたプログラムのようなものと見ることもできる。他には針時計、レコードプレイヤー、エレキギターなどもプログラムのようなものだ。電気的な動力をしようしないものある。楽器はすべて自然界の音に関する性質を利用した一種のプログラムだ。ここまで解釈を広げると、あらゆるものがプログラムに見えてくる。机、椅子は、人間の体型に合わせてプログラムされている。衣類とそれをしまうクローゼット、靴と靴べら、食器と箸、 鉛筆と消しゴム、などだ。別にペアであることを強調したいわけではなくたまたま思いついたから書いただけだ。これらは、現実の問題を解決するために生み出されたという点で、ソフトウェアのプログラムと共通している。そして、人工的に生み出されたものであるという点も共通している。異論は当然あるだろうが、これらをすべてプログラミングによって生み出されたものとし、そして、その活動をプログラミングとしてみなすなら、人工的に自然界に手を加えて、本来の姿形に何らかの別の法則を適用して便利なものを生み出す行為をプログラミングと呼べる。 

 では、プログラミングは人工的な操作を行うものかというと、まだ解釈を広げることができる。 まずは生命だ。生命はコンピューターよりも遥かに高度なハードウェアとソフトウェアを備えている。生体をハードウェアに見立てるなら、遺伝子はソフトウェアといっていい。遺伝子は人工的にプログラムされたものでは、通常はない。しかし、何らかの法則にしたがって、生命単体から子孫を通してその種の生存を制御しようとしている。生命を持たないものでも、プログラムのようなものがある。気象、地形などは、何らかの要因があって、雨が降っているとか、川が流れているというような現象を観測できる。他には、空は青い、東から日がのぼり、西に沈む、夜には月が出る。これらにはすべてなぜそうなっているのかという理由があり、従っている法則がある。これらの法則をプログラムとみなすことにしてみよう。そうしたプログラムを開発することがプログラミングだとすると、プログラミングによって宇宙を創造することができる。こういう存在を神とか創造主とかいったりする。

 ここでようやく完璧なプログラミングとは何か、という問に戻ると、それは究極的には完璧な世界を作るということになる。しかし、そんなことは全く現実味がないし、不可能でもある。そこで、シミュレーションという現実的な選択を取ることができる。世界を完璧にしようなどというだいそれた考えを抱かなくても、自分の好きな形に世界をシミュレーションすることで代わりができる。世界のシミュレーションはコンピューターゲームで実現できる。現実世界と全く同一のゲームというのは、やはり実現不可能という意味で現実味がないのと、面白くもない。逆に、現実で不可能なことを可能とする世界の方が面白い。大部分が現実に近いような仮想世界で、現実で不可能なことができるというのが望ましい。そして、今のゲームはそういう風な方向に発展してきている。これは自分の作りたいものとも一致していて、だからゲームプログラミングの修行をしているというところがある。

 結論を出すと、自分にとって完璧なプログラミングとは面白いゲームのプログラミングだ。いかにコードが優れていても、ゲームが面白くなかったら完璧とは言えない。では、面白ければどんなひどいコードでもいいのかというとそれは違う。ひどいコードのゲームは完璧ではない。完璧なゲームは完璧なコードによって生み出される。ひどい変数名をつかっていたり、ひどい関数名をつかっていたりするコードからは面白いゲームは生まれない。最終的には、読みやすく、誤りがなく、効率的で、保守しやすいコードというありきたりのところに行き着く。そのためには高い技術と豊富な知識と長い経験が必要となる。そんなのは幻想に思えるところもある。実際にどこまで到達できるかよりも、このくらい理想を掲げていないとすぐに堕落してしまう。それくらい完璧なプログラミングというのは難しい。

 三並べを作った。しかもCPUなし。一人で二役やらないといけないこのゲームは、もうゲームとすら呼べないのではないだろうか。GUIライブラリのデモとして考えればそうひどいものではない。それにしてもつまらないゲームだ。プログラミング中には色々考えるところがあって、Rustの練習にはなっているように思える。並行してゲームプログラミングの経験値まで稼ごうというのはちょっと欲張り過ぎかもしれない。三並べのような原始的なゲームで一体何の経験値が得られるのかのと軽く見てしまうと良くない。CPUを用意するのはそこそこ良い経験値になりそうだ。今回はやらなかった。どうせつまらないゲームだからと割り切って、GUIライブラリの使い勝手をテストするだけのような形で終えた。一度に完全なものを作る必要はない。10分の動画に収めるには情報が多すぎる。少しずつ発展させていく形にするのもよいだろう。

 とにかく、今回のはGUIライブラリの使い方とRustの練習としてはそこそこ良い経験値が得られたものの、ゲームの方は全然だった。こんな初歩的なゲームを作ることに何の見返りを求めているのか、繰り返しになるけど、そんな風に侮るのは良くない。こういう初歩的なゲームであっても、完璧に仕上げていくことを繰り返すのと、形だけ取り繕った中途半端な完成度のもので満足してしまうのでは、後々、大きな差になって現れる。実利的な立場からすれば、三並べを完璧に完成させたとしても、誰にもプレイされない可能性が高く、中途半端であって完璧であっても大した違いはなく、微妙な部分に多くの時間を割くよりもさっさと次の、面白くなるかもしれないであろう新しいゲームに取り掛かるのが良い。本当に夢中になって継続して作り続けられるゲームをやる方が良い経験になる。

 今思うのは、まだ本格的なゲームの制作に取り掛かるような時間帯ではない。まだ慌てるような時間じゃない。Rustをこつこつやって、ついでにゲームの経験値もためて、いずれは塵も積もれば山となっていることだろう。そういうわけなので、中途半端な状態のゲームを作り続けるのはこの方針にあっていない。面白いゲームを作るというのはちょっとハードルが高い。つまらないゲームを作り続けることの弊害として、つまらないゲームを作ることに慣れてしまい、感覚が麻痺してしまうことも見逃せない。だから、YouTubeに継続的に投稿していきたいという気持ちがあっても、あまりハイペースでつまらないゲームを作り続けるのは褒められたものではない。つまらないならつまらないなりに、完成度を高めておきたい。細かいところをきちっと作り切るつもりでやるのが良い。大体つまらないゲームは完成度が低い。三並べに完成度なんて求めるもんではない、というのは、また繰り返しになるのでもう言わない。

 それっぽく動くだけのゲームというのは、つまらないならつまらないなりに、完成されたゲームに到達するまでのどれだけまで到達しているのだろう。今回の三並べについては、半分もいっていないのではないかと思う。良くて30%、悪ければ20%くらいだ。それどころか、今回作ったのはプロトタイプくらいの水準に到達していないとも考えられる。プログラミングの常識では、プロトタイプのコードは捨てるのが正しい。プロトタイプのコードをもったいないと思って使い続けて本番用に流用してしまうのは、陥りがちな罠だ。もう一度、なぜRustでゲームを作って動画にして投稿しているのかというと、最大の目的はRustの練習だ。ついでにゲームも作れるようになれれば、といったところなので、これもやはり練習の一貫といえる。したがって、その成果として出来上がったものは、本番用のプログラムとは言えない。本番の前段階の試作品、つまりプロトタイプの領域にすら達していない。そもそも具体的な成果を求めていない。経験値こそが最大の報酬だ。この視点に立つと、完璧な三並べのどの段階まで到達しているか、という質問自体が成り立たない。あえて答えるなら0%ということになる。

 目的は練習だけど、完成度は高めておきたい、というのは矛盾を抱えている。練習用に作ったものに、それ以上の意味をもたせるのは無理がある。プロトタイプを使いまわすようなものだ。完成度の高いゲームを作ろうというのなら、最初から目標をプレイして面白い、リリース目的のゲームに設定する必要がある。それをやってしまうと、今度はRustの練習という、どちらかというと実験的なプログラミングの経験ができなくなってしまう。考えられる対策としては、リリース目的のゲームの制作と並行して、練習目的のゲームを作っていくことになる。これはなかなか大変なことに思える。今、練習用にやっているだけでも、ほぼすべてのプライベートなプログラミング活動に対するエネルギーをそこにつぎ込んでいる。これに加えて本番のプロジェクトを稼働させることは不可能に思える。並行処理が苦手なのはプログラミングだけでなく、現実でも同じのようだ。

 無謀な計画を立てるのではなく、とりあえず目の前のことに集中しよう。これまで同じようにRustの練習目的でゲームを作るのは継続していく。ただし、完璧までとは言わないまでも、できるだけ、そこに近づけるようにがんばることにする。でも、出来上がったものはあくまで練習用なので、使い回しのできるものだとは考えてはいけない。あとはどこでRustが使えるようになったかと判断するかだ。時間も有効に使いたい。いつまでも練習ばかりしていられない。

 昨日と今日は、RustのGUIライブラリであるicedを触っていた。なぜicedを選択したのか。しばらくSFMLを使ってきて、あまりRustらしいコードが書けていないことが気がかりだった。SFMLがC++のライブラリだということもあり、バインディングもオリジナルの使いやすさそのままにRustにポーティングされたようになっている。あまりRustらしい書き方を強制されることはない。これは良い面と悪い面がある。良い面は、C++での使い方を知っていれば、同じような使い方であまり迷うことなく始められるということ。悪い面は、良い面をそのまんま裏から見たもので、Rustらしい書き方をしなくても使えてしまうので、Rustらしいコードを書く機会を逃してしまうこと。今はRustらしいとはどんなものなのか分からない。Rustらしい書き方を身に付けたいにしても、どうやればいいのかわからない。SFMLを使うとどのようにも書けてしまうので、これまでC++で使ってきたのと同じように書いてしまうことが避けられない。今必要なのは、Rust流の書き方を強制することだ。SFMLは良いライブラリだけど、今は適切ではない。そう考えて、Rust製のライブラリを利用することにした。

 なぜゲーム用のライブラリで はなく、GUIライブラリにするのか。五目並べとかマインスイーパーのようなパズルゲームを作りたいと思っていて、それってGUIのウィジェット、例えばボタンなどを組み合わせてできそうだと思って、面白そうだと考えた。ちょっと息抜きに変なことがしたかった。RustでGUIプログラミングというのはなかなか新鮮で面白そうだった。ちょっとゲームとは別のことをしてみたいというのもあったかもしれない。ゲームプログラミングは比較的自由度が高い。そのため、どのような書き方でもできるとなると、Rust流の書き方をせずに、これまでの経験を引きずってしまう可能性が高い。GUIライブラリを利用したプログラミングというのは、最もライブラリに近いところでは、フレームワークが定めた範囲の中でプログラミングしないといけないところがある。そのフレームワークに従ったの書き方をしないといけない。通常はそのような制約は窮屈で、言語の可能性を下げることにもなるので、あまり良いものではない。しかし、Rust流の書き方を身につけるためという目的をもって見ると、何らかの制約がもたらされることはむしろプラスの方向に捉えられる。Rust製のライブラリなのだからRust流の使い方を強制されるだろう。そうすれば、どうしてもRust流の書き方をせざるを得ないことになる。これは願ってもないことだ。GUIのライブラリはおそらくゲームのライブラリよりも制約が多い。そこに目をつけた。

 ライブラリはいくつか選択肢がある。 GTKとFLTKが利用できて、使い勝手も良さそうだ。しかし、Rust製ではないので今回の目的にはそぐわないだろうからパスした。Rust製で人気がありそうなのは、icedとeguiだ。eguiはまだ試していない。icedはコンパクトで、割と簡単に覚えられそうな印象をもった。実際やってみると、ライブラリはコンパクトで大量に覚えることがあるというわけではないけど、基本動作が独特な感じになっていて、それを理解してしまわないといけない。Elmという言語のアーキテクチャに倣っていると書かれている。遠回りに思えるだろうけど、Elmのドキュメントを読んだほうが良さそうだ。

 icedを使用する上で困ったことは、ガイド的なドキュメントやチュートリアルがほぼないことだ。それなりの数のサンプルと、十分な量のAPIリファレンスはあるので、それを頼ることになる。今回はまず三並べを作ってみようとした。ボタンを3×3マスに並べて、それをクリックしたときにマスを選択したという風にしたいと考えていた。デフォルトのボタンはマスに見せるには無理がある見た目なので、変更したかった。参考になりそうなサンプルプログラムを探して、ボタンの見た目を変更するコードを発見したのだが、icedのリファレンスにある仕様と違っている。どうやらサンプルが使用しているicedのバージョンが古く、そのままでは利用できないようだった。しばらく時間を書けて、現在のバージョンのicedではどうやればいいかを調べた。その結果、ボタンの見た目を完全に変更することはできないという結論に達した。

 この結論は納得がいかない。ボタンの見た目を変更するなど、ありふれた要求に思える。こんなことすらできないGUIライブラリなどあるのだろうか。結論が間違っている可能性を捨てきれない。そこで行き詰まった。結論が正しいとして、ボタンの見た目を変更するのではなく、カスタムウィジェットがあるので、それを利用するか、結論が間違っているとして、また時間をかけて変更する方法を模索するか、板挟みになった。

 このように行き詰まったときに取ることのできるもう一つの方法は、しばらくその問題から完全に離れてしまうということだ。案外、割と単純なことを見落としていたり、勘違いしていたりすることもある。ちょっとリフレッシュすれば何か発見があるかもしれない。というのは楽観的すぎるだろうか。でも、やはりボタンの見た目が変えられないというのは受け入れがたいので、何かしら方法が見つかる可能性にかけてみたい。これを機にeguiを試してみるのもよいだろう。

 昨日は何を作るか長々と書いた末にブロック崩しを作った。Pongのコードの大部分がそのまま使えて楽ができた。今はまだ、とにかく動作するものを作るということに意識が持っていかれて、他のことにまで配慮ができていない。他のことってなんなのかと言うと、2つ無視できないことがある。

 1つ目は、コードの質について妥協していることだ。昨日書いたブロック崩しでは、明らかに問題なところがあったのを認識した上で、とりあえず動作するからこれでいいかと完了にした。練習だしRustに不慣れだからこんなもんでいいだろうという気持ちもあった。何が問題だったかと言うと、ひどく重複したコードがあって、本当なら共通の処理なので関数にまとめ上げるべきだったのを、そのままにしておいた。同じことを繰り返さないというのはプログラミングにおいて大切な姿勢だ。その姿勢はコードの中にも現れる。重複するコードが出現するというのは、典型的な改善するべきポイントとなる。Rustに不慣れだからだめなコードを書いてしまうのではなく、手持ちの能力でも改善できると認識していながら放置していってしまうと、良いプログラミングの習慣を身につけるチャンスをわざわざ逃していってしまうことになる。コードを良いものに作り変えるプロセスには、リファクタリングと呼ばれる名称がついている。リファクタリングについて学んだり練習したりしたことはないのだけど、おそらく今回のコードの重複を取り除くという改善作業は、リファクタリングに該当するのではないかと思う。せっかくプログラムを作ってリファクタリングを適用できる、訓練できる機会があったのに、むざむざとそれを手放してしまうというのはなんとももったいない話だ。コードの質の妥協についてはだいたいこんなところだ。 

 2つ目は、ゲームが面白いかどうかを気にかけていないということだ。既存のゲームのクローンを作るのだから、それが面白いかどうかなんて関係ないと思っていた。練習のために作ったゲームなので、誰も、自分自身ですらもそれで遊ぶことはないと割り切っている。ゲームプログラミングそのものを訓練しいるのであって、ゲームのデザインは自分の仕事ではないと思いこんでいる。確かに、ゲームデザインは自分の本業ではないかもしれない。将来的には、何かしらこういうのを作りたいという要求がどこからか湧いてきて、それを忠実にプログラムすれば面白いゲームができるのではないかという、夢の世界に生きている。現実ではそんなことはありえない。要求のとおりにプログラムするだけで面白いゲームになるわけでもない。これはゲームでないプログラミングについても同じで、要求のとおりにプログラムしたら使い勝手の良くないものが出来上がるというのはよく知られた悲劇で、プログラミングの失敗例だ。

 既存のゲームのクローンを作るというのは、ある意味、要求の分析を行う訓練を行うことを放棄していることでもある。プログラミングそのものを訓練しているのだから、それでいいというのはちょっと違う気がする。プログラミングと要求の分析というのは完全に切り離されたステージではない。プログラミングをどう定義するのかは置いておいて、もし完全に切り離してしまったら場合のコードを書くステージは、プログラミングと呼ぶより、コーディングと呼ぶほうがより適切になる。そう考えた場合、既存ゲームのクローンをとりあえず動作させるというだけの行為も同様に、プログラミングではなく、コーディングというのが適切だ。将来的に、忠実にコーディングだけを行うようなことを生業としたいかというとそんなことはない。面白いゲームをプログラミングすることを生業としたい。

 要求というのは安定しないものだ。特にゲームに置いては、ある程度形になってきてから、ここはこうした方がいいと分かって、コーディングよりも前の段階に戻ってやり直すなど日常茶飯事となる。前に戻るのがコストが高いから妥協するとなったりすると、つまらないゲームがになってしまう。つまらないゲームは、研究対象として興味があるかもしれないというのを置いておくと、使いにくいアプリケーションのような役に立たないプログラムと同じだ。アプリケーションの最大の存在価値化は、便利かどうかというところにある。ゲームの最大の存在価値は、面白いかどうかというところにある。だから、必ずしも実践できなくてもよいのだけど、今作っているゲームは面白いかどうか、というのは常に頭の片隅にでも置いて置かなければいけない。クローンの元となるゲームが面白くないのなら、どうやったらこれを面白くできるかということも検討するべきだ。どうやっても面白くならないのなら、そんなことはあまりないはずだけど、それはクローンする価値がない。そもそもの要求が間違っていたということだ。

 常に面白いゲームを作らなければいけないというのは、ちょっと理想が高すぎるかもしれない。 Rustの使い方がままならず、練習をしている段階でさえもゲームデザインについても考えながらやらないといけないとなると、前も書いたかもしれないけど、二兎を負うものは一兎も得ずの状態になってしまう。そんなたいしたことではない。ちょっとした意識の配分の仕方による。例えば、今回のブロック崩しを例に取ると、ボールの軌道にXとYが反転するだけ以外に変化がないのはいかにも退屈だ。パドルの当たり具合によってボールの軌道や速度に変化があるようにすると、ずっと良くなる。こんな感じで、気がついたことを直していく習慣をつけていくのが良い。その分プログラムはごちゃごちゃしてきて、見通しが悪くなる。これは必ずしも悪いことではない。現実の問題を解決するには、そういう状況に耐えうるようにプログラムを設計しなければいけない。ちょっとした変化をつけるだけで、何がなんだかわからなくなるようなのは、設計が不十分である、複雑さに耐えうるだけのしっかりしたものになっていないからだと考えられる。

 だんだんハードルが高くなってきている気がする。まだやっとこさブロック崩しを作った、という段階で要求やら設計やら考える必要があるだろうか。文字数を稼ぎたかったので、少し話を膨らませて書いたところが多い。本当の話は単純だ。面白いゲームにしたいという気持ちを持ち続けること、それだけ。プログラミングしながらそれを覚えておけば、あとはついて回るだろう。ここはこうした方が面白くなる、だからコードを書き換える、そうするとコードが煩雑になる、だから基本から設計をやり直す、と自然にそういう流れになるだろう。この練習を繰り返すことは、Rustの習得という点においても、そんなに効率が悪いとは思わない。

 そういう方向でやっていこう。

 Rust練習のために丁度いいゲームがないか探している。1ファイルで収まるくらい小さくて、可能な限りシンプルなものが良い。ありそうでなかなか見つからない。よく挙げられるのが2Dのシューティングなんかだ。シューティングゲームはどの程度作り込むかによってプログラミングの規模に大きな幅がある。シューティングゲームに限ったわけではない。ただ、シューティングゲームは根底のゲームロジックはどれも同じだ。敵に弾を当てる、敵の弾を交わす、それだけなので、シンプルなゲームと言える。プレイして面白いかどうかなどは求めていない。ゲームを作ることが目的ではなく、プログラミングの練習ができれば良い。結果として何かを残したいだけだ。とりあえず動作すれば良い。

 シューティングゲームの名作だと、自分の中ではグラディウスが真っ先に思い浮かぶ。これのクローンを作るのはなかなか大変だ。練習のためのモチーフとしては複雑過ぎる。他に思いつく、もっとも有名なシューティングゲームはインベーダーゲームだろう。グラディウスに比べればシンプルだ。練習題材として十分にシンプルだろうか。少なくともPongよりは難易度に高いように見える。Pongは画面にパドルとボールという2つの要素しかない。インベーダーゲームは、自機、防壁、敵がたくさん、UFO、敵の弾、自機の弾、こんなにもたくさんある。必ずしもこれらを全部作らないといけないわけではない。Pongと同じくらいシンプルにするなら、敵が1体と自機で弾を打ち合うということもできる。なんなら敵は弾を撃ってこないようにして、1対1で、一方的に敵に弾を当てるだけとしてもよいだろう。これならPongより少しだけ要素が増えただけで、十分にシンプルといえるのではないか。ただ、これを作っても何かをやってやったという達成感が得られないのが残念なところでもある。PongはPongとして完成されている。インベーダーゲーム先に上げたような要素全部が入ってインベーダーゲームだ。一方的な1対1だともはやインベーダーゲームの名前で定着しているものとはまったく異なるので、完成されたゲームとは言えない。クローンを作ったとは言えなくなる。

 クローンを作ることにそれほど固執する必要はないだろう。絵のデッサンとは違う。絵の贋作を作ることにそれほど重きを置く必要もない。先日のPongも、オリジナルの特徴的な部分を抽出してそれっぽく見せたものに過ぎない。オリジナルのプレイ感やゲームを面白くするために工夫されている様々な調整が欠落していて、クローンであるとは言えない。目立つのは、パドルの操作にかかる慣性や、ボールを打ち返すときにパドルの状態によって軌道や速度に変化を与えるなど、ゲームに変則的な法則を取り込んで、プレイヤーにゲームの状態を予測させることで楽しみや快感をもたらす、そういったぱっと見は分からなくても、ゲームの面白さを決定する重要なところが欠落している。そういうのを作り込むのは、ゲームプログラミングの練習には重要とは言える。今はまだRustの基礎を練習しようとしていて、ゲームプログラミング自体にはに重きを置いていない。どうせ作るならゲームがいいかなという程度だ。なので、Pongあれで良かった。あのくらい簡単なものがちょうどいい。

 昨日書いたのだけど、ある程度の複雑さがないと、Rustの特徴を活かしたプログラミングをする必要性がなくなってしまう。1対1の一方的なシューティングゲームを作るとして、シンプル過ぎるのではないだろうか。たぶん、シンプルすぎるように思える。しかし、やってみないとわからないところでもある。一発で成果を得ようなどと考えず、何度か繰り返していって感触を掴んでいくのが良い。何度も繰り返していれば、だいたいどの程度の規模感なのかを予測できるようになって、Rustの練習としてどの程度有用かも把握できるようになっていくだろう。今はまだシンプルすぎることを懸念しすぎるような時間じゃない。とりあえず1対1のをつくって、次に敵を増やして、弾を撃ってくるようにして、と段階的に発展させていくとよい感じがする。Pongしたって、あれで完成とはせず、オリジナルはやったことないのだけど動画で確認できるような、それに近づけていくのも良い練習になりそうだ。

 だいたい1対1の一方的なシューティングが候補に見えてきた。他にもいくつかある。テトリスとか、ブロック崩しとかどうだろう。テトリスは原始的なバージョンであってもそれなりに複雑なプログラムになる。さらに面白くしようとすればいくらでもやることがある。現在でも活発にプレイされているような完成されたルールと拡張性を備えた奥の深いゲームだ。ブロック崩しは、対人戦がないからというのもあって、テトリスほど現役のゲームではない。その分、基本的なプログラムのシンプルさという点では軍配が上がる。複雑なゲームであると、完成させることからとりあえず動作させることに意識が持っていかれる。そしてRustの練習をするという目的から外れてしまうことがある。コードがとりあえず動かすためにやっつけ仕事になってしまうということがある。意識していればそんなことにはならないというのは当てにならない。長い時間コンピューターに向かっていると、早く終わらせて次に行きたいという気持ちが湧いてくるのは避けられないことだ。テトリスはそれなりに複雑なロジックがある。ブロック崩しはPongのちょっと複雑なバージョンといった程度でちょうどよい。テトリスの原始的なものはいろんな言語で作ったことがあるけど、そんなに成果が得られたという感じがしない。どうしてもとりあえず動作させることに意識が持っていかれてしまい。言語を注意深く観察することを降ろさかにしていたためと思われる。ブロック崩しはあまり作ってこなかった。テトリスとブロック崩しのどちらかにするとなったら、ブロック崩しが良いだろう。

 ここまでで、次の候補は、1対1の一方的なシューティングか、ブロック崩しとなった。当初考えていたのは三並べのようなパズルゲームだった。具体的には、Simon Tatham’s Portable Puzzle Collectionのクローンを作っていくことで練習にしようと思っていた。いたのだけど、こういうパズルゲームは、リアルタイム性がなくて、SFMLのようなライブラリとはあまり相性が良くない。典型的なメインループを中心にフレーム単位でゲームを回すという処理が必要とされない。不可能ではないし、特段難しくなるというわけでもない。そうなのだけど、これはGUIライブラリを使ってやってみたいと思っていた。GUIのフレームワークが想定する、おそらくイベントドリブン型のプログラムでやってみたい。なので、もう少しあとにとっておくことにする。

 もっとさくさく作りたいものが見つかるかと思っていた。意外と見つからない。Rustの練習のためという名目があるので、ちょうどよい感じになるかどうかを考えると、かなりの制約があることが分かった。一番良いのは楽しみながらやることだ。やらなければならないという負の感情を抱えたままやるよりも、楽しんでやったことのほうがずっと脳はよく記憶してくれそうな気がする。楽しむということでは、自分でオリジナルのゲームをデザインしてそれを作るというのがベストだ。まだそこの領域まで到達していないので、今はクローンをたくさん作って行くことで我慢しておこう。

 Pongを作ってみた。Rustの動画を投稿したいと思って、何かしら作らないとネタがなかったのでとりあえずやってみたという感じだ。やってる最中は、こんな書き方でいいのだろうかと疑問がついて回った。そんなに難しいという感じではなく、CやC++で書くのとあまり違いはない。それもそのはずで、CやC++で書くときと同じ思考で書いている。結局の所、どの言語でも通用するような、公約数の部分だけを使って書いている。Pongのような単純なプログラムでは、熟練度が低いうちは、意図的にでもそのプログラミング言語の特性を強調しようとしないと、表に出てこない。どの言語でもかけるような解決法があるのなら、わざわざ専門的にならなくても、その方法を使えば良いというのは正しいやり方なのだろうか。

 Pongを単純なプログラムとみなすかどうかは微妙なところだ。とりあえず動くものなら簡単に作れるという意味では、単純であり簡単ともいえる。手の混んだ解決策を探さなくても、ストレートに書いていけば、とりあえず動くものは完成する。ライブラリが、今回はSFMLなのだが、低レベルな部分を吸収してくれて、高いレベルでプログラミングができるからそうなのだということは置いておいて、低レベルなところは無視する。SFMLの上に構築する基礎部分と純粋なゲームロジックだけに目を向けよう。そうしたとき、とりあえず動くものが作れるから、簡単だとなめてかかるよりも、どうやればよりRustらしいコードになるかを模索するのに、ちょうどいいくらいの複雑さを持っているように思う。しかし、Rustらしいとは何なのだろう。不必要に賢くなろうとすることは、良いプログラミングの姿勢とは言えない。しかし、Rustを全く知らない誰でも理解できる部分だけ使ったコードが、もっとも単純で良いコードになるのかというと、それは違うだろう。賢くなりすぎず、シンプルにしすぎない、この相反するような姿勢をバランスよく保つのがまず目指すところになる。もう少し具体的に言うことができればいいのだけど、思いつかない。シンプルという言葉はあまり適切でないかもしれない。プログラミングだけでなく、多くの分野でシンプルであることは好まれる。今言いたいのは、今回やったPongのように、多くの言語の公約数的な部分だけを使ってプログラミングすることを指している。反対に、賢くなりすぎるとは、使用する言語の秘伝のテクニックを多用するようなことを言う。シンプルすぎればコードは冗長になり、賢くなりすぎると冗長さは軽減されるが、理解するのに言語の詳細な知識を備えていることが条件になったり、直感的でなくなる場合がある。別の例えを使うと、最適化に対する警句が適用できるかもしれない。時期早々な最適化は諸悪の根源だという。時期早々な不最適化も避けるべきというのを聞いたことがあるけど、時期早々な最適化に比べればりは強くはない主張だった。これらの警句を賢くなりすぎることとシンプルすぎることに対応させると、ちょうどよい感じに思えなくもない。賢くなりすぎずに問題を解決できるならそれ以上はやらないほうがいい。しかし、あまりに非常識なRustにそぐわない方法を取るべきではない。

 だいたい目標が見えてきた。これから目指すところは、賢くなりすぎない程度にRustらしいプログラミングを身につけることだ。Rustらしいとは、漠然と思い浮かべているのは、トレイトを活用したジェネリックなプログラミングだったり、並行処理や非同期処理を活用したプログラミングだったりするのかもしれない。こういうのには憧れるが、Pongにはオーバースペックなので、出番はもともとなかったように思える。もし無理矢理にでも使っていたら、それは賢くなりすぎたという結果に終わっただろう。もしトレイトや並行処理を多用してRustを活用している気になりたいのであったなら、それに見合った問題に取り組むべきだ。この問題を自力で見つけ出すというのは、経験が不足しているうちはなかなか難しいことに思える。現段階ではそれらを身につけられていないからこそ、練習したいのでそういった問題に取り組みたいのだが、どういった場面に最も適合しているのか、例えば、この問題はトレイトを使えばうまく解決できるなどといった具合に判断ができない。取りうる手段は2つ思いつく。1つ目は最適な解決策なのかどうかに関係なく、無理やりにその手法を適用させてしまうことだ。これはさっき言っていた、賢くなりすぎることだ。目的は練習のためであると明確であり、事前に賢くなりすぎていると自覚しているのであれば、弊害はそれほどないだろう。練習であると割り切って数をこなしていけば、適用するべき場面のパターンのようなものが見えてくる可能性がある。ただし、これはあくまで練習であって、本来やるべきでないことをやっているということを常に忘れてはいけない。そうしないと、無意識に賢くなりすぎてしまう癖がついてしまう危険性がある。2つ目は、誰かが、Rustの達人たちが用意してくれたフレームワークで問題に取り組むことだ。例えば、Rust製のWeb開発のためのフレームワークや、GUIライブラリ、ゲーム用のライブラリなど、決められた枠組みの中で、型にはまったプログラミングを要求するものがある。その要求されるプログラミングはRustらしいものであると期待ができる。そういったものの利用して問題に取り組めば、問題の性質に関係なく、フレームワークが要求するやり方でやらなければならないので、否応なしにRustらしいプログラミングを体験することができる。思いついたのはこの2つだ。どちらか一つだけに絞らないというわけではなく、併用していくのが良さそうだ。

 Pongを作っただけにしては、こうして今後の心構えというか方針がはっきり見えてきたことは、大きな収穫だった。作っている最中にも作り終えたあとにもこんなことを考えていたわけではない。こうやって文章に書き出しているうちに出てきた。今の練習のサイクルは、①何か作る、②動画にして投稿する、③ブログに書き出す、となっている。時間はかかるけど、学習効果はそこそこな気がする。といってもまだ目的を取り違えているところは否めない。本来は、Rustを使いこなせるようになることや、プログラミングの学習をすること自体が目的というわけではない。ゲームを作ることが目的だ。しかし、1回だけの大作を作るのではなく、継続的にゲームを作り続けるというのが健全なあり方だろう。そのためにはどうしてもプログラミング自体が目的になったり、学習して熟練度を上げていくということ自体が目的になったりするものだ。したがって、学習することそのものに対して熱意を抱くことは恥じるべきものではない。かといって、誇るべきことでもない。学習の過程をスキップして直感だけでプログラミングができる人も稀にいるようで、そうした人と比較したときどちらが神に愛されているかといえば、後者かもしれない。そうした人に向かって、あなたは学習を実行しないから恥ずべきだと告げるのは滑稽だ。色んな方法がある。たかがPong、されどPong。