プリグラ（プリコネ！グランドマスターズ）で少し話題になったMagicOnionを試しに使ってみたいって方が環境構築するときに参考になれば幸いです。結構二番煎じだと思いますが、まだMagicOnionの文献が少ないので少しでも貢献できればいいな。

はじめに

MagicOnionは、アプリとサーバーをC#言語で統一しgRPCでつないでしまおうという通信フレームワークです。

何でC#言語かというとUnityがC#ってのが影響力大きいと思います（ただUnityのC#は「Unity独自のC#」なので厄介な問題があるんですけどね）。

Unityで使える貴重な通信フレームワーク（他には最近だと開発途上のNetcodeなど）なので詳しく知りたいという人はかなり多いと思いますし、最近は確実に企業での採用実績も増えてきています。

ただMagicOnion、環境構築が少しクセがあります。

アプリとサーバーを共通化する以上、環境構築の際に必要な知識もアプリ側、サーバー側と、今まで別々に担当者が分かれていた両面必要になるので、そこが曲者となってきます。

この記事では、その辺りも踏まえて解説していこうと思います。

ディレクトリ構成の完成予想図

まず最初に全体像を見てもらった方が分かりやすいかな。

MagicOnionは共通化という概念の自由度の高さから、各々のプロジェクトの都合に合わせて様々な構成を作ることができます。

逆に言えば千差万別になりやすく、それ故に初学者が目標を見失いやすい部分があります。

分かりやすさ重視として、私は今回こんな感じのディレクトリ構成にしました。

オレンジ：Unityプロジェクト
赤：アプリ側
黄緑：サーバー側

MagicOnion2というひとつの大きなUnityプロジェクト（3Dテンプレート）の中に、サーバー用のフォルダが内臓されている形になっています。

サーバー用のフォルダ（Server）をUnityプロジェクトの外に出して管理することも出来ますが、今回は分かりやすさ重視で。

この完成形を目指して環境構築を始めます。

Unityプロジェクトの作成

アプリ側の環境構築から行きますね。

Unityプロジェクトの作成については特に不要かと思いますが、UnityHubから「新しいプロジェクト」→テンプレート「3D」→エディタバージョン「2021.3.0f1」を選んでプロジェクト名（私のはMagicOnion2）を指定して「プロジェクトを作成」って感じです。

※今回はUnity2021での動作確認もかねていました。

プロジェクトが作成出来たら、プロジェクト設定を少し変更する。

API互換性レベルを「.NET standard 2.1」から「.NET Framework」に変更する。
（理由についてはアプリ実装の部分で解説します）

他所様では「スクリプティングバックエンドをIL2CPPにしなさい」ってあったりしますが、今回は不要です。

IL2CPPはC#をC++として変換する仕組みで、iOSビルドなどに必要になります。
（通常はMonoというUnity独自の.NET互換C#コンパイラを使います）

MagicOnionはC#で出来ているので、IL2CPPで構成する場合は同じようにC++変換する作業が必要です。その場合、コードジェネレーター（moc.zip）を使う必要があり環境構築が複雑になります。・・・ので、今回は使いません！

気付いた方もいらっしゃると思いますが、「スクリプティング ランタイム バージョン（Scripting Runtime Version）」という項目が無くなっています。

以前はそこで「.NET 4.x Equivalent」などを選択する必要がありましたが、Unity2019から「.Net3.5」が無くなったので項目が無くなりAPI互換性レベル（Api Compatibility Level）に統一されました。

つまりAPI互換性レベルを「.NET Framework」にしておけば、「.NET 4.x Equivalent」を選択するのと同じになります。

MagicOnionをプロジェクトに追加

公式ドキュメントから
https://github.com/Cysharp/MagicOnion#support-for-unity-client

MagicOnionリリースページへ
https://github.com/cysharp/MagicOnion/releases

そして「MagicOnion.Client.Unity.unitypackage」をダウンロードして、Unityプロジェクトにインポートします。

gRPCをプロジェクトに追加

公式ドキュメントからgRPC公式ページに行き
https://packages.grpc.io/

最新の「Build ID」項目にあるリンク→「C#」の「grpc_unity_package.2.47.0-dev202204190851.zip」をダウンロードして展開します。

zip展開した中の「Google.Protobuf」「Grpc.Core」「Grpc.Core.Api」だけをUnityプロジェクトのAsset/Pluginsにコピーします。

間違って全部コピーすると画像のようなエラーが発生しますが、先ほどの3つのフォルダ以外を削除すれば大丈夫です。

MessagePackをプロジェクトに追加

公式ドキュメントからMessagePackのリリースページに行き
https://github.com/neuecc/MessagePack-CSharp/releases

「MessagePack.Unity.2.3.85.unitypackage」をダウンロードしてUnityプロジェクトにインポートします。

インポートの際にMagicOnionの「System.Buffers.dll」「System.Memory.dll」「System.Runtime.CompilerServices.Unsafe.dll」「System.Threading.Tasks.Extensions.dll」の重複警告が出ますが上書きしてしまって大丈夫です。

VisualStudioCodeの環境構築

UnityプロジェクトにMagicOnionでアプリを作る準備は出来ました。

次はサーバーと行きたいところですが、その前にVSCodeでC#開発できるように環境構築をします。以下の参考サイト様とやることはほぼ同じです。

どうしてもC#をVSCodeで書きたい
https://qiita.com/_patrush/items/dc8b2f8ea4c59d49c1fd

参考サイトに従って必要な拡張機能をインストール

Unityプロジェクトのフォルダを開いて

「フォルダーをワークスペースに追加」をやって保存すればワークスペースファイルが作成されるので、サイトの内容をコピペした後、「**/Assets/Scripts/Generated」「**/Assets/Scripts/MagicOnion*」「**/Assets/Scripts/MessagePack」の行をコメントアウトします。

こうするとAssetsのスクリプトも見えるようになります。
（参考サイトでは非表示設定だけど、アプリ実装で表示する必要がある）

「extensions.json」はUnityプロジェクトの「.vscode」フォルダの中に入れます。
（VSCodeで開いたときに.vscodeフォルダが自動生成されるはず？）

これでC#の開発環境はだいたいOKだと思います。

MagicOnionサーバーの環境構築

VSCodeの設定が終わったら、そのままServerフォルダを作成して、その中にMagicOnionのサーバーを構築します。
（アプリもMagicOnionというのでややこしいです）

公式ドキュメントには「dotnet app package MagicOnion.Sever」（.NETコマンド）を使って追加すると書いてありますが、ちょっと初心者には説明不足で、そのまま実行すると失敗します。

（既に開いてるかもですが）先ほど作成したSeverフォルダを右クリックして「統合ターミナルで開く」を選択します。

メニュー「ターミナル」からでもいいですが、フォルダから開くとコマンドラインのパスがそこになるので便利です。

Severの中で「dotnet new grpc」を実行します。

MagicOnionはgRPCで作られているので、gRPCプロジェクトを指定して作成します。
（Severフォルダの中に色々追加されます）

その後に「dotnet add package MagicOnion.Sever」を実行します。

後は公式ドキュメントにある通り、Severの中に作成されたStartup.csの内容を変更します。

最後に「dotnet run」でサーバーが起動すれば完了です。

共通インタフェースの作成

ここまでお疲れさまでした。

環境構築が終わったら、いよいよ通信アプリの実装をやって行こうと思います。

まずはMagicOnionでの共通インタフェース「IMyFirstService.cs」を作成します。

IMyFirstServiceの内容は公式ドキュメントと同じで大丈夫です。

ファイルの位置だけ注意が必要で、このIMyFirstServiceをサーバーから参照設定するので、他の共通化しないファイルと別々に分ける必要があります。

また、UnityでIMyFirstServiceを使いたい場合、これをUnityコンパイルする必要があるので、Asset内に存在していないといけません。

ディレクトリ構成は自分も悩みましたが、namespaceと同じようなフォルダ構成で「Assets/Scrips/MyApp/Shared/IMyFirstService.cs」としました。ここら辺は割と自由だと思います。

アプリ部分の実装

次に通信アプリの実装を行います。

公式ドキュメントと以下のサイト様を参考に「SampleAppCall.cs」作りました。

UnityとMagicOnionの環境構築（IL2CPP）
https://zenn.dev/kumatta_ss/articles/dab376b180aa85

注意点としては、公式ドキュメントでは「GrpcChannel」を使っていますが、これはUnityでは利用することが出来ませんのでコメントアウトして、2行下の「new Channel」の方を使います。

またgRPCのssl通信が今のUnity環境では出来ないっぽい？ので、ポート番号5001を5000にして、ChannelCredentials.Insecure（安全でないセキュア）を指定します。

この辺りの問題は、Unityのプロジェクト設定「.NET standard 2.1」「.NET Framework」と密接に関係しています。

アプリのUnityコンパイルが通ったら、Unity上に空のオブジェクトを作成してコンポーネントにこの作成したスクリプトを設定して準備完了です。

サーバー部分の実装

まず共通インタフェースを参照できるようにします。

Severフォルダ内の「Sever.csproj」に「<Compile Include=”..\Assets\Scripts\MyApp\Shared\**\*.cs” LinkBase=”LinkFromUnity” />」を追加します。

これでShared以下のスクリプトを全て参照できるようになりました。

コンパイル参照が出来たら、Sever/Servicesの中に「MyFirstService.cs」を作成します。
（内容は公式ドキュメントにある通りです）

出来たらServerのターミナルを開いて、「dotnet run」を実行します。

asyncに関する警告が表示されますが、とりあえず無視でOK
（公式ドキュメント通りだもの）

サーバーを待機中にしたまま、Unityに戻ります。

最後にUnityで動作確認

後はUnityプロジェクトをテスト実行するだけです。

上手く行けば、Unityのコンソールと、VSCodeのターミナルにログが表示されます。

サーバーが起動していなかったり、何らかの問題があった時は、Unityのコンソールにエラーが表示されます。
（以下はサーバーが起動していなかったとき）

おまけ

MagicOnionの環境構築またやるか（3回目）

— 藤原工房 (@FujiwaraKoubou) April 21, 2022

Netcodeのチュートリアル的な動画を自分でも実践してみましたが、かなり苦戦したので、せっかくなので記事として記録したいと思います。内容はレベルの低い話も多いかと思いますがご容赦くださいませ。

チュートリアル動画との差異

まず初めに前提として書いておかないといけないのは、苦戦した理由の一つに、UnityのStarter Assetsで再現しようとしたことがあります。

