ドルアーガの塔でマップが似ているフロアを探したら予想外にたくさんあった

 先日ドルアーガの塔で6階と22階のマップが同じなのではと思い確かめたら違っていた件で、乱数列生成アルゴリズムを実装してどうなっているかを確認していたのだけど、

ドルアーガの塔の6階と22階 - naoya2kの日記

どのような感じで途中から迷路が一緒になるのかを確認したくなり迷路生成を行うプログラムを作って確認した。

 

https://github.com/naoya2k/drumaze/blob/main/README.md

(このリンク先には全60面の生成の様子がわかる動画を置いてある)

 

そして、6面と22面の迷路生成をじっくり観察したところ、結果的に途中まで迷路生成が進んだあたりで状態が全く一緒になってしまい、その後は同じ、みたいな感じであった。

 

 

ところで、このプログラムを使っていろいろ見ていると16階と32階の左側も同じであることに気づいてしまった。他にも左側が同じになっている面があるのではないかと思い、左半分だけのマップファイルを生成して同じものがないかを抽出したところ、下記の9つのペアが見つかった。

  • 6階と22階、15階と30階、16階と32階

    6面と22面の類似に最初に気づいたのはどちらもファイヤーエレメントに耐えてソーサラーを倒す必要があり、迷路の構造に注意した立ち回りが必要だったからと思われる。一方でその他のペアは片方がゴールドマックを取ったあとに訪ずれる面のため迷路の構造が全く重要じゃない攻略となっていたために気づかなかったのではないか。16階と32階などはかなり特徴的なのに気づけてなかった。
  • 20階と56階、25階と49階、26階と55階

    特に26階と51階は、右上のポールから上に壁が延びたか下に延びたかの違いしかない。わずか2ブロックしか違いがないというのに気づいてなかったことにびっくりした。

  • 28階と55階、29階と57階、31階と36階

    28階と55階も、26階と51階のペアと全く同じように、右上2ブロックだけの違いとなっていた。

つまりドルアーガの塔の全60フロアのうち、1/3弱の18フロアが、似たフロアが他に存在する迷路構造になっているということだった。これまで全然そんな認識がなかったのだけど。

 

あと冒頭のリンクの先にある動画を見ると、迷路生成において左上から右下に階段上に延びる壁が目立っており、全然対称的な構造になっていないんだけど、それでいいんだっていうところが興味深かった。

ドルアーガの塔の6階と22階

今でもたまにやる。1980年代のナムコのゲーム、人によって「いまでも遊んだときに面白い思う」ゲームが違いそうなところが興味深い。大学のときにパックランドが好きな先輩とかドラゴンバスターが得意な人とかそれぞれ居た。自分はドルアーガリブルラブルと源平のような気がするが、リブルラブルギャプラスはボーナスステージがもっと短かかったらいいなと今は思うものの、ボーナスステージがなかったらあまり上手くないときに遊ばなかったのではないかという気もするので難しい。

 

ところで10年くらい前から6階と22階は同じマップなのではと思っていたのだけど調べてみると右の5〜6ブロックだけが違っていた。

 

6階

 

22階

 

ドルアーガの迷路は各階ごとに乱数のシードがあるだけであとは自動生成ということだったので、左半分が同じなら全部一緒になりそうな気がしていた。しかしこの事象だけでドルアーガのマップは右側から左に向かって生成されていることがわかるのだ。生成途中でなぜか乱数が同じ動きをするように収束してしまったのだ。

 

調べたところドルアーガの塔の迷路は、右上の柱からどこかの方向に壁を伸ばしていく、その方向を乱数で決める、というようなアルゴリズムで実装されているっぽかった。そして60階ではその乱数列が全ての柱で左方向になるような(それはもはや乱数ではないが)seed値が設定されているということだった。

この迷路生成につかわれる疑似乱数は https://hayasememo.tumblr.com/post/55601992754/%E3%83%89%E3%83%AB%E3%82%A2%E3%83%BC%E3%82%AC%E3%81%AE%E5%A1%94-%E3%83%95%E3%83%AD%E3%82%A2%E7%94%9F%E6%88%90%E3%82%92%E5%8F%AF%E8%A6%96%E5%8C%96 あたりで解説されているのだがこれを実装してもなんだかうまくいかなかった。

 

下記のページにDで記述されたコードがあった。

https://qiita.com/devmynote/items/ea9d9cd323439363a670

これの乱数部分だけCで実装してためしたところ、

6階の乱数(seed=5)は

3321212012001333200012001213201213213213333332133321321213332012120132013212121320001320120121333321213212013321320013320000000133332001...

