自分のサイトを作った

自分のサイトをプログラミングして作らないのはプログラマーとして問題なのでは？
ということで作った。

マグロにアグロ

サイト自体は年の初めくらいにほぼ完成していたものの、デザインがいけてなかったり良いタイトルが思いつかなかったりで放置してた。

4か月かかったこのタイトルだが、アグロとはTCG文脈での「序盤から高い攻撃力を出して速攻する」ような戦術のことで、タイトルは寿司屋で速攻でマグロを頼むという意味。美味いからね、マグロ。

ゲームもあるのでアクセスして遊んでね！！！！！

激遅25秋アニメ評価

新年から１ヶ月が経過しようとしていて、前クールの話の内容についてもだいたい忘れているわけですが、後からどんなアニメを見ていたのか振り返る際に記事にまとめられていた方が便利だと至り、25秋の話を書くことにしました。1ヶ月前に書けやというツッコミについては返す言葉は本当にないです。

25秋アニメ評価（見た範囲で）（左の方が強い）

• 5.0: なし
• 4.5: 機械仕掛けのマリー
• 4.0: 嘆きの亡霊、アルマちゃん、わたたべ
• 3.5: 異世界カルテット3、ユウグレ
• 3.0: 銀八先生

あとはそれぞれのアニメにちょっとずつ触れます。敬語も捨てます。ネタバレはありません。

このクールの主役はウマ娘もスパイファミリーだったはずだが見てなかった。だってニコニコで最新話無料の対象外なんだもの俺は悪くねぇ！見てたら4.0~4.5くらいに入ってたと思う。

これら主役を除くと機械仕掛けのマリーが一際輝いていた。話の閉じ方がものすごく綺麗で好き。面白かったけど、2期は蛇足なのでやらないでほしい。

嘆きの亡霊や異世界カルテットらへんのシリーズものも普通に良かった。嘆きの亡霊については文句なし。異世界カルテットは登場人物が多すぎて話を捌けていなかったのがマイナス。3期になって影実メンバーが追加され、影実は私が好きな作品の一つだが、参加しなかった方が全体としては良かったと思う。ファン向けのアニメなんで話の完成度を気にしてもしょうがない気もするけど。

クールの中で1つは欲しい枠、アルマちゃんは家族になりたい。安定して面白かった。

わたたべを一言で表すなら、「関係性の構造を楽しむ」アニメだと思った。構造や謎が明らかになるにつれ、その構造が詰んでいることが良く分かるし、だからこそ今後のキャラの行動が気になり惹きつけてきた。逆に構造が判明しない序盤はそこまでだったと思う。評価が難しいアニメ。

悠久のユウグレは......オリジナルアニメってやっぱ難しいんでしょうね、という感想。ラノベや漫画原作だと基本的に面白い作品がアニメ化されて品質が多少担保されるわけだが、アニオリだとこれらの段階を飛ばしてしまうので、面白くない作品が淘汰されない。やっぱりヒット作を書けそうな原案者なり脚本家なりを起用するしかなさそう。ひびめしスタイルこそ最強。

銀八先生はツッコミが酷かった。本編第100話でダメな例として銀さんに指摘されてたツッコミそのままだったよね。続編やるらしいけど大丈夫なんですかね...。

【感想/考察】(謎が)果てしなきスカーレット

果てしなきスカーレットの感想や考察を述べていきます。記事後半にはネタバレも含みます。

何故この映画を見たのかと言えば、それは何故わざわざジェットコースターに乗るのか、何故わざわざお化け屋敷に入るのかという問いと同じであり、つまりは怖いもの見たさであった。暇なんだと思う。YouTubeでは酷評に晒され、行きつけの美容院では、

「この映画の感想を聞くと皆さん『うーん』と黙ってしまうんですよ...w」

と言われ、逆に自分の目で確認したくなってしまった。

ちなみに果てしなきスカーレットを見てきたのは先々週の土曜日。前日の金曜の時点でも席は7割ほど埋まっており、前評判ほどのスカスカっぷりではなかった。

映画の感想に移ります。まずはありがとう。（これから殴りますという宣言）

CGはそこまで問題なかった

映像についてはまあまあ安定してた。多少CG臭がきついシーンもあったが、そこまで悪い箇所はなかったと思う。1週間以上経過して覚えてないだけかもしれないが、忘れるくらいには自然だったということで...

ただ海外ウケを意識した造形は気に入らなかった。ぶっちゃけ可愛くない。スカーレットは劇中殴られたり鼻血を出したりと無様に描かれるシーンがあったが、美醜の落差を感じられずあまり刺さらなかった。もっと萌え豚に媚びた造形にしていれば、売上も1割くらい上がったんじゃなかろうか。

声優もそこまで問題なかった

主人公のCVは芦田愛菜"さん"で、ところどころイントネーションに違和感があったが、全体を通してみれば悪くなかったと思う。でもまあ普通に声優使った方がもっと良かった気もするけど。

あと敵役のクローディアスのCV(役所広司)が良かった。これは手放しで褒められる。

ここからはストーリーに触れるため、ネタバレを含みます。

「『ここからはネタバレを含むわよ！』と注意をしてくれるウマ娘のダイワスカーレット」というプロンプトをnano banana(非pro)に投げた結果

謎1. スカーレットの生還条件

「許す」がこの作品の主軸であったように、「クローディアスを許したから死者の国から生還できた」というストーリーは自然に感じる。もちろんこの考え方を否定するつもりはないが、当サイトでは「仮にクローディアスに復讐したとしても生還できていた」説を提唱したい。

というのも、死者の国からクローディアスが消えたのち、あの謎の婆ちゃんはスカーレットに対して「時間切れ」という言葉を使っていた。「許したから」ではなく、単に「時間切れ」によって死者の国を去ったのではないか。

少し話は変わるが、スカーレットとクローディアスは合わせ鏡のような存在である。 スカーレットが叔父クローディアスへの復讐を望んでいたのと同様に、クローディアスもまたスカーレットの父であり兄である国王アムレットを処刑し復讐を果たした。国王として実権を握った後も反乱分子筆頭候補のスカーレットを生かし続けたのは、復讐に駆られる姪をかつての自分と重ねていたからではないだろうか。

ではスカーレットが叔父への復讐に囚われたまま生還し、国王の地位を授かっていたらどうなっていたか。恐らく憎き叔父と同じような、力で民を掌握し相互不信がまん延した国を運営していただろう。

この作品を語る上で最も重要な箇所は、死者の国でのくだりにはなく、むしろその後の所信表明演説にあるように感じた。死者の国で叔父を許したからこそ、民からの信頼を得られ、天気も国民の気持ちも晴れた。その許す/許さないの集大成が演説という形で表われていたと思う。

謎2. 渋谷のダンス

16世紀デンマークの王女は父を殺めた叔父に復讐をするべく死者の国を彷徨う中、現代世界から転生してきた聖と出会い夢に見た光景がこれ。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

　『 #果てしなきスカーレット 』
　　 プロダクションノート
　　＜３Dアニメーション編＞
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

渋谷のシーンでの後ろのモニターには、
わざわざさまざまな角度から撮影した
スカーレットが映っています。

本編では一瞬ですが、… pic.twitter.com/gU49im4h3R

— 【公式】『果てしなきスカーレット』＠スタジオ地図 (@studio_chizu) December 26, 2025

なんでやねん。

そもそもダンスがなんかチープ。聖も野原ひろしとジョイマンを足して2で割った感じ。あと視点の切り替えも少ない。1つのカメラを動かすだけってどうなんだ。スカーレットが楽しそうに踊っているのを見せたいなら、もっと顔に寄って笑顔にフォーカスしなきゃダメだと思う。あと周りの人ももうちょっと描いてあげて。

そもそも何故現代の渋谷で踊るのか。このシーンでスカーレットは、今とは違う自分、強引に換言すれば理想の自分を発見できたわけだが、観客の中で今の渋谷を理想郷と思える人は大変少ないのではないか。ハロウィンでは車が横転するし、JRの改札近くの通路でホームレスの方が寝てるし、イスラエルへの反戦デモが車をせき止めて一時一帯が渋滞してたし（その時現場にいた）。まあ渋谷でなかったとしても、現代日本を理想郷としてしまうと観客から白い目で見られるのは必至だろう。

