2022年9月の日記

買ったところで無料でやってもらえる。
1年8ヶ月換えていなかったようだ。
おそらく2万キロ程度は走っているはず。
もっと早くにいくべきだった。
何回でも無料なので、次は早めにいこう。
帰りについでに髪を切ってきた。

眠くて、アルゴリズムも読書もしないまま、朝まで寝てしまった。

黄金分割法の残り、elispとbashとfishをやっておいた。
次の回帰分析はかなり長いので、飛ばすことにした。
その次の階乗進数に手を付けた。
\(\sum_{i=1}^{n}i!i = (n + 1)! - 1\) という式が表われる。
これは数学的帰納法で証明できる。
やってみたら、簡単にできた。

今日までのセールでちょっと気になるのがあって、追加で購入しておいた。
Hadesというゲーム。
全く知らないのだけど、トレーラー見ると面白そうだったので、気になっていた。
インディーゲームっぽさが漂っているのも良い感じだ。
早くプレイしたいのだけど、今はちょっと余裕がないかもしれない。

黄金分割法。
かなり苦戦したが何とかなった。
逆数の二乗をとっているのは、s:t=t:uとしたとき、uをsとφで表わすとそうなるからだった。
結局自力解決するしかなかった。

黄金分割法をやっていたのだが、どうしても一つ理解できないことがあって、アップできなかった。
\(\frac{s}{t} = \frac{1 + \sqrt{5}}{2}\) という比率で分割していくところで、Cのコードではなぜかこの比率を二乗している。
なぜ二乗するのか、いくら考えても、コードを追っ掛けても理由が分からない。
Web検索すると、いくつか二乗しているものが見つかる。
もうちょっとじっくり調べてみよう。

SingletonとCommand。

シングルトンってまだ使われるのだろうか。
Commandは悪くない。

π。

数式もそれをコーディングするのも難しくはない。
しかし、なぜこの数式でπが表われるのかは全く分からない。
πについては、その値を計算する方法がたくさん存在している。
そのうちの二つということになる。
実用プログラムで、この方法で求めたπを利用するということはあまり考えられない。
数学の実験ということになる。
真に理解することは困難だが、こういうのも面白い。

フリープレイ回収のために、久々にPS4を起動した。
ついでにちょっとセールを覗いてみると、なかなか良い感じで、つい手を出してしまった。

• Lost Ruins
  
• アクトレイザー ルネサンス
  
• ロックマンゼロ&ゼクス ダブルヒーローコレクション
  
• Capcon Arccade Studium Packs 1、2、3セット
  
• BIOHAZARD RACOON CITY EDITION
  

エジプトの分数をやった。
かなり短かいコードとなっている。
計算のステップは巧妙で、なぜこのやり方で目的の結果が得られるのか、理解するのはやや難しい。

導入編 (Strategy)、Observer、Decorator、Factory。
めっちゃ分かりやすい。
かといって、過度に簡略化、省略された類のものではない。
適当なコードを示しておいて後は暗記しておいてね、というようなものでもない。
ちゃんとオブジェクト指向とまともに対峙している。
内容は、オブジェクト指向のこころに沿っているように見える。
こころの方を先に読んでいたので、いっそう分かりやすく感じる。
オブジェクト指向の原則など、矛盾していない。
一致している。
狙ったわけではないのに、たまたま一緒に買った2冊がこうも関連し合っているとは珍しい偶然だ。
相乗効果を期待したい。