22階の乱数(seed=21)は、

2120000012133212120120013332000120012132012132132133333321333213212133320121201320132121213200013201201213333212132120133213200133200000...

となった。22階の乱数列から冒頭の"21200000121"を省いたものは6階の乱数列と同じになった。数字を1つ生成するごとに変わっていくseedを確認したところ212000000121が終わったところでseed=5になっていた。そりゃその後は同じになるよね。

でももしドルアーガの壁生成アルゴリズムが、「ある柱に対して、一つの乱数を生成したら必ず壁を1個作る」みたいなものになっていたら、同じ乱数列がでも位置がズレていると同じ迷路パターンになったりしないはず。ドルアーガの壁生成アルゴリスムでは、「乱数によって決まった壁を伸ばす方向に既に壁があった場合、再度同じ場所で乱数を引きなおして、壁が作れるかどうかを確認することになっており、なので、6階でも22階でも乱数を何度も無駄打ちした結果、たまたま同じ柱の位置で同じパターンで始まるような感じになり、しかもそのあと生成される迷路の壁生成にそれまで生成されてきた壁のパターンが影響を及ぼさないような感じになったということになる。これはなかなかのレアな確率なのかもしれないと思った。

太陽光発電と蓄電池のある家に住んで1年が経過しました

miro氏の太陽光発電+蓄電池のエントリを読んだ。東京都は補助金がすごく出るのですぐに元が取れる的な話でした。

家庭用太陽光発電+蓄電池をつけて1年が経った|MIRO

 

一方で自分は横浜市太陽光発電と蓄電池のある家に昨年引越して同じくちょうど1年が経ったところで、だから上記エントリとちょっと比較しつつ自分の収支も公開してみようと思いました。

 

横浜市は補助がないんだよ!

横浜市では補助金は出ない。自転車で行ける距離である東京都だと200万円以上の補助金が都から出ているのにこちらではまったくゼロ。あまりの格差にクラクラしそう。

現在、横浜市では「電気自動車(EV)」、「プラグインハイブリッド自動車(PHV)」、個人向けの「太陽光発電」・「蓄電池」の補助は実施していません。

 

カーボンニュートラル事業推進課(旧環境創造局環境エネルギー課)における補助事業のご案内 横浜市

 

でも、たとえ補助が出なくても、いま新築を建てるときに太陽光発電と蓄電池をつけないという選択肢は自分にはなかった。正しい日本人としてカーボンニュートラルに向けてできる限りの節電と創エネをやっていく必要があるのだ。

それにあとで公開する収支の通り十分元はとれそう。

 

自分ちの設備の概要

自分ちの設備は下記のような感じ。

miro氏は360万円のシステムだったとのことだがこっちは約200万円で、えらく差があった。

この差はどこからきているかというと、まず蓄電池の容量が半分以下しかないこと、自分がこのシステムを含む諸々の見積をしたのが2022年の3月頃で円安やインフレが始まる直前だったこと、そして自分のはハウスメーカーへのOEM品だがmiro氏のものはパナソニックで高級品だということ、のような気がする。この費用が安いことがこのあとの収支での利回りにものすごく影響している。

 

収支(1年目)

自分の1年目の収支は下記となった。

 



 

基本的にはmiro氏と同じフォーマットにしてみたのだけど、事前予測はしてなかったので予測比は出していない。

左側が各月の実績値。

  • 太陽光発電の発電量
  • 家庭全体の電力消費量
  • 太陽光発電のうち、売電した量(のこりは自家消費)
  • 電力会社から電気を買った量

発電量の青いセルは、年間で一番発電量が多かった月である。一方で消費量の赤いセルはそれぞれ夏と冬で電力消費量がピークだった月の数値を示している。

右側は具体的な収支。

  • 電力消費量から逆算した、本来の電気代
  • 電力会社から買った分の電気代
  • 電力会社へ電気を売った額
  • 差し引き収支(本来の電気代 - 実際に買った電気代 + 電気を売った額)
  • システム設置費用(196万円)に対する表面利回り
  • 設置費用を回収するのにかかる年数

本来の電気代を計算するときの単価は、その月の電気代の請求から算出した平均電力単価を使った(単価としては4月5月は25円/kWh程度だったがその後は18~22円/kWh程度で推移していた)。

 

自分もmiro氏と同じような感じで、おおむね毎月1.5〜2万円くらい、年間で約19万円の回収があって、補助金がなかったにもかかわらず投資額に対する利回りが10%近くあり、10年ちょっとで回収できる見込みとなった。

 

ほんとうだろうか。

 