何より面白いのは、この渋谷ダンスが仮に無くなってもストーリーの進行に特段の支障がなかったことだ。一応復讐以外の生き方を知らずに悩むスカーレットが楽しそうに踊る自分を見て今とは違う生き方を知るという意義がこのシーンにはある。ただ後半のストーリーに深く絡んでたかというと......。なんというか渋谷ダンスを入れるために生き方云々の話を持ってきたという印象を拭えなかった。

これは想像だが、ストーリーを改善するうちに不要になったが諸々の理由で映画に含めざるをえなかったのではないか。例えば、「渋谷再開発関連のステークホルダーに既に話を通していて今更変えられなかった」「既に莫大な資金を渋谷ダンスにつぎ込んでいて変えられなかった」とか。あとは売上面。

渋谷ダンス前後が不自然な流れになっていたことを監督自身もさすがに理解していると思う。そうでなければ、映画後半でこのダンスがもっと導線になっていただろうし、シーン自体ももっと気合い入れて作っていたはず。その上で捻じ込むだけの非ストーリー上の理由があったんだと思うが、まあこれ以上は邪推ですね。

謎3. デカい竜の正体

あのデカい竜は何なのか。なぜスカーレット達を助ける行動をとっていたのか。最後竜は無数の鳥として消えていったがどういう意味なのか。

なんとなく「神はお前らをみているぞ」と的なノリを主語を竜にして実装した印象を受けた。ただ、最後は単純に竜としての役目を終えて消えようとしたのか、それとも一羽一羽の鳥が国民というメタファーであり「民はお前たちを見ているぞ」的なノリで終わらせたかったのか不明。すいません、良く分からなかったっす。

謎4. 婆ちゃんの正体

他の人の考察も見てみましたが、分かりませんでした！いかがでしたか？

まとめ

• CGや声優も見られる程度には良かった
• 許す/許さないがこの作品のテーマで、最後の演説がその集大成だと思った
• 渋谷ダンスはカス
• デカい竜と婆ちゃんは何なのか分からん
  

冒頭に述べた「感想を聞くとみんな黙る」という美容院の人が放った言葉は意外と芯を食ってたと思う。明確な感動ポイントが存在せず、残された謎も解決されない。だがなぜか渋谷でダンスする。全く面白くなかったわけではないのだが、面白さよりは謎が勝る作品だった。

逆に言えば、謎解き気分で見に行く人にとっては楽しめる作品だと思います。是非この記事を参考にして、自分なりの考察にたどり着いていただければ幸いです。

【えいがさき感想】虹ヶ咲学園スクールアイドル同好会完結編第2章を観てきました

えいがさきを観るために、お台場まで1時間をかけて見に行った。お台場は虹ヶ咲学園の舞台でもあり聖地巡礼の意味合いもあるが、単純に上映時間の都合が良かったのがお台場を選んだ主な理由である。

既に公開から2週間が経過しており、どの映画館でも1本/日程度、その上朝8時とか9時とかに上映する映画館も多かった。ラブライブの、しかも虹ヶ咲を観るような人間がそんな朝早くから観に行けるわけないだろ。まあスパスタだったらギリ通用するかも、スパスタ好きは早起きできそうだよね逆に（再偏見）

そんな中、お台場の映画館はこれ。流石は聖地、1日に8本を上映する怒涛っぷりである。

東京テレポート駅では虹ヶ咲メンバーのパネルがお出迎えしてくれた。テンション爆上げだったのだが、駅を出た時点で上映まで残り10分程度だったので写真を撮るのは断念した。ちなみに帰りはゆりかもめ台場駅を使ったが、虹ヶ咲関連のパネルは置かれてなかった。現在進行形でコラボしてるのに...

🌈コラボ情報🌈#えいがさき 第2章×ゆりかもめ30周年記念コラボ開催決定🎊

期間：10/24(金)～ 12/25(木)

🌟ゆりかもめ30th記念 ニジガクデジタルスタンプラリー
🌟ゆりかもめ各駅フォトブース
🌟コラボ記念グッズ販売
🌟一日駅長イベント
🌟限定キッチンカー出店
など盛りだくさん🎉

詳細✅… pic.twitter.com/1pSheTiJe5

— 『ラブライブ！虹ヶ咲学園スクールアイドル同好会』【公式】 (@Nijigaku_movie) September 25, 2025

映画を見終わり、「せつあい良ぃ...」となった衝動で2人のアクリルキーホルダーを買った。俺は軟派なオタクだからよぉ、素直で性格が良い陽キャ目な女の子に夢見ちまうんだ

アクアシティの三階では映画館のものとは別の虹ヶ咲グッズが販売されていた。そこでアクリルスタンドが飾ってあったので撮ってきた。

今気づいたけど右4人に蛍光灯が反射してた。すまない...俺が写真とは無縁の人生を送ってきたばかりに...

あとは映画の感想です（ネタバレ含む）

• ポニテ+和テイスト衣装の栞子さん可愛すぎだろ...
• アプリが落ちただぁ？負荷テストさぼってんじゃねぇぞ
• 果林先輩が「侑には伝えるな。」の後に「愛たちにも言っといて」とさらっと言ってたのにスマートさを感じた。アニメの果林先輩にはこいつ賢いなと感想を抱くことが多い。
• ミアちゃんもお姉ちゃんに本心を伝えられて良かったねぇ
• 璃奈、お前それ犯罪だからな
• せつあい最高。「スクールアイドルを辞めたら優木せつなはいなくなる」と言うせつなに対して「スクールアイドルを通して中川菜々が優木せつなに近づいている」と。中川菜々が優木せつなを理想の姿として作り上げたわけだが、優木せつなも中川菜々を作り替えつつある。これを同じくせつなに作られた（=せつなに感化されスクールアイドルを始めた）愛さんが言うわけですね。アニメの頃から一貫しているが、スクールアイドルは自分を成長させるきっかけを与えてきた。ミアのように自覚がある場合もあれば、菜々のように後から変化に気づくことも。ニジガクメンバーは覚悟が決まりすぎているので前者が強調されることも多いが、後者のような救われ方も美しいなぁと思った。

ブログ名を変えた

 前のブログ名気に入ってなかったんすよ（）

...というわけで「雑多なブログ・フォン・あすらと」に変更しました。

ちなみに「フォン」は所有の前置詞で、ドイツ語版の"of"です。大学の第二外国語としてドイツ語を選択した経験が遺憾なく発揮されています。ちなみにドイツ語の数字はuns?(1), zwei(2), drei(3)までしか思い出せません。

「雑多なブログ・フォン・あすらと」もちょうど3つ目のブログ名になりました。投稿しない期間が長引くとなんかブログ名を変えたくなるので、今後変えないためにも投稿を頑張りたいなあと思います。なによりこれ以上数えられませんし。

個人的25春アニメ評価（アマプラ星基準）

アマプラの作品は、0.5点刻みで5点満点で評価される。

マイ基準はこんな感じ

• 5.0: 神。1年で2~3本程度の面白さ。
• 4.5: 傑作。自信を持って他人におすすめできるライン。
• 4.0: 良作。豊作のクールはこの層より上が厚い。
• 3.5: 普通。放送クールでないならわざわざ見る必要ないライン。ただし稀にめちゃくちゃ面白い掘り出しモノのようなアニメがある。
• 3.0: 凡作。これ以下は基本見ない。

個人的な2025年春アニメの評価はこんな感じだった

• 5.0: ひびめし、ジークアクス
• 4.5: WITCH WATCH、薬屋、ウマ娘 シングレ
• 4.0: にんころ、アポカリプスホテル
• 3.5: ざつ旅、ロックレディ

今日言いたいのはほとんどこれで、

ひびめしありがとう

いやー、のんのんびよりのスタッフが集まった時点で良い作品なのは確定的に明らか。最終話Xのトレンド1位おめでとう

ついでにジークアクスも面白かったよ

流れてきた岡田斗司夫の切り抜きはわりかし同意できた。曰く、「ギャグアニメのスピード感をシリアスなアニメに導入したことで面白さに繋がった」と。やっぱアニメ単体だと脳のリソースを余らせて退屈になるんだと思う。テンポ良く話を回すか、ニコニコでコメントと合わせて見るかしないと。