これは動画の中のサンプルが公開されていましたが、勉強のためにもUnityの標準アセットでも再現できれば、今後応用したいと思ったときに楽になると思ったからです（結果として大苦戦しますが）

Netcodeで今回使ったやつhttps://t.co/cs4qZLz40y

— 藤原工房 (@FujiwaraKoubou) December 5, 2021

Starter Assetによる再現方法

もしかすると、この記事を見て自分で同じことをやって見たいという人がいるかもしれないので、構築方法を書いておきます。

環境
Windows10、Unity2021.2.5f1（NetcodeはUnity2021から対応）、Visual Studio Code

①Starter Assetを全てインポートしたら「Asset > Starter Assets > Environment > Prefabs > Environment_Prefab.prefab」を自分のシーンにドラッグ＆ドロップして配置します。

②元からあるMainCameraを削除して「Asset > Starter Assets > ThirdPersonController > Prefabs > MainCamera.prefab」を自分のシーンにドラッグ＆ドロップして配置します。

③「Asset > Starter Assets > ThirdPersonController > Prefabs > PlayerArmature.prefab」を自分のシーンにドラッグ＆ドロップして配置します。

④このPlayerArmatureを編集したいので、自分の「Asset > Scenes」にドラッグ＆ドロップして、バリアントとしてコピーします（コピーするときに選択肢が出ます）。

⑤最後に③で作ったコピー元のプレハブを削除します。

あとはチュートリアル動画の進む通りにNetworkManagerなどを入れていきます。

※以下は、チュートリアル動画を見た前提で書いていますのでご注意ください。

苦戦①InputSystemが動画と違う

Starter AssetのPlayerオブジェクトは、チュートリアル動画のようにUpdate()の中で入力を取得していません。

具体的には、ThirdPersonController.csで移動を、StarterAssetsInputs.csで入力を取得しています。

なので、この2つのスクリプトをMonoBehaviour→NetworkBehaviourに変更して、IsOwner、IsServerなどで制御する必要があります。

また、動画では古いInputSystem、Starter AssetはUnityの最新のInputSystemを使っています。

この新しいInputSystemには大いに苦しめられることになります。

苦戦②Visual Studio CodeがNetcodeをサポートしていない

バリアント化したプレイヤープレハブのThirdPersonController.cs、StarterAssetsInputs.csをコンポーネント削除をして、Starter Assetのプレハブからスクリプトを自分のところにコピーします。

元の名前と同じだとややこしいので、それぞれ適当にリネームして下さい。
（自分は接頭にMyを付けてリネームしました。この辺はお好みでどうぞ。）

そして、Visual Studio Codeでスクリプトを編集するわけですが、Netcode系、新InputSystem系のアセンブリ参照が見つからない問題にぶち当たります。

これに関しては、最後まで解決できませんでしが、Unity側でのコンパイルには問題ないようです。

おそらくVisual Studio Code Editor がそのうち修正されて対応されると思います。

苦戦③IsServerの解釈違い

チュートリアル動画の説明では、難しいところがあったので自分なりに考えて解釈していたところ大はまりしたので、解釈違いを起こしていた部分とその解説を入れたいと思います。

まず理解が必要だと思ったのは、ServerRpcの挙動です。

以下のリンクを見て下さい。

ServerRpc | Unity Multiplayer Networking
https://docs-multiplayer.unity3d.com/docs/advanced-topics/message-system/serverrpc/index.html

ここの図を見ていただければ口で説明するより分かりやすいと思います。

[Unity.Netcode.ServerRpc]がついたSetMoveInputServerRpc()は、呼び出されたときに直接実行されるわけではなく、リンクの図のように（別のネットワークの）Serverで実行されます。

つまり、ClientでMoveInput()は実行されません。
全てServerでMoveInput()が実行されます。

ここでややこしいと頭を悩ませるのが、このスクリプト自体がServerでも使われ、Clientでも使われることです。

そこで、スクリプトをServer、Clientで分岐させる必要があります。

そのための関連フラグを軽く説明します。

IsOwener：スクリプトが実際に操作しているプレイヤーのものかどうか

マルチ実行中は操作プレイヤーだけでなく、他のプレイヤーもオブジェクトとして同じスクリプトを使って複数生成されます。

そうなると、キーボードなどで操作したい（入力を取得したい）オブジェクトを判別する必要があるので、そのために使われます。

このフラグの管理は、NetworkManagerによって行われます。

IsClient：クライアント⇔サーバーにおけるクライアント側（操作のみ）
IsServer：クライアント⇔サーバーにおけるサーバー側（処理の集約と展開）

動画の中では、Host、Clientで説明されるので自分は誤解してしまいましたが、HostとClientは対ではありません。

Hostは、IsServerであり、IsClientでもあります。
（自分は最初、HostはIsClientではないと思っていた。）

対になっているのは、ClientとServerであり、HostもまたClient扱いになります。

IsServerを使って、Move()をServer側（Host側）にだけ実行させます。

Client側の移動はどうなるかというと、全てオブジェクトに付けたNetworkTransformによってNetworkManagerにより、まずServerに全て集約され、ネットワーク経由で各々配信され行われます。

この辺りの理解はかなり誤解していました。

苦戦①に関連して、2つのファイルにわたって動画と実装が異なっているので注意して下さい。

苦戦④新InputSystemの仕様に苦しめられる

出来たアプリをビルド実行して（ウィンドウ化設定をした方がいい）、HostボタンでPlayerArmatureを作ります。

そして次に、Unityのエミュレーターを実行して、ClientボタンでPleyerArmatureが作られると、Client側ではHostで作られたものと合わせて2つ作成されます。

この時に、PleyerArmatureに設定されているInputSystemは、2つのオブジェクトそれぞれに存在するので、それぞれが操作できるように自動で割り振りを行います。

そうすると、1つ目はキーボードになり、なんと2つ目はXboxコントローラーに割り振られます。

この現象と、Netcodeが必ずHostキャラから生成する仕様と合わさり、Clientボタンで2番目に作成されたPleyerArmatureが操作できないという問題にぶち当たりました。

これには大いに苦しめられました。
（操作できない理由にたどり着くまでに紆余曲折がありました）

https://t.co/XOIE5apT2q
↑を自分でやってたけど、クライアント側が動かない（単体だと動かせる）。煮詰まってしまった。ちょっと休憩かな。何か間違ってるんだろうなぁ。 pic.twitter.com/teXJ737mms

— 藤原工房 (@FujiwaraKoubou) December 4, 2021

Netcode現状まとめ
新しいInputSystem（PlayerInputManager）に大苦戦中
WindowsアプリでHostを起動し、UnityでClientを起動すると、Client側が動かせなくなる。
これは、操作Playerが生成されると自動的に操作可能なキーボードを割り振るが、2人目が生成されるとキーボードを禁止するため pic.twitter.com/A0Ywtk7kWq

— 藤原工房 (@FujiwaraKoubou) December 5, 2021

2つ目がXboxコントローラーになる件については、厳密には「操作無効になった状態をXboxとしてデバッグ出力していた」です。

この状態を何とかするために、関係ないオブジェクト（Client側から見たらHost側のオブジェクト）にInputSystemは必要ないので、プレハブのPlayerInputのenabledチェックを外しておいて、スクリプトの中でtrueにすることで解決しました。

まとめ

やった対応自体は、ほんの一握りのことですが、これにたどり着くまでに数十のサイトで調べに調べたので丸一日ぐらいの時間がかかりました。

疲れた。

願わくば、この記事が何かの役に立てばいいな

ちなみにチュートリアル動画のリレーサーバー以降は、ノーヒント状態なので再現するのは諦めました。

ウマ娘プリティーダービーに現在（2021年5月）公開されているサポートカードの完凸状態におけるトレーニング予測値をまとめたスプレッドシートを作ったので公開しようと思います。

使い物になるかは正直微妙なところです。

例えば、新キャラが実装されたときに、「無凸だとどれくらいの位置にいるのかな？」とかを調べられたりするかも。

閲覧のみ（編集不可）になっているので、自分用に使いたい場合は、メニューの「ファイル」から「コピーを作成」を選んで、このスプレッドシートをコピーして下さい。

コピーされたものなら自由に編集できます。

※　入力されたデータは攻略サイトの目コピなので、もしかするとどこか間違っているかもしれません。

※　キャラ補正値、トレーニングレベル、人数補正、やる気補正など、状況に合わせて適時変更する必要があるのでご注意ください。

※　固有ボーナスの初期ステやレースボーナス、得意率などは予測値算出に不要なので（調べるのが面倒なので）値が入力されていません。　固有ボーナスはネットに転がっていた値や個人的推測を元に暫定的に入れています。　

※　予測値はサブステータスの考慮していません。例えば、スピードトレーニングではスピードと一緒に上がるパワーは考慮してないです。

※　「手持ち」シートは私の手持ち状態を比較するために入力されたものなので、ファイルをコピーしてからご自由に変えてください。

※　「複数トレーニング」シートは、緑のセルに「番号」を入力すれば「手持ち」からデータを呼び出します。さらに、参加、友情が発生しているサポートには「1」を緑のところに入力すると自動でトレーニング予測値の一覧が計算されます。

以下が、そのスプレッドシートです。

※7月1日にウマ娘引退のため、更新を停止しました（イベントゴールドシップまで）

https://docs.google.com/spreadsheets/d/1PdjGxxVOdwI5j3IWURIIaHI9_JLf0Z3fItwQo4Ddr1U/edit?usp=sharing

毎日の日課の人も多いかもしれない魔晶石マラソン。

水晶フルマラソンと並行して、毎日リポップする魔晶石の中にも水晶があるので、毎日鍛造をMAXで作成させるなら、毎日頑張らないといけないかもしれない（ただしソロプレイヤーに限る）。

私はあまりに苦行だったので、最近このマラソンを引退しましたが、その中で法則性みたいなものを発見したので、この記事に報告書として簡単にまとめておこうと思います。

NPCによって決まるという仮説

魔晶石のポップする場所について、一定の地域によるランダムポップ説が有力ですが、私はNPCによって出現位置がある程度定まっているのではないかという仮説を立てています。

既にご存知かもしれませんが、モンド、璃月それぞれに魔晶石のポップする場所を教えてくれるNPCが4人ずつ存在します。

モンドの魔晶石関連NPC

・モンド城内の鍛冶屋　ワーグナー

・明冠峡谷の詩人　デービー

・清泉町の狩人　ドゥラフ

・千風の神殿の冒険者　ドゥーラン

璃月の魔晶石関連NPC