太陽光発電+蓄電システムは10年で本当に回収できるのか?

さて、自分の1年間の収支によれば、補助金がない自治体であっても設置費用は10年で回収できるという結果になっており、これを信じるなら設備の設置費用は太陽光発電を導入しない理由にはならない。

「だからみんな導入すべき。絶対元は取れる」みたいに短絡的な結論にもっていってこのエントリを終了してしまってもよいのだが自分はそうはしない。このエントリに乗っている僕の収支を単純に信じてはいけない、いくつか疑うべきポイントがあるのでそれを説明する。

 

  • 去年の横浜は異常に日照時間が長かった
    去年の実績を参考にするときに一番注意しないといけないのがこれだ。2023年の横浜の日照時間は2410時間だった。下記の気象庁の統計によればこれはなんと統計以来最長だったのだ。わりと外れ値である。
    気象庁|過去の気象データ検索

    横浜市の過去30年の年間日照時間。横軸が年、縦軸は日照時間(単位h)


    つまり、去年と同じ発電量を毎年期待することはおそらく正しくない。最近では2006年の日照時間は1667時間しかなかった。次の1年は昨年度と比べて発電量が2/3になってしまうかもしれないということだ。

    たとえば平年の発電量は去年の75%、売電量が2割減、買電量が3割増と仮定して計算すると、年間収支は昨年度実績の19万円ではなく14.5万円になり、回収に13.5年かかることになってしまう。

  • 10年経ってFIT終わったらどうなるんでしたっけ?
    去年や今年に太陽光を設定した場合、FITによって設置後10年間は買電額が1kWhあたり16円で買いとってくれることが確定するので、売電額の見通しがたてやすかった。しかし10年後以降は売電額がどのようになるかは現時点では全く不明である。
    太陽光発電が普及しすぎて本当に二束三文(1円/kWhなど)でしか売れなくなっているかもしれないし、逆にインフレが進んでもっと高く買いとってもらえるようになっているかもしれない。

  • 電気代が安くなってしまったら回収できないんだけど
    昨年の電気代は高かったと思う。年間平均で22円/kWhだった。このエントリの収支も当然それで計算している。
    来年以降、突然原発が稼動する、政府が補助金をバカみたいに増額する、国際的に天然ガスがめちゃくちゃ安くなる、などの要因によってもし17円/kWhになったりすればその分だけ収支も計算上は減ってしまい、回収に必要な年数も14年とかになってしまう。
    まあ今後は賦課金はしばらく3~4円/kWhで推移するだろうし、託送料金分の9.92円/kWhが劇的に減ることもあまりなさそうなから15円/kWhを切ることはないと思うが。

  • そもそも僕のような省エネ生活ができる人は少ない
    自分たちの家族はかなり省エネに全振りした行動を取っていると思う。「本来消費額」のところを見てもらえばわかるとおり、今回の太陽光発電がなくても月の電力量料金が1万円を大きく超えることはないし、年間の電力量料金も15万円以内である。
    夫婦と子供1人が暮らしていて、オール電化で、12月~1月に月500kWhしか使わなかった、というのが一般的な家庭だとは自分はあまり思わない。日中にもっとたくさん電気を使う人であれば今回の自分の結果よりも断然収支のプラスが大きくなるだろうと思う。一方で夜間に電気をたくさん使う人であれば…それでも太陽光発電システムとしての収支はあまり変わらないのではないかと思う。トータルの電気代が自分よりも大きいことで、電気代の削減効果が小さく見えてしまうところはちょっと残念に思われるかもしれない。

自分の場合はとにかく10年~15年で元が取れる。FIT終了後は売電額は下がるだろうとは思うが、蓄電池の交換が必要だったとしてもその後の収支黒字化は容易いと思う。

パネルは30年、パワコンは15年くらい持つという話だ。一方で蓄電池は10年、15年経ったら相当にヘタってくると思うが、そのときに
「ほぼ故障しているようなもんだし交換必須だな」になってるのか、
「交換しなくてもあと5年くらい平気っぽいけどいい機会だから交換しようかな」になってるのか、
「思ったよりも全然OKだからあと10年くらいイケんじゃね?」になっているのかはいまいち予想できない。

 

長々書いたけど、太陽光+蓄電池のトータル収支、自分のケースでは補助金なしでもぎりぎりプラスになりそうだと思っている。だから自分はこれを他の人に「ぜったいやるべき」と勧めるかというとちょっと違うような気がする。本気で考えるなら結局自分のライフスタイルで試算して納得した上で選択するしかないし、5年後10年後の電気代がどのようになるかの予測も難しい。