ただ俺は「二次創作」は割とキーワードな気がした。特にソシャゲの二次創作と相似形で、「ソシャゲの二次創作という概念をアニメに導入したことで面白さに繋がった」んじゃないかと内心思っている。

ほら、遊んでないソシャゲの二次創作見てキャラ覚えちゃうし、なんなら二次創作経由でソシャゲ始める人多いでしょ？なあ、ブルアカ。なあ、ゼンゼロ。おい何目を背けてるスタレ。お前もこっち側だからな。

1stガンダム未視聴であってもジークアクスを二次創作として楽しめる土壌はソシャゲによって既に養成されていて、だからこそガノタ以外も巻き込んだあの盛り上がりようになったんだと思った。特に根拠はないけど。

【Unity】アスペクト比を維持して固定値を使わずに整列させる

アスペクト比を維持して固定値を使わずに整列させる方法をなんと2つも説明します。

問題設定

まずは目指す状態について説明します。

上の画像では半透明の範囲に本の画像とその白背景のセットが2つ描かれています。また白背景は正方形で、本の画像はその中に収まります。つまり、本+白背景の縦横比は1:1になります。

整列の設定を上手く施すことで、中身を増減させても自動的に間隔を調整してくれます。実際私は、以下の画像を作る時に位置や大きさを入力しませんでした。

以降の章でこの自動整列の設定方法について解説します。

なお、この記事では横に整列させる方法を解説しますが、Horizontal←→Vertical、Width←→Heigh(t)と適宜変換すれば縦にも同様に整列させられます。

共通部分

自動整列を実装する方法は複数ありますので、まずはそれらの共通部分について説明します。

上の画像は本の画像と白背景のセットが2つある場合のヒエラルキーです。

上のヒエラルキーに登場するCanvas内のGameObjectが有するComponentを以下に示します。

• Area(親オブジェクト)
• Horizontal Layout Group
• 横に整列させるやつ。今回の主役
• Control Child SizeのHeighをTrueにして、子の縦の長さを親に合わせるようにする
• Child Force ExpandはいずれもTrueに
• Image
• 半透明なやつ
• GameObject 1(子オブジェクト)
• 今は何もつけない
• Background(孫オブジェクト)
• Image
• ただの白背景なので、Spriteは何も入れない
• Book(孫オブジェクト)
• Image
• 本の画像を挿す
• 画像の比を維持するため、Preserve Aspectをtrueに

これらに追加でComponentを加えるケースもあります。

Aspect Ratio Filterを子オブジェクトにつける方法

Areaに紐づける"Horizontal Layout Group"の"Control Child Size"のHeighがTrueになっている場合(上の画像)、子のオブジェクト(GameObject1)のHeightには何も入力できない状態になります。"Control Child Size"はその名の通り、子のWidthやHeightを親が決定するかどうかのフラグであり、Trueになると子オブジェクトに対するWidth/Heightの入力を受け付けなくなります。

子オブジェクトにてHeightが入力できない状態

本と白画像のセットの縦横比は1:1にするためには、Widthの値をHeightからコピーしてくる必要があります。そこで、子オブジェクトに"Aspect Ratio Filter"を適用します。

Aspect Ratio Filterはそのオブジェクトのアスペクト比を自動で決定するためのComponentです。Aspect Modeで"Height Controls Width"を選択すると、WidthがHeightの値から自動入力されます。このように設定することで、本+白背景を複製しても同じ親にある限り上手に間隔を作ってくれます。

しかし残念なことに、子オブジェクト以下をPrefab化してスクリプト上から複製すると自動整列が機能しません。Aspect Ratio FilterとHorizontal Layout Groupが共存すると発生する問題のようで、入力をロックする箇所が異なっていても動作しないようです(実際警告が出てる)。Aspect Ratio Filterが先にWidthやHeightをロックすることで後のLayoutGroupが動作できなくなり、機能しないのではないかと睨んでいます。Prefabから生成する場合は次の方法を試してみてください。

Aspect Ratio Filterを孫オブジェクトにつける

代替案として、子オブジェクトの代わりに孫オブジェクト(Background)にAspect Ratio Filterをつけることでも自動整列が可能です。その際、Aspect Modeを"Envelope Parent"に設定しましょう。Envelope Parentモード下では、元々設定していた孫オブジェクトの大きさを子の大きさによって拡大することが可能になります。

孫オブジェクト(Background)のComponent

上の画像ではW Deltaに82.79999と入力されています。これは親オブジェクトのHeightが182.79999で、元々設定されていた子オブジェクトのWidthが100であり、Envelope Parentによって引き伸ばされた分がW Deltaに入力されます。

この方法ではPrefabから生成しても自動整列が機能します。Aspect Ratio FilterとHorizontal Layout Groupが同じ箇所をロックすることもないので、警告も発生しません。

余談

自動整列問題がややこしいのは、WidthやHeightを画面の大きさに応じて変化させようとするからです。WidthやHeightに固定値を入力させられれば、Layout Elementなどを利用してもっとわかりやすく自動整列を実装できます。まずは画面のサイズを最初に決めて、WidthやHeightに固定値を入力させるのが良いと思います(一敗)。

まとめ

• XXX Layout Groupを親に設定して整列させる
• Aspect Ratio Filterを子か孫に設定してアスペクトを維持させる
• 画面のサイズは最初に決めよう

以上です。

【ゲーム製作】日◯簿記の問題集で家を確保するゲーム

日◯簿記の問題集で家を確保するゲームを公開しました！

URL: https://unityroom.com/games/boki-warashibe

よかったら遊んでください。（偉い人に怒られたら消します）

【プログラミング】ヘクス座標系でのマスの管理方法

 
こんにちは、あすらと（＠__asurato__）です。

モダンなゲームではあまり見かけなくなりましたが、大戦略やCivilizationのような戦略シミュレーションではヘクス座標系が採用されています。ヘクス座標系では1つのマスが正六角形になっており、正六角形の各マスは隙間なくマップに敷き詰められます。本日はヘクス座標系のマスの管理方法について考察しましたのでご覧ください。

ヘクスマップの例

前提

本記事では以下を前提としています。これらの前提が容易・高速に達成できるアルゴリズムが良い手法であるとここでは定義します。

• Tileクラスが各マスの情報を表す
• Tile型のインスタンスは配列や二次元配列に格納される
• マスが指定されたらそのマスに関するTile型のインスタンスを取得したい
• あるマスに隣接しているマスも取得したい

例えば tiles[id] 等でそのidに関するTile型のインスタンスを取得することができれば前の3つについて達成されます。言い方を変えると、関数f: id→Tile となる関数が作れるならOKです。

またマスXに隣接したマスYを取得できれば最後の項目は達成されます。前3つの項目によりidからTileへの変換は前提とするため、XのidからYのidが取得できれば達成されます。

以下からマスの管理方法について章立てで説明します。

並んでる方向にIDを振る手法（一次元）

すごく自然なIDの振り方で、右上のマスは+3、右下は+4と隣接マスも計算しやすいです。ただし以下のような上下で対称でないマップの場合、右上のマスはIDが+4 or +5され固定値になりません。

上下が非対称なヘクスマップ

このような場合はIDを振る方向を横に変えるとなんと解決します。

すごくない？

• 特徴
• 隣接マスのIDの取得が簡単
• 自然な発想
• メモリの無駄がない
• マップが長方形の場合のみ使用可能

二次元直交座標に変換する手法

一次元的にIDを与えるのではなく、二次元座標を用いて各マスを二次元配列に格納することもできます。座標[a, b]のマスはtiles[a][b]として取得します。

問題点として、tiles[0][0]とは異なりtiles[0][1]には値が存在しません。tiles[a][b]が存在するかを常にチェックする必要があります。

• 特徴
• 隣接マスのIDの取得が簡単
• 例）a→a+1、b→b+1で右下のマスを取得できる
• 全てのマップ系で使用可能
• 座標にマイナスの値が含まれるときは別途対処の必要あり
• 配列の戻り値がTileとNullの2種類があり、Nullチェックが必要
• 二次元配列のうち半分が死にマスとなり、メモリの無駄遣い♠️