良い本だった。
練習問題を全部スキップしたので、かなり早いペースで読み終えることができた。
その分、経験値は少なめだっただろう。
あまり身に付いてはいないとは思う。
もう一冊、同時購入したデザインパターンの本が控えている。
Head First デザインパターンという本。
これも面白そうで早く読みたいということもあって、こころは早めに切り上げることにした。
なんで今さらオブジェクト指向なんてやってんだという気がしないでもない。
もう2023年なわけで、もっと良い方法がないのだろうか。
C++を使い続けるのなら、どうしても身に付けておかなければいけない感がある。
実際に使わないとしても、消化不良な気持ちが残ったままで気持ち悪い。
RustやGoはオブジェクト指向を採用していない。
これは素晴しいことだ。
オブジェクト指向から解放されるには、C++を完全にあきらめて、Rustに乗り換えるというのも現実的な選択肢に思える。
C++を完全にあきらめるというのは、無理があるかもしれない。
C++はオブジェクト指向を一切使わないやり方でもできる。
たとえ可能であっても、そこに可能性が存在している以上、存在がちらつくのを無視するのは難しい。
Rustならそういう雑念に惑わされることはない。
そこに魅力を感じる。
オブジェクト指向そのものを否定しているわけではないといことは間違えたくない。
Rustの主戦場はシステムプログラミングという分野であって、アプリケーションのプログラミングがメインではない。
CとC++もシステムプログラミングに使われる代表的なものであって、Rustはそこに乗り込んできたという形だ。
システムプログラミングではオブジェクト指向は有効な方法ではない、ということだけのことだろう。
ゲームプログラミングでは、システムプログラミングと同じ性質のところもある。
ゲームエンジンのプログラミングではそうだろう。
しかし、ゲームそのもののプログラミングはそうではなく、アプリケーションのプログラミングと同様にオブジェクト指向が適しているところがある。
そこがなかなか難しいところだ。
C++は万能選手だ。
システムプログラミングも、アプリケーションプログラミングも、スタイルを切り替えることで同時にこなすことができる。
C++一本ですべてを構築することができる。
Rustはどうなのだろう。
まだちょっと触った程度なので、良く分かっていない。
もうちょっと時間を割いてみた方が良いだろう。
本当にC++からメイン言語として乗り換えることが可能なのかどうか、判断できるくらいまでは学習しておきたい。
もし可能であるならば、もうオブジェクト指向に悩まされるともなくなるのではないか。
そういうことでいいのかどうか、それも良く分からない。

異性体の問題なのだけど、これはちょっと良く分からないところがある。
炭素原子の数が5の場合、それによってできる構造異性体の数は3になる。
まずここがよく分からなかった。
組合せはもっと他にもあるように見えるのだが、どういう形を同一とみなすのかが分からなかった。
これはどういうことかというと、ひっくり返したり、折り曲げたりしたりしてできる形も同一とみなすようだ。

• 異性体（構造異性体・幾何異性体・光学異性体）
  

そこまはずクリアしたのだけどそのあとにまたよく分からないのが控えていた。

基が生成できたら、これをつなげば求める構造(飽和鎖式炭化水素)ができる。このような構造は、その最も長い鎖の炭素原子の数が偶数の場合は単に同じlengthの基を2個つないでできる。最も長い鎖の炭素原子の数が奇数の場合は、炭素原子をもう1個用意し、これに同じlengthの基を2個と、そのどちらよりも番号の若い基をさらに2個つないで作る。

ここのところが分からない。
イメージと一致しない。
Cでは一応コピーしてみたが、やはり分からない。
理解しないままコードだけ書いても意味がないので他のはスキップすることにした。
次の因子分析もやや難度が高そうで、コードも長めなので、これもスキップして、次のエジプトの分数をやることにする。

石取りゲーム2をやった。
正直ちょっと飽きてきたかもしれない。
bashとfishが同じことの繰り返しのようで、面倒に感じてしまう。
どちらか一方にしたいところだが、両方とも使いこなせるようにしたいので、外すことはできない。
別の言語を追加して気分を上げるかした方が良いかもしれない。
アセンブリとawkを考えている。
今の段階でも時間がかなりきつい。
もう少し手早くこなせるようになってからの方が良いだろう。