自分はトータルで赤字になっていたとしても「太陽光発電ちょっとおもしろいから体験としてはいいよね」みたいに思ってポジティブに考えちゃうと思う。自分は1年住んでみてエコキュート太陽光発電と蓄電池システム、それから家の空調などをそれぞれ違うメーカーがバラバラに開発していてうまく連携できていない、でもこれをうまく成立させるのは難しそうだということを、割と身を持って実感できたのがよかった。ちょっとでもそういう体験したい人で、付けれるチャンスがあるなら絶対つけるべきだというようなことは思った。

スーパーマリオワンダーのリスポーンの特許と、ゼルダの伝説ToTKのスクラビルド(じゃなかったウルトラハンド)の特許

仕事がしんどすぎて久しぶりに任天堂の特許を検索したところスーパーマリオワンダーらしき特許が大量に出願されていたことに気づいた。

この2023年11月から12月にかけて出願された18件の特許は図面とかを見た感じスーパーマリオワンダーに関連する特許のようだった。一番上の2つはレンダリングに関係するものなので読みたいと思っている。ちょっと時間と気力がなくて全部チェックするのはすぐには無理。なので一番最初に見た特許について紹介しようと思う。他の特許もマルチプレイ関連が多いような気がする。

 

特開2023-169896(P2023-169896A) - 死んだあとのリスポーン位置を決める特許

https://www.j-platpat.inpit.go.jp/c1800/PU/JP-2023-169896/A3A009FAA3611A376237881353491653546A12F903EB012F0094BD5E17CB8B33/11/ja

【公開番号】特開2023-169896(P2023-169896A)
【公開日】令和5年11月30日(2023.11.30)
【発明の名称】ゲームプログラム、ゲームシステム、およびゲーム処理方法
【出願番号】特願2023-132926(P2023-132926)
【出願日】令和5年8月17日(2023.8.17)

【要約】
【課題】適切な位置にキャラクタを出現させることができるゲームプログラム、ゲームシステム、およびゲーム処理方法を提供すること。
【解決手段】ゲーム空間内の所定の位置を所定のキャラクタの出現予定位置として設定する。出現予定位置が、所定のキャラクタが出現可能な位置の場合は、当該位置にキャラクタを出現させる。一方、当該位置が、所定のキャラクタが出現できない位置の場合は、当該位置に探索中オブジェクトを配置し、所定のキャラクタが出現可能な位置に到達するまでの間、当該探索中オブジェクトをゲーム空間内で所定距離移動させて、当該移動後の位置において所定のキャラクタが出現可能か否かを判定する処理を繰り返す。そして、探索中オブジェクトが所定のキャラクタが出現可能な位置に到達すれば、当該位置に所定のキャラクタを出現させる。

 

これを見てスーパーマリオの特許だとは普通は思わないかもしれない。マリオの特許かどうかを素早く判定する方法は、図面を見ることだ。この特許には下記のような図面がある。これはマリオだ。

特開2023-169896の図4

さてしかしこの特許の課題とか解決手段とかを見てもあたりまえのことしか書いてないのである。「リスポーンできる場所ならすぐリスポーンするんだけど、そうじゃない場所だった場合には困るだろ? だからリスポーンできる位置まで仮のキャラを移動させてそこでリスポーンするんだよ」という。

ところでスーパーマリオワンダーにはマルチプレイ時の復活に関して下記のような説明がされていた。

ミスをすると「タマシイ」となってさまよい、カウントが0になる前に他のプレイヤーにふれることでその場で復活!

スーパーマリオブラザーズ ワンダー : マリオも仲間も一緒に冒険 | Nintendo Switch | 任天堂

 

この内容が請求項6に書かれていた。

【請求項6】
  前記所定のキャラクタは、プレイヤの操作に基づいて移動制御され、前記ゲーム空間内のオブジェクトとの衝突判定が行われ得るプレイヤキャラクタであり、
  前記プレイヤキャラクタが移動制御可能な状態で前記出現予定位置にプレイヤキャラクタを出現させる、請求項1に記載のゲームプログラム。

 

つまり、、この特許からの視点では、上記のタマシイのシステムは、ゲームを成立させるための制約としてのルールづけではなく、あくまで「その位置でリスポーンできるかどうかを判定するための一つの方法」として「タマシイをユーザーに操作させて他のキャラに衝突したとき、そこをリスポーン可能な位置(リスポーンしたあとにゲームが続行できる位置)と判定する」というような説明になっている感じである。

 