二次元直交座標＋Map法

上の手法の派生系で、二次元座標を文字列に変換してMapに格納する手法です。ちなみにPythonのようにタプルをキーにできる言語や、座標を示す構造体をMapのキーに自前で設定する場合は文字列への変換は不要です。メリットはメモリの無駄がないこと、デメリットは座標とMapのキーとの相互変換が面倒な点でしょう。

• 特徴
• 隣接マスのIDの取得には座標とMapのキーとの相互変換が必要
• メモリの無駄がない
• 座標がマイナスを含む場合も対応できる
• 全てのマップ系で使用可能

二次元座標＋配列法

私が考えたイケイケアルゴリズムです。

まず上図のように軸を設定し座標を計算します。B軸の位置について、Aの要素が0以上になるように設定しましょう。

次に2つの配列を用意します。1つ目の配列には全てのマスが格納され、もう1つの配列には前者の配列のキー(ID)が入ります。

まず要素Aが小さい順に、要素Aが同値の場合は要素Bが小さい順にマスを配列１へ格納します。その格納の際に、要素B=0となるマスの（配列１における）IDを配列２に格納します。2つの配列を用いて、座標(a, b)のマスは arr1[arr2[a] + b] として取得できます。

• 特徴
• 隣接マスのIDの取得が簡単
• 例）a→a-1、b→b+1で右下のマスを取得できる
• ほとんどのマップ系で使用可能
• ただし間が空くマップ系だと「二次元直交座標に変換する手法」と同様にNullチェックが必要になる
• メモリの無駄がない
• 軸が斜めになっているので直感的ではない
• でも頑張れば直交座標でも使えそう

まとめ

• マップが長方形ならIDを縦or横方向に振る方法でよい
• 縦か横かはその時のマップの性質によって見極める必要がある
• 二次元直交座標＋Map法は任意のマップで使えるので、最終手段として検討しよう
• 二次元座標＋配列法はコードが少し難しくなるが色々効率的
  

参考サイト

http://higesusk.blog.fc2.com/blog-entry-146.html
https://ninagreen.hatenablog.com/entry/2015/11/14/193417
https://sinsei.space/blog/11747
https://www.redblobgames.com/grids/hexagons/

【Blogger】ラベルを階層化する

階層構造に、改装！w　こんにちは、あすらとです。

Bloggerでは記事に対してラベルを付与できますが、このラベルの機能はあまりリッチではありません。そこで、当BlogではBloggerのブログアーカイブのHTML構造を参考にし、比較的自然なラベルの階層化機能を自前実装しました。本日はこのラベル階層化の手順について解説します。

先に完成後のスクリーンショットを以下に載せます（まあPCなら横に表示されているとは思いますが念の為）。

ご自身のブログに同様の機能を実装したいと感じた方は是非最後までご覧ください。

---

まずBloggerはラベルの階層化機能を提供しておりませんので、HTMLを自分で編集する必要があります。「テーマ」→「カスタマイズの横の下三角」→「HTMLを編集」とクリックしHTMLの編集画面を開きます。

続いて、編集画面で「id='Label1'」で検索し、ラベルの機能を探します。（検索にない場合は元の画面に戻り、「レイアウト」からラベルガジェットを追加してください。）おそらく以下のように表示されていると思います。

最後に<b:widget...から次の</b:widget>まで以下のコードに差し替えて終了です。

  <b:widget id='Label1' locked='false' title='カテゴリ別' type='Label' version='1'>
    <b:widget-settings>
      <b:widget-setting name='sorting'>ALPHA</b:widget-setting>
      <b:widget-setting name='display'>LIST</b:widget-setting>
      <b:widget-setting name='selectedLabelsList'/>
      <b:widget-setting name='showType'>ALL</b:widget-setting>
      <b:widget-setting name='showFreqNumbers'>false</b:widget-setting>
    </b:widget-settings>
    <b:includable id='main'>
  <b:if cond='data:title != &quot;&quot;'>
    <h2><data:title/></h2>
  </b:if>
  <div expr:class='&quot;widget-content &quot; + data:display + &quot;-label-widget-content&quot;'>
    <ul class='hierarchy' id='rootNode'>
      <b:loop values='data:labels' var='label'>
        <li class='labelNode archivedate collapsed' expr:name='data:label.name'>
          <b:include name='myToggle'/>
          <a class='post-count-link' expr:href='data:label.url'>
            <data:label.name/>
          </a>
          <span class='post-count' dir='ltr'>(<data:label.count/>)</span>
          <ul class='hierarchy' style='padding: 10px 0 0 10px'/>
        </li>
      </b:loop>
    </ul>
    <ul class='hierarchy' id='templateElement' style='display:none;'>
      <li class='labelNode archivedate collapsed'>
        <b:include name='myToggle'/>
        <a class='post-count-link' href='javascript:void(0)'>LABEL_NAME</a>
        <ul class='hierarchy'/>
      </li>
    </ul>
    <b:include name='quickedit'/>
  </div>
  <style type='text/css'>
li.collapsed &gt; ul.hierarchy {
  display: none;
}
  </style>
  <script type='text/javascript'>