石取りゲームをやった。
アルゴリズム自体はかなり簡単なものだった。
Emacs Lispでは、ゲームの進行状況の表示と入力受け付けを同時にこなすために、ちょっと工夫が必要だった。
色んな方法が考えられる。
今回やったのは、表示用のバッファを作成して、出力はそこに書き込み、入力はミニバッファから行うというものだ。
これが一番簡単だろう。
入力はread-numberを使えば良いだけで、完璧にこなしてくれる。
表示用にwith-output-to-temp-bufferは使えない。
これはブロックに含まれる処理がすべて完了してから初めてバッファが表示される。
そうではなく、進行中も表示、更新されないといけない。
別の方法として、get-buffer-createで作成、あるいは同名のバッファを取得して、switch-to-bufferで切り替えて、そこにinsertでテキストを追加していく。
愚直な方法だが、まあまあうまくいった。
本当はdoctorのように、専用のバッファで入力もそこで行うのがベストだ。
今のスキルでは、ちょっと作り込むのに時間がかかってしまいそうなので見送った。

安定な結婚の問題をやった。
まだCとfishしかできていない。
fishでは2次元配列を扱うことができない。
fishだけでなく、普通、シェル言語ではそうだろう。
関数が戻り値を返す方法もなく、echoやprintfで出力してそれを利用する必要がある。
関数に変数を渡して、その値を変更するということもできない。
その辺りをちょっと工夫する必要があった。
本当ならオリジナルのCのをそのまま書き直すのではなく、より適したものに書き直す方が良かったのだろう。
しかし、今はまだ、fishでこれを実現するにはどうやるのだろうというのを模索している段階なので、よりfish言語らしいと判断するのは難しい。
なので、当面はオリジナルをそのまま書き直していくことにする。
bashとelispは明日やる。
次の石取りゲームは簡単そうなので、合わせてやることもできると思う。

半袖で出たら、風が強かったせいもあって寒かった。

2日目にしてさっそく途切れてしまった。
安定な結婚の問題をやるはずだった。

特定のパターンを扱う章はそれほどでもないのだが、それ以外の章が難しい。
どういう内容かとおおざっぱに言うと、主に分析と設計の方法論の議論ということになる。
自分が未熟であることもあり、設計についてしっかりとした方針を持っていなく、普段からあまり考えることもない。
そのため、関心が薄かったこともあり、言葉は入ってきても、そのまますり抜けていってしまう。
もう少し経験を積まないと真に理解することは難しそうだ。
ひとつこれまで認識していなかったことは、カプセル化について。
この本では、広く普及しているカプセル化の認識が不完全であることを指摘している。
それは、カプセル化は単にデータや隠すためだけのものではない。
メソッドや型、構造、あらゆるものを隠蔽する。
特に流動的要素、つまり、変化する部分を隠蔽するということが重要となる。
この考えは完全に抜け落ちていた。
ここで知ることができたのは、大きな収穫だった。

今日から毎日やることにした。
とりあえず1本目、XORによる暗号をやった。
シンプルなプログラムで、最初の一本にぴったりだ。
C、Emacs Lisp、bash、fishで書いた。
bashはかなり苦戦した。
特にバイナリデータを扱うところに苦戦した。
そもそも可能なのかどうかも分かってなかったけど、なんとかなった。
RANDOMによる疑似乱数でも、シード値を与えるところで奇妙な動作をして、時間がかかった。
こんな簡単なプログラムに半日くらいかかった。
この先続けられるのかどうか自信がない。

最初はデザインパターンに対する賞賛に満ちていて、いかがわしい感じもしていた。
読み進めるとそうでもないことが分かってきた。
確かに長く読まれている本だけあって、精巧な分析と、それを正確に伝えようという意向が読み取れる。
ありがちな問題を単純化てそれっぽく見せただけのものではない。
その分難解さはまだ残っている。
特にオブジェクト指向に特徴的な独特の語彙が満載なので、その辺が難解な見せかけになっている。
しかし、不思議とすらすら読める。
半日で半分弱読み進めてしまった。
内容が面白いということもあって、半日で半分弱ほど読み進めてしまった。
練習問題などはすべてスキップしている。
一度にすべてを理解しようとしない方が良いだろう。
そもそも無理だろう。
おそらく2週でも無理で、3週くらい回す必要があるようにに思える。

