Scratch で作ったゲームはセーブできるのか？
Scratch で作ったゲームはセーブできるのか？ この場合、ゲーム自体をファイル上に保存できることは勿論だが、ゲームの途中経過（どのステージまで行ったかとかレベルとかスコアとか）を保存できるのかという意味である。
答えは、出来る。特に、何もしなくてもファイルを上書き保存すれば、変数の値やスプライトの位置や向きなども上書き保存される。
逆に言うと、ゲームを最初から始められるようにするためには、変数やら何やらを初期化するスクリプトを作らなければならない。
PCDesk（ダウンロード版）がツンデレな件
PCDesk とは、eLTAX 用のソフトである。そのダウンロード版が起動しないという現象があった。
そういえば、以前もそんなことがあった。最初は仕方なく最新版をインストールし直したのだが、そうしなくても大丈夫な方法があったはずだ。
少し調べて思い出した。Windows のカレンダーの種類を「西暦（日本語）」にすればよかったのだ。
マニュアルの「動作環境を確認・設定する」にも書いてあるし、「よくあるご質問」にもあった。ツンデレだなあ。
ていうか、ユーザー側でそんな設定をしなくても動作するように作れないのか？ ポンコツなのをツンデレで誤魔化してるだけじゃないですか？
e-Tax ソフトのダウンロード版は Mac OS では使えないし、申請用総合ソフト（法務省）は、住所に半角文字が使えないとかいう謎ルールがあるし、けっこうポンコツなんだよな。
「バグではなく仕様です」って一時期流行ったよ。
思えば、私もずいぶんポンコツ扱いされて来た。私がおっさんに命令されても動かないのは、そういう仕様に出来ているからだ。
e-Gov の公文書がウェブブラウザで表示できない件
これは、自営業者や士業の間では話題になっていることであるが、e-Gov から送られてくるというかダウンロードしてくる XML ファイルが表示できない件が、本稿執筆時点で確認されている。
解決策として、e-Gov のホームページの「お知らせ」に載っている方法（2025年11月4日版）を試してみると、表示できたのだが、これは対処療法と言わざるを得ない。
e-Gov の公文書は XML 形式であり、ウェブブラウザを用いて表示することが推奨されている。以前から、Microsoft Edge の Internet Explorer モードを使わなければならなかった。今回の件も、この Internet Explorer モードを有効にするメニューが現れないということだった。
Microsoft が Internet Explorer モードを廃止する方向に向かっているのは明らかだ。そして、XML と XSL の組合せをウェブブラウザでサポートすることから各ヴェンダーが撤退しようとしているのは、時代の流れだ。
その意味で、日本政府はこの時代の流れを読み誤ったことになるが、私は日本政府の先見性のなさを責めるつもりはない。
XML、XSL、XSLT、XSL-FO という規格にはヴィジョンがあった。それは、アプリケーションに依存しない形でデータをやり取りしようというものであった。このムーヴメントが盛り上がったのが2000年代初頭だったから、もう25年くらい前のことである。
XHTML が勧告されたのも同じ時代である。これは、HTML を XML のひとつとして定義するというものであった。すると、XHTML 以外の XML 文書も DTD や XML Schema などを使ってそのスキーマを定義し、XSL を使ってスタイルを与えれば、XHTML と同等に扱えるという将来像があった。
時代の流れとしては、HTML は HTML5、HTML Living Standard と形を変え、XHTML は主流ではなくなった。各ウェブブラウザも XML と XSL のサポートから撤退しようとしている。
それには、テック企業たちの思惑があるのだろう。アプリケーションからの独立性という理念よりも、自分たちの製品を業界のデファクトスタンダードにしたいという願望が勝るのは当然のことかもしれない。
e-Gov によると、 Internet Explorer モードを使わなくても XML 文書を表示できるようにアプリケーションを更新する予定だと言うが、それは充分可能だろう。昨今の AI に対する投資に比べればはるかに少ない額でそのようなアプリケーションは作れると思う。
さらに、任意のスキーマとスタイルを元に XML 文書をレンダリングするための API なども、公共性の高いプロジェクトだと思うのだが、どうだろうか？ それを自由に使えるようにすれば、そこから様々なアプリケーションが育つことが出来る。そのようなプラットフォームを政府が後押しするのか草の根レベルで構築するのかは、どちらでもよい。ボトムアップでの公共性というのは、元々 IT 業界が持っていた理念である。
AI（人工知能）だって、「人工知能冬の時代」と言われた頃があったのだ。第五世代コンピュータが事実上失敗プロジェクトと呼ばれた時代のションボリ感を知っている人にとっては、現在の生成 AI ブームは隔世の感があることだろう。
アプリケーションに依存しない形でのデータの交換と保存方法としての XML は、全くもって実現可能な目標であるし、大義がある。短期的な流行り廃りなど気にせずに大きな目標を追いかけたいものである。
ピッチベンドが0に戻っていない
Cubase で打ち込みをしていた時の話。
あるパートを聞き返していると、どうしても違和感がある。散々悩んだ末に原因を突き止めたのだが、それがピッチベンドが0になっていなかったのだ。
ピッチベンドとは、ピッチつまり音の高さを変化させる機能であるが、それを使ってギターソロのチョーキングを表現していた。その次のパートに入る時にピッチベンドを0に戻していなかったために、それ以降のパートの音程がずれていたのである。
これは、単純なミスのようであるが、コピペでパートを作ったり、コードパッドでコードを入力していく場合など、前のパートでピッチベンドを操作していたことを忘れがちである。
ギターソロがチョーキングやビブラートで終わる時、次のパートの最初でピッチベンドを0に戻しておくことを忘れないでおきたい。自分のための備忘録として、ここに記しておく。
はじプロにおける「れんけつ」
はじプロでは、ノードンとノードンをれんけつできる。
れんけつポートをワイヤーでつなぐことによってれんけつするのだが、例えばモノノードンには上と下のれんけつポートがある。モノとモノをつなぐ時にどちらからどちらにれんけつしても同じことだろうか？
答えは否である。下のれんけつポートから上のれんけつポートにつなぐのである。モノAとモノBがあったとして、モノAの下のれんけつポートとモノBの上のれんけつポートをつないだ場合、モノAをモノBにれんけつしたことになる。
これが本質的に問題になる例としては、設定を選ぶと出てくる「れんけつ面」がある。これは、自分のれんけつ面とれんけつ先の面を指定するのであるが、自分の下のれんけつポートとれんけつ先の上のれんけつポートがつながっている時に、この設定は意味をなす。
ノードンによっては、上にしか連結ポートがないものや下にしかれんけつポートがないものもある。それは、自分に何かをれんけつ出来ても自分は何かにれんけつ出来ない場合や、自分を何かにれんけつ出来ても何かを自分にれんけつ出来ない場合があるということである。
また、れんけつに関する制約については、れんけつポートにつなげるワイヤーの数の上限やれんけつグループに含めることの出来るノードンの数の上限があるが、これはリファレンスを参照してほしい。
シフトJIS では、第3水準・第4水準の漢字を扱えないのか？ 番外編(3)－JIS X 0213 を使う EUC もある－
以前、EUC-JP は文字集合として、ASCII、JIS X 0201 のカナ部分、JIS X 0208、JIS X 0212 を使うと書いたが、JIS X 0208、JIS X 0212 の代わりに JIS X 0213 を使う EUC が存在する。
その名も EUC-JISX0213 で、Shift_JISX0213 のように JIS X 0213 の附属書に規定されている。
ASCII、JIS X 0201 のカナ部分については、EUC-JP と同じである。EUC-JP で JIS X 0208 を使っていた部分に JIS X 0213 の1面を使い、JIS X 0212 の代わりに JIS X 0213 の2面を使う。
すなわち、GL に ASCII を呼び出し、GR に JIS X 0213 の1面を呼び出し、SS2（バイト列8E）で1文字分だけ JIS X 0201 のカナ部分を GR に呼び出し、SS3（バイト列8F）で1文字分だけ JIS X 0213 の2面を GR に呼び出す。
具体例でみてみると、
「A」（ASCII）は EUC-JISX0213 でも 0x41 だ（0x は16進数の意味）。
「ｱ」（半角カタカナ、すなわちJIS X 0201 のカナ部分）は 0x8EB1 だ。
「理」も EUC-JP と同じく EUC-JISX0213 でも 0xCDFD だ。JIS X 0208 に存在する漢字は JIS X 0213 第1面の同じ区点に存在するからだ。
「嚬」は EUC-JISX0213 で 0xAFBD である。これは、EUC-JP の場合と異なる。EUC-JP では JIS X 0212 を使い、「嚬」は22区68点に存在したのに対して、EUC-JISX0213 では JIS X 0213 を使い、「嚬」は1面15区29点に存在する。計算すると、15＋160＝175を16進数に直した0xAFが1バイト目、29＋160＝189を16進数に直した0xBDが2バイト目である。
芝野耕司編著、日本規格協会発行『増補改訂 JIS 漢字字典』の「嚬」の項目の GR の欄には AFBD とあり、「この字典の利用法」には「GR 漢字集合を GR に割り当てたときのビット組合せ。一般に EUC と呼ばれるビット組合せ。」とあるが、これは EUC-JISX0213 が JIS X 0213 を GR に呼び出すからである。この字典が言う EUC は EUC-JP ではなくて EUC-JISX0213 である。この書物における JIS X 0212 の無視のされっぷりは面白いくらいである。
最後に、JIS X 0208 にも JIS X 0212 にも存在しないが JIS X 0213 には存在する漢字「嚲」について見てみよう。この漢字は EUC-JP では表現できないが EUC-JISX0213 では表現できる。「嚲」は JIS X 0213 の2面4区50点に存在する。よって、JIS X 0213 の2面を GR に呼び出すために SS3 を使う。これで、1バイト目は 0x8F。4＋160＝164を16進数に直した0xA4が2バイト目で、50＋160＝210を16進数に直した0xD2が3バイト目である。まとめると、「嚲」は EUC-JISX0213 で0x8FA4D2 だ。
ここまで読めば、EUC-JISX0213 は第3水準・第4水準の漢字を扱えることが理解できたと思う。
この EUC-JISX0213、Shift_JISX0213 よりも更にレアな存在と言えるが、実装されていないことはない。テキストエディタ界の老舗 Emacs には euc-jis-2004（エイリアス、つまり別名 euc-jisx0213）というものがある。このエンコーディングでファイルを作り、上記の文字たちを入力（かな漢字変換で入力できなければ IME パッドなどを使い）すると、きちんと表示できるし保存もできる。そのファイルを開いた時に意図しないエンコーディングが採用されてしまった場合には、C-x RET r でエンコーディングを指定して読み直せばよい。 M-x hexl-mode を使ってバイナリモードに移れば、これらの文字のバイト列を確認できる。
Scratch のスプライト
無料で使えるプログラミング環境にはいろいろ選択肢があるが、教育用としても趣味用としてもちょうどいいものに Scratch がある。
Scratch は、MIT メディア・ラボのライフロング・キンダーガーテン・グループの協力により、Scratch財団が進めているプロジェクトであり、 https://scratch.mit.edu から自由に入手できる。
Scratch では、スプライトごとにコードを書く。デフォルトでは、「スプライト1」というスプライトが存在する。そのコスチュームは " Cat-a " と " Cat-b " である。コスチュームはコードと同じように、後から変更できる。
スプライトは、オブジェクトのようなものと考えてよいだろう。ここで、どのスプライトにも属さないコードを書きたいと思った場合、どうしたらよいだろうか？
そのためのスプライトを作ればよい。スプライトは表示しないことも出来るし、コスチュームを無地にしてしまってもよい。