・璃月港の鉄工職人　章

・黒岩場の作業員　鉄腕

・層岩巨淵のリーダー　石壮

・絶雲の間　判官

これらのNPCから毎日魔晶石のポップ場所を聞くことができます。

そしてそれにはある規則性があることが分かります。

①主要拠点の鍛冶屋は毎日必ず場所を教えてくれる

②他の3人は日によって違う

③それぞれ教えてくれる場所は重複しない

④NPCが教えてくれない場所がある

これらの事実から、私は毎日のポップする場所とNPCが、密接な関係性があると考えました。

そしてその後の長い調査から、ある程度の法則性を確信しました。

■モンドの法則性

モンドの魔晶石は大きく分けて３パターンあります。

詩人パターン

モンド城周辺に魔晶石がポップします。

詩人の場所はセシリアの苗床の東、狩人は銘記の谷の東、鍛冶屋は日によって微妙に変動します（全部の場所にポップするわけではない）。

教えてもらえない場所（以下、天然魔晶石、画像では赤色）は１パターンのみです。

冒険者パターン

モンド城周辺と東側に魔晶石がポップします。

冒険者が教えてくれる場所（望風山地、千風の神殿）によって変わります。

望風山地のときはこんな感じ。
狩人が教えてくれない日でもあります。

千風の神殿のときはこんな感じ。
鍛冶屋の場所は変動します。
詩人のときと似ているので、よく見逃されているパターンではないでしょうか。

風龍廃墟パターン

風龍廃墟周辺に魔晶石がポップします。

鍛冶屋だけが教えてくれる日です。

天然魔晶石についても、風龍廃墟周辺にのみになります。
毎回微妙に鍛冶屋と天然魔晶石の場所が変わるので、このパターンではランダムポップかもしれません。

■璃月の法則性

璃月の魔晶石は大きく分けて２パターンあります。

黒岩の作業員と層岩巨淵のリーダーはお互いに教える日が重なることはありません。

黒岩層岩パターン

璃月の中央から南側にポップします。

天然魔晶石は、弧雲閣に４つ固定でポップし、他の場所は教えてくれるNPCが黒岩の作業員と層岩巨淵のリーダーとで変わります。

黒岩のパターンです。
黒岩の場所は天衡山、他は微妙に変動します。

層岩のパターンです。
層岩の場所は七天神像の西、他は微妙に変動します。

絶雲の間パターン

璃月の中央から北側にポップします。

天然魔晶石は、判官によって２つのパターンがあります。

毎回複雑に場所が変わるため、ここと風龍廃墟はランダムポップの可能性もあります。

判官の場所が北東の隅っこになったときです。
鍛冶屋と天然魔晶石の場所が入れ替わったりします。

判官の場所が七天神像の北西になったときです。
天然魔晶石が南側にもポップするのが特徴です。
鍛冶屋と天然魔晶石の場所が入れ替わったりします。

これ以外にもうひとつ、判官が教えてくれない日のパターンがありますが、七天神像の北西になったときとほぼ同じなので省略しました。

■おまけ

最後に、マラソンの効率化について小技を少し。

鉱石を掘る役は誰にやらせていますか？

これを見てください。

レザーのスキルは鉱石を効率よく壊すことができます。
おすすめのキャラです。

あと小技ですが、ダッシュ飛び降りもご紹介！

これをご覧ください。

このようにダッシュジャンプしながら飛び降りると、普通に飛び降りるより高速に落下することができます。

さらに応用技として、ジャンプせずダッシュだけで降りる、ダッシュ滑り降りっていうさらに高速な降り方もありますが難易度が高いです。

空月の祝福610JPYと天空紀行1220JPYってどれくらいの差があるかご存知でしょうか。

今月はお財布が厳しくて、どっちかだけしか課金できないけど、どっちがいいの？
という方への参考になれば幸いです。

2021年2月3日アップデート分更新

空月の祝福を原石換算すると30日で3000個（ショップ枠300を原石300に変換）あります。これは分かりやすいですね。

では、天空紀行を原石換算するといくらになるでしょうか。

では最初に、天空紀行で貰えるものを整理すると以下のようになります。

• 大英雄の経験　126個
• 仕上げ用魔鉱　288個
• モラ　2160000（216万）
• 風士の導き　4個
• 岩間の導き　3個
• 風士の哲学　1個
• 岩間の哲学　1個
• 脆弱樹脂　5個（2021年2月3日追加）
• 紀行武器　1個
• 紡がれた運命　4個
• 原石　680個

これを地脈の花芽や天賦秘境と比較します（世界ランク6）。

大英雄の経験

地脈の花芽・啓示の花は、冒険家の経験を6～7個、大英雄の経験を4～5個を出します。

これを計算しやすいように冒険家の経験に揃えて、22～27個となります。

対して、天空紀行を冒険家の経験にすると504個になります。

つまり天空紀行で貰える経験は、地脈の花芽・啓示の花（22～27個を24個とすると）換算で、およそ21回分に相当すると考えられます。

地脈の花芽・啓示の花は1回で樹脂20を消費するので、樹脂420になります。

ここまでいいでしょうか。
この消費樹脂量を他の貰えるアイテムでも算出して合算し、最後に原石に変換します。

仕上げ用魔鉱

毎日頑張れば1日20個ずつ、30日で600個無料で手に入るので、仕上げ用魔鉱は原石換算の対象外とします。

モラ

地脈の花芽・蔵金の花は、6万モラを出します。

対して、天空紀行では216万モラになるので、およそ36回分に相当すると考えられます。

地脈の花芽・蔵金の花は1回で樹脂20を消費するので、樹脂720になります。

導きと哲学（天賦素材）

風士の導き4個、岩間の導き3個、風士の哲学1個、岩間の哲学1個、これを分かりやすいように、モンドの天賦、璃月の天賦を同じものとし、哲学＝導き3個＝教え9個で計算します。

すると、教えが39個となります。

天賦素材の秘境（モンドキャラは忘却の峡谷、璃月キャラは太山府）の最高難易度（推奨チームレベル88）で入手できる個数は、導き（青）2個、教え（緑）2個になります。

これを換算すると教えが8個になるので、天空紀行と比較すると秘境のおよそ5回分に相当します。

天賦素材の秘境は1回で樹脂20を消費するので、樹脂100になります。

樹脂の合算と原石換算

大英雄の経験、モラ、導きと哲学、これらの消費樹脂を合計し、これに脆弱樹脂5個（樹脂300）を追加して、樹脂1540になります。

これを1日1回樹脂補充に原石50を使って樹脂60に変換すると考えると、樹脂1540を入手するのに必要な日数は26日かかります。

これで計算すると、原石1300個に相当すると算出されます。

紀行武器

これは後で注記しますが、単純に比較して原石に換算するのは難しいです。

この記事では、必ず星4武器が手に入る想定で、武器ガチャを10回分回したものと同じと考えて、紀行武器を原石1600個とします。

紡がれた運命

紡がれた運命4個は原石640個に相当します。

空月の祝福と天空紀行の比較

これまで算出した原石個数と、天空紀行で貰える原石680個を合計すると、原石4220個になります。これでスッキリしましたね。

空月の祝福は610JPYで原石3000個、天空紀行1220JPYで4220個（＋魔鉱）という感じになります。お得なのは空月の祝福という事になります。

ただ注意点がふたつ。

ひとつは紀行武器の優位性です。

例えば、あなたはガチャで入手した新キャラのために、星4大剣が欲しくなったとします。その時に、欲しい武器種が選べる紀行武器なら一発で問題を解決できます。

武器ガチャに頼った場合、10連（原石1600個）で欲しい武器種が出る可能性はどれくらいでしょうか（だいたい20%）。

そういった状況や、紀行武器の性能に魅力を感じた場合、単純な原石個数では推し測れない優位性があることは考えないといけません。

ふたつは時短です。

空月の祝福を樹脂に変換して、大英雄の経験やモラなどを入手しようとすれば、地脈の花芽などを実際にクリアしないといけません。

その労力と時間を節約できるのも結構大きいと思います。

何となく空月の祝福がお得なのは、皆さんご存知だったと思いますが、実際にどれくらい差があるのかを真剣に考えた人は少ないと思います。

どっちも課金じゃい！って人が多いのではないでしょうか。

以上、ご参考になれば幸いです。

きっかけは、さくらのVPSをスケールアップしたときストレージが増えたはずなのに、サーバーではそれが反映されてない（容量が少ないまま）って記事を見つけたのが始まりです。

「あれ？1Gプランにして、ストレージが50GBに増えたはずなのに、内部的には25GBしか使えてないな」

「それじゃ、さくらのVPSのスケールアップの反映について公式マニュアルがあるから、これを参考にやってみるか」

中略

「・・・再起動しても、OSが立ち上がってこない」

何をやってしまったか

あまりも馬鹿としか言いようがないミスなんですが、以下の文章を読んで、自分はこう考えてしまったんです。

思考停止状態の私「えーっと、fstabに追加ね」「コピペして・・・vi /etc/fstabっと」

冷静に見れば直ぐに気付きます。

これが「設定内容ではなく」「コマンドを入力すること」だということに・・・

憐れ思考停止状態の私は、コマンド出力からのファイル書き込みを、fstabにコマンドを直接書き込んで再起動してしまったのです。・・・馬鹿としか言いようがない。

再起動してどうなったか

「Booting from Hard Disk…」

さくらのVPS、VNCコンソールに表示される最後の一文がピクリともしない。

待てども待てどもOSが立ち上がってこない。

05分後の私「ファイルシステムの更新って時間がかかるんだな」

10分後の私「うーん、VPSだから時間がかかるのかなぁ・・・」

30分後の私「・・・やべぇ明らかにおかしい」

復旧させようと試みるが

何度再起動したり、シャットダウン→起動しても変化が無いことに焦った私は、ついにサポートに聞いてみることにした。

コロナの影響で、電話窓口は閉じており、チャット相談もさくらのVPSは対象外ということで、メールでの問い合わせになった。

パニック状態の私「公式マニュアル通りにやったのに再起動しません。どうすればいいでしょうか？」

改めて振り返ると、いわゆる「何もしてないのに壊れた」ですねこれ。恥ずかしい。

メールの返信は「カスタムOSにてインストールされたOSは対象外になります。」という門前払い的な内容が営業時間終了後（メールを送信したのは13時）に届いた。

私は「酷いじゃないか」と頭にきて、「ほら、OSインストール画面だと標準OSってなってる（ただの勘違い）」「カスタムOSってどこで確認したんですか？」と怒りの返信。