はじめてのアルゴリズム入門を読破した勢いで、続けてアルゴリズムの学習を継続することにした。
ライセンスは明示されていないのだが、前書きにこの本のソースは自由に使っていいと書いてある。
このサイトに掲載しても問題なさそうだ。
ただCでやるだけではなくて、別の言語に書き直していくことにしたい。
特に、Emacs Lisp、可能かどうか分からないけど、シェルスクリプト(bashとfish)をやりたい。

まだゲーム動画が完成していないのに新しいことに手を出してしまうのは良くない。
この3連休でゲームは完成させてしまうつもりだった。
もう残り1日しかないので、完成は厳しいかもしれないと思い、それならいっそ来週まで回してしまって、面白そうなことをやろうという気になった。
このサイトのプログラミングの記事も中途半端だし、何もかもが途中で放置されている。
この日記だけは、もうすぐで1年というところまで続いている。
ゲーム動画は投げ出すつもりはない。
ただ、ちょっと行き詰まった感があるので、休憩しているだけだ。
遅くとも、次の3連休中までには完成させる。

アルゴリズムの方に戻ると、さっそく最初のプログラムである、xorでの原始的な暗号化プログラムをelispで書いてみた。
思ったより簡単だった。
むしろ、Cのバージョンより短く、読み易いものになっている。

(defun string-from-file (file-path)
  (with-temp-buffer
    (insert-file-contents file-path)
    (buffer-string)))

(defun crypt-char (c)
  (logxor c (random 256)))

