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

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

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つのケースを分けて考えると整理しやすいと思います。

余談

---

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

結論

---

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

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

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

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