メールを送信してから次の日の返信を待っている間、私は冷静になり始め、そこで初めてfstabの誤記入に気付いて事態の深刻さを思い知る。やっちまったと。

怒りのメール返信を「もういいです。やっぱり自分で解決します。」って取り下げて（サポートが受けれない事実はショックだったので、メール文面がひねくれています）、自分の力で何とかしようと悪戦苦闘を始める。

その時に参考になったサイト様です。

しかし現実は非情である

あれやこれやと試してみるが、結局進展はせず、ただ時間だけを浪費していく。

そこで私は復旧を諦め、最初からサーバーを建て直すことをようやく決心する。

幸いにも、サーバーはまだWordpressしか使っておらず、またWordpressのバックアップはUpdraftPlusにて全て保存済みであったので、理論的には元に戻すのはそう難しい話ではなかった。

・・・しかし、ここで欲張りモードが発動する。

「せっかく再構築するんだから、Docker Swarmを使ってみよう」

そもそも、事の発端になったスケールアップのトラブルが発生したきっかけは、Wordpress内の警告に「PHP7.0と古いので更新してください」という文言を発見してしまったことだ。

そして、Dockerコンテナで運用されているこのホームページを、どうやって新しいPHPでホットデプロイ（Wordpressがメンテ状態にならないままアップデート）するかを調べていた。

本来の目的はWordpressコンテナをPHP7.3に更新することであった。

「Dockerコンテナをホットデプロイするにはどうしたら？」

「Wordpressコンテナを2個（replica 2）たてて、片方を起動しながら、もう片方を更新する」

「Docker Swarmを使えば簡単に構築できるらしい」

となれば、やってみたくなるのが心情（技術向上への強迫観念）である。

Docker Swarm と Kubernetes (k8s) どっち？

「Docker Swarm について調べて見よう」

「何か Docker Swarm はもうオワコンらしい」「今は Kubernetes が流行り」

「それじゃ Kubernetes を勉強しよう」

「k8s ってホットデプロイできない？」「k8s の拡張ツールとかならできるらしい」

「なんか k8s 自体はそうでもないけど、ホットデプロイとなると複雑で面倒そう」

「Docker Swarm なら簡単そうやな」

「やっぱ今回は Docker Swarm を使うのさ、たとえオワコンでも！」

技術向上への強迫観念はどこへ行ったのか、面倒そうと思ってしまったが最後、簡単に楽な道へと進んでしまうのだ。

これは後から分かったことなのだが、Swarm も k8s も、コンテナ構築の手順や複雑さは、そう差は無い。どちらもDockerコンテナを使う以上、 docker-compose でコンテナの構築を行うのだが、composeを使った時点で9割やることは終わったようなもの。

Swarm と k8s の違いを感じたところは、用語と、初期設定と、環境構築ぐらいである。どちらも、そこに拡張ツールなどを付け加えて「やれること」を増やしていく感じなのだ。

それじゃ Docker Swarm をやっていきますか

OSをクリーンインストールし、DockerがCentOS8にまだ対応してないので、また同じCentOS7にしました。そこから、ssh、firewall、user、wheelなど面倒だけどやらないといけない設定をあれやこれやと済まし。

Docker の最新版をインストール。最新のは、これだけで他にも必要な、docker-ce-cli、containerd-ioも一緒にインストールされていた。

Docker Compose もインストール。自分は上記の通り1.26.1だったが、今は1.26.2が最新版ということで、ここのバージョン番号は時間と共に変動するのだ。

Swarm に関しては、Docker をインストールすれば使えるようになる。

Swarm の初期設定はこれで終わりである。オプションとして、listen-addでネットワークの制限があるサーバーに対しての設定が必要だったりするが、サーバー1台しか持っとらんし、ネットワークの制限なんぞも無い。これで完了。

これを実行すると、「To add a worker to this swarm, run the following command: docker swarm join –token ・・・」みたいな文章が表示される。

Swarmは、簡単に言えば、サーバー全体を管理するManagerサーバー、その他管理される側のWorkerサーバーで構成されていて、これを使ってネットワーク的に離れた場所のサーバー同士を1台のサーバーのように構成することができる。

「swarm init」したサーバーがManagerになるので、先ほどの文言は、他のサーバーをWorkerとして構成に追加（join）したければ、このコマンドを使ってねという感じである。

だが、サーバーが1台しかない自分の環境では全く関係のない話。

あれ？Docker Swarmってこれで出番終わり？

Swarm の主目的は、ネットワークを介して離れたサーバー同士をつなぐために使うものなのだが、私はサーバー1台の中に、ManagerとWorkerを混在できると勘違いしていた。

「This node is already part of a swarm. Use “docker swarm leave” to leave this swarm and join another one.って出るな」

「MangerとWorkerは同じサーバーに設定できないか」

「あれ？Swarmの機能を使ってなくない？」

「でもホットデプロイのサイトでSwarm使ってるのにな」

「docker service createとかupdateとかってSwarmが必要なのかな？」

「This command works with the Swarm orchestrator. って書いてあるから関係あるっぽい？」

「なんだかよく分からんがSwarm使う意味はあるっぽいのでヨシ！」

よし、あとはhttps-portalとか使って・・・ん？

以前までは、通信のHTTPS化にhttps-portalコンテナ、あとWordpressコンテナ、MySQLコンテナをlinkで繋いで、はいお終い！だった。

しかし、今回はホットデプロイのために、Wordpressコンテナを2個用意して、それをdocker service update でローリングアップデートさせる野望があった。

コンテナが2個に増えたので、通信はSwarmのロードバランサーによって振り分けられる。そこで問題になるのが、セッションである。

Swarmがコンテナの状態を見て通信を振り分けるのだが、これは1回の通信ごとであるようだ。そのときにセッションは維持されない（ようだった）。

例えば、Wordpressのダッシュボードを開くためにログインするが、ログイン状態はセッションが使われている。つまりセッションが維持されないと、何かダッシュボード内のリンクをクリックするたびにセッションが途切れ、またログイン画面に戻されてしまうのだ！

https-portalを調べたところ、セッションについて言及されていないので、このコンテナはセッションが維持される（普通はそう）前提なのだ。このままでは不味い。

Swarm でセッションを維持するような追加設定はないらしい（なんじゃそりゃ）。

そういうときは「traefikを使うといいよ」という記事が多かった。

ここから大苦戦のはじまり

Swarm なんじゃこいつ役に立たんやんけ、ってことで、どうやってセッションを維持させつつhttps化をすればいいんじゃ・・・って悩んでいたところ、traefikというSwarmを拡張するコンテナを見つけた。

・・・だが、このtraefik、かなりの曲者だったのだ。

ちなみに k8s も同じようにセッション問題があり、ingress というネットワークコントローラ（その正体はnginx？）をかぶせることで解決しているようです。

Swarmもk8sも本体は役立たずなんじゃないか？・・・あんまりdisってると、まさかりが飛んでくるかな。

・・・さて、traefikとは何者なのか。

traefikは、Dockerコンテナで、Swarmのロードバランシングを無視して通信を振り分けるロードバランサです。ようはSwarmが使えねぇんでネットワークを乗っ取ってしまうコンテナらしい。

実はこの事実に気付くのは、かなり苦戦した後になります。

traefikの設定記事、みんなバラバラやん・・・

traefikは、様々なネットワーク構成ができるようになっているので、調べれば山のように設定情報が見つかりますが、自分の欲しい情報（Swarmでセッション維持）が簡単には見つかりません。

しばらくして、英語圏ではセッション維持のことを「sticky session」と呼称するのが分かりました。

ようやく突破口を見つけましたが、同時に奇妙なことに気付き始めます。

同じsticky sessionの設定が書かれているはずなのに、みんな書いている設定がバラバラなんです。これには理由がありました。

traefik.tomlとdocker-composeどっちでもいい

traefikの設定値は、外部ファイルから読み込む形（tomlファイル）と、docker-compose（ymlファイル）でtraefikコンテナを作るときにcommandで指定する形の2通りがあります。

この2通りの方法について、各利用者サイトが両方使っている場合が大半だったのが問題でした。

さらには、同じ設定値をtomlとymlで、重複しているのに気づいていない人が大半だったのです。つまり、みんな他所からコピペしてなんか知らんが動いたからヨシ！状態。

例えば、tomlで

とdockerに対する設定を書くのと、ymlで

これは同じ意味になるんですが、ほとんどのサイトで重複して書かれていたりします。

この2通りで書ける狙いとしては、tomlで設定の共通化を図りつつ、環境によって差がでる部分を各ymlで吸収させること。

しかし、その自由さ故に、各個人での設定がバラバラになり、さらには煩雑なコピペが進むことで、重複した設定情報が世にあふれることになってしまっています。

これが大いに私を苦しめる原因のひとつになりました。

ですが、さらに大きな問題が・・・

traefik v1とv2が混在している・・・？！

traefikは現在v2.2なんですが、ネットに設定情報として書かれている7割ぐらいがv1時代のものでした。

参考サイトのすべてがv1時代の情報だったら良かったんですが、v1とv2の情報がネット上に混在していました。

以下は、v1からv2への変更点がまとめられた公式マニュアルです。

見てもらえば分かると思いますが、機能追加だけでなく、書式の大幅な変更が入ったところや、もう別物やんけみたいな所、無くなった設定や、追加された必須設定など、様々な修正が入っています。

各利用者サイトが、これに正しく対応していれば何も問題なかったんですが・・・

なんと混在していたんです。v1と、v2の設定が。

つまり動作確認されてない情報もたくさんありました。

「書いてある通りに設定しても、うまく行かないなぁ」

「FAQサイトによると・・・なになに？traefik:v1.7にしろって？」

「え？なにこれ？v1とv2って完全に別物やんけ！」

「え？でも公式マニュアル、これv1の設定じゃ？公式が古いじゃん」

「えーと、今まで見てきたサイトは・・・」

「こっちはv2で書かれてるっぽい？あれ？でもこれv1じゃないとダメでは？」

「・・・正しい設定情報はどこなんだぁ～」

正しいのは何処だと、調べて行けばいくほど沼にはまっている感じがしました。

みんな「何となく」「何だから知らんけど」って設定値を書いてる感じなんだよね。

↓心が折れそうになった私

だー、だめだ、心が折れそうｗ
traefik の v1 と v2 の違いが大きいのに、ネットに散乱している traefik 設定が v1 と v2 で混在していて、何が正解なのかさっぱり分からん。
おまけに、traefik.toml で設定するパターンと、traefik.yml で設定するのも混在していてカオス