(defun crypt-string (s)
  (mapcar 'crypt-char s))

(defun crypt-file (file)
  (crypt-string (string-from-file file)))

(defun write-crypted (infile outfile key)
  (with-temp-file outfile
    (if (not (stringp key))
        (error key))
    (random key)
    ;;(mapc 'insert (mapcar 'char-to-string (crypt-file infile)))))
    (mapc 'insert (crypt-file infile))))

(write-crypted "foo.el" "foo.el-output" "hello")
(write-crypted "foo.el-output" "foo.el-output-output" "hello")
;;あいうえお

最後の「あいうえお」というのは、非ASCII文字以外もちゃんと復号できるかどうか確認するためのものだ。
コメントアウトされている、char-to-stringを噛ますと、ファイルのエンコーディングを確認するプロンプトが表示された上、でたらめな内容になってしまう。
あまり良く分かっていない。
ここに掲載していくには、ちょっと長いので、専用のページを用意していくことにしよう。
Cのオリジナルのバージョンを掲載しておきたい。

パズルとゲーム。
最後の章。
おまけ的な印象も受けなくもない。
しかし、やはり面白い。
そして、分かりやすい。
ただ本の通りに書いていっただけなので、ちゃんと理解しているとは思っていない。
どの項目も研究しがいのある内容だ。
全部きっちり追求していったら、ここだけで1ヶ月とかかかってしまいそうだ。
割り切ってプログラムが動作するところを見て、満足する程度にしておいた。
これでこの本は完了なのだが、当初の目的は、別の言語でトレーニングなる題材を探すことだった。
こんなにじっくりと読むつもりはなく、いまさらCで写経するのもなんかなーと思っていた。
実際やってみて、なかなか楽しく、また基礎を見直すことにもなって、有意義な経験だった。
まだ入門しただけであって、これで終わりでは無駄遣いになってしまう。
ここから先にいくには、もっと個々の話題を掘り下げていく必要がある。
予定通り、別の言語で書き直すことで、トレーニングするということにも活用できる。
また開く機会は多そうだ。

持ってるのは第3版(2008)なのだけど、新しい版の第4版も出ている。
良い本だったから、貢献したい気持ちがないわけでもない。
しかし、おそらくVC++のバージョンが上がったという点以外に、それほど大きな変更はないだろうから保留しておく。

3連休なので油断していた。
昨日はずっと起きてたので、夕方から寝てしまった。

原始的なグラフィックスの章。
MFCあるいは.NETのグラフィックスAPIをラップした、簡単なライブラリが付属している。
Windowsがターゲットとなっているため、VC++以外の環境では使えない。
しかし、ソースを見ると、まったく難しいものではなく、簡単にX11に対応できそうなのでやっておいた。
一応できあがったので、それを使って読み進めることにした。
結果、全部期待通りに動かすことができた。
この章は、アルゴリズム本であるという視点からはあまり重要ではないかもしれない。
しかし、ちょっとした仕掛けのコードで、はっと見惚れるような不思議な図形が描かれるのは、貴重な経験になる。
説明が不足気味で、何が行われているのか理解するには難しいところもある。
そこは別のところで補えばいいので、欠点とはいえない。
あくまで入門の本なので、これからどこへ迎えばいいのか、方向を示してくれることの方が重要だ。
この本で一番楽しかった章だった。

久々に本屋に行った。
特に目当てのものはなく、適当にぶらついてみた。
これといってピンとくるものがなく、何も買わずに帰るかどうか悩んだ。
でもせっかくきたのだし、ということで、何でもいいので手にとってみることにした。

• ワンス・アポン・アルゴリズム
  
• デザインパターとともに学ぶ オブジェクト指向のこころ
  
• Header Firstデザインパターン 第2版
  

これらを買うことにした。
まったくきまぐれに選んだものだ。
いまさらオブジェクト指向とか学ぶのもどうなのか分からない。
最近ゲームの動画を撮り始めて、確かにオブジェクト指向に基づいた設計は役に立ちそうだという感覚を覚えてきている。
ゲームとオブジェクト指向は相性が良いような気がしないでもない。
アルゴリズムのは、これも最近勉強し始めたからつい手に取ってしまった。
表紙のイラストが良い感じで、今買っとかないと、あとで後悔しそうなので、確保しておいた。
がちがちの解説書じゃなくて、物語になっている。

はじめてのアルゴリズム入門のグラフィックスの章で使用されているライブラリを書き換えていた。
そのライブラリは、Windows APIあるいはMFCのための薄いラッパーのようなものだ。
ライブラリというのも大げさに思えるくらい、小さなもので、簡単に書き換えられるように思えた。
X11を使うことにした。
X11のプログラミングの経験はあまりない。
ぽつぽつ調べながら、試行錯誤しながらやっていた。
主に、ここのチュートリアルを参考にしながらやっていた。
ひとつだけどうしても解決しないことがあった。
XSetBackgroundという関数があるのだが、これで色を指定しても何の効果もない。
期待する効果は、XClearWindowなどで消去されるとき、指定した色で塗り潰されることだ。
XSetBackgroundは、引数にGC(Graphics Context)を取るので、GCに関連する背景色のみに影響があるものと思われる。
XClearWindowは、引数にGCを取らない。
なので、XClearWindowに反映されることを期待するのは間違っているのだろう。
XSetWindowBackgroundという関数もあり、これは期待通り、指定した色でウィンドウ全体を塗り潰してくれる。
それで終っておけば良いのだが、じゃあXSetBackgroundはどういうときに効果が発揮されるのか気になって、半日くらい調べていた。
GCをに関連する、グラフィックス用の関数、例えば、XFillRectangleや、XDrawStringなどを試してみるが、何の効果も得られない。
XSetForegroundに指定すると、塗り潰しの色や、文字の色に指定した色が適用される。
そもそもGCとはどの領域を指しているのだろう、GCの背景とは何なのだろうという疑問がある。
戻り値を調べてみると、エラー値である1となっている。
これは、BadRequestとなっている。
しかし、XSetForegroundでも同様にBadRequestが返ってくるが、ちゃんと反映される。
なので、これが原因ということでもなさそうだ。
おそらく解釈を間違えている。
GCの背景色を利用する機能(関数)を利用したときにだけ、その値が使われるのだろう。
XFillRectangleや、XDrawStringは背景色を利用しないというだけのことなのだろう、という結論で納得しておくことにした。
じゃあウィンドウ全体を特定の色で塗り潰したいというときにどうすればいいのかというと、先のXSetWindowBackgroundとXClearWindowを使えば良いだろう。
もうひとつ、XFillRectangleでウィンドウ全体を塗り潰すという方法が考えられる。
実際にやっているサンプルが見つかった。

• COMP2401 - Course Notes (8 - Graphics を参照)
  

ここでは、XSetForegroundとXFillRectangleを使っていて、XSetBackgroundは使っていない。
奇妙な感じはするが、もうこれ以上時間を無駄にしたくないということもあり、そういうものだと割り切っておく。

マイクロ秒単位でスリープする時間を指定できる関数。
unistd.hをインクルードする前に、_BSD_SOURCEあるいは_DEFAULT_SOURCEを定義しておかないと使えない。

• implicit declaration of function usleep (Stack Overflow)
  

何でそうなっているのかまでは理解していない。

グラフ。

木。

昨日は今日中に読み終える見込みでいたけど、まだ少し時間かかりそうだ。

今日は一日中読んでいた。
かなり楽しい。
たぶん明日か明後日には読み終わるだろう。
ゲームもやりたいのだけど、こちらを優先してしまおう。

やらなかった。

数値計算の章。
これまでまったくやったことがなかった。
今まで自分がどれだけ間違った道を歩んできたのかが分かる。
かなり楽しい。
ちょっとしたことを覚えるだけで、ぐっとプログラミングの幅が広がる。

昨日今日と手をつけていない。
1日2、3件のアクセスしかないし、再生時間も1分程度と、誰にも見られていないので、強制する必要はあまりない。
しかし、あまりに時間を空けてしまうと、また放置状態に移行してしまう可能性がある。
それだけは避けたい。
せっかくここまでやったので、きっちり完成させておきたい。

そろそろ再開しとかないとまずいと思い、手をつけた。
Spacemacsでやっていたのだが、操作をすっかり忘れている。
思い出すのに時間がかかりそうだ。
これから毎日コツコツとやっていく。
10章はかなり難しい。
今の状態であまり時間をかけても、停滞するだけで、効率が良くないと判断して、流してしまうことにした。
マーキングしておいたので、もう少し理解が進んだところで再開することにする。

今までちゃんと時間をかけて学習したことがない。
これから毎日何時間か割り当てて、継続的に学習していくことにする。
アルゴリズムモンキーになる。
テキストは何冊もある。
全部消化したい。
まず簡単なのから始めた。
「C言語によるはじめてのアルゴリズム入門」という本だ。
いつ、どういう理由で購入したのか、記憶にない。
解説が浅くて、あまり良い印象はなかったのだが、ちゃんと読んでみるとなかなか味わい深い。
まず、トピックの選択と分類が良い。
コードをきっちり写していくと、解説がもの足りなくても、なんとなく分かった気になれる。
コードは、ちゃんとしたプログラムとして動作するように書かれている。
これはプログラミングを始めたばかりの人をターゲットとしているためだろう。
どうやって動作させたらいいのか分からないとか、ちゃんと写したのに動かないとか、混乱させることを避けるためだと思われる。
これは理解できるところだ。
一方で、プログラムの動作とアルゴリズムが分離されていないという欠点もある。
再利用可能な形に書き換えるのは、練習課題と考えておけば問題ない。
コーディングスタイルもあまり美しいとは言えないので、そこを改善するのもあとにとっておこう。
そもそも、この本を読み始めた理由が、Cで書きたのではなく、今学習中のHaskellで書き直して訓練したいという理由からだ。
あまり期待せずに読み始めたら、なかなかしっくりきたので、そのままCで続けて、一度きっちり読んでしまうことにした。

やられモーションだけ。
次は亀を踏んだとき甲羅になるようにしたいところ。
しかし、今の状態のコードに追加するのは厳しいものがある。
もう一度コードを整理する必要があるだろう。
以前、一度コードの見直しだけで一回使ったばかりなので、もうちょっと後回しにしたい。
今の状態でもできそうなところからやっていくのが良いだろう。

• ブロックを壊せるようにする
  
• 背景を追加する
  
• ゴールできるようにする
  

敵キャラにパックンフラワーも追加したいところだ。
敵キャラ関係はとにかく今のコードでは厳しい。

やられのアニメーションを作っていた。
なんとかできた。
ビデオを撮る時間はなかった。
コードがごちゃごちゃしてきた。
今日で休暇は終わりなので、早く寝た。

• アクションゲームを作る MoonScript編 #5
  

敵キャラの追加。
ようやくPascal編の先に進めた。

• アクションゲームを作る MoonScript編 #4
  

コードの見直し。
タイルマップの表示が乱れるバグが修正できたのは、大きな収穫だった。
原因は、カメラのターゲットが小数値になっていたことだった。
これは、DrawTextureRecの描画位置が小数値になっていても発生する。
特定するのに時間かかった。
ともかく解決できて良かった。

• アクションゲームを作る MoonScript編 #3
  

Pascalでやっていたとこまでの巻き戻し完了。

ラズパイPicoの特集だ。
楽しみにしていたのをようやく入手した。
ラズパイ4もPicoも、もう半年以上も触っていない。
せっかく入手できたのに、もったいないことだ。

• アクションゲームを作る MoonScript編 #2
  

引き続き、巻き戻しをやる。
衝突検出と応答だけで終わってしまった。
しかも、1時間30分程度の長い動画になってしまった。
あまりスピードアップできていない。
全部いちいちコメントしながらやってるので、仕方ないところもある。
そもそも速さを競っているわけではないので、気にしなくてもよい。
それよりもMoonScript、それにLuaを含めると、もっと良い作りができるのではないかということに気を使いたい。
Luaは、データを定義するのにも優れている。
テーブルをもっと活用して、プログラムロジックにデータを記述するのではなく、設定あるいはカスタマイズポイントとして、Luaのコードを利用するという書き方もできた。
例えば、他の言語だったら、JSONやXMLやYAMLなどで書くところを、Luaで書いてしまうといったやり方があった。
今の状況だと、タイルセット画像のファイル名と、タイルの数、タイルの幅と高さなど色々考えられる。
今回はステージ一つしか作らないつもりなので、あまりメリットはない。
しかし、もっと良い作り方があったということを気に止めておく。

• アクションゲームを作る MoonScript編 #1
  

Pascalでやっていたとこまでの巻き戻し。
1回で終えたかったのだけど、やはり無理だった。
タイルマップでステージを表示するところで終り。

アップした。

• MoonScriptでやってみる
  

今回からMoonScriptを始めた。
Pascal版はもう少しで完成だったので、本当なら完成させてしまった良かった。
ただちょっと飽きが来たというか、だれてきたので、気分を上げるために切り替えることにした。
今回はウィンドウを表示させるという、それだけの内容だ。

luarocksでMoonScriptをインストールした経過で、不明な点が出てきた。
LuaJITは、Lua5.1のライブラリというかパッケージ、あるいはモジュールを利用するようだ。
検索パスは、おそらく /usr/lib/lua/5.1 とか /usr/lib/luarocks/rocks-5.1 とかになるかと思われる。
なので、例えばMoonScriptをLuaJITで使いたいとかなったら、次のようにすればいいのかと考えた。

$ luarocks install --lua-version 5.1 --global moonscript

SolusのデフォルトのLuaは5.3で、5.3を使うなら単に $ sudo luarocks install moonscript とやるだけで、うまくいく。
そのため、5.1を使うにはバージョンを指定してやる必要がある。
このコマンドを実行しても(–global があってもなくても)、なぜか、システムに、言い換えるとグローバルにインストールされない。
ユーザーのホームディレクトリ ~/.luarocks にインストールされる。
LuaもLuaJITも、何もしなければそのパスを検索しないので、設定してやる必要がある。
次のようにすることが考えられる。

$ luarocks path --lua-version 5.1 >> .bashrc

これで、LuaJITは ~/.luarocks にある、5.1のライブラリも検索してくれるようになる。
しかし、今度は逆にLua5.3の方が誤って5.3のライブラリではなく、5.1のライブラリを見つけてしまう。
どっちもうまくいくようにということができずに困っている。

• 参考になったページ
  

巻き戻しが終わった。
いつものように、もう一度繰り返してその様子を録画する。
1本に収めたいところだ。
半日近くかかったので、ちょっと厳しいかもしれない。