いや、確かに、単純に「他のキャラにぶつかるまで移動させないとリスポーンできないんだよ」ってのはなんか、それってゲームのルールですよね。特許じゃないですよねみたいな話になりそう。

でもだからってそれを、
「死んだ位置でリスポーンしたら無限に死ぬから、いい位置にリスポーンさせる方法が必要
 → そのリスポーン位置をプレイヤーに知らせるために、そこまで移動する間の仮のキャラを表示したりするんだよ
 → その仮のキャラをプレイヤーに操作させて他のプレイヤキャラに当たったら、そこはリスポーン可能位置と判定するのもそのうちの一つだよね」
みたいな流れで説明しているのは… このタマシイのシステムが、このゲームの開発中に本当にこういう流れで試行錯誤として生まれたのか、それとも特許として出願するために考え出されたロジックなのか、どっちなのか、自分は割と気になる。

 


 

特許7397237 - ゼルダの伝説ToTKのスクラビルドの特許

さて以前にToTKの特許がいっぱい出てたというエントリを書いていたのだけど、その時点では公開されていなかったスクラビルドウルトラハンドに関する特許が去年の12月に登録されていたようだった。それがこの特許73927237である。

https://www.j-platpat.inpit.go.jp/c1800/PU/JP-7397237/FF578A14C4ABCDE3EBEEEC7832A1FE5B4FCA31F362192A473C5A88996DEF3557/15/ja

【特許番号】特許第7397237号(P7397237)
【登録日】令和5年12月4日(2023.12.4)
【発行日】令和5年12月12日(2023.12.12)
【発明の名称】情報処理システム、情報処理プログラム、情報処理方法、および情報処理装置
【出願番号】特願2023-523122(P2023-523122)
【出願日】令和4年3月3日(2022.3.3)
【要約】
仮想オブジェクト同士を接続して複数の仮想オブジェクトからなるオブジェクトを生成する場合にユーザビリティを向上させることが可能な情報処理システムを提供する。情報処理システムの一例は、複数の仮想オブジェクトのうちの第1オブジェクトをユーザの選択操作によって選択し、選択した第1オブジェクト、及び、複数の仮想オブジェクトのうちの第2オブジェクトのそれぞれの接着位置を示す接着オブジェクトを生成する。ユーザの接着指示に応じて、第1オブジェクトと第2オブジェクトとをそれぞれの接着位置において接着する。

つまり、A,Bの2つをくっつけるような操作をやるときに、

  • ユーザはそのうちの1つだけを選択する(選択して操作する)
  • A,Bの接着位置を示す接着オブジェクトをつくって表示する

みたいなことがポイントだとしている。ここでの接着オブジェクトは、例えば下記の図16にある78で示されているものであり、これは自分も「これ特許で出願されそうだな」って思っていたところだった。

図16

特許明細書の文面には、この接着オブジェクトのことだけではなく、リンクが持ち上げて動かしている物体(明細書内では「選択オブジェクト」と書かれている)と他の物体との位置関係をわかりやすくするために、選択オブジェクトの像を他の物体に投影するとか、中心点を描画するとか、プレイヤーキャラの動きに合わせて選択オブジェクトがどう動くかとか、さらには、所定の解除条件を満たす入力がなされた場合には接着が解除されることなどが記載されている。

既にこの特許の分割で 特開2024-015493 が出願されている。これは「オブジェクトそれぞれに、他の箇所よりも優先的に接着位置となるような位置が設定されている」というものだ。

他の分割出願が今後どれだけ増えるのかは要ウオッチかもしれない。

 

(2024-02-05) id:sailorojiさんからスクラビルドじゃなくてウルトラハンドだと指摘を頂きました。指摘ありがとうございます。なぜ間違えたのだろう…

pythonのasyncioの勉強をしていました

あけましておめでとうございます。というエントリを書こうとしてたんだけどいいネタがなくてこのままでは2月になってしまうというところでなんでもいいから書こうとなっています。

httpでストリーミング的にデータを垂れ流してくるようなサーバがあってそこから適当にデータをダウンロードしつつ処理をしたい。できればpythonで、という相談を受けたのでasyncioってやつを使ってみたのをメモっときたいと思いました。

 

 