— 藤原工房 (@FujiwaraKoubou) July 11, 2020

結局、公式マニュアルなどで各設定値の意味や情報を洗い直すことになり、かなりの手間になりました。また、v2の動作確認された情報が少なすぎたので、v1.7で進めることにしました。

悪戦苦闘したおかげで、何とかtraefikが起動しましたが（ダッシュボードが見れるようになる）、wordpressにアクセスしようとしてもタイムアウトしてしまいます。

「traefikの設定をコメントアウトしたりしながら確認してみよう」

「・・・どうやら、swarm = trueにすると何かおかしくなるなこれ」

「swarmオプションを全部コメントアウトするとwordpressが見れるか」

「いろいろ調べたが、traefik.backend.loadbalancer.swarm=true・・・これが追加で必要っぽい？」

「traefikはロードバランシングを行わず、swarmに委譲します、と小さく書いてあるな」

「これを追加すると、swarm=trueでもwordpressコンテナに通信できるようなる。・・・swarm=trueの効果を無効にしているような気もするけど・・・これでいっか！」

「えっと、次は、つながるようになったが、何でwordpressは404なんだ・・・」

WordPressの初期化に失敗する・・原因は？

今度はWordpressにアクセスしようとすると、404エラーしか出ない問題にぶち当たります。本来ならば、言語選択画面が表示されて、Wordpressのインストール画面になります。

traefikの設定が間違っているのかと、あーでもない、こーでもないとネット情報が当てにならないので自力で手探りで色々試していました（すでに疲労困憊）。

しかし、夜も更け、朝になっても解決せず・・・も～ダメだと寝ました。

起きてからリセットされた頭で考えた結果、原因の切り分けを行うことにしました。

まず大前提として「traefik無しでwordpressが起動するか」

・・・すると、なんと起動しなかったのです

何故これに気付かなかったのかというと、Dockerコンテナというものは起動することが基本的に証明されたものが公式によって配布されています（traefikみたいに設定が別に必要なのはともかく）。

PCで言えば、PC業者が組み立ててくれたものを買ってきたので、電源ボタンを押せば起動するのが当たり前みたいな話です。

「wordpressコンテナが起動しないだと？！」

「原因は？初期化に失敗している・・・なぜ？」

「えーと、MySQLコンテナが起動する前に、wordpressコンテナが起動するとダメ？」

「wordpress.ymlのdepens_on: mysqlってやってるけどなぁ・・・」

「え？depens_onって起動の順番までは制御してない？なん・・だと・・！」

「みんなどうやってこの問題を解決しているんだ？・・・シェルスクリプト？！」

「え？docker-composeに知らない設定があるとかではなく、自作だと・・？！」

「・・・な、何か他にやりようは無いのか？」

何だか知らんが動いたからヨシ！

今回docker-composeで、Swarmを利用した新しい概念としてserviceを使っていました。以下のような感じで、deploy属性のreplicasを指定することで配置するコンテナの数などを設定できます。

前回と違うところは、このdeploy属性です。特にコンテナの数が2個になったので、それが影響しているのではないかと考えました。

ログを見ると、最初の1個が起動に失敗し、その次に2個目が起動し（その間にmysqlが起動したから？）、最後に最初に失敗したのが起動するという感じになっていました。

その最初の失敗の影響でwordpressの初期化に失敗し、起動はしているがwordpressにアクセスできない状態を作り出しているのではないか。

いろいろ試していると、初期化に成功することもありました。たまたまmysqlが先に起動したこともあったのでしょう。たまに成功するのが問題を複雑にしていました。

・・・正直なところ、この問題を解決できたのは偶然です。

コンテナ内で発生するデータ変更を永続化するために、volumes属性があります。

このvolumes属性は、Dockerが決めた場所（/var/lib/docker以下）か、自分で指定したディレクトリにすることができます。

いろいろ試しているときに、自分で指定した場所（./www:/var/www/html）にしてみたところ、何故かずっと成功するようになりました。

完全に推測ですが、最初に永続化されたDocker配下のvolumesが何かしら壊れた状態になったが、完全に壊れたわけではなかったので、コンテナは起動するが、wordpressの初期化に成功したり失敗したりするようになったのではないかなと思います。

そこで、新しくvolumesの場所を変え、新品のvolumesを使ったことで成功するようになったのではないかと。

・・・詳しく原因を調べるのはもう面倒なのでやめました。

何だか知らないけど動いたのでヨシ！！

やっとここまで俺は戻ってきた

ついにWordpressも使えるようになり、当初の目的だったhttps化や、sticky sessionも問題なく働いています。2個あるwordpressコンテナの片方をstopしても、Wordpressを変わらず操作し続けることも出来るようになりました。長かった、ここまで本当に長かった。

あとはブログを復元するだけ・・・

実は今回フルバックアップからのフル復元は初めてでした。

↓（頼む・・・成功してくれ・・・！）

しゅげー！もどってきた pic.twitter.com/eUuySZJ8H8

— 藤原工房 (@FujiwaraKoubou) July 12, 2020

正直こんなに簡単に復元できるとは思っていませんでした。

ここまでの苦労が報われた感じがしました。

いろいろあったプラグイン、その設定まで元通りになっていました。

ただ一つだけ問題がありました。

バックグラウンド更新が想定通りに・・・

最新のWordpresにはサイトヘルス機能という、Wordpressの様々な問題を発見して警告を表示するものがあります。事の始まりであった「PHPが古い」という警告もサイトヘルス機能で表示されていたものです。

復元したWordpressのサイトヘルスに見慣れない致命的エラーがありました。

「バックグランド更新が想定通りに動作していません」

これは調べたところ、新しくvolumesを作ったのが原因でした。

wwwというディレクトリをvolumesに設定しましたが、このwwwディレクトリの権限設定を変更すると解決しました。

「wordpressコンテナ内の/var/www/htmlの権限は、www-data:www-dataか」

「www-dataは33に設定されているな、それじゃ、wwwをchown 33:33にしてみよう」

「あれ？33:tapeってなるけど・・・CentOS7だと33はtapeグループなのか」

「サイトヘルスの警告文が消えてる・・・これでいいみたい！」

これにてWordpressの再構築は完了であります！

最後にGithubに設定ファイルを公開して終わります。

注意点として、traefikのSwarmに関する設定は、自分から見てもかなり怪しいです。また、v1.7での設定方法になるので、将来的に公式サポート外になるかも。使うならば自己責任でお願いします。

細かい設定などについては、Githubの方に書いておきますね。

Oculus Rift 利用者が Quest を使ってみて感じた相違点をメモ。

センサーが不要になって真の自由を手に入れた感

Oculus Rift ではセンサーが机の上をある程度占有します。
そしてPCにつなぐ必要があるので、どこにでもセンサーを置けるわけではなく、広い机やPCの場所などを制限されます。

これが結構なストレスでしたが、Quest になって本体にセンサーが内臓されるようになり、PCへの接続も不要になったので、VR端末としての物理的な自由度がかなり高まりました。

真の自由を手に入れたVR端末って感じ。

パソコンが不要

Oculus Quest ではスマホさえあれば初期設定が可能です。
Bluetooth 通信が可能なスマホ端末であれば、スマホに Oculus アプリをインストールして、そこで端末とヘッドセットを Bluetooth ペアリングするだけで、あとは Wifi 設定を入力するぐらいです。

ただ、Quest 向けのアプリ開発をしようと思ったら、どの道パソコンは必要なので、あくまでお手軽さが利点って感じですね。
旅先で遊ぶみたいな、持ち運びできる携帯ゲーム機って使い方が出来ます。

メガネがすんなり入る

Rift よりも Quest の方が若干ヘッドセットのレンズ周りの空間が広いです。なので、Rift ではかなりギリギリでメガネが入るって感じでしたが、Quest だとすんなり入ります。
個人的にはもう一回り大きく空間を作って欲しい所です。

重量は Quest の方がセンサーとかの分だけ重くなってる影響で、顔面、特に頬骨辺りへの負荷が高まったように感じます。
お手軽さと引き換えに長時間は装着が難しい感じ。
この問題は、頭の後ろ側にカウンターウエイトを付けて、重さのバランスを取るって方法もあるらしいですね。

日本語入力が出来ない

これは自分の環境のせいなのか分かりませんが、Rift では端末デフォルトの備えついたキーボードで日本語入力が可能だったのに、Quest では出来なくなっていました。
なので、ブラウザはわざわざ日本語入力が出来る Firefox Reality というアプリが必要です。

なんで劣化したんだろう？
コミュニケーション系アプリとかで、チャットしようと思ったら英語しか打てないって、日本展開ではわりと致命的のような気もしますけども。

一応、英語入力中に予測変換で日本語が表示されたりします。
Quest ユーザーはそれで何とかやってたりするのかな。でもスラングとか、会話中のくずした口語とか予測変換に出てこないですよね。
みんな我慢してるのかな。

※2020年7月23日追記
バージョン19から日本語入力に対応したようです。

アプリ開発時のケーブル不足

Quest がPCから独立したのは良かったんですが、逆にアプリ開発時にPCから端末へデータを転送するために、新しくケーブルを1本買いました。

端末に同梱されていた充電ケーブルは、「USB Type-C オス」⇔「 USB Type-C オス」なので、PCに USB Type-C が差せるスロットが無いとつなげないわけですが、自分のPCはちょっと古めなので無いです。
最近の新しいパソコンなら標準で付いてるみたいですね。

なので、携帯用の「USB Type-A オス」⇔「USB Type-C オス」の USB2.0 のケーブルを買いました。携帯の一般的なものでOKでした。
本当は Oculus Link 的に USB3.0 の方がいいみたいですが、そういうのは家電屋さんにはおいてなかったですね。
3.0 の莫大な転送量の関係でケーブルも光ケーブルとかでちょっとお高いですしね。

追記
ベータ版機能で USB2.0 でも Oculus Link が使えるようになったらしいです。

The latest Oculus software beta update allows Oculus Link to work with many USB 2.0 cables- including the one in the box!https://t.co/8Xf2fcXmmM pic.twitter.com/PKb06Audvs

— UploadVR (@UploadVR) May 14, 2020

ホーム画面（バーチャル環境）で移動できない

Rift のホーム画面の部屋では、カメラ（自分のヘッドセット）の位置を変えたり正面の向きを変えたり、何かオブジェクトを置いたり、ミニゲーム（ラケットでボールを飛ばすみたいな）が出来たりしたんですが、Quest ではそういった機能はなく、ホーム画面は背景って感じの空間になっていました。