// 深さ優先探索でHTMLタグを形成する関数
function dfs(ul, obj) {
  for (const label of Object.keys(obj)) {
    let {node, children} = obj[label]

    if (!node) {
      const template = document.querySelector(&#39;#templateElement&#39;).innerHTML.replace(&#39;LABEL_NAME&#39;, label)
      node = new DOMParser().parseFromString(template, &#39;text/xml&#39;)
    }
    node.firstElementChild.addEventListener(&#39;click&#39;, () =&gt; onToggled(node.firstElementChild))
    console.log(ul)
    console.log(node)
    ul.appendChild(node)

    if (Object.keys(children).length &gt; 0) {
      dfs(node.lastElementChild, children)
      continue
    }

    node.removeChild(node.lastElementChild)
    node.removeChild(node.firstElementChild)
  }
}
// トグルがクリックされた時の関数
function onToggled(element) {
  element.parentElement.classList.toggle(&#39;collapsed&#39;)
  element.parentElement.classList.toggle(&#39;expanded&#39;)
  element.firstElementChild.classList.toggle(&#39;toggle-open&#39;)
  if (element.parentElement.classList.contains(&#39;expanded&#39;)) {
    element.firstElementChild.innerHTML = &#39;&#9660;&#160;&#39;
  } else { // 縮小する
    element.firstElementChild.innerHTML = &#39;&#9658;&#160;&#39;
  }
}
function main() {
  const treeObj = {} // 木構造を有するデータ
  document.querySelectorAll(&#39;li.labelNode[name]&#39;).forEach(node =&gt; {
    node.parentElement.removeChild(node) // 一旦DOMから消えてもらう

    // ラベルの名前をツリー状になるように登録する
    let obj = treeObj
    node.getAttribute(&#39;name&#39;).split(&#39;_&#39;).forEach((label, i, a) =&gt; {
      if (label in obj === false) {
        obj[label] = {&#39;children&#39;: {}, &#39;node&#39;: null}
      }
      if (i === a.length - 1) {
        obj[label][&#39;node&#39;] = node
      } else {
        obj = obj[label][&#39;children&#39;]
      }
    })
  })
  dfs(document.querySelector(&#39;#rootNode&#39;), treeObj)
}
main()
  </script>
</b:includable>
    <b:includable id='myToggle' var='interval'>
  <a class='myToggle' href='javascript:void(0)'>
    <span class='zippy'>
      &#9658;&#160;
    </span>
  </a>
</b:includable>
  </b:widget>

保存は忘れずに！お疲れ様でした！

【Rust】IteratorとVecの関数が多すぎ？

RustはC言語並みの実行速度、モダンな言語特有の安全性、堅牢な型システムを有するプログラミング言語です。

Stack Overflowの調査ではRustは最も愛される言語に選ばれましたが、Rust固有の概念や型システムは難解で言語の性能に比べて愛用者は少ない印象です。「好きな言語？まぁ、Rustかな。」と言った日には圧倒的玄人感で周囲を威圧させ、その眩き威光には流石の水戸黄門も平伏すしかありません。

そんな厨二病患者へのサポートも欠かさない言語、Rust。私も最近勉強を始めました。しかしサクッと競プロも問題を数問解いてみたところ、このような感想を持ちました。

Rustくん、君ねVecとIteratorの関数多すぎじゃないかい？反省してる？ねぇ？

— あすらと (@__asurato__) April 19, 2023

ということで検証しました。

Rust

Rustの関数の個数は以下でした。（手作業のため誤差があるかもしれません）

• Iterator: 75個
• Vec: 50個
• Array: 12個

やっぱりVecとIteratorの数が多いですね。これはRustがオーバーロードを実装していない点が原因の一つです。reduce関数とfold関数は顕著な例で、初期値の有無のみで2つの関数に分かれています。

続いてRust以外の言語の関数の数について紹介します。

JavaScript

• Array: 45個

（そうだよ！これだよこれ！）

JavaScriptのArrayはVecとIteratorの役割を同時に果たすことも相俟って、関数の数は少ないです。まあブラウザで動かし続けないといけないからね。そりゃ慎重にもなる。

Java

• Stream: 33個（オーバーロードの関数名重複ありで39個）
• List: 22個（オーバーロードの関数名重複ありで28個）
• Arrays: 17個（オーバーロードの関数名重複ありで155個）

155個！？

これは私の推測ですが、Arraysクラスの関数の多さはJavaが互換性を残しているためだと考えられます。binarySearch関数は全部で18個存在し、T[]のようなジェネリクス以外にint[]やdouble[]を引数として用意する徹底ぶり。

しかし、比較的新しいStreamクラスについてはRustに比して関数は少なく、Listクラスについても同様です。

C#

• LINQ(IEnumerator): 66個（オーバーロードの関数名重複ありで213個）
• List: 32個（オーバーロードの関数名重複ありで48個）
• Array: 32個（オーバーロードの関数名重複ありで94個）

さて私の愛するC#ですが、意外と関数が多い。競プロで使うくらいLINQ好きなんですけどね...

なんか雲行きが怪しくなりました。

Scala

さて、Pythonは組み込み関数だから比較は難しいし、あと触ったことがある言語は......Scalaかぁ。

• Collection: 150個

結論

疑ってすまないRustくん。君も多い方なんだろうけど......

あと今日からScala叩きに転身します。

P.S. Pythonのリストの関数は11個でした。

終わり

【ゲーム製作】ウサ娘 プリティラービー！

ゲームを作りました！その名も......

ウサ娘　プリティーラービー！

一発ネタですが、遊んでくれると嬉しいです。

【Civ6GS】難易度神の倒し方、知ってますよ

このタイトルだと倒せなさそう（小並感）

久々の投稿となります、あすらと（@__asurato__）と申します。本日はCiv6での難易度神の倒し方について説明します。特にまだ難易度神で勝利したことがない方は参考になると思います。目指せ†ゴッドスレイヤー†

私の実績

私が勝利した時の指導者と勝利方法は以下になります。

• ジョン・カーティン（オーストラリア）→外交勝利
• トラヤヌス（ローマ）→科学勝利
• ヴィクトリア（イギリス）→科学勝利
• ペリクレス（ギリシャ）→文化勝利
• トミュリス（スキタイ）→制覇勝利
• 赤髭王フリードリヒ1世（ドイツ）→科学勝利

プレイ環境については、ゲームスピードは速い、マップは小、地形はイギリスのみ大陸で他はパンゲアを選択しました。

科学勝利が多いですが、ローマやイギリスは頑張れば別の方法でも勝利できたと思います。スキタイについてはわざと宇宙開発プロジェクトを止めてようやく制覇勝利を達成しました。そのため必然的に科学勝利に寄った解説になってしまっていると思います（各勝利条件ごとの最適行動とか分からん）。以降で神の攻略法について章ごとに説明します。

仮想敵国を設定する

Civilizationシリーズは戦略シミュレーションゲームであり、文字通り戦略が重要なゲームです。Civにおいては自分の文明を勝利に持ち込むための方針が戦略にあたります。この方針がグラグラだと、意味の無い戦争をしたり、逆に戦争をせずにジリ貧で負けたりします。戦略を明確にするために「戦争するならこいつ！」のように仮想敵国を作り、その後で「こいつとは戦争したくない！」という文明と同盟を組むことをお勧めします。

仮想敵国の設定の観点について以下にまとめました。

• 自分と相手の都市の立地
• 自分と相手の指導者・文明特性
• 自分の文明の技術的優勢
• 自分が有する都市数や科学力・文化力

敵となる文明を決める上で最も重要なのが立地です。自分の都市の近くに出せるかどうか、忠誠心を維持できるかどうか、国境線が山脈で守られているかどうかを確認しましょう。例えば山脈で自国の都市への入り口が部分的に遮られていると、防衛の際に敵のユニットを各個撃破できる可能性が上昇します。逆に攻勢には手間取ってしまうかもしれません。この場合はお互いに戦争をするのが不利なので、積極的に同盟を組みたい文明だと言えるでしょう。

指導者や文明の特性を見極めるのも重要です。自分の指導者・文明が戦争に向くかどうか、他の文明が戦争が得意かどうかを確認しましょう。ただ個人的には指導者や文明の特性よりも立地の方が戦争を決定づける要因としては強いと思います。

立地や指導者特性を考慮しても敵となる文明を絞り込めないなら、より技術力が低い文明を敵とするべきです。逆に相手の方が技術力が大幅に高いなら、戦争は諦めましょう。また相手の方がちょっと高い程度であれば小手先のテクニックでカバーして領土拡張に努めましょう。むしろ十二分に都市数を繰り出せないことを恐れるべきです。

確か偉い人もこんな言葉を残していた気がしないこともありません。 

「戦争を恐れるな、ジリ貧を恐れろ。」ーーーーーアスラト・フォン・ミネストローネ 

 

また自分が十分な都市数を持っており高い科学力や文化力を出力するなら戦争をする必要がありません。従って仮想敵国を設定する必要もありません。ただ難易度が神にもなるとこのようなケースは稀です。特に非戦で科学勝利を狙うのは難しいので積極的に戦争しましょう。

戦争を仕掛けるタイミングを考える

戦争にベストなタイミングは相手よりも自分の方が有利なユニットを使用できる時です。例えば弩兵を量産して戦争を仕掛けた時に、相手が弩兵を研究し終えていなかったら、一方的に蹂躙できます。以下のユニットは早めに研究・量産することをお勧めします。

• 弓兵
• 弩兵
• 野戦砲
• 戦車
• 爆撃機
• 自文明の固有ユニット（強いなら）

敵とする文明が他の文明と戦争をしている場合があります。その際はその文明に乗っかり、敵文明に二正面作戦を強いると良いです。自国が戦争を準備している最中に和平されないよう、開戦から８ターン以内に自文明も攻撃を開始するのが望ましいです。

注意点として敵の固有ユニットの時期が攻撃のタイミングと重なる場合は他の時代より苦戦する可能性があります。またアップグレードにより新しいユニットを調達する場合はアップグレードに必要な金額が半額になる政策をスロットに入れましょう。ただし投石兵→弓兵と弓兵→弩兵の場合はこの政策の取得が間に合わない可能性が高いです。

ハイキング中に出会ったCiv6プレイヤーも確かこのように言っていたように思われます。

「大量生産した弓兵は捨て駒にし新たに弩兵を生産するのもまた一考に値する。」ーーーーーアスラト・フォン・カルボナーラ

都市国家を喰らう

都市国家に囲まれた立地の場合、都市国家が領土拡張の邪魔になる場合があります。基本的には容赦無く侵略して構わないのですが、条件があります。

• 科学重視・文化重視の都市国家ではない
• 仮に宗主国になれなくても科学力・文化力のボーナスが美味しいから
• その都市国家の宗主国が以下のいずれかであること
• 宗主国がいない
• 宗主国とは友好宣言等により戦争にならない
• 宗主国と戦争してもよい
• 宗主国ボーナスが強くない
• 強いなら宗主国を目指すべき

都市国家への侵攻のタイミングは弩兵（中世）〜複葉機（近代）の間が良いと思います。この時期には相手の文明の都市に防壁が建設されており、攻囲ユニットが必要になります。しかし攻囲ユニットは防壁の長距離攻撃の的になり、侵攻に苦戦する場合があります。この問題は航空技術の解禁による攻囲ユニットの射程を伸ばす支援ユニットの導入により解決できます。でもこの時期に全く領土拡張しないのは勿体無い......ということで、他文明の都市と比べ都市の防御力が低い都市国家に侵略することで軍事力を文明の成長に繋げられます。

戦力を多めに作る

難易度神に挑戦した人なら突然宣戦布告を受けた経験があると思います。その後、弓兵の大量生産で戦争を凌ぎきってしまった人も少なくないと思います。このような経験から、過去の私のように必要最低限の軍事ユニットしか生産せず、毎回のように宣戦布告を受ける人がこの記事の読者の中にもいるかもしれません。

知っておくべきなのはCPUは真の軍事力ではなく、数値としての軍事力を参照し宣戦の布告を判断することです。中身が弓兵なのか戦士なのかは軍事力としては（おそらく）区別されません。そのため攻撃しても反撃されない長距離ユニットを保有するほど、真の軍事力と数値上の軍事力は乖離します。CPUは自他の数値上の軍事力を参照し、数値上優勢であると判断すると宣戦布告に乗り出します。

数値上の軍事力は赤枠の箇所からわかる

この問題への対策は単純で、大量のユニットをあらかじめ生産しておくことです。たくさん生産すればその分数値上の軍事力が上昇し、戦争の確率を減らせます。軍事力の目安は周辺の文明と同程度、最低でも３分の２は確保するようにしましょう。体感になりますが、相手文明の軍事力が自文明の倍以上になると宣戦布告を受ける確率が高くなる気がします。職人技（文化ツリーの最初の分岐を上に進んで得る政策）を使ってユニットを効率よく生産しましょう。また軍事力増強の際に傭兵のひらめき（陸上ユニット数が８以上が条件）を確保しておきましょう。

都市は少し疎に

「都市数を多く出せ」という主張がCiv6の攻略記事によく見られます。私はこれに賛成です。しかし「都市数を多く出すために都市を密に作れ」という立場には賛成しません。科学勝利には都市の生産力が高いほど有利になるため、生産力が強い場所を自分の都市同士が取り合う状況は好ましくありません。文化勝利の場合は劇場区域をたくさん置くために密の方がいいのかもしれませんが......

私は５マスを都市の間隔の目安にしています。都市間が５マスなら市民の配置箇所の受け渡しが簡単で、区域を建設するスペースも十分あります。また沿岸部などで区域を建設するスペースが少ない場合は６マスくらい空けることもあります。好みの問題かもしれませんが、迷っている方は参考にしてみてください。

商業ハブは弱い

私が商業ハブが弱いと考える理由は以下の3点です。

• 自分で稼ぐよりCPUが生み出すお金から徴収する方が稼げる
• 灯台や造船所と政策による生産力の増加が強い
• お金を稼ぐという点で交易商が強くなるタイミングが遅い

難易度が神になるとCPU文明が出力する生産力やゴールドが倍になるため、高級資源や戦略資源を売って稼ぐ方が手っ取り早い場合があります。中世あたりからでも高級資源は1つ11ゴールド（30ターン）で取引される時もあり、ゲーム後半の交易商の半分ぐらいの出力を期待できます。また馬や鉄などの余らせがちな戦略資源は、特に同資源を相手が保有していない時に高値で買い取ってくれます。ゲーム後半であればスパイを使ってゴールドを奪取する方法も有効です。お金を自力で調達するのではなく領土を広げ新たに得た資源を輸出することで、CPUの出力ボーナスでさえも自分の文明に利用できます。

交易商のために市場（商業ハブの建造物）を建設する人も多いかと思われますが、交易商は灯台（港の建造物）を建設することでも上限を解放できます。港はお金を稼ぐ以外の能力も優秀で、灯台は交易商と住宅の増加が、造船所（港の建造物）は都市の生産力の向上が可能です。またベテランという政策では港と兵営＋その建造物に対する生産力を向上、統合宇宙機構という政策では士官学校（兵営の建造物）や港湾（港の建造物）がある都市での宇宙開発競争プロジェクトへの生産力を向上でき、これらも非常に強力です。港の建設のデメリットはそもそも沿岸部への都市出し自体が弱い点ですが、湖に港を建設する場合は港の強さをフルに享受できます。ちなみに私は湖から真水を引く場合は必ず港を建設しています。商業ハブの代わりに港を建てることを検討してみてください。

高名なインフルエンサーもこう言っていたとか言わなかったとか。

「片思いとは商業ハブと交易商の関係と同じである。つまり商業ハブに交易商は必要不可欠だが、交易商は商業ハブを必要とはしないのだ。」ーーーーーアスラト・フォン・フォッカチオ

また交易商はゲームの前半と後半で使い方が異なります。ゲームの前半では開拓したばかりの都市から出発させ、食糧や生産力の都市への提供と道路の敷設が一般的な目的だと思います。ゲーム後半でこそ大量のゴールドを交易商から得られますが、ゲーム前半では微々たるもので、お金を稼ぐ目的なら序盤に交易商を作ってもあまり機能しません。一方でゲーム終盤ではスパイを利用することで交易商以上にゴールドを生産することも可能です。交易商が効果的に機能する場面は意外と少ないのではないかと考えてます。

以上までで商業ハブをディスってきましたが、全く不要なわけでもありません。都心を川と海の両方に隣接させ港と商業ハブと都心を三角形状に建設することで、港と商業ハブの隣接ボーナスは合計+8も得られます。それに加え総督レイナの能力で港と商業ハブの隣接ボーナスを2倍にさせたり、研究の自由という黄金時代の公約により港と商業ハブの隣接ボーナスを研究力に変換させたりできます。そもそも近くに海も湖もない場合は港を建設できませんから、あくまで商業ハブを建てる優先度が低くなるだけだと認識してください。意見が分かれそうですが、私は優先度について「キャンパス＞＞＞劇場広場＞商業ハブ」くらいの気持ちで区域を建設しています。

マルチプレイの戦い方とは違う

相手がCPU（難易度神）か人かでは理想とする動き方がかなり異なります。例えばマルチプレイではコロッセオという6タイル以内の都市の快適性を向上する遺産は奪い合いになるほど人気ですが、難易度神の攻略ではCPUから安価で高級資源を調達できるため重要視される遺産ではありません。他にもマルチプレイでは戦争を前提としていたり中世での黄金時代が必須とされていたりしますが、必ずしもこれらを守る必要はありません。マルチプレイの実況動画を難易度神の攻略の参考とする場合は気をつけましょう。

......と得意気に語ってきましたが、一緒にCivをやる友達なんて存在するはずがないので当然マルチプレイ未経験です。あくまで参考までに。

その他

• 最前線都市は防壁優先
• 真水を得られるなら高級資源の上に都市を出すことも考える
• 高級資源の上に都市を敷いてもその高級資源は獲得される
• 灌漑が必要な高級資源は灌漑の研究が遅い分有利
• 特に砂糖は強い
• 蛮族は早めに潰す
• 文化勝利しそうな文明から傑作を買いまくる＆スパイで盗む
• ルール地方は科学勝利にすごく役に立つ
• ルール地方＋マグナスの垂直統合で生産力200とかにできる

まとめ

全体をまとめると、正しく戦争し領土を拡張することが重要で、そのために方針を定め戦力を確保しようというお話でした。人により好みが分かれる箇所もあるかと思いますが、ぜひ参考にしてみてください。最後はあの方の言葉で締めようと思います。

「すき焼き食べたい」ーーーーーアスラト・フォン・マルゲリータ

終わり

ブログ名称変更とTwitter垢作成

ブログ名称変更とTwitter垢作成しました。

ブログ名変更の理由は「アスラト」という名前の人が居たり居なかったりしたからです←謎

まあ元々の「アスラトの雑多なブログ」も雑な名前だったので変える機会になって良かったかも。
今回のブログ名「明日の空は曇り時々晴れ」は「あすのそらはくもりときどきはれ」と私の名前を散りばめてシャレオツにね。

ついでにTwitterのアカウントも作成しました
https://twitter.com/__asurato__

2020年秋アニメ感想

まだ全て最終話まで見てないけど秋アニメの感想を述べていきます。

覇権: 虹が咲, 呪術廻戦

個人的に好き: スト魔女RtB, 安達としまむら

安定枠: おちフル, 魔王城, 魔女の旅々, ひぐらし, ごちうさ, 無能なナナ

語りたい枠: シグルリ, 神様になった日

ラブライブ！虹が咲学園スクールアイドル同好会

---

全員可愛い。これだけでもう強い。最初はせつなちゃんが一番可愛いと思って見始めたのに、結局個人回毎に別の女の子に目が移ってしまった。

加えてテーマも分かりやすかった。ライブという目標は共有するが、ライブの方向性は譲られることなく解散。しかし全員が同じ方向に走るのではなく、個々にステージに立つことで解決（アイドルものなのに！）。個別回もよかったのでダレることなく面白かった。毎回神回。

呪術廻戦

---

漫画の方を見てないけど原作激強なのがアニメで伝わってきた。登場人物の頭のキレの良さが他のアニメと一線を画してる。作者絶対頭良い。

戦闘シーンも群を抜いていたし、笑わせるポイントみたいなのとマッチしてたし、これ以上望めないよなぁ。次クールも期待。

ストライクウィッチーズ ROAD to BERLIN

---

ニコニコで見てるんですけどどうして再生数少ないの；；民度良いのに；；

今期はバルクホルンの良さが際立ってた感。ベルリン奪還で焦っているかと思いきや、意外と余裕があったのが印象的（特にシャッキーニ回）。戦闘部分もさることながら、テンポやネタ回も良かった。原作者のツイッターも合わせてご覧ください。

安達としまむら

---

最初は期待してなかったけど、週を経る毎に次の回が楽しみになった枠筆頭候補。安達が女の子としての可愛さを存分に発揮してて、やっぱ鬼頭さんやるなって。

あと視聴中、俺はしまむらなんじゃないかなって見てた。普段アニメに感情移入しないけど、今回はしまむらを自分に重ねていた気がする。これはみんな思った（そういう構成になっているから）と思うんですけどどうですかね。

（でも周りは俺のことを安達側の人間だと認識してるんだろうなぁ）

おちフル, 魔女の旅々, 魔王城, ひぐらし, ごちうさ, 無能なナナ

---

この辺りは全話安定してたけど覇権とは呼べない、特におちフルはさせてはいけない。おちフルに登場した女の子は可愛いがしっかり頭もおかしい。主人公を一言で表すと、尿素と百合の花が香るアイドル！衣乃ちゃん可愛い！まあ僕ははゆちゃんが一番好きなんですがね

魔女の旅々は鬱回がきつい人も多かったらしいけど、個人的にはあんまり気にならなかった。ただ点を稼いだのは間違いなくサヤちゃん。やはり百合は正義。

魔王城はあの設定で良く最後まで話を重複させずに来れたよなぁという印象。ニコニコで放送してくれれば良かったけど......

ひぐらしは古参に向いたアニメだった気がする。ただ僕はひぐらし系初見でも楽しめたのでヨシ！あとニコニコのコメントは切っておこう（戒め）。

逆にごちうさはコメントがプラスポイント。求めていたクオリティ安定して提供してくれたので良かった。チノのお母さんについて意外と重い背景を垣間見た気がする。あとで調べる。

無能なナナは少年誌っていう感じがした。あと主人公は「しまった」言い過ぎ。

以下ネタバレと、批判があります

戦翼のシグルドリーヴァ

---

随伴機損耗率９９％から死神と呼ばれた主人公が転属先でおもしれー仲間と一緒に敵を倒すというのが1話の方向性でした。ただそれ以降普通に仲間で結束して敵を倒しているので、主人公の死神設定いるぅ？とどうしても思ったし違和感が離れなかった。思うに死神という設定は「仲間と結束して倒す」ためではなく、主人公が「死についてどう向き合うか」に活用されるはずだったのかなぁと。敵は復活可能で死を軽視している存在だし、3話らへんのワルキューレが仲間を看取るところもここから来てるのでは。友情ではなく死ぬことに着目してれば化ける可能性があったと思う（雰囲気に合うかは別）。

死ぬことに関して3人がどう思っているかと妄想してみるとこんな感じ

アズズ→戦局全体を考えて、自分(非有能)を犠牲にしても有能なやつは助ける

ソノカ→目の前で死なれるのは我慢できないので、自分を犠牲にしても誰かれ構わず助ける

ミヤコ→仲間がピンチな時は仲間を信じてやられる前に敵を討つ

んで、例えば園香があずずを助けた結果入院したとして、

あずず「私なんかよりお前が生きていた方がよっぽど多くの人を救える。だから私のことは見捨てろ」

園香「アズちゃんの分からず屋！」

的な。

一方で味方がことごとく有能だったり、戦争しているのにどこか柔らかい雰囲気だったのは製作陣の強い意志を感じた。女の子は可愛かったし、ラストに向けて熱い展開になってきたのも評価。あとOPは今期で一番好き。加点/減点が激しい作品だと思った。

神様になった日

---

主人公がアホとか、無茶な展開・ご都合主義とか散々に言われ、最終的に作者のツイッターが削除されるという。追撃を仕掛けるようで申し訳ないけど、他の誰も言って無さそうなので一つ。

何話目か忘れたけど、「量子力学、〇〇学、〇〇学、言語学に精通している博士なら量子コンピュータも作れたかもしれません。」みたいな会話があった（細かい部分は忘れた）。問題は言語学が完全に不要なところ。多分ひなを会話させるために言語学という言葉を含めたと思うんだけど、その会話内容自体はソフトウェアに依存するはずで量子コンピュータとは無関係。今回の量子コンピュータがすごいのはハードウェアと脳と接続する部分でソフトウェアがすごい訳ではないはず。ハードウェアとソフトウェアの区別ついてる？とすごい疑問になった。

3話目までのギャグは結構好きだったんですけどねぇ。どうしてこうなった。

【朗報】卯月コウ、３D化

最近.....もとい半年以上、卯月コウというVtuberにはまっています。

そんな彼も3D化へ。何をするのかちょっと楽しみ。

【🎉卯月コウ 3Dお披露目配信決定！！】

卯月コウ(@udukikohh)の、3Dお披露目配信日が決定いたしました！

≪ 12/16(水) 21:00 ≫ 配信開始！！

🌙待機場所はこちら▽https://t.co/wnzdr9O1rT
ぜひ「リマインダーを設定」に！お見逃しなく！#卯月コウ3D　#にじさんじ3Dお披露目 pic.twitter.com/E0TrTdIbpO

— にじさんじ公式🌈🕒 (@nijisanji_app) December 9, 2020

ところで卯月コウはことある事に何かに歯向かっている気がします。納豆ASMRはリスナーに大量の低評価をもらっていました。初期の頃は葉っぱネタを擦っていましたが、これはYoutubeに喧嘩売ってますね。後は案件をくれたマジカミの運営とかにも。やっぱり卯月コウは何かに叛逆せねば存在し得ないキャラなのだと感じます。

さて彼の3D配信では一体何に叛逆してくれるのでしょうか。

リスナー？いちから運営？Youtube？

私としては卯月コウは卯月コウに叛逆して欲しいと思っています。

ハードル上げるようで申し訳ないけど、彼自身を裏切るような彼らしさを見せてくれることを期待しています。

【数学】確率の収束のイメージをあなたに

こんにちは。アスラトと申します。今日は確率の収束をわかりやすく解説したいと思います。

なぜ執筆するに至ったかというと、「数学苦手なので皆さんの味方です^^〜」という顔をしつつ、長ったらしい文章だけの記事を駆逐するためです。

対戦よろしくお願いします。

仮定

---

こんなお話を考えてみましょう。

ある日天才陽キャ魔術師のアスラト君の元にとあるYoutuberからの依頼が届きました。

「『25mプールを全部海水にしてみた』っていうドッキリしたいんすけど、用意できやす？w」

アスラト君は「う、うぇーい...」と返答し、報酬金を得るべく早速仕事に取り掛かりました。天才陽キャ魔術師のアスラト君は特殊な転送スキルを持っていて、1回の操作で海からランダムに場所を選んでその地点の海水をバケツ一杯分だけプールに転送できます。この時プール中の塩分濃度はどのように変化するでしょうか。

海水を転送した場所によって塩分濃度の推移が大きく左右されます。海全体の塩分濃度は3.4%になりますが、遠洋ならそれより高く、逆に河口付近が選ばれたなら0%付近になります。

そして超重要事項として「海水転送前後で残された海水の塩分濃度は変化しない」という点があります。つまりバケツ一杯程度の海水が消えたところでその近くの塩分濃度はほとんど変わらないよね！ということです。

あれれ......？

---

しかしアスラト君はバケツ100杯分の海水を入れ終わったところで大変な事実に気づいてしまいました。なんとプールの塩分濃度が2%しかないのです！これじゃあ真水でカサ増ししたのではないかと陽キャ達からあらぬ疑いをかけられてしまいます！アスラト君の運命や如何に！

結果

---

作業は全然終わっていませんが、なんと最終的には確率の収束によってプールの塩分濃度は3.4%付近になると考えられます。

ただあまり知らない方からすると確率の収束にはこのようなイメージがあるかと思います。

こちらは正しくありません。なぜなら転送予定の海水の塩分濃度が3.4%を大きく超える(3.75%)ためです。これは「海水転送前後で残された海水の塩分濃度は変化しない」ことに反します。新しく転送する海水も期待される塩分濃度は3.4%でなくてはなりません。

正しいイメージはこちらになります。確率の収束は期待される塩分濃度の向上によってではなく、期待される濃度は同じだがその圧倒的な量によって予定に近づくものです。そのため確率の収束にはたくさんの回数が必要だと言われています。実際プールの容積はバケツ6万杯ぐらいなので100杯程度で偏っていても問題ありません。

別の話

---

上の2つはくじの引き方の関係に似ています。

上側が引いたくじを戻さない場合、下側は戻す場合になります。上側では1回目を外すと2回目の確率は1/2となり1回目よりも大きくなります。これは確率の収束の誤ったイメージの例と似ています。確率の収束とは1回目よりも2回目の方が確率が大きくなる事で期待していた結果に近づくこととは別物です。この2つのケースを分けて考えると整理しやすいと思います。

余談

---

上記まで確率の収束とは、確率変数の収束や確率収束という意味で使用させていただきました。上で述べた混乱の原因って確率の収束という言葉にあると思うんですよね。だって予定に合わせて確率が変動しそうですもん。実際には確率は変わらずとも成立します。したがって確率の収束で確率は収束しないのです！

結論

---

確率の収束とは、確率の変動とは関係なしに、試行回数を増やすと予定した結果に近づく法則のことです。

余計に分からなくなったら申し訳ないけど中和ではなく希釈って感じです。以上！

ここまでの説明で理解できたのは元々数学ができる人なのでは......ボブは訝しんだ

色々不明瞭な部分もありましたので気が向いたら記事を改良します。

乖離性ミリオンアーサーサービス終了；；

高校２年生の時の思い出が終わってしまった；；
これでミリオンアーサーシリーズのソシャゲ全滅かぁうーん

私の記憶が正しければクリスタル175個で9800円だったはずなので12万円分持ってたんですかね。最近はあんまり配ってなかったけど２周年目くらいまではログインだけでもめちゃくちゃ石を配ってた印象。それ自体が衰退の一因な気がするのでもどかしいけれども。

こんな感じでオフライン版を残してくれたのはまじ有能。

【即日追記】

伝えたかったことを忘れてた。

実は「アスラト」という名前は「アストラトエレイン」が元ネタ。最初は５文字目以降除いた「アストラ」で活動しようとしたら予想以上に使われていたので「アスラト」に変更。「アストラトエレイン」ってめちゃくちゃ響きが良くて好きなんですよね。少女漫画チックな絵も珍しかったので印象にも残ってます。

RPGが好きなレベリングが好きな人

皆さんはRPGが好きな人ですか？ちなみに私はRPGが好きな人です。

本記事ではこのタイプのゲームが好きな人の傾向と対策について私の経験から述べていきたいと思います。
傾向という謳い文句を聞くと性格診断とかを思い浮かべる人がいるかもしれません。
以下が某サイトのRPGが好きな人の恋愛傾向になります。(なぜ恋愛)

ロールプレイングゲーム（RPG）
『ドラゴンクエスト』のような長時間かけてレベルを上げたり、アイテムを集めたりしながら根気よくゴールを目指すRPGを好きな人は、物事の『過程』を楽しむタイプ。恋愛においても、日々のデートやメールのやり取り、プロポーズをするまでの準備期間などをワクワクしながら過ごす性格です。また、先の展開が読めないRPGを好むという好奇心旺盛な一面もあるので、何気ない日々に楽しさを見つけて、一緒にワクワクしながら過ごせるポジティブな異性を求める傾向があります。

疑問なのが太字の部分。
まるでレベリングは世間から嫌われているみたいじゃないですか。

俺は大好きなんだよ！レベリングが！

もっと詳しく言うと自分のステータスや武器性能といった数値が上昇するのが楽しい。
逆にボスの撃破とかはそこまで興味がないですね。工夫して倒しても順当に倒しても数値に何の変化もないですし。

ここで私の感性を伝える為に「楽し〜ポイント」を図解したいと思います。

「RPGが好きな人はボスを倒す為に苦痛なレベリングをする」方とは性質が異なることがご理解いただけたと思います。(ほんまか)
「RPGが好きな人は過程を楽しむ」っていうのもレベリングそれ自体が目的なので、過程を楽しむタイプと言われるとうーん。
道中は全て過程で細かい目的の集合自体が過程になる人がいるとも言えなくはないのですが......ねぇ。

さて今回の主張はこれからです。
私のようなレベリング自体も好きな人は現実の世界でも自身の能力の数値化をすることを心がけるべきだと思います。
例えばダイエットをしたいなら、ダイエット器具よりも体重計を買うべきとか。
筋肉をつけたいならダンベルより握力計?の方が良いとか。色々。

特に私に近い人は能力や成果を可視化してみると何か変わる...かもしれません。お試しを。



実は私、運動ができず勉強はできる方なのですが、これは短期的に成果の可視化されたからかもしれません。
勉強って頻繁かつ明確に自分の立ち位置を点数化されますが、運動はそうはいきませんし。
学校の体力測定の成績表を見ると結果は散々ですが数値化されていて結構好きです。
ん？成績？高3の1500m走の全国偏差値が28になります。対戦よろしくお願いします。

【C#】競プロ用にSegmentTreeのライブラリを作ったよ！

SegmentTreeってセグメント木とかセグ木とか色々に呼ばれているので検索するの苦労しません？
あなたはどのワードでここに辿り着きましたか？

先にコードを載せます。超普通のセグ木になります。

using System;
using System.Collections.Generic;
using System.Linq;

namespace Library
{
    public class SegmentTree<T> where T: struct
    {
        private readonly T[] data;
        private int size = 1;
        private T defaultValue;
        private Func<T, T, T> function;

        public SegmentTree(int size, T defaultValue, Func<T, T, T> function)
        {
            while(this.size < size) this.size *= 2;
            this.defaultValue = defaultValue;
            this.function = function;
            data = Enumerable.Repeat(defaultValue, this.size * 2 - 1).ToArray();
        }

        // [a, b)
        public T RangedValue(int a, int b) { return RangedValue(a, b, 0, 0, size); }

        private T RangedValue(int a, int b, int now, int l, int r)
        {
            if (r <= a || b <= l) return defaultValue;
            if (a <= l && r <= b) return data[now];

            return function(RangedValue(a, b, now * 2 + 1, l, (l + r) / 2), RangedValue(a, b, now * 2 + 2, (l + r) / 2, r));
        }

        public T this[int index]
        {
            get
            {
                return data[size + index - 1];
            }
            set
            {
                index += size - 1;
                data[index] = value;
                while (index > 0)
                {
                    index = (index - 1) / 2;
                    data[index] = function(data[index * 2 + 1], data[index * 2 + 2]);
                }
            }
        }
    }
}

以下工夫した点

• Genericsの型であるTに値型の制約を与えた
• indexによるアクセスでより直感的に
• ぐう短い