まず無限に応答を返すようなhttpサーバを建てる必要があった。

  • MacOSでは標準で搭載されているapacheを有効にしてcgiを動かした。このへんは他のWebサイトにもいくらでも載ってるので割愛である。/Library/WebServer/CGI-Executables/ にcgiスクリプトを入れたらアクセスできるようになる。
  • 下記の無限に数字が出力されつづけるinfinity.plを上記ディレクトリに配置した。IO::Handleを使ってautoflush(1)をしているところがポイントで、これをやらないとバッファリングされてしまってタイミングよくクライアントに応答が送られない感じになる。

    #!/opt/local/bin/perl                                                           

    use CGI;

    use IO::Handle;

     

    STDOUT->autoflush(1);

    my $q = new CGI;

    print $q->header();

    for (my $n = 0; ; $n++) {

        print "$n\n";

        sleep(1);

    }

  • ブラウザではよくわからないのでcurlで出力してみるとちゃんと1秒毎に数字が表示されて動いていた。

なんでperlなのか、pythonっていってたじゃんかと思われるかもしないが、それはこのへんは主題じゃないから。次が本番のpythonのクライアント

  • aiohttpってやつを使えば非同期でhttpのリクエストを出してレスポンスを受けとれる。

    import aiohttp

    import asyncio

     

    async def main() :

        async with aiohttp.ClientSession() as session:

            async with session.get('http://localhost/cgi-bin/test.pl') as resp:

                print(resp.status)

                print(await resp.text())

     

    asyncio.run(main());

    これはいろんなWebページに良く載ってるやつで、これをTaskにして複数個並列に実行させてスクレイピングをやるよみたいな例でよく出ている。でもこれだとresp.textをawaitしているので結局最後まで受信しないとテキストが出力されない。
  • 無限に応答を返しつづけるようなサーバに対しては、
    https://docs.aiohttp.org/en/stable/client_quickstart.html
    の、「Streaming Response Content」のセクションに解説があった。下記のコードで…つまりresp.text()とかではなくresp.content.read(20)で受けるとサーバから受信したタイミングで処理ができる。

    import aiohttp

    import asyncio

     

    async def main():

        async with aiohttp.ClientSession() as session:

            async with session.get('http://localhost/cgi-bin/infinity.pl') as resp:

                while (1):

                    print(await resp.content.read(20))

    asyncio.run(main())

  • read(20)でやってみたんだけど、これは
    https://docs.python.org/ja/3.6/library/asyncio-stream.html#asyncio.StreamReader
    のreadメソッドで引数は一度に読みとるbyte数だった。read(10000)にしても動作は変わらなかったので、受信したタイミングで受信する最大バイト数を指定しており、それより小さいデータしか受信できてなくても応答が返ってくるようだった。あたりまえだがこれをread(1)にすると1バイトずつしか取ってくれなかった。
  • 受信中に他の処理をしたい場合にはasyncioのcreate_taskを使う必要があるとのことだった。3秒経ったら止めるフラグを立てる下記のようなコードを作って確認した。

    import aiohttp

    import asyncio

     

    cont = True

    async def timeout(duration):

        await asyncio.sleep(duration)

        global cont

        cont = False

     

    async def connect():

        global cont

        async with aiohttp.ClientSession() as session:

            async with session.get('http://localhost/cgi-bin/infinity.pl') as resp:

                while (cont):

                    print(await resp.content.read(20))

     

     

    async def main():

        t1 = asyncio.create_task(connect())

        t2 = asyncio.create_task(timeout(3))

        await t1

        await t2

     

    asyncio.run(main())

  • 実際のところ「3秒だけ情報を取得する」みたいなのだったらもっと他にやりかたいっぱいあるだろという気がするがいろんなやりかたを試しておきたかった。
  • main()と、taskのawaitはわりと理解しづらい気がした。たとえば上のコードでは「await t2」は無くてもいい、いやむしろ無いほうが良いくらいなのだけど、そういうのはWebで出てきたサンプルをちょろちょろコピペして「やったー動いたー」ってやってるとわからない気がする。