これが Rift を経験していると結構ストレスというか、これじゃない感があって、設定＞すべてを見る＞バーチャル環境から色々と配信されてるものを試しましたが、全部固定視点、固定背景って感じでした。

補足
バーチャル環境の設定で「インターネット接続できません」ってエラーが表示されて、いろいろ解決策を調べましたが、ネットには載ってませんでした。ただ、端末を再起動（ヘッドセットの電源ボタン長押し＞再起動）するとリストが表示されるようになったので、同じところでトラブった人はお試しあれ。

追記
Oculus Link を使うと Rift のアプリが遊べますが、Rift のホーム画面を使うことも出来るらしいです。
これにより移動できるホーム画面を体験できると思います（まだ試してない）。

（・・・もしかすると日本語入力の抜け道として Quest ユーザーは Oculus Link で Rift を使う感じだったりするのかな？）

ひと昔前までは、Unityの公式チュートリアルといえば以前解説したような、動画形式の簡素なものでしたが、今は新しくチュートリアル専用のサイトとして「Unity Learn」があります。

Roll-a-ball – Unity Learn（英語版）玉転がし – Unity Learn（日本語版）

で、今回は、この玉転がしの解説ではなく、新しく作られたチュートリアルサイトで初学者が「これってどこから手を付けたらいいの？」「入り口はどこにあるの？」という素朴な疑問を解消するために、サイトでの最初の道筋を解説してみたいと思います。

サイトの日本語化

まず初めに、英語に拒否反応を示す方のために、サイトの日本語化（一部だけ）のやり方を説明します。まずはトップページを開き

トップページを一番下までスクロールすると、言語指定が出来るところがあります。そこで「日本語」を選択します。

サイトのログイン

チュートリアルを始めようとすると「ログインして下さい」的なことを言われるので、まずはアカウント作成とログインについて軽く説明します。

トップページの右上のアイコン（人影の形です）をクリックすると、「Unity ID を作成する」というのがあるので、それをクリックして下さい。

Unity ID はこのサイトだけでなく、この先での Unity Hub や Unity 本体でも使うので、パスワードは忘れないように。掲示板とかに表示される「ユーザーネーム」の設定だけは気を付けた方がいいかもしれません。

Getting Started with Unity という入り口　

ログイン出来たら、早速チュートリアルを探してみましょう。

まずは、メニュー欄の「コース」をクリック

コースをクリックすると画面中段に「コース」と表示されて、検索欄やタグ、そしてコース一覧が表示されるようになります。

そこで「レベル」タグを「Foundational」にして、絞り込み検索（フィルター）をします。Foundational は「基礎」って意味ですね。

すると、2つのコースが表示されます。その内、右側の「Getting Started with Unity」がどうやら Unity 入門コースになっているようです。こんなやや小難しい手順を踏まないといけないのは「どうなんだろ？」と思いますが、おそらくこれが初学者の入り口かと思います。

「面白くない」だけじゃだめ

ゲーム開発への知見を深めるために、日課と言うほどではないですが、プレイしたゲームが面白いか面白くないかを真剣に考えることがあります。そして今回は東方キャノンボールを少しプレイしてみました。

結論としては面白くなかったですね・・・

しかし、ただ漠然と面白くないとするのは、ゲーム開発者としてはダメだと自分は思っています。

〇 自分の感性を疑う必要があります

〇 面白い、面白くない理由を探す必要があります

〇 どうすれば面白くなるかを考える必要があります

特に3つ目は重要で、プログラミングやデザインなどより、ゲームを作る上で最も必要な技術です。面白くないものをどうすれば面白くできるのか、初めから面白いものは作れません（運よく作れることはありますが）。

そしてそれはゲームを作るか、ゲームをプレイして考察するかぐらいしか、技術を磨く方法がないと考えています。面白さを自分の頭の中で構築するために、ゲームで遊ぶのは必要だと自分は思います。

ボードゲームって面白い？

まず、この問題を考えないといけないでしょう。

一般的にゲームを作る上で、大本のゲームデザイン、そのジャンルを最初に考えます。RPGで行くのか、シューティングで行くのか、パズルで行くのか、それとも全く新しいジャンルに挑戦するのか、ジャンルを組み合わせたりするのか、これはディレクターあるいは企画者が「これは面白いのではないか」という期待をもって設計します。

その選択肢の中で、東方キャノンボールはボードゲーム形式の「すごろく」にしました。厳密に言えば、モノポリーのような資産管理を重点に置いたルールで行うものです。

この選択がまず厳しい。

推測でしかないですが、製作チームが桃鉄を作っていたと噂されていただけに、得意とする分野だったからというのが大きな理由だったの思います。しかし、・・・そもそも、すごろくってそんなに面白いですかね。

自分であれば、ジャンル選択の時点で、すごろくは反対したと思います。桃鉄など、このボードゲームジャンルにファンがいることは知っていますが、広い視点から見て、一般客が右も左もすごろく面白い！ってイメージできますかね。もちろん面白いと感じる人もいるでしょう、でも少数派な印象を自分は持っています。

ソシャゲの基本設計と相性が悪いボードゲーム

そして、さらにこのゲームは基本ソロプレイになっているというのが、また厳しい点ですね。ソロプレイ主体なのは、ソシャゲの基本的な設計にボードゲームを組み込んだ影響だと思います。

ソシャゲの設計について語ると、それだけで３つ４つ記事が書けてしまう話なので、ここでは色々割愛して、探索→報酬→育成の一般的なソシャゲサイクルを基本設計とします。

ソシャゲの設計に他のジャンルのゲームを落とし込む場合、このサイクルを避けて通ることはできません。無理に避けようとすると、サイクルが崩壊してソシャゲの面白さを損なうからです。

東方キャノンボール制作は、この一般的なサイクルにボードゲームを適用するために、ソロプレイを選択しました。この選択自体は、避けて通れない道だったと思います。どのようなソシャゲにおいても、ソロプレイが主体じゃないゲームはないでしょうし、詳しくは割愛しますが、そうしないとソシャゲサイクルを維持できない。

そもそもボードゲームをソロプレイで面白いと思えるのか

そこで、問題になるわけです。

ソロプレイ用のボードゲームは存在します。しかし、東方キャノンボールはソロプレイ用ルールではなく、マルチプレイ用のルールで他プレイヤーをNPCにすることでソロプレイとしています。

これがまず第一に不味かったのではないでしょうか。

桃鉄に確かに同じような形でソロプレイは実装されています。しかし、それは、マルチプレイを想定したゲームに「おまけ」としてある部分で、言ってしまえば「面白くないけれど」ソロプレイできるようになっているに過ぎないと私は思います。

他プレイヤーが存在しないような、いわゆるボードゲームのソロプレイ用のルールを作り、マルチプレイとは異なったゲーム性を作れば、あるいは面白いものになった可能性があるのではないかと思います。

とはいえ、自分はそもそもボードゲームジャンルに懐疑的な上、ソシャゲに落とし込むのは無理があったのではないかと思います。

無理だったのではないかと思う理由の一つに、例えば、まどマギオンライン（サービス終了）が個人的に印象に残っていますが、このゲームも面白くなかったですね。どう面白くないのかはここでは語りませんが・・・

「魔法少女まどか☆マギカ オンライン」はどんなゲーム？ ようやく姿が見えてきた話題作のゲーム内容についていろいろ聞いてきた

この記事で注目するべきは、このジャンルを選んだ理由についてのインタビュー質問と回答ですね。東方キャノンボールと照らし合わせてみて、考え深いものがあります。

ボードゲーム的にあかん

さて、ボードゲームが面白いかどうかは、とりあえず置いておきましょう。ここでは、ボードゲームが面白いと仮定して、ゲーム内容自体を考えて行きます。

すごろくとしての面白さはしっかりあるか。

東方キャノンボールは、 プレイヤーの選択に関わらず起こるマイナスイベントがあります。これは良くないゲームデザインだと自分は思います。

これは個人的な考えですが、すごろくとは、自分が選択した道が面白い結果につながる過程を楽しむものだと考えています。 ですが、このゲームはあまりにも理不尽で不愉快な結果が、プレイヤーの選択に関わらず「多く」発生します。これはボードゲームの基本的な部分の面白さを損ねています。

マイナスイベントは、それが発生する可能性があることを、プレイヤーが知っていなければなりません。それはどんなボードゲームでも当然のように行っている基本設計です。唐突にマイナスイベントが発生するボードゲームは良くないと思います。

まずそこでしょうか。どうしてそうなったのか分かりませんが、可能性としては、ソシャゲに落とし込もうとして捻じ曲がったのか、桃鉄だからそうしたのか。桃鉄だと、自然災害が唐突なマイナスイベントになるのかな。

現状は、唐突なマイナスイベントが多すぎるので、マイナスイベントを減らして、もっと大量にプラスイベントを追加するべきです。かなり不快なマイナスイベントについては、廃止するかもっと勝敗に影響が少ない形に修正するべきだと思います。

マイナスイベントの避け合いではなく、プラスイベントの奪い合いに。

以下は、ボードゲームのすごろくの面白さを考えた記事で、内容全部に同意はできないですが、参考になる記事ですね。

【CEDEC2013】遠藤雅伸氏がゲーム制作者に問う「面白さって何？」

ゲームバランス的にあかん

イベントだけでなく、キャラの固有スキルについても、修正が必要だと思われる部分があります。これは不快というのもありますが、単純にゲームバランスとして強すぎるのではないかと思うやつですね。

例えば、魔理沙の資産を強制的に奪うスキル。桃鉄で言えば物件を奪うカードでしょうか、ただ、東方キャノンボールのスケールを桃鉄に当てはめると、駅丸ごと、いや地方の複数の駅を丸ごと奪ってるようなスキルなので、強力すぎると思います。

防ぐには、相手スキルを無効にするキャラか、スキルを反射するキャラを用意しないといけないので、プレイヤーの選択の幅を狭めているのが面白さを損ねていますし、NPCは確実に毎回使ってくるので、確実に発生するマイナスイベントのようなものになってしまっています。

他にも、桃鉄のスケールで言えば問題ないような効果も、全体的にスケールが圧縮されたキャノンボールでは強力な効果になっている理不尽スキルがたくさんあります。これらをプレイヤー有利な形で、例えば、スキルの確定にプレイヤーが簡単に介入できる「出目勝負が必要にする」とかであった方がいいのかなと自分は思います。

そもそもボードゲームにプレイヤーがそれぞれ十人十色のスキルをもってボードゲームのルールに介入するっていうのが無理があると思いますが、これもソシャゲに落とし込んだ弊害でしょう。

テンポを損ねる煩わしい部分

ボードゲームはそもそもテンポが悪いゲームです。アクションゲームのように撃てば響くようなものではなく、行動と結果に時間がかかるものです。

その中で、さらにテンポを悪くしている部分があります。

〇イベントの終了を告げるイベント

全く不必要なイベントだと思います。バフアイコンでイベント中なのか分かるので削っていいでしょう。全くゲーム的に意味の無いテンポが遅くなってるだけのイベントです。

〇五分の魂

ほんのわずかな金銭を貰えるイベントです。桃鉄で言えば、100万円貰える感じで、物件は最低1000万からなのに100万もらっても微妙的なイベント。このイベントは割と発生するので、プラスイベントですがテンポ悪くなってますね。せめてプラスマスを踏んだくらいの効果はあっていいかと。

〇不要なバトル開始ボタン

これはイベントではなくてUIの話ですが、戦闘シーンに入るときに、すでに戦闘をするかを選択しているのに、戦闘が始まる前に一旦停止して、戦闘を開始するボタンを押す必要があります。これは不要ですね。二重確認になっています。

〇メニュー内のスキップボタン

オプションでイベントを強制スキップする設定もできますが、リグルの空中散歩のようなイベントで選択肢がある場合、そのオプションをONにしていると毎回特定の選択がされてしまうので、万能ではありません。

そういったときに、イベント中にスキップボタンを押す必要があるんですが、メニューボタン内の押しにくい位置にあるので、押しやすい位置にボタンを移動するのがいいと思います。

もしくは、オプションでの強制スキップでも、しっかり簡易表示された選択肢から選択できるようになればもっと良いと思います。

理不尽なAI

ゲームにおいてNPCの強さはゲームの面白さに直結します。根本的に、ゲーム内で敵NPCが最善手を撃つとプレイヤーは成すすべがなく負けます。東方キャノンボールのNPCは最善手とは言えませんが、それに近いことをしてくるかなり強力なAIになっています。これもまた面白さを損ねているでしょう。

やるとすれば、NPCの所持金を増やしてハンデをあげて、それをプレイヤーが追い越す形がいいと思います。NPCが馬鹿をやってる間に、プレイヤーが最善手をうつよう努力して勝つでいいのではないかと。

サイコロの出目を運で決めるゲームですので、NPCが強い出目で最善手をうつことほど理不尽で不快なことはないです。

桃鉄で名人NPCと戦うのがありますが、このゲームだとスケールが圧縮されていて、逆転の手筋なく1ターンキルみたいなことを平気でNPCがやってくるので、名人NPCよりもっと凶悪ではないかと思います。

ボンビーと紫苑の違い

桃鉄のボンビーに相当するものが、東方キャノンボールの放浪キャラ紫苑として存在しますが、かなりルール的に異なったものになっています。

ボンビーは誰かがゴール到達したときに、ゴールから最も遠かったプレイヤーに罰ゲームとして与えられる要素です。罰ゲームだから納得感がありますよね。

東方キャノンボールの場合は、放浪キャラの移動出目次第で取りつかれる決まります。つまり罰ゲームではなく、1位でも容赦なく対象になります。避けるには特定イベントを引き当てないといけないので、ほぼ防げません。理不尽ですよね。ターン経過時の順位による罰ゲームでないならば、取りつかれる前に出目勝負をさせるべきだと思います。

最適化の末の虚無

そもそもボードゲームジャンルは面白いのか。そしてボードゲームとして、すごろくは面白いのか考えました。では、それらを考えた上で、すごろくは面白いんだよ！と仮定すれば、他に面白くない原因は何があるでしょうか。

これ書いてる本人もここまで面白くない要素が多すぎて辛いんですが、ここが大事ですね。数多くの間違った選択の結果、完成してしまっているゲームを、どうすれば面白くなるか。そのヒントになるから。

私はこのゲームの問題点として、全く同じ作業を強いられている、すなわち虚無を強いられていることが重要だと感じています。

桃鉄で全く同じ手順で駅の物件を購入し、全く同じ場所のゴールを目指すことはないですよね。でも、東方キャノンボールは行います。正確にはそれを強いられます。そうしないと報酬が少なくなる、あるいはNPCに敗北するからです。

プレイヤーの行動は最適化されていきます。最適を何度も繰り返すことに面白さはありません。ただの虚無です。

この虚無に対して、イベントやスキルが存在しますが、根本的な解決にはなっていません。どのマップ、どんな条件でも、やってることはほぼ同じになってしまっています。キャラはほぼ固定でいつも同じタイミングでスキルを発動し、できるだけNPCを妨害して、出来るだけ資産を増やす。

同じような操作を何百回何千回何万回と果てしなく繰り返す。

・・・ゲームとして大切な部分が抜け落ちてます。

ボードゲームがつまらないから弾幕バトルを足した？その悪手

推測でしかないですが、制作チーム側のテストプレイで「面白くない」ってなった結果、ボードゲームに弾幕バトルを足すことで何とかしようとしたのではないでしょうか。

アイデアとして悪くないように見えますが、悪手ですね。

まず、追加するだけでボードゲーム側のテンポが悪くなります。そして、ボードゲームのテンポが悪くしたくないからバトルが単純化されます。単純化されたバトルのゲーム性は、単純なのでつまらないものになります。つまり、二兎を追う者は一兎をも得ず。

ソシャゲ的に相性が良いのは、むしろ弾幕バトルの方ですが、その間にボードゲームが挟まっているので、 弾幕バトルが生かせないし、むしろボードゲームの面白さを損ねてしまった。

バトルとしてはそもそもサイコロを出し合う出目勝負があるわけで、弾幕バトルをあのくらい簡略化できればテンポを悪くしないでしょうが・・・

ソロプレイ用のゲームを作っておけば良かったですね。その中で弾幕バトルが主体になるようにボードゲームを調整すれば（すごろくをやめれば）良かったでしょうか。この辺の考察は、今から新しく作り直せレベルで無意味ですが、出口戦略として有っても良いかもしれませんね。

このゲームをもっと面白くするためのアイデア

面白くないものを面白くするにはどうすればいいかを考えるのは、如何に大変で辛いことなのか、ここまでを読んでくださった方には少しわかってもらえたかも知れません。

何故こんな修業が必要かというと、ゲーム制作においては、こういうことがまま存在するからです。最初の方に書きましたが、生まれてくるゲームが最初から面白いということは稀です。

どんなゲームでも面白そうという期待から生まれてきますが、作ってみたら想像以上につまらなかったということの方が多いです。何ででしょうかね。面白いと思った考えを正確精密に作れていないのか、そもそも面白いイメージは錯覚だからか、これも語ると長くなるのでここでは割愛します。

で

面白くないところはたくさん挙げて来ましたが

東方キャノンボールをこの状態から面白くするにはどうすればいいか。

面白くないと叫ぶことは簡単で誰にでもできます。

ゲーム作る人ならここからです。どうすれば面白くなるのか。

絶望的な状況をどうやって好転させるか。

・・・

偉そうに書きましたが、正直に申しますと自分もかなりお手上げ状態です。

作り直した方がいいじゃないかと思いますが、現実はそうはいかないでしょう。開発費に何千万、何億とかかって出来上がったものを捨てるのは、会社が傾くレベル。追加開発の予算も厳しい、出来るだけ少ない工数で、速効性があり、事態を急速に好転する何か。それは何なのか。

マイナスイベントの調整や、バランス調整は平行してやるとして、やはり「虚無」を何とかしたいですね。これさえ何とかすれば、まだ助かる可能性がありそうです。・・・まったく、何でボードゲームを選んでしまったのか。そこでもう無理だろと思考停止しそうになる自分がいる。

キャラの育成に応じて移動距離が増える

ボードゲームとソシャゲが噛み合ってない部分の一つとして、育成結果がボードゲームにあまり反映されていない所があります。サイクルでの育成が探索中にメリットとして目に見えないと育成する意味がないですよね。

そもそも東方キャノンボールは育成が一気に終わって、育成が停滞する状況もサイクルとしては大変よろしくないんですが、そこを今から変更するのは厳しいかなぁ。

育成しても変わらぬ状況は虚無を生みます。

現状、育成によるボードゲーム上の効果は、出目勝負時のサイコロの数、資産獲得費、資産収益ですね。これにもっと目で見て育成結果を楽しめる要素を足しましょうか。

例えば、移動に使うサイコロの数を育成に応じて足しましょう。そしてマップもだんだん広大にしましょうか。そうすればマップの幅を作れますし、移動にかかるテンポもキャラの育成によって一度に移動できる距離が増えているので、育成次第で初期マップと変わらぬテンポで移動できるはずです。

他にもボードゲームに与える要素とキャラの育成結果を結びつけて面白くなりそうな要素はあるかもしれません。そのような部分を追加することで虚無感を薄めることが可能なはず。

マップにボーナス宝箱を配置

全く同じマップに同じ行動が虚無を生み出しているので、ここにランダムなプラス放浪システムを追加してみるのはどうでしょうか。

例えば、開始時に稀にボーナス放浪キャラを出現させて、何ターンか経つと逃げてしまうようにする。その放浪キャラと同じマス目にとまって出目勝負に勝つと、ものすごいボーナス（そのマップクリア時の１０回分くらい）を得られるみたいな。注意しなければならないのは、プラスイベントであることと、達成して必ず喜べる報酬が得られることです。

今の東方キャノンボールは、プレイヤーが不利になるようなシステムばかりを入れていますので、方針転換して欲しいですね。不利になって面白いと思える人の方が稀なんです。

とりあえずこんなところですかね・・・

このゲームの根幹であるボードゲームを面白くしないと未来はないと思います。プレイヤーが気持ちよく周回できるようにしていって欲しいですね。運ゲーなのに高難易度クエストみたいなのは合わないと自分は思います。

その他改善すべき点

〇総資産に適したスキル

スキルが最初に使用できるまでに４ターンとかかかりますが、総資産ルールの場合、３ターンぐらいで決着がつくので、このゲームのスキル要素を無意味にしてしまっている現状があります。

総資産の条件で達成が必要な資産量をもっとターンがかかるようにするか、スキルが使用できるまでのターンをもっと早めるかだと思います。ターンがかかるようにするのは、テンポを悪くするだけなのでおすすめできません。

〇総資産ルールでの報酬増加