ストリーミングを説明してくれているサイトでいいところがあるのかよくわからなかったので公式っぽいところを参考にしてみたんだけど動作するものはわりと簡単に作れた。一方でpythonのコルーチンとかスレッドのモデルは、asyncio.run(main())のところはわりと面白いなと思う一方で、いまいちまだ自分の中であまりちゃんと理解ができてない感じなのでもうちょっとがんばってドキュメント(https://docs.python.org/ja/3/library/asyncio-task.html#)とリファレンスを読んでいく必要がありそう。

2023年に見たアニメで好きなOP/EDたち

自分あんまり網羅的にアニメとか見てないのでもっといいのがきっとあるんだろうと思うのだけどこんだけ大量のアニメ番組を全部見てるやつとかすげー少ないだろうから自分が見たなかでいいなと思ったのを紹介するでもよいのかとも思う。

 

「お兄ちゃんはおしまい!」OP「アイデン貞貞メルトダウン

このアニメは話題になったと思うのだけどその半分くらいはこのOPのインパクトがあってのこそなのではないかという気がする。そういう意味ですごい。

 

TVアニメ『お兄ちゃんはおしまい!』“おにまい”OPムービー(ノンクレジット)/OPテーマ「アイデン貞貞メルトダウン」えなこ feat.P丸様。 - YouTube

 

下のカットとかちょっと意味不明だけど勢いがあってよかった。

 

「英雄王、武を極めるため転生す 〜そして、世界最強の見習い騎士♀〜」OP「セルフハグ・ビッグラヴ (Selfhug Biglove)」

【TVアニメ】『英雄王、武を極めるため転生す』ノンクレジットED|ゆいにしお「セルフハグ・ビッグラヴ」 - YouTube

おしゃれな感じでよかった

 

「推しの子」OP「アイドル」

これはここで紹介するまでもなく良かった。

【推しの子】ノンクレジットオープニング|YOASOBI「アイドル」 - YouTube

個人的には↓のカットがめちゃくちゃ好きだった。

「ワールドダイスター」OP「ワナビスタ!」ED「トゥ・オブ・アス」

TVアニメ「ワールドダイスター」ノンクレジットエンディング - YouTube

 TVアニメ「ワールドダイスター」ノンクレジットオープニング - YouTube

両方すごく好きな曲なのでアニメを見ようと思ったのだが自分にはちょっと難しかった。2話くらいまでしか見ることができなかった。

このOP/ED曲は良かったのだがOPもEDも映像はYouTubeを見てもわかるようにいまいちぱっとしなくて、どっちも映像なしで聴いてたほうがいいんじゃないかという気がしてしまった。

 

アイドルマスター シンデレラガールズ U149」ED「グッデイ・グッナイ」

【アニメ】「アイドルマスター シンデレラガールズ U149」第10話ノンクレジットエンディング「グッデイ・グッナイ」【アイドルマスター】 - YouTube

10話でこれが流れてきて「えっここでこんな新しい曲をつっこんでくるの凄くね?」と思ったが、本来これがメインのED曲でそれまでの話は全部特殊EDだということだった。11話も特殊EDだったのでこの曲が流れたのは結局2話だけだったし、どちらもライブシーン後に流れる曲になっているのでEDに派手なアニメがあるわけでもなかったけどめちゃくちゃ良かった。

 

「私の推しは悪役令嬢。」ED「O.C. 〜Optimum Combination〜」

【ノンクレジットED】TVアニメ『私の推しは悪役令嬢。』/ 「O.C. 〜Optimum Combination〜 Episode1 ver.」レイ(CV.芹澤優) - YouTube

これは好きなので見たいと思っているがまだ見れていない(最近忙しい)。OPの「レイジョアハンズ!! 〜Raise Y/Our Hands!!〜」も良かった。

 

ポーション頼みで生き延びます!」OP「tailwind」

TVアニメ「ポーション頼みで生き延びます!」ノンクレジットOP|katagiri「tailwind」 - YouTube

EDの「Love is a potion」もかわいい感じで良かった。

 

「でこぼこ魔女の親子事情」ED「Welcome!」

「Welcome!」|「でこぼこ魔女の親子事情」エンディング映像 - YouTube

低予算感があふれているのだけど一方でセンスがあって非常に良いEDだった。

EDだけじゃなくOPも、アニメ本編もそういう感じでセンスの良さしか感じなかった。2023年で一番おすすめのアニメはなんだったかと聞かれてこれを答えた。

 

「豚のレバーは加熱しろ」OP「私が笑う理由は」

アニメ『豚のレバーは加熱しろ』ノンクレジットオープニング|ASCA「私が笑う理由は」 - YouTube

どこがどうとはうまく言えないが良い曲なんだ。

 

聖女の魔力は万能です Season2」OP「Semisweet Afternoon」

TVアニメ『聖女の魔力は万能です Season2』 ノンクレジットオープニング映像|結城アイラ「Semisweet Afternoon」 - YouTube

ストリングスアレンジが良かった。

 

異世界転生モノ、アニメ本編はもうかなり食傷気味で見なくていいなと思っちゃうようなものが多いのにOPEDにいい曲が入ってくることが増えて困ってしまう1年だった。

今年買ったコンピュータたち

なんかいろいろあったんだけどいつものように今年買ったものを書く。

 

Apple MacBook Air (M1 late 2020)

今年1月、RAM8GB, SSD512GBのモデルの中古が税込96000円で売っていたのを発見し、1週間考えて、結果購入した。もともと持っていた、同じくRAM8GB, SSD512GBのearly 2020を売り払ったところ66000円くらいで売れたので、3万円でM1にリプレースできたということになる。

売り払ったearly 2020は10分使うとCPU(Core i5)の温度が100℃になってしまい、定格のクロックで動作しつづけることができないという、自分からしてみれば「これは不良品一歩手前じゃねーか」みたいな感じの機械だったのだけど、そんなことを気にしない人にとってはちゃんとしたMacBook Airなわけで、自分のようなやつに不機嫌になりながら使われつづけるよりも、たまにスタバでドヤ顔するために使われたほうが幸せなのでそうなってほしいなと思いました。

Apple M1の省電力性能と安定性はすばらしく、Euro Truck Simulator 2(ETS2)が1920x1200の解像度で快適に遊べてしまう。Core i5-1035NG7のMacBook Airでは描画品質をかなり下げて1408x880に落としたりしても発熱でプチフリが発生して(ゲーム内で)事故るみたいな状況が多発し、フルHD解像度にするなどはとても無理という感じだったが、このM1では1920x1200で描画品質をultraに設定してもわりと問題なく遊べてしまう。1035NG7はすぐに15Wくらい電力を喰っていたがM1は5Wでたいていのコトが済んでしまう。アイドル時も1035NG7は1W以上消費していたところM1は80mW未満だったりする。できることは殆ど同じなのになにかが根本的に違う。

 

 

Chuwi minibook X (N100)

minibook Xはキーボードがまともな配列なので興味があった。N100も、あのちょっと良かったGoldmont plusの子孫なので気になっていた。わりと期待通りだし可愛い製品ではあるのだが、キーボードのキータッチがかなり悪いのと、タッチパッドの操作性も悪く、なんだかんだ言って使うのがちょっと苦痛である。タッチパッドは押し込みを検知するための物理ボタンが残念ポイントではあるのだが、その他にタッチパッドを触ってから画面上のマウスポインタが動くまでに微妙に遅延があり、それが操作性の悪さに直結している。なんとかならないものか。

N100には期待していたがこの前にM1を見てしまっているせいでわりと微妙な評価になってしまう。全体的にN100はM1の半分以下の性能しかない。それでいてN100はM1よりも消費電力が大きい。そしてキーボードの出来がわるい。全体的に良さげなのに残念だ。もうちょっと軽ければ魅力的だったのにとか思わざるを得ない。

 

 

Minisforum UM790pro

Ryzen9 7940HS搭載のminiPC。不具合がある個体をつかんでしまった報告がある中で、自分に届いたものはあまり不具合がなさそうだった。

「イヤホン端子からの出力を聞いていると音の出始めのタイミングでブチ音が聞こえる」という不具合がどこかのサイトで書かれていたが、それは音声出力の電源を不要なときにOFFにしているからONにしたタイミングでブチ音が鳴ってしまうのであろうと思う。自分はこれはそういうものだと思っているのであまり気にならなかった。

USB PDからの給電で動作するとはあまり思ってなかったし、動作しなかったというブログもみかけたのだが、自分のものは65WのACアダプタとe-Markerいりのケーブルで繋いでみたらちゃんと起動した。65Wだと自動的にCPUパワーが抑制される感じで、意外にちゃんと動くので凄いと思った。

RAM 64GBのモデルを購入して「この半分も使うことは当面ないだろうな」と思っていたが、KritaのStable Diffusion Pluginを動かしてみたら32GBをGPUに使われて「使われることがあるとは…」とびっくりした。

買ってすぐにUM780XTXが発売されてちょっと凹んだりもしたけど同じくらいの価格でCPUがグレードダウンしてWindows Homeになっていることを考えればまあそこまで落胆するほどのことはないかな。

 

Xiaomi SmartBand 8

買って1ヶ月、2週間に1回充電するペースで毎日つけている。歩数の心拍数と睡眠時間がわかるだけだが、とくに睡眠時間がわかるのは意外に嬉しかった。mi band 4と違って充電が楽なのもよかった。簡単に着脱できるようにしたくて金属ベルトを買ってたんだけどPCを傷つけそうなので平日は最初に付属していたやつを使っている。

 


 

去年と一昨年はほとんどコンピュータ的なものを買わなかったのだけど(去年はpi400だけだった)、今年はたくさんコンピュータを買った。M1, Gracemont, Zen4と新しめのCPUコアを使えているのは良いことだ。そしてこの中ではGracecmontのN100がいまいちだった。次のCrestmontもあまりアーキテクチャ的には変わらないんだがチップ全体の構成やプロセスルールとかで化けるのかもしれない。