一部イベントでは実装されていたのもありましたが、このゲームのクエストクリア報酬は終了時の資産が多いほど多くなるので、ターンを出来るだけ長く経過させて資産を稼ぐプレイが普通になってますが、これが１プレイのテンポの悪さを招いています。

調整次第ではありますが、クエストクリアまでのターン数が短いほど報酬を増加させるべきだと思います。特に、総資産ルールでは長くても５ターンぐらいで決着が必ず付くので、他のルールより報酬が少なくなるので、同じとまでは行かずとも、10ターン以内ならフルターン経過に近いレベルの報酬を貰ってもいいと思います。

ようするに、ターンが短いほど報酬をよくするシステムを入れるべき。

〇現在のターン数

これは単にUIですが、現在の経過ターンを見る方法が、かなり面倒な手間がかかるので、ボード画面上のどこかに表示するべきだと思います。クエストのチャレンジ項目に「１０ターン以内」とかあるのに、現在のターン数をすぐ確認できないのはすごく気になります。

配合のお助けアイテム

ダビマス初心者を卒業するには、配合を自分で考えることが不可欠です。しかしながら、配合の仕組みは複雑で、どうすれば完璧な配合になるのか分からない人が多いと思います。

そこで！

手っ取り早く配合を理解できるスプレッドシートをご用意しました！

配合計画書（公開用）

コピーを作成を実行すれば、自分のGoogleドライブに編集できるファイルを保存できます。Googleアカウントをお持ちでない方は、形式を指定してダウンロードからエクセルファイルなどにしてダウンロードしてください。

系統や因子はスプレッドシート内の各セルがそれぞれリンクするようになっているので、一番古い祖先のデータを入力すれば、他の全ての空欄に自動的に入力されるようになっています。

例として、ダイワメジャーとエイシンサニーが最初から入力されています。

この配合計画書をよく見て、実際に入力してみれば、配合の血統や因子がどのように引き継がれていくかを理解できると思います。

完璧な配合を目指す

完璧な配合を生み出す条件

1. 牡馬の親系統のすべてが7種類以上（1つまで重複できます）
2. 牡馬の黄色部分の系統、牝馬の黄色部分の系統が同じ

この2つの条件を同時に満たす必要があります。

1については、種牡馬の親系統が最初から7種類になっている馬もいれば、系統が重なりまくって4種類や5種類の馬もいます。

7種類でない牡馬は、一度牝馬と配合して、配合後に7種類になるようにします。これをダビマス用語で「薄める」と言うらしいです。

また、1だけを満たす配合をゲーム内では「面白い配合」として表示されます。面白い配合を意識すると、次の代で完璧な配合を狙えるということです。

2については、順番は問題ありません。また、2種類以上同じであった場合、例えば、牡馬の黄色部分がRoNaNaHaであったなら、牝馬はHaNaHaRoでも大丈夫です。組合せが同じなら有効になります。

2だけを満たす配合をゲーム内では「見事な配合」として表示されます。つまり、面白い配合＆見事な配合＝完璧な配合となります。

ちなみに「よくできた配合」は、 黄色部分の3つの系統が同じであるときに表示されます。

配合計画書を使い、緑色と黄色（ゲーム内の血統表と同じ個所に同じ色を塗っています）部分の系統を「完璧な配合」の条件になるように調整しましょう。

カラムーン1974による実例　その１

さて、配合の基本を理解しただけでは、「実際どうすればいいの？」という壁に直面すると思いますので、これから実例を示しながら、どういった手順で何を目標に配合を考えればいいか、それを書いていこうと思います。

ここからは難易度ハードなので心して読んでください。

まず、BCに登録したい馬に「非凡な才能」を付けたい場合、カラムーン1974など非凡な才能をもった馬を牡馬にして配合する必要があります。

では最初に、カラムーンの血統表を見てみると、こうなっています↓

ではこのカラムーンで「完璧な配合」は可能でしょうか？

正解は、不可能です。

牡馬である緑と黄の親系統を数えてみてください。

Ns、Ec、Ec、Ec、St、He、Fa、Ph、何種類でしょうか。

6種類ですね？つまり、完璧な配合の条件の1つ目、7種類以上の系統を牡馬が持ってないと、どうやっても完璧な配合になりません。なので、まずはこのカラムーンを薄めて、系統が7種類になるようにするのが第1目標です。

実例　その２

次に意識しなければならないのは、因子です。

カラムーンを薄めて使う前提で、因子はどうなるでしょうか。

カラムーンを薄めたときの系統と因子はこうなります↓

牝馬部分はまだ何にするか決められないので、確定している部分だけで、このカラムーン産馬と因子がクロスするような配合を考えます。

狙い目は「短」因子が付いている

• 底短　Grey Sovereign
• 気短　Nasrullah

この辺りでしょうか。もちろん狙えるなら、なるべく多くの因子とクロスするようにした方がいいです。ここでは分かりやすく、この2種類の因子のみを考えて配合を組み立てます。

確定している部分のみで条件を考えると、このカラムーン産馬のお相手は

• Grey Sovereign 、 Nasrullahの因子どちらか（両方）持っている
• 親系統の黄色部分に、Ec、Faが含まれている

ここまで条件を絞ることができます。

実例　その３

では、次にカラムーン産馬のお相手を探してみましょう。

ゲーム内の配合掲示板では、牝馬をある程度検索することができます。

牝馬検索ボタンから、左下のボタンを押して表示順変更を開き、下にスクロールさせると系統の絞り込み設定部分があります。

配合掲示板などゲーム内で指定できるのは、黄色部分の1つ目（父系統）と3つ目（母父系統）になります↓

実例その２で確定していた、カラムーン産馬との完璧な配合で、Ec、Faを含む必要があるのは覚えているでしょうか。

一番手っ取り早いのは、この検索で、Ec、Faを指定して検索に引っかかるかどうかですが・・・

検索ヒット数・・・０！

2つ目と4つ目の条件も指定出来たら、もしかすると条件に合う牝馬がいるかもしれません。

全ての牝馬情報から、手探りでEc、Faを含む牝馬を探すのも一つの手段ですが、今回は「なければ作ればいいじゃない」ということで、カラムーン産馬のお相手を自家製牝馬にしてみましょう。

実例　その４

自家製牝馬の条件は、以下の通りです。

• Grey Sovereign 、 Nasrullah の因子
• 親系統が、Ec、Fa

・・・Ec、Fa、実は配合で非常に厄介な系統でして、

種牡馬で該当する父系統を検索すると

Ec種牡馬は

• 凄馬 ☆5ニットエイト1968
• 凄馬 ☆5ナオキ1975
• ☆1ワンモアライブ

Fa種牡馬は

• ☆5アイランドホワール
• 凄馬 ☆5 アウザール1992
• ☆5ホクトシチセイゴー20xx
• ☆4アイランドホワール
• ☆3リンドホシ

と入手困難または、微妙な種牡馬しか存在していないので、自家製を作る上で、Ec、Fa系統は工夫してやる必要があります。

例えば、種牡馬を父系統ではなく、母父系統で検索すれば、☆5ギャロップダイナなど、比較的入手が楽な種牡馬を指定したりできます。

・・・ここで悩みます。このまま条件が厳しいEc、Faの種牡馬を目指すと、肝心の短因子のクロスを厳選できません。

配合計画で難しいのは、系統条件を満たしつつ、因子が入っている自家製馬を考え出す、これが難題です。

実例　その５

種牡馬検索、牝馬検索を使って、Ec、Faを持ちつつ、短因子がクロスできそうな馬がひとつ見つかりました。

☆3カミノテシオです。

今回はこれを使って行きます。カミノテシオを使ったときの自家製牝馬はこうなります↓

カラムーン産馬の因子とクロスする部分が、丈長のPrice Bio、気短のNasrullahと、いい感じに因子が付きます。

そして、黄色部分にFaを持たせることが出来ました。

あとは、Ecを持ってる牝馬を探しましょう。

・・・Palestineがあるセカンドアニバサリが良い感じです。

この時、良い因子を持ってる牝馬が見つからなかったときは、少しでも生まれてくる牝馬のスピスタアップを狙って、カミノテシオと「よくできた配合」になるような牝馬をあてがうのも有りです。

今回はセカンドアニバサリと配合してみます。

これで、カラムーン産馬のお相手は完成です。

あとはカラムーン産馬の確定していなかった牝馬の部分を決めましょう。

自家製牝馬の黄色部分が、St、Fa、Ma、Ecなので、カラムーン産馬も同じ系統になるようにします。

実例　その６

カラムーン産馬で牝馬を探すときに忘れてはいけないのは、産馬の系統が7種類以上になっていないといけない、ということです。

つまり、産馬の残りの空白部分は、

• 黄色部分は、St、Ma
• 緑色部分は、NsEcStFaMa以外の系統

で埋めないといけません。

配合掲示板の牝馬検索では、絞り込み設定で、父系統、母父系統ともに、NsEcStFaMaのボタン「以外」を押して検索します。

そして、黄色部分の2つ目と4つ目が、St、Maの組み合わせになっているものを探します。

・・・現状、血統表ボタンを各々押していき、2つ目と4つ目を目視で確認しつつ探すしか方法はありません。気合で探しましょう。（父母父と母母父も検索できるようにならないかな）

・・・（15分ほどポチポチ血統を確認中）・・・

・・・見つけました。アルカシヨンがいけますね。

散々探しても見つからないことがあります。そのときは、この牝馬も自家製で作りましょう。今回は見つかってよかった。

カラムーン産馬はこうなります↓

どうでしょうか。親系統は、NsEcStFaRoStNeMaと、St被りですが7種類以上の条件1をクリアしていますし、黄色部分が、EcFaStMaとStFaMaEcと4つ同じ系統の条件2もクリアになってますね。これでカラムーン産馬とカミノテシオ産馬は完璧な配合になります。

まとめ

いかがだったでしょうか。

今回は、強引に2代で完璧な配合を目指しましたが、上級者になると、完璧な配合を3つ連続で続くような配合（その場合はたいてい、因子クロスは1ついければOK）を考えたり、自家製牝馬のスピードスタミナ（スピスタ）がAAになるまで配合を繰り返し、それからその牝馬を土台に本命の配合計画を作る、みたいなやり方もあります。

また、このような完璧な配合計画を、いざ実行してみても、たいして強くない馬しか生まれてこないというパターンは往々にしてあります。

そこがダビマスの罪深い所であったり、奥深い所であったり、面白い所であったりするので、みなさんもオリジナルの配合計画を立てて楽しみませんか？ダビマスがもっと面白くなると思います。