リサーチ

Windows 11 22H2 以降の HEVC サポートとは

CodecNeededWindows 11 22H2 以降では HEVC (H.265) 動画を再生できるのか、確認してみました。

詳細は Zenn をどうぞ:
https://zenn.dev/shinta0806/articles/hevc-support

次期パソコンイメージ

2019 年に購入した現行パソコンも十分な性能を持っているものの、次は AI / VR ready PC にしたいな、ということで、次をイメージしてみる。来年くらいに買えたらいいな。

本体

パーツ型番想定価格(税込)
名称次期メインマシンイメージ(2024/06)
360,000 円
マザーボードASUS
20,000 円
CPUIntel Arrow Lake
50,000 円
GPUGeForce RTX 4070 Ti SUPER 16GB
140,000 円
メモリ128GB
50,000 円
システム SSDNVMe PCIe 4.0 7,000MB/s 級 1TB
10,000 円
データ SSDSATA 8TB (4TB × 2)
60,000 円
光学ドライブ現行 PC 流用
0 円
ケース未選定
15,000 円
電源未選定15,000 円

CPU:長らく停滞していた Intel が再起動したので、Intel 製 CPU にしようかな。とはいえ、ノート PC 向け Core Ultra (Meteor Lake) は面白いものの、デスクトップ向け (Arrow Lake) はどうなるか不透明。

GPU:今までは消費電力の低いものを選んでいたが、今回はそうもいかない。AI モデル格納用に VRAM は多めが良いが、4060 Ti 16GB は性能が微妙らしいので、1 つ上で。

メモリ:VRAM に格納できないモデルデータをメインメモリに置けるようになってきているので、メインメモリは多めに。

価格がかなり高くなってしまうので、GPU を格下げして、データ SSD も現行 PC 流用するなどして、25 万円くらいまで抑える必要があるかもしれない。

周辺機器として VR 機器も必要だし……。


WinUI 3 で気に掛ける issue メモ

WinUI 3(Windows App SDK)公式 issue のうち、気になる issue のメモ(随時更新)。

microsoft-ui-xamlWindowsAppSDK に分かれているのが使いづらいが……。

未解決


解決済


Microsoft Store 審査時間

StoreTimeMicrosoft Store でアプリを公開しようとする際、審査(認定)の所要時間はどれくらいか、実際に 23 回審査してかかった時間をまとめてみました。

詳細は Zenn をどうぞ

ニコカラメーカー 2 vs 3 速度比較ベンチマーク

ニコカラメーカー 23 の速度を比較してみました。

プレビュー速度

プレビュー 1 フレーム当たりの処理に要する時間の比較です(1 スレッドの場合)。

ニコカラメーカー 2ニコカラメーカー 3速度向上率
15.68 ms
8.07 ms
94% up

MP4 出力速度

MP4 動画出力に要する時間の比較です。
ニコカラメーカー 2 には MP4 出力機能はないので、無圧縮 AVI で出力し、HandBrake でエンコードしています。
ニコカラメーカー 3 は直接 MP4 出力しています。
いずれも、H.264 (AVC) CRF 18 でエンコードしています。

ニコカラメーカー 2ニコカラメーカー 3速度向上率
無圧縮 AVI 出力:0 分 39 秒
MP4 エンコード:0 分 23 秒
合計:1 分 2 秒


0 分 36 秒
75% up

無圧縮 AVI 出力速度

無圧縮 AVI 動画出力に要する時間の比較です。

ニコカラメーカー 2ニコカラメーカー 3速度向上率
0 分 39 秒
0 分 31 秒
26% up

まとめ

ニコカラメーカー 3 は様々な場面で処理速度が向上しており、効率的にカラオケ字幕付き動画を作成できるようになります。

補足

  • 測定は開発者環境で行っています。
  • 素材動画は 1 分 00 秒、FHD、30 fps です。
  • ニコカラメーカー 2 には処理速度測定機能がないため、ニコカラメーカー 3 でニコカラメーカー 2 Ver 13.00 相当の処理を再現した上で測定しています。このため、厳密にはニコカラメーカー 2 の速度ではなく、参考数値となります。
  • ニコカラメーカー 3 は Ver 1.01 相当の処理速度計測用開発バージョンを使用しています。


テーマの実際の色等をコードで取得する(C# / WinUI 3)

テーマで指定されている色が実際何色なんだ、というのをコードで取得する方法を整理しました。

詳細は Zenn をどうぞ

WPF vs WinUI 3 機能対比表

WPF から WinUI 3 に移行する際に迷ったところを一覧にしました。

詳細は Zenn をどうぞ

ニコカラ作成 PC 環境アンケート結果

みなさんのカラオケ字幕動画(ニコカラ)作成環境(パソコン性能など)について、アンケートに回答いただきありがとうございます。

現時点でいただいた 50 件の回答について、特徴的なところをご紹介したいと思います。

PC 本体について

デスクトップ or ノート

DesktopOrNote8 割近くの方がデスクトップをお使いです。

日本の PC 出荷台数(2022 年)を見てみると 8 割以上がノートなので、今回の結果は真逆です。

動画を扱うクリエイティブ領域ではデスクトップが便利だということかと思います。

PC メーカー

Maker半数近くが自作でした。動画を扱う PC となると高性能のものが良いですが、予算は有限です。性能を割り振りたいパーツを自分で決めたいとなると、自作が一番ということなのかもしれません。

メーカー製では僅差でサードウェーブ(ドスパラ)がトップ、続いて DELL とマウスコンピューターでした。

メモリ容量

Memoryなんと、4 割の方が「32 GB 以上」でシェアトップです。世間ではようやく 8GB が標準になってきたかなという感じですが、みなさんはメモリを盛り盛りにされているようです。確かに、動画を扱うならメモリは多めが良いですよね。

ちなみに私も、主に開発がやりやすいという理由でメモリは 32 GB にしています。

しかし、こんなことになるなら「32 GB」と「64 GB 以上」で選択肢を分けておいた方が良かったですね……。

動画出力先ディスク

OutputDisk動画出力先ディスクは、過半数の方が HDD でした。

恐らく C ドライブは SSD の方も多いのではないかと想像していますが、動画出力用ともなると大容量が必要になりますので、HDD の出番ということなのでしょう。

HDD に無圧縮 AVI を出力するのはかなり時間がかかりますので、ニコカラメーカー 3 では是非とも MP4 出力を実装したいと改めて思いました。

ソフトウェアについて

OS

OS3 分の 2 の方は Windows 10 を使い続けています。Windows 11 にアップグレードする積極的な理由がないということなのでしょう。

ただ、マルチディスプレイをお使いの方は Windows 11 にアップグレードしたほうが便利なのではと思います。Windows 11 の場合、ディスプレイのみ電源 OFF にしたり一時的に切り離したりした後、マルチディスプレイに復活させた際、アプリのウィンドウ位置が自動的に復元されます。私の環境では、ということなので、全部の環境でそうなるのかは分かりませんが。

字幕作成アプリ

Subtitle4 分の 3 の方がニコカラメーカー 2 でした。

その他、初代ニコカラメーカー、Aegisub などです(txt2ass と Aegisub を併用されている方は Aegisub でカウントしました)。

パート分け表示用アイコン作成アプリ

過半数の方はパート分けアイコンを作成しないということでした。

作成される方のアプリは様々で、特にこれが人気というのはなかったのですが、ペイントや Office などのプリインストールアプリで作成されている方もいらっしゃいました。

カラフル×メロディパート分けアイコンをご存じないという回答もあったので補足しますと、歌手が 2 人以上いる場合、右のようにアイコンを付けることでデュエット等で歌いやすくなります。

歌詞ファイルは
<M>[00:03:00]あいうえお[00:09:00]
@Emoji=<M>,ミク.png
のように、アイコンを入れたい箇所に目印(この例では"<M>")を入れ、@Emoji タグで目印に画像ファイルを割り当てます。

EmojiTag@Emoji タグは RhythmicaLyrics の[ツール → @ タグオプション]メニューで入力することで、歌詞ファイル出力時に @Emoji タグも出力されます。

パート分けアイコンを付けることで、歌詞の色分けを自動的に行うことも可能となり、ニコカラメーカー 2 での作業が楽になります。詳しくはニコカラメーカー 2 ヘルプをご覧ください。

(追記)
本記事公開後のアンケート回答にて、匿名で「動画について指摘するのとコキおろすのは違うと思いますよ?」とのご意見をいただきました。
匿名のため詳細は不明ですが、もし、パート分けアイコン動画について知らないことをコキおろしていると誤解させてしまったのだとすれば申し訳ありませんでしたが、パート分けアイコンについて記載したのは情報提供のためで、コキおろす意図は無いことを申し添えておきます。
なお、今後は連絡先未記載回答へのご案内は差し控えさせていただきます。

その他

ニコカラメーカー 3 へのリクエスト

たくさんのリクエストをいただきありがとうございました。とても参考になります。

やはり MP4 出力のリクエストは多く、是非とも実装したいと思っています。

ニコカラメーカー 2 で既に実現している機能をお書きいただいた方も複数いらっしゃいました。今回のアンケートでは、9 割の方は連絡先を書いてくださっていたので、その方々には個別にやり方をご連絡いたしました。

エピソード

歌えて良かった、本家様から反応をいただけた等、何かしらの反応をいただいたというお声が比較的多かったように思います。やはりそういうのがあると作って良かったと思えますよね。

中には、ニコカラ作りがきっかけでお付き合いが始まったり、ゴールインされたかたもいらっしゃって、末永くお幸せに。

なお、アンケート回答は引き続き募集しております。ニコカラを作成されている方でご回答がまだの方は、是非ご協力よろしくお願いします。



マシンベンチマークまとめ(モバイルマシン:Vivobook 14)

CrystalDiskInfo新しい Vivobook 14(詳細スペックはこちら)のストレージ性能を CrystalDiskMark で見てみた。

CrystalDiskInfo によれば、搭載されている SSD は Intel(現ソリダイム)SSDPEKNU512GZ。製品名的には 670p に該当。

M.2 NVMe PCIe 3.0 x 4、QLC。

CrystalDiskMark性能としては、
  • シーケンシャルリード:3,059 MB/s
  • シーケンシャルライト:1,651 MB/s
  • ランダムリード:47 MB/s
  • ランダムライト:84 MB/s
となった。

メインマシンの SSD も PCIe 3.0 だが、それと比べると特にライトが遅く、シーケンシャルライトは△34% の性能悪化、ランダムライトに至っては△61% と半分以下の性能である。

とはいえ、モバイルノートとして出先で使う分には十分すぎる性能。

プロセスちなみに、ストレージ性能には影響しないと思うが、ASUS のサービスは結構いろいろ動いている。

日本製のノーパソ(というのも今や少ないが)はアプリがわんさかインストールされているなどと批判が多いが、海外のものも、アプリという目に見える形ではなく、むしろステルスでいろいろインストールされているようだ。

マシンスペックまとめ(モバイルマシン:Vivobook 14)

Vivobook14新しく購入したモバイル(?)ノート PC「ASUS Vivobook 14」のスペックを整理。

購入価格はお正月特価で 99,800 円。

パーツ型番
名称ASUS Vivobook 14
(M1402IA-EK127WS)
ディスプレイ14.0 型液晶(ノングレア、TFT、タッチパネル非対応)
1920 x 1080(フル HD)
CPU
AMD Ryzen 5 4600H (Renoir)
(6 コア 12 スレッド、基本クロック 3.0 GHz(ブースト 4.0 GHz)、cTDP 35W、7nm プロセス)
メモリ
8GB
(DDR4-3200?(PC4-25600?)、8GB x 1)
SSD
512GB
(Intel (Solidigm) 670p SSDPEKNU512GZ M.2 NVMe PCIe 3.0、QLC)
光学ドライブ
なし
ビデオカード
オンボード
(Radeon RX Vega 6)
サウンドカード
オンボード
有線 LAN
なし
無線 LAN
IEEE802.11ax/ac/a/b/g/n 準拠
(Wi-Fi 6 2x2、最大 1.2 Gbps?)
Bluetooth
Bluetooth 5.1? 5?
WAN
なし
インカメラ
720p
外部インターフェース
HDMI 1.4 x 1
USB 2.0 x 1(本体左側)
USB 3.2 Gen1 Type-A x 2(本体右側)
USB 3.2 Gen1 Type-C x 1
マイク・ヘッドフォン出力端子
電源入力
バッテリー
約 9.4 時間駆動
質量
本体 1.5kg + AC アダプタ
OS
Windows 11 Home
Office
Microsoft Office Home & Business 2021


ASUS 公式サイトに正確なスペック情報が記載されていないのが驚きだが、型番のうち M1402IA までのスペックシートはある。並列記載ばかりであまり役に立たないが……。
Vivobook 14 の第 2 世代の何か、ということなのかもしれない。

箱商品の箱にいくつかの項目のスペックが記載されている。右がその写真。

詳細なスペックはヨドバシのサイトに記載がある。さすがヨドバシ。
リュック付属品として、有線マウスとキャリー用リュックが付いてくる。リュックは、ドンキとかで 3,000 円くらいで売ってそうなイメージのやつ。

MS Office 込みでこの価格。Office 単体だと定価 38,284 円だが、PC とセットだとだいたい 3 万円くらいなので、Office なし版がもしあるとすれば本体価格は 7 万円くらいだろうか。

本当は防水ノート PC が欲しかったのだが、これといったのが見当たらなかったので、防水は諦めて適当なのを買った感じ。AC アダプタ込みで恐らく 1.8kg くらいある(物理的に)重いノート PC だが、この価格で普通に使えるモバイル(?)パソコンとしては悪くない選択肢だと思う。

防水で LTE 付きの良い感じのパソコンなり Windows タブレットなりが登場したら買い直したい。

使い勝手

MyASUSデフォルトではファンクションキーは、そのまま押すとディスプレイ輝度調整などとなり、Fn キーと共に押すと本来のファンクションキーとして機能する。

逆にしたい場合は、MyASUS アプリ(ユーザー登録を促されるが未登録でも使える)の「カスタマイゼーション」のところで変更できる。




SetWindowSubclass によるウィンドウプロシージャーのカスタム(C# / WinUI 3)


はじめに

GitHub標準のイベント等では処理できないウィンドウメッセージ(WM_*)を処理したい場合、自前のウィンドウプロシージャー(WndProc)を作る必要があります。

C# では、WinForms(フォーム)や WPF なら、ウィンドウプロシージャーをカスタムする仕組みが用意されている(HwndSource)ので簡単なのですが、WinUI 3(Windows App SDK)には残念ながら今のところそのような仕組みはないようです。

結局ネイティブ Windows API を使うしかないようですので、その方法をまとめました。Windows API なので WinUI 3 専用ではありませんが、出番としては WinUI 3 で開発するときくらいかと思います。

はやいとこ WinUI 3 にも簡単な仕組みが用意されることを祈っています……。

サンプルプログラムのソースコードは GitHub に上げてあります。

使用する API

ウィンドウプロシージャーをカスタムするのを「サブクラス化」と呼んでいるようです(C# でいう派生クラスではありません)が、マイクロソフトのドキュメントによれば、サブクラス化は新旧 2 種類あります。

旧バージョンでは SetWindowLong() or SetWindowLongPtr() と CallWindowProc() を使います。欠点は先のドキュメントにいろいろ書いてありますが、個人的にはそれよりも、元のウィンドウプロシージャーを自前で管理する分、手間が増えるのかなと思います。

新バージョンでは SetWindowSubclass() と DefSubclassProc() を使用します。元のウィンドウプロシージャーは気にしなくて済みます。

ここでは新バージョンを使います。

というか、新バージョンの情報が少なくて苦労したというのもあってここにまとめたというのもあります。

やりかた

ウィンドウメッセージを扱うので、NuGet で PInvoke.User32 を入れておきます。

カスタムウィンドウプロシージャーの型(SUBCLASSPROC コールバック関数)をデリゲートとして宣言しておきます。型の詳細はこちらに書いてあります。

internal delegate IntPtr SubclassProc(IntPtr hWnd, User32.WindowMessage msg, IntPtr wPalam, IntPtr lParam, IntPtr idSubclass, IntPtr refData);

カスタムウィンドウプロシージャーを作成します。

自分が処理したいメッセージの部分だけ書いて、あとは元のウィンドウプロシージャーに丸投げします。

private IntPtr CustomSubclassProc(IntPtr hWnd, User32.WindowMessage msg, IntPtr wPalam, IntPtr lParam, IntPtr idSubclass, IntPtr refData)
{
    switch (msg)
    {
        case User32.WindowMessage.WM_HogeHoge:
            (処理)
            return IntPtr.Zero;
        default:
            // 関心のあるメッセージ以外は次のウィンドウプロシージャーにお任せ
            return DefSubclassProc(hWnd, msg, wPalam, lParam);
    }
}

カスタムウィンドウプロシージャーを登録します。

_subclassProc = new SubclassProc(CustomSubclassProc);
SetWindowSubclass(hWnd, _subclassProc, IntPtr.Zero, IntPtr.Zero);

注意点の 1 つめは、SetWindowSubclass() に渡すのはカスタムウィンドウプロシージャー本体を「インスタンス化」したもの、ということです。インスタンス化していない CustomSubclassProc も SetWindowSubclass() に渡せてしまいますが罠です。

注意点の 2 つめは、そのインスタンスをずっと(カスタムウィンドウプロシージャーが不要となるまで)持ち続ける、ということです。

Crashこれらを守らないと、特に 64 ビットバイナリ(x64)において、一見うまく動くようですが、メッセージ処理をこなしているうちにアプリが強制終了します。私はこれでハマりました。

強制終了時は集約エラーハンドラーにすら引っかかりませんでした。デバッガーでは以下の箇所で落ちていました。

global::Microsoft.UI.Xaml.Application.Start((p) => {
    var context = new global::Microsoft.UI.Dispatching.DispatcherQueueSynchronizationContext(global::Microsoft.UI.Dispatching.DispatcherQueue.GetForCurrentThread());
    global::System.Threading.SynchronizationContext.SetSynchronizationContext(context);
    new App();
});

サンプルプログラム

Sampleサンプルプログラム(GitHub に上げてあります)では、ウィンドウのタイトルバーにヘルプボタンを表示しています。

このコンテキストヘルプは WinUI 3 標準ではハンドルできないため、カスタムウィンドウプロシージャーで処理しています。

ヘルプボタンをクリックする度に、ウィンドウのサイズが変化します(アプリとしてはありえない動きですが……)。

ちなみに、SetWindowSubclass() にインスタンス化していない CustomSubclassProc を直接渡すようにコードを変更すると、うちの環境で x64 バイナリを実行すると、チェックボックス連打で 1 分もしないうちにアプリが落ちました。

【追記】
Zenn をはじめてみました。試しにこの記事を Zenn に再掲してみました。

WinUI 3 立ち位置メモ

アーキテクチャー的に? 構造的に? 階層的に? WinUI 3 がどのへんにいるのかがよく分からないので、調べてみた。

※情報をご存じの方はご教示いただけると幸いです!

今のところの想像はこんな感じ。

階層図2

以下元ネタ。

ニコカラメーカー 3 のイメージ

まだまだ先の話だけど、ニコカラメーカー 3 はこんな感じにしたいかも、というのを。

mp4 出力

AVI と連番 PNG に加え、MP4 も出力できるようにしたい。映像は H.264 (AVC) と H.265 (HEVC) の両方に対応できればベター。

基礎実験はうまくいったので、研究を重ねていけば実現できる……かもしれない。

さらなるマルチスレッド化

ニコカラメーカー 2 は字幕処理をマルチスレッドで高速化しているが、最大 8 スレッドまでしか対応していない。Ryzen 9 5950X が 32 スレッドの時代、より多くのスレッドに対応したい。

とはいえ、実現の目処はまったく立っていない。まぁ、字幕処理 8 スレッド、mp4 エンコードで残りのスレッド、という分担でも悪くはないのかもしれない。

ハードウェアブラー

ニコカラメーカー 2 ではブラー処理が遅い気がしていて、ソフトウェアでブラー処理されている気がしなくもない(未確認)。ハードウェアで処理できれば速くなるのではないか。

Fluent UI

ニコカラメーカー 2 は UI にマテリアルデザインを採用しているが、時代は進み、Fluent UI の時代になりつつあるかもしれない。

とはいえ Fluent UI は発展途上なので、いつまともに使えるようになるのかは不明。


保存用動画は CRF(固定品質)モードでエンコードしよう

動画(の映像部分)をエンコードする際、「1-pass」「2-pass」「VBR」「CRF」などいくつかのモードを選べますが、どれを選べばいいのでしょうか?

Understanding Rate Control Modes (x264, x265, vpx)(英語記事)によれば、使用目的によって選ぶべきモードが異なり、
  • 保存用(HDD・SSD から再生する動画)……CRF でエンコード
  • ストリーミング(YouTube・ニコニコ動画などのサーバー側)……2-pass VBR 等でエンコード
とのことです。

YouTube などにアップロードする際はサーバー側で再エンコードされますので、アップロード前の動画は CRF でエンコードしてあっても問題なく、結局のところ、個人でエンコードする場合はすべて CRF でエンコードすれば問題ないでしょう。

英語記事にはその他のモードについても解説されていますので、詳しく知りたい方はどうぞ。

本記事では、保存用に動画をエンコードする場合として、CRF に焦点を当てます。

目次


CRF とは?

CRF(Constant Rate Factor:固定品質)を聞き慣れない方もいらっしゃるかもしれませんが、CRF は「映像を一定のきれいさでエンコードする」モードです。「とてもきれいにしてね」と言えばどんな動画でもとてもきれいにしてくれますし、「まぁまぁきれいにしてね」と言えばどんな動画でもまぁまぁきれいにしてくれます。

映像をきれいにエンコードするのに必要なビットレートは、映像の内容によって異なります。動きの激しい部分、テクスチャーが細かい部分には多くのビットレートが必要です。

CRF は、指定されたきれいさを達成するためにはどのくらいビットレートが必要なのかを自動計算し、激しい部分には多めのビットレート、動きの少ないのほほんとした部分には少なめのビットレートを割り当てます。

裏を返すと、CRF は「どんな動画でも一定のきれいさ」になる反面、「動画によりビットレート(ファイルサイズ)が異なる」ということになります。激しい場面が多い動画はファイルサイズが大きくなり、のほほんとした場面が多い動画はファイルサイズが小さくなります。

CRF と VBR の違い

CRFvsVBRVBR(ABR)も、激しい部分には多めのビットレート、のほほんとした部分には少なめのビットレートを割り当てるモードです。しかし VBR では、全体の平均ビットレートは指定されたビットレートになるように調整します。

つまり VBR は「どんな動画でも一定のファイルサイズ」(ある程度の調整が入ることがあります)になる反面、「動画によりきれいさは異なる」ということになります。激しい場面が多い動画は汚くなり、のほほんとした場面が多い動画はきれいになります。

VBR には 1-pass と 2-pass がありますが、1-pass VBR ではビットレートの割り当てが割と適当です。2-pass VBR は動画全体を確認してからビットレートの割り当てを行うので、最適な配分を行うことができます。VBR といえば実際には 2-pass VBR でエンコードすることが多いのではないでしょうか。

CRF と 2-pass VBR では、結果的に平均ビットレートが同程度になった場合、映像のきれいさも同程度になります。

CRF は 1-pass ですので、エンコードに要する時間は 2-pass VBR の半分程度で済みます。

まとめると、保存用動画を CRF でエンコードするメリットは、
  • いろんな動画をきれいにエンコードできる
  • VBR の半分の時間でエンコードできる
となります。

(補足)
たまに 2-pass CRF という表現を見ることがありますが、私はまだそれを知りません。2-pass CRF について詳しい方がいらっしゃいましたら、コメントで教えていただけると助かります。

HandBrake で CRF

logoCRF は比較的新しく登場したモードなので、すべてのエンコードソフトで利用できるわけではありません。内部的に x265 を利用しているエンコードソフトで利用でき、例えば、無料ソフトであれば HandBrake で利用できます。

HandBrake は本家サイトからダウンロードしてください。サイトは英語ですが、ソフトは日本語対応しています。2022 年 7 月現在の最新バージョンは 1.5.1 です。日本語版というサイトがありますが、日本語版はバージョンが古いので注意してください。

インストール後に起動した際、「.NET が見当たらない」的なエラーが表示される場合は、メッセージをクリックすると表示されるサイトから .NET をダウンロードしてインストールします。

必要なのは「.NET Desktop Runtime」です。名前の似ている「.NET Runtime」ではないので注意してください。Desktop の付かないほうをインストールしてもエラーは改善されません。

Launchインストール後に起動し、エンコードしたい元動画を指定します。

エクスプローラーから動画をドラッグ&ドロップすれば OK です。

Videoドロップするとタブが表示されるので、「動画」タブをクリックし、以下の設定にします。
  • 動画エンコーダー ➡ H.265 (x265)
  • フレームレート ➡ Same as source
  • 品質 ➡ 固定品質 24 RF
  • 保存先ファイル ➡ 拡張子を mp4 に変更
動画エンコーダーは H.265 の種類がいくつかありますが、特別な理由が無い限り「H.265 (x265)」が良いです。

フレームレートはいじると映像がぼやけたりするので、「Same as source(元動画と同じ)」にします。元動画のフレームレートによって、自動的に固定になったり可変になったりするようです。

CRF(固定品質)は数値できれいさを指定します。0~51 で指定し、「小さい方がきれい」です。H.265 の場合はデフォルトが 28 です。実質的な最小値は 24 で、それよりも小さくしてもファイルサイズが無駄に大きくなるだけとのことです。一般的な人間では見た目的に 24 未満のきれいさを見分けられないということなのでしょう。

個人的には、いくつかの動画できれいさを試した結果、CRF 24 を使用しています。

保存先ファイルで、デフォルトでは拡張子が .m4v になっています。m4v でも問題はありませんが、mp4 のほうが一般的だと思いますので、拡張子は .mp4 にしたほうが良いかと思います。

設定を終えたら「エンコード開始」ボタンをクリックすると、エンコードできます。

(補足)プリセットについて

画面下の方にプリセットがあり、HandBrake のデフォルトでは Fast になっています。ここをいじると、エンコードのスピードと画質が変わります。

詳しく調べていませんが、HandBrake のデフォルトの Fast か、H.265 のデフォルトの Medium あたりが無難なのではないでしょうか。

プリセットの詳細については x265 本家サイト(英語)に説明があります。

TMPGEnc で CRF

有料ソフトの TMPGEnc Video Mastering Works も CRF でエンコードできます。2022 年 7 月現在の最新版は 7 です。

Format2元動画をドラッグ&ドロップした後、出力フォーマット選択画面で
  • フォーマット別出力 ➡ MP4 ファイル出力
  • 映像ストリーム形式 ➡ H.265/HEVC
  • 映像エンコーダー ➡ x265
を指定します。

Syuturyoku続いて出力設定画面で、
  • フレームレート ➡ (元動画と同じものを指定)
  • レート調整モード ➡ VBR(固定品質)
  • 品質 ➡ 54
を指定します。

フレームレートはデフォルトで元動画と同じものが指定されているはずですが、念のため確認したほうが良いでしょう。

レート調整モードは「VBR(固定品質)」にします。VBR が 2 種類あるので、間違って平均ビットレートを選ばないように注意しましょう。

品質できれいさを指定します。HandBrake と異なり、「大きいほうがきれい」なので注意が必要です。HandBrake と TMPGEnc の数値の対応は以下の計算式で求められます。

[TMPGEnc 7 品質] = 102 - [HandBrake 品質] × 2
[HandBrake 品質] = 51 - [TMPGEnc 7 品質] ÷ 2

HandBrake で 24 に相当するのは TMPGEnc では 54 なので、個人的には 54 を使用しています。

ニコカラメーカー 3 で CRF

カラオケ字幕付き動画作成ソフト「ニコカラメーカー 3」(無料ソフト)も CRF でエンコードします。

ニコカラメーカー3[ツール → 環境設定]メニューで環境設定ウィンドウが開くので、「MP4 エンコード」パネルをクリックします。

ニコカラメーカー 3 はエンコード時に FFmpeg を利用しますので、予め FFmpeg をインストールしたうえで、FFmpeg の場所を指定します。

ニコカラメーカー 3 はエンコード設定をタブごとに複数保持しておくことができ、デフォルトで「高品質」タブが H.265 でのエンコードになっています。

映像エンコードデバイスは「ソフトウェア」のままにしておきます。

映像エンコードデバイスがソフトウェアの場合、「画質」は CRF 画質になります。数値は HandBrake と同じです。個人的には 24 を使用しています。

ニコカラメーカー3動画出力設定を終えたら、メインウィンドウの「動画出力」パネルをクリックします。

「出力形式」を MP4 にして、さらに「高画質」を選択すると、先ほど設定した高画質タブの内容でエンコードできます。

おまけ:H.265 と H.264

H.264 でも CRF モードエンコードができますが、数値が異なるので注意してください。


H.265H.264
デフォルト2823
実質的な最小値
(一番きれいな中でファイルサイズ小)
2418


一般的に、H.265 のほうがきれいでファイルサイズが小さくなりますので、通常は H.265 でエンコードすれば良いかと思います(ニコニコ動画は H.264 のみ対応のため、ニコニコ動画にアップロードする時だけ H.264)。

H.265 のほうが多少エンコードに時間がかかりますが、私の環境で、フル HD 30 fps の 3 分 11 秒の動画を HandBrake でエンコードした場合の所要時間は、
  • H.265 CRF 24 ➡ 2 分 06 秒
  • H.264 CRF 20 ➡ 1 分 41 秒
となりました。

H.265 のほうが 20% 程度多く時間がかかっていますが、目くじらを立てるほどではないかと思っています。

更新履歴

  • 2022/07/24 初版。
  • 2022/09/03 .NET Desktop Runtime について記載。
  • 2023/05/14 フレームレートについて追記。
  • 2024/03/22 ニコカラメーカー 3 について記載。
  • 2024/03/22 CRF と VBR の比較図を掲載。
  • 2024/10/25 H.265 と H.264 の比較表を掲載。


DirectX 系譜図 メモ

DirectX や Media Foundation 周りの関係性がいつも分からなくなってしまうので整理して系譜図にまとめた。
DirectX系譜図


メモ

  • DirectX には基本ランタイム(Windows プリインストールや Windows Update で入る)と追加ランタイム(Windows 8.x 以降で特定のバージョンがプリインストール)がある。
  • DirectX 1.0 は Game SDK として発表された。
  • DicrectInput は DirectX 1 から存在していたという記述もあるし、DirectX 3 で統合されたという記述もある。
  • DirectX 4 は欠番。
  • XACT 終了時の DirectX バージョンは不明だが、Windows 8 で廃止。
  • XAudio は Xbox 専用で、PC で使えるのは XAudio2。
  • D3D は 11 からビデオ再生ができる。

参考資料



エクセルでパート分けアイコンの飾り枠を作る

飾り無しアイコンカラオケ字幕動画でパート分け用アイコンを付ける際、キャラクター画像をそのまま使うのも良いですが、「飾り枠」を付けたくなる時もあるのではないかと思います。

馴染みのグラフィックスソフトがある方はそれを使えばいいのですが、普段グラフィックスソフトを使っていない方はエクセルで飾り枠を作ることもできますので、その作り方を整理してまとめました。

About本記事は Microsoft 365 Excel バージョン 2204 で動作確認していますが、比較的最近のエクセルであればだいたい似たような感じで作成できるのではないかと思います。

縮小されている画像はクリックで拡大できます。

目次


飾り無し

エクセルによる飾り枠の話の前に、飾り枠無しの状況もまとめておきます。

飾り無しキャラクター画像を加工せず、飾り無しのまま使った場合は右のようになります。

ニコカラメーカー 2 の @Emoji タグを使う際、NoDecor オプションを付けます。

@Emoji=【飾り無し】,アイコン_飾り無し.png,,NoDecor,MarginRight=7

@Emoji タグの詳細についてはニコカラメーカー 2 のヘルプ「インライングラフィックス」をご覧ください。

飾り無し拡大これはこれで味がありますし、また、使い方によっては効果的です。一方で、背景動画の色合いによっては視認性が悪くなることがあります。

ブラー

ブラーキャラクター画像を加工せず、ニコカラメーカー 2 の機能で飾りを付けた場合は右のようになります。

ニコカラメーカー 2 の @Emoji タグを使う際、NoDecor オプションを付けません。

@Emoji=【ブラー】,アイコン_飾り無し.png,,MarginRight=7

ブラー拡大キャラクター画像を加工する必要が無いため、手軽に使えます。一方で、飾りは字幕フォントと同じものを使うことになるため、字幕フォントの飾りに引きづられます。

凸枠

凸枠アイコンここからが本記事の本題です。

まず、少し立体的に盛り上がっているような飾り枠をエクセルで付けるやり方です。

外枠

凸枠1盛り上がる枠を作成するには、まず、エクセルの[挿入 → 図形 → 四角形]にある「四角形:角を丸くする」で角丸四角形を作成します。

作成時、必ず「Shift キーを押しながら」ドラッグして作成することにより、縦と横のサイズを同じ(正方形)にします。

ある程度大きめ(ニコカラメーカー 2 のフォントサイズ指定よりも大きめ)のほうが最終的にきれいになります。筆者環境では、エクセルシート 10 行くらいのサイズにすると、最終的なアイコンサイズが 200 ピクセル程度になりました。

凸枠2作成後にリサイズする場合は、右下のリサイズポイントで縦と横を同時にリサイズし、必ず「Shift キーを押しながら」リサイズすることにより、縦と横のサイズを同じにします。

凸枠3作成した角丸四角形を右クリックして表示されるメニューから「図形の書式設定」を選ぶと、右側で設定ができるようになります。

凸枠4[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で、塗りつぶしの色を指定します。今回はピンクにしてみました。

線は「線なし」にします。

凸枠5[図形の書式設定 → 図形のオプション → 効果]で、面取りを指定します。「丸」がシンプルで使いやすいと思います。

幅と高さは枠のサイズに合わせますが、枠を 10 行くらいで作成している場合、10 pt 程度で良いかと思います。

背景枠

次に、背景枠を作成します。この作業は、キャラクター画像が透過 PNG になっていて背景色が付いていない場合のみ行います。キャラクター画像に背景色が付いている場合は不要です。

凸枠6[挿入 → 図形 → 四角形]にある「四角形:角を丸くする」で角丸四角形を作成します。今回も Shift キーで正方形にします。

外枠よりも一回り小さい枠にします。

位置合わせがやりづらい場合は、エクセル右下の拡大率をアップさせるとやりやすくなります。また、細かな位置調整はマウスよりもカーソルキーのほうがやりやすいです。

[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で、塗りつぶしの色を指定します。白が使いやすいかと思います。

線は「線なし」にします。

キャラクター枠

凸枠7最後に、キャラクター枠を作成します。

[挿入 → 図形 → 四角形]にある「四角形:角を丸くする」で角丸四角形を作成します。今回も Shift キーで正方形にします。

[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で塗りつぶしを「図またはテクスチャ」にして、画像ソースの「挿入する」ボタンをクリックすると、ダイアログが表示されます。「ファイルから」を選び、キャラクター画像を指定すると、角丸四角形がキャラクター画像になります。

凸枠8キャラクター画像の位置やサイズを調整して、良い感じになるようにします。サイズ調整時は、必ず右下のリサイズポイントで「Shift キーを押しながら」リサイズし、正方形をキープします。

個人的には、頭の上に少し余白があるほうが見やすいかなと思います。

画像出力

ここまでできたら、いったんエクセルを(通常の xlsx 形式で)保存します。

凸枠9その後、[ファイル → 名前を付けて保存]で形式を「Web ページ (*.htm, *.html)」にして保存します(単一ファイル Web ページではないので注意してください)。

凸枠10例えば icon.htm というファイル名で保存すると、そのファイルを保存した場所に「icon.files」というフォルダーが作成され、「icon.files」フォルダーの中に複数の画像ファイルが作成されます。

通常は、最も番号の大きい画像ファイル(例:image004.png)が凸枠アイコンになっているかと思います。

凸枠そのアイコンファイルを歌詞ファイルと同じフォルダーにコピーし、ニコカラメーカー 2 で使います。

画像自体に飾り枠が付いているので、@Emoji タグには NoDecor オプションを付け、ニコカラメーカー 2 による飾りは付けないようにします。

また、MarginRight オプションでアイコンと歌詞の間に隙間を多少空けておくと、字幕が読みやすくなると思います。

@Emoji=【凸枠】,アイコン_凸枠.png,,NoDecor,MarginRight=7

凸枠拡大立体感があり視認性も良いアイコンになったのではないかと思います。

半透明ダブル枠

半透明ダブル枠アイコン半透明の枠を 2 重にした枠をエクセルで作るやり方です。

背景枠

最初に、背景枠を作成します。凸枠の時と同様、この作業は、キャラクター画像が透過 PNG になっていて背景色が付いていない場合のみ行います。キャラクター画像に背景色が付いている場合は不要です。

半透明ダブル枠1[挿入 → 図形 → 四角形]にある「四角形」で四角形を作成します(角丸ではなく通常の四角形です)。今回も Shift キーで正方形にします。

[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で、塗りつぶしの色を指定します。今回はエンジにしてみました。

線は「線なし」にします。

キャラクター枠

背景枠とキャラクター枠はぴったり同じ大きさにしたいので、背景枠をコピー&貼り付けして、新しく同じ大きさの正方形を作成します。

半透明ダブル枠2[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で塗りつぶしを「図またはテクスチャ」にして、キャラクター画像を指定します(凸枠の時とやり方は同じです)。

背景枠とキャラクター枠がぴったり重なるように位置を調整します。

半透明外枠

半透明ダブル枠3[挿入 → 図形 → 四角形]にある「四角形」で四角形を作成します(角丸ではなく通常の四角形です)。今回も Shift キーで正方形にします。

[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で、塗りつぶしを「なし」にします。

線を「単色」の「黒」にして、透明度を「50%」にします。

線の幅は適宜調整ですが、背景枠をエクセル 10 行分くらいで作成している場合、「10 pt」程度で良いかと思います。

半透明内枠

半透明ダブル枠4半透明外枠と同様にして、半透明内枠も作成します。

半透明内枠は、半透明外枠よりも 1 周り小さくします。

また、線の色は「白」、線の幅は外枠の半分「5 pt」にします。

画像出力

凸枠の時と同様にして PNG 画像を出力します。

背景枠・キャラクター枠・半透明外枠がぴったり重なっていれば PNG 画像は正方形になりますが、微妙にずれていると正方形の画像になりません。多少長方形になるのを許容するのも 1 つの手ですし、気になるようであれば、ペイントなどで正方形に切り取って保存し直しても良いでしょう。

半透明ダブル枠凸枠の時と同様、ニコカラメーカー 2 で使用する際は NoDecor オプションを付けます。

@Emoji=【半透明ダブル枠】,アイコン_半透明ダブル枠.png,,NoDecor,MarginRight=7

半透明ダブル枠拡大枠が半透明なので、キャラクターが枠と被っているところが逆に面白いのではないかと思います。








はじまるA列車 セーブデータ配布方法 まとめ

A列車で行こう はじまる観光計画(はじまるA列車)(Steam 版)のセーブデータを他のプレイヤーとやり取りするための方法をまとめて整理しました。

シナリオアップロード・ダウンロード機能があるのになぜそんなことをするのかというと、以下のように、はじまるA列車がもっともっと面白くなるのではないかと思うからです。はじまるA列車がさらに盛り上がると楽しいなと思います。

メリット

1. 自分の街を丸ごと紹介できる

自分が作った街を紹介したい時、ニコニコ動画などの動画サイトで紹介するのがメインです。

もちろんこれはこれで楽しくて、誰でも(はじまるA列車を持ってない人でも)手軽に見られるというメリットがあります。

一方で、
  • 録画にはハイスペック PC が必要
  • 動画編集スキルが必要
  • 動画の録画・編集に時間がかかる
  • 街の全てを紹介するのは事実上不可能
などのデメリットもあります。

セーブデータ配布は動画作成よりもはるかに簡単ですし、街を丸ごと見てもらうことができます。

動画では紹介しきれなかった細かい部分などを見てもらえて、Twitter などでコメントをもらえたりしたら嬉しいですね。

しかも、これはコンストラクションモードに限らずです。公式シナリオや他のプレイヤーの自作シナリオでの街づくりも紹介できます。

2. 他の人の街づくりを参考にできる

他のプレイヤーが作った街を丸ごと見ることができるので、動画では分からないような細かい工夫や、鉄道や子会社がどのくらい儲かるかなど、より詳細に学ぶことができます。

次回からの自分の街づくりに、大いに参考になるのではないでしょうか。

3. 攻略途中や攻略完了後のデータを披露できる

公式シナリオや、他の人が作成した自作シナリオなどを攻略している途中、あるいは、クリア後のデータを披露することができます。

攻略方法が同じだったとしても、実際の街づくりは他の人とは少しずつ違う形になると思います。そういう部分を比べてみるのも面白いのではないでしょうか。

「もうちょっと早くクリアできたかも」「この部分の街づくりはイマイチだったかなぁ」などの反省ポイントも含めて、お互い切磋琢磨できるかもしれません。

4. チームで自作シナリオを作れる

自作シナリオを作成するには数多くのステップがありますが、その全てが得意な人というのもなかなかいないのではないでしょうか。「会話シーン作るの苦手だから誰か作ってくれないかなぁ」とか。

「街づくり」「列車開発」「会話作成」などのステップを複数名で分担することで、それぞれの得意分野を持ち寄り、ハイクオリティーな自作シナリオを作ることができるかもしれません。

そういうハイクオリティーシナリオがたくさん登場すると、プレイする側も楽しいですね。

……というように、ぱっと思いつくだけでも、セーブデータ配布には多くのメリットがあります。これ以外にも、もっと可能性が広がるのではないでしょうか。

重要な注意事項

Build 30257.629 現在、公式ではセーブデータ配布はサポートされていません。

セーブデータを上書きすることになりますので、最悪の場合、はじまるA列車が起動しなくなるなどのリスクがある恐れがあります。

誰もサポートしてくれませんので、実施する場合は、自己責任で実施してください。

……シナリオアップロード・ダウンロードみたいに、ゲーム内機能でセーブデータのアップロード・ダウンロードできるようにバージョンアップしてくれないかなー(チラッ

セーブデータ配布方法

1. セーブデータ番号確認

セーブ番号はじまるA列車を起動し、ロード画面で配布したいセーブデータのセーブ番号を確認します。

確認後、はじまるA列車を終了します。

2. セーブデータコピー

セーブデータはじまるA列車のセーブデータは
C:\Program Files (x86)\Steam\userdata\数字\1685460\remote
配下に「slotXX」というフォルダー名で保存されています。

先ほど確認したセーブ番号のフォルダー(セーブ番号が 61 なら slot61)を、作業用の適当なフォルダーに丸ごとコピーします。

3. リネーム

コピーした「slotXX」フォルダーの名前を、「slot0」(ゼロ)にリネームします(Steam 配下のフォルダーはいじらずに、コピーしたほうをいじります)。

slot0 はオートセーブ用で、このスロットだとうまく読み込んでくれるのでリネームします。

4. zip 圧縮

圧縮slot0 フォルダーをフォルダーごと zip で圧縮します。

5. 配布

zip ファイルを自分のホームページや Dropbox などにアップロードします。

Twitter ハッシュタグ「#はじまるA列車」で URL をつぶやくと見つけてもらいやすくなるのではないでしょうか。

セーブデータ読み込み方法

1. バックアップ

Steam が起動している場合は終了します。

念のため、はじまるA列車のセーブデータを全てバックアップとして取っておきます。
C:\Program Files (x86)\Steam\userdata\数字\1685460\remote
配下のデータをすべて、他の適当なフォルダーにコピーします。

2. ダウンロード

他のプレイヤーが配布してくれているセーブデータをダウンロードします。

zip になっているので、すべて展開すると、slot0 フォルダーがあると思います。

3. セーブデータ入れ替え

C:\Program Files (x86)\Steam\userdata\数字\1685460\remote
の中にある「slot0」フォルダーをフォルダーごと削除し、代わりに、ダウンロードした「slot0」フォルダーを配置します。

4. 読み込み

はじまるA列車を起動します。

起動時、Steam から「クラウドのデータを使うか、ローカルのデータを使うか」聞かれた場合は、必ず「ローカル」を選択してください。

ゲームロード画面で、一番上のオートセーブをロードすると、ダウンロードしたセーブデータをプレイすることができます。

ロード時、サムネイル(スクリーンショット)はセーブデータとは異なったものになっているようです。ロード後、上書き保存することで、サムネイルも正常になるようです。

サンプルセーブデータ

ストーリー分岐コンストラクションはじまるA列車 自作シナリオ作成方法 まとめ(シナリオ編)で使用しているストーリー分岐の例をサンプルデータとして置いておきます。以下のリンクからどうぞ。




はじまるA列車 自作シナリオ作成方法 まとめ(公開編)

前回、テストプレイを終えてゲームとして成り立っていることを確認できたので、いよいよ公開です。

アップロード

アップロードシナリオ選択画面で、クリアしてトロフィーの付いた自作シナリオを選択します。

右上のアップロードボタン(上向き矢印のボタン)をクリックすることでアップロードできます。

Steam 版の場合、自作シナリオのアップロードは無料で行えます。Nintendo Switch 版の場合は月額課金が必要なようです。

公開設定

非公開
アップロードすると Steam の画面になります。

画面に表示されている注記書きの通り、アップロードしたシナリオはデフォルトでは非公開になっています。つまり、他のプレイヤーからは見えていません。

公開設定変更画面を下の方にスクロールさせると、「公開設定変更」があります。「非公開」の設定を「公開」に変更することで、他のプレイヤーからも見えるようになります。

併せて、「画像&動画の追加/編集」でシナリオのスクリーンショットをアップロードしておくと、他のプレイヤーに内容が伝わりやすくなると思います。

Twitter で自作シナリオ公開報告をする際は、ハッシュタグ「#はじまるA列車」「#はじまるA列車自作シナリオPC」を付けると分かりやすくなると思います。

補足

完成度自作シナリオのアップロード・公開は、テストプレイで自分でクリアしていなくても可能です。

クリアしたか否かは、「Completion Status」で分かります。
  • Scenario Completed on Expert……難易度達人でクリア済
  • Scenario Completed on Standard……難易度標準でクリア済
  • Scenario Completed on Easy……難易度やさしいでクリア済
  • Not Yet Completed……クリアしていない
自分がプレイヤーとして他の人の自作シナリオをダウンロードする際は、「Not Yet Completed」のものはクリアできない可能性があるので注意しましょう。

おしまい

以上で、マップ作成から公開まで、一通り完了しました。

はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)

参考リンク


更新履歴

  • 2022/05/05 初版。
  • 2022/05/07 シリーズインデックス作成。


はじまるA列車 自作シナリオ作成方法 まとめ(テストプレイ編)

前回までで一通りの作成が完了しました。

しかし、それで終わりではありません。

ゲーム準備きちんと動作するかの確認、つまりテストプレイが必要です。

テストプレイで確認すべき項目は大きく分けて 2 つです。
  • シナリオパラメータ分岐が意図通りに動作するか(シナリオパラメータを使用している場合)
  • クリアできるか

テストプレイ前の確認

テストプレイを始める前に、特に以下をもう一度確認しておくと良いのではないでしょうか。
  • 駅や停留所の名前を付け忘れていないか
  • 列車やバスがきちんと配置されているか(いつの間にか撤去されている場合があります)
  • 余計な子会社が無いか(即時処分し忘れていないか)
  • ゲーム設定の基本設定に問題は無いか(社員状況は変動している場合があります)
  • 助成金案件、資源売買案件は十分なラインナップがあるか

シナリオ登録

ゲーム設定テストプレイをするためには、シナリオ登録する必要があります。

[ゲーム設定]メニューにシナリオ登録があるので、クリックします。

登録確認確認ダイアログが表示されるので「はい」を選ぶと登録されます。

シナリオ登録ボタンが無効化されている場合は、感嘆符の出ている項目が正しく設定されていないので、見直し・修正します。

シナリオ登録は、あくまでもあなたのパソコンでプレイできるようにするためのものであり、まだインターネットには公開されません。

シナリオ選択タイトルに戻ってゲームを始めると、シナリオ選択で先ほど登録したシナリオが選べるようになっています。

公式シナリオの下側に自作シナリオが並びます。

シナリオパラメータ分岐確認(ノーマル版)

登録した自作シナリオを選択してプレイ開始します。

シナリオパラメータを使用している場合は、街づくりは後回しにして、まずは選択肢に応じた結果になるかを確認します。

原則としては、すべての選択肢のパターンで正常に動作するかを確認することになります。

前回のラーメン屋の例で言うと、ラーメンが好きか嫌いか、ラーメン屋と牛丼屋どちらに行くか、2×2=4 パターンすべてです。質問の数が 3 つ、4 つ、と増えていくと、パターン数は 8、16 と増えていきます。

質問が 4 つで、4 つめの質問がプレイ開始から 2 年後の場合、2 年間の早送りを 16 回することになり、かなり大変です。

主要なパターン(特に、クリア条件を変更するようなパターンでは確認必須)に絞って確認するというのも 1 つの手です。

シナリオパラメータ分岐確認(イベント日付変更版)

2 年間の早送りを 16 回するのは大変でも、4 日間の早送りを 16 回なら現実的です。

というわけで、動作確認用にイベント日付を短期集中型にする「テスト用シナリオ」を作成するという方法もあります。

(プレイ用ではなく)コンストラクションモードのデータを読み込んだ後、「新しく保存」で別データを作り、シナリオ名を「テスト用」などと見分けが付くようにします。

質問と結果発表のイベント条件を、4/1、4/2、4/3……と 1 日ごとに発生するようにします。そのシナリオを登録・プレイすることで、手早く動作確認をすることが可能になります。

注意点としては、
  • 新しく保存した別データで日付をいじる
  • 間違いが見つかった時は、オリジナルを直した上で、再度新しくテスト用シナリオを作る
が挙げられます。特に、間違いが見つかった時、きちんとオリジナルを直すことと、オリジナルにテスト日付を入れてしまわないように注意が必要です。

コンストラクションモードのゲーム設定画面でシナリオパラメータが記憶されていればこんな面倒は不要なのですが……。

クリアできるかの確認

ゲームとしてクリアできるかを確認します。

登録した自作シナリオを選択し、難易度は達人が望ましいでしょう。

クリアし、シナリオクリアのカップが付与されることを確認します。

次:公開編

はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)

更新履歴

  • 2022/05/05 初版。
  • 2022/05/07 シリーズインデックス作成。

はじまるA列車 自作シナリオ作成方法 まとめ(シナリオ編)

渓谷の琵城シナリオ前回、クリア条件を設定したので、今回はシナリオを作ります。

シナリオ解説

会話シーン[ゲーム設定 → シナリオ]メニューをクリックすると、未作成の会話シーンが並んでいます。

一番上、0 番は「シナリオ解説」となっており、シナリオ選択画面に表示されるシナリオ解説を設定します。

シナリオ解説シナリオ解説をクリックして編集ボタンをクリックし、シナリオ解説を入力します。構想で整理した見どころや目的を盛り込むと良いかと思います。

会話シーンの概要

視察提案会話シーンは 1~40 の最大 40 個作成できます。

決められた日付(条件は色々な方法で指定できます)になるとキャラクター同士の会話がはじまり、場合によってはプレイヤーに選択肢を出したり、何らかのアクション(資金が減るなど)を起こしたりします。

公式シナリオでは、
  • ゲーム開始初日に街を見回ることを促す
  • その後数日かけてシナリオの背景や目標などを示す
  • 併せて攻略のヒントも示す
  • たまにキャラクター同士が雑談などをする
  • クリア条件を 1 つ満たす(もしくは目標の半分に達する)ごとに盛り上げる
というパターンが王道のようですので、基本的には同様にしておくのが無難なのではないかと思います。

傾国の美女ご参考までに、渓谷の琵城では、
  • ゲーム開始初日:街を見回ることを促す
  • 2 日目:シナリオの背景と目標を提示
  • 3 日目:攻略の基本方針を提示
  • その後 1 年間は月に 1 回程度のペースで
    • 琵城小噺集
    • 傾国の美女イベント進行
    • 攻略のヒント
    • 雑談
  • 目標半分&全クリ時にコメント
という流れにしています。

編集

会話シーン選択会話シーンを選択するとサブメニューが表示されるので、「編集」をクリックします。

空の台詞秘書の空の台詞が表示されているのでクリックすると、さらにメニューが表示されます。

文章入力「文章入力」ボタンをクリックすると、台詞の文章を入力できます。

文章の中には HTML タグのようなものを埋め込むことができます。例えば、
あいうえお<color=green>かきくけこ</color>
とすると、「かきくけこ」だけ文字が緑色になります。

チートシートどのようなタグが使えるかは、シナリオ台詞スタイルタグ・変数チートシートにまとめられています。

目標指標(人口 5 万人など)は文字を黄色(color=yellow)、地名は文字を水色(color=#00FFFF)にしておきましょう。

改行例細かいことですが、文が 1 行に納まらない場合、意味のあるまとまりなどのキリの良いところで自主的に改行を入れると読みやすくなります。

右の図は公式シナリオのセリフですが、そのままでは「鉄道総延長」あたりまでが 1 行目で、「20km」あたりが 2 行目になり、目標指標が行分割されて読みづらくなってしまいます。

1 行目にまだ余裕があるにもかかわらず、「鉄道総延長」の前に改行を入れることで、「鉄道総延長 20km」がまとまって表示され、読みやすくなっています。

キャラクター呼称表キャラクター同士が互いに相手をどう呼ぶかについては、公式解説動画の末尾に「キャラクター呼称表」としてまとめられています。これは大変ありがたいですね。

人物なし文章入力後、「人物」「表情」をスライドさせて変更できます。人物を「なし」にすることもできます。

「コマンド」で様々なアクションを起こせます。コマンドについては、後ほど説明します。

「コピー」「カット」「貼り付け」で台詞のコピーや順番入れ替えができます。ドラッグ&ドロップでは順番を入れ替えられません。

「セリフ追加」で、現在のセリフの「前」にセリフが追加されます。個人的には、最初にセリフ追加でたくさんセリフ枠を追加しておいて、余ったらカットで削除するのがやりやすいです。

コマンド

コマンド「コマンド」ボタンでコマンドを追加できます。

コマンドで様々なアクションを起こすことができ、「マップ移動」「資本金増加」などたくさんのコマンドが用意されています。

用意されているコマンドの一覧は公式ヘルプにあります。

BGM必ず使うコマンドは「BGM」です。シーンの先頭に BGM コマンドを入れることで、セリフ表示の際に BGM が流れます。

ほとんどのシーンで、種類「がんばるぞっ!」の BGM を使うことになるでしょう。

会話シーン典型例典型的な会話シーンは、「BGM がんばるぞっ!」→文章→文章→文章……のようになるかと思います。

条件

条件ボタンで、どのような時に会話シーンを再生するかを指定できます。

画面下から条件を選びます。条件の一覧は公式ヘルプにあります。

日付指定最も良く使う条件は「日付指定」ではないでしょうか。

その名の通り、指定した日付(の午前 9 時)になると会話シーンが再生されます。

個人的には、毎月「1 日、15 日、末日」を指定するのはなるべく避ける方が良いかなと思っています。1 日や末日はレポート確認などでプレイヤーが忙しく、15 日は助成金支給日なのでカレンダー上でアイコンが被ってしまいます。

強制発動を「オン」にすると、指定日付(の午前 9 時)に必ず再生されます。「オフ」にすると、指定日付(の午前 9 時)になると画面右上にベルマークが表示され、プレイヤーがベルマークをクリックしたタイミングで再生されます。

プレイヤー側からすると、街づくりしている途中で強制的に会話が始まるのはうざいので、余程の事情が無い限り(そのタイミングで発動しないとシナリオに支障が出る場合など)、強制発動はオフにしておくほうが良いでしょう。

渓谷の琵城では、初日の導入メッセージ以外はすべて強制発動オフにしてあります。

クリア条件条件を「クリア条件」にすると、クリア条件を半分達成した時などに会話シーンを始めることができます。

例えば、クリア条件が「年間観光客数 10 万人」だった場合、5 万人になった時点で再生されますので、「残り半分も頑張りましょう」的な会話を入れておくと良いでしょう。

イベントなし少し特殊なのは、条件を「イベント」の「なし」にする場合です。

こうすると、単独では再生されない会話シーンになります。

他の会話シーンからコマンド「シーンジャンプ」などでジャンプしてくる場合にこれを使います。

シーン名変更

シーン名変更シーンに名前を付けることができます。

プレイヤーには表示されないため、シーン名がネタバレになることはありません。自分が分かりやすい名前を付けておきましょう。

再生

会話シーンを作り終えたら、「再生」ボタンをクリックし、きちんと再生できることを確認します。

特に、選択肢コマンドを使った場合は、それぞれの選択肢が正しく動作するかの確認が必要です。

シーンの順番

残念ながら、シーンの順番は入れ替えられません。

シーンを作り込んでいるうちに、順番がばらばらになって分かりづらくなってもどうしようもありません。ドラッグ&ドロップなどで入れ替えられると良かったのですが……。

ストーリー分岐

プレイヤーの選択によってストーリーを分岐させたい場合は、コマンドを利用します。

その場合、必ず使うコマンドは「選択肢」です。

複数の会話シーンでの選択肢を組み合わせて分岐させる場合は「シナリオパラメータ計算」「シナリオパラメータ分岐」コマンドも使います。

場合によっては「シーンジャンプ」も併せて使います。

ストーリー分岐例:ラーメン好き

ラーメン好きストーリー分岐の例として、ラーメンが好きな場合にラーメン屋建設資金として 10 億円もらえる、というケースを作ってみます。

2 回の質問の結果、ラーメン好きであれば建設資金をもらえることにします。

シナリオパラメータを「ラーメン好き度」とし、初期値を 50 点にします。

【会話シーン 1】

ラーメン好き会話シーン1初日(開始から 0 日後)に発動するようにしておきます。

質問 1 つめを行う会話シーンです。

ラーメン好きか、という文章の次に、選択肢コマンドで「はい」「いいえ」を用意します。「はい」の場合はシーン 2 にジャンプするようにします。

「いいえ」が選ばれた場合はシーン 1 の会話が続くので、シナリオパラメータ計算コマンドでシナリオパラメータ(ラーメン好き度)をマイナス 10 します。

【会話シーン 2】

ラーメン好き会話シーン2会話シーン 1 で「はい」が選ばれた場合にジャンプしてきます。

BGM の設定は不要です(シーン 1 で設定した BGM が流れ続けるため)。

シナリオパラメータ計算コマンドでシナリオパラメータ(ラーメン好き度)をプラス 10 します。

【会話シーン 3】

ラーメン好き会話シーン32 日目(開始から 1 日後)に発動するようにしておきます。

質問 2 つめを行う会話シーンです。

どちらに行くか、という文章の次に、選択肢コマンドで「ラーメン屋」「牛丼屋」を用意します。「ラーメン屋」の場合はシーン 4 にジャンプするようにします。

「牛丼屋」が選ばれた場合はシーン 3 の会話が続くので、シナリオパラメータ計算コマンドでシナリオパラメータ(ラーメン好き度)をマイナス 10 します。

【会話シーン 4】

ラーメン好き会話シーン2会話シーン 3 で「ラーメン屋」が選ばれた場合にジャンプしてきます。

BGM の設定は不要です(シーン 3 で設定した BGM が流れ続けるため)。

シナリオパラメータ計算コマンドでシナリオパラメータ(ラーメン好き度)をプラス 10 します。

【会話シーン 5】

ラーメン好き会話シーン53 日目(開始から 2 日後)に発動するようにしておきます。

前の 2 つの質問の結果、ラーメン好きかどうかによって分岐します。

シナリオパラメータ分岐コマンドで、シナリオパラメータ(ラーメン好き度)が 50 より大きい場合はシーン 6 にジャンプします。

50 以下の場合はシーン 5 が続くので、ラーメンはお好きではないようですね、という会話にしておきます。

【会話シーン 6】

ラーメン好き会話シーン6会話シーン 5 でシナリオパラメータ(ラーメン好き度)が 50 より大きい場合にジャンプしてきます。

BGM の設定は不要です(シーン 5 で設定した BGM が流れ続けるため)。

資金をプレゼントします、という文章の次に、資本金増加コマンドでプラス 10 億円します。実質的に資金が 10 億円増えます。

以上のように、選択肢の度にシナリオパラメータを増減させ、最後にシナリオパラメータ分岐でストーリーを分岐させることができます。

分岐させる前の質問の回数をもっと増やすことは可能ですが、シナリオパラメータの下限値が 0、上限値が 100 であることには注意が必要です。

また、選択肢 1 つごとに 2 つの会話シーンを使います(今回のようなシンプルなケースだとシーン 2 と 4 を統合することも可能ですが)。全部で会話シーンは 40 しか設定できないことにも注意が必要です。

【ストーリー分岐コンストラクションモードデータ】

ストーリー分岐コンストラクション上記例を実装したコンストラクションモードのセーブデータを公開します。

読み込み方法や注意事項などはこちらの記事をお読み下さい。

ストーリー分岐例:フラグ方式

先の例ではシナリオパラメータの大小でストーリーを分岐させました。

大小ではなく、シナリオパラメータをフラグとして使うことで、選択肢の組み合わせによってストーリーを分岐させることもできます。

フラグ設定フラグ方式の場合、シナリオパラメータの初期値は 0 点にしておきます。

質問 1 が行き先についての質問で、「北海道 or 九州」とする場合、九州と答えたらフラグをプラス 1 します。

質問 2 が交通手段についての質問で、「新幹線 or 飛行機」とする場合、飛行機と答えたらフラグをプラス 2 します。

すると、最終的にフラグの値が
  • 0……北海道へ新幹線で行く
  • 1……九州へ新幹線で行く
  • 2……北海道へ飛行機で行く
  • 3……九州へ飛行機で行く
というように、すべてのパターンを判定できます。

質問が多い場合は、プラスするフラグの値を 1、2、4、8……のように倍々にしていきます。

ただし、質問が多くなってくると、すべてのパターンを判定するには会話シーンが足りなくなってしまいます。実用上は、特定のパターンだけ判定して、残りはその他的な扱いをすることになるでしょう。

渓谷の琵城はフラグ方式で、誰を傾国の美女と思ったかを記録しています。
  • 1=観光課長
  • 2=証券会社員
  • 4=秘書
  • 8=都市計画担当
です。フラグが 8 の場合、都市計画担当が単独で傾国の美女となります(他の複数人が傾国の美女だったとしても 8 にはなりません)。

シナリオパラメータ分岐の動作確認

上昇残念ながら、コンストラクションモードのゲーム設定をしている途中ではシナリオパラメータの増減が記憶されません。

ラーメン屋の例で言えば、会話シーン 1 を再生してラーメン好きを選んだ場合、「ラーメン好き度が上がりました」と表示されるにもかかわらず、実際には上がっておらず、50 点のままです。

そのため、その後会話シーン 5 を再生しても、資金プレゼントには進みません。

ゲーム設定中にシナリオパラメータ分岐の動作確認はできないことになります。ゲーム設定中もシナリオパラメータを実際に増減させてくれると良かったのですが……。

この辺りの対策については、次のテストプレイで説明します。

機能制限

機能制限プレイヤーに使わせたくない機能がある場合は、[ゲーム設定 → 機能制限]メニューで制限できます。

使わせたくない機能をオフにします。

シナリオコマンドの「機能制限」コマンドでオン・オフすることも可能です。

次:テストプレイ編

はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)


更新履歴

  • 2022/05/04 初版。
  • 2022/05/05 機能制限を記載。
  • 2022/05/06 ストーリー分岐セーブデータ公開。


はじまるA列車 自作シナリオ作成方法 まとめ(クリア条件設定編)

ゲーム設定前回、地域設定をしたので、メニューを 1 つ戻って、今回はクリア条件設定をします。

当然ながら、クリア可能になるように条件を設定する必要があります。

クリア条件追加クリア条件設定メニューの追加ボタンでクリア条件を追加します。

指標

指標何をクリア条件にするかです。

「人口」、「年間売上高」、部門別の利益系(「年間鉄道利益」など)、会社格付けなど、さまざまな指標を設定することができます。

条件 1(数値など)

20km以下指標が目指すべき具体的な数値を設定します。

例えば人口なら「人口 10 万人以上」のような設定が可能です。

指標によっては「以上」か「以下」かを選択できるものもあります。

例えば、鉄道総延長は通常は「20km 以上」のように発展させる方向で条件を設定しますが、鉄道に代わる交通手段を育成するシナリオであれば「20km 以下」のような設定をすることもあるかもしれません。

「人口」は「以下」を選択できません。立ち退きシナリオを作りたい場合は、代わりに「住宅経済規模」を用いることになるのではないでしょうか。

指標が「会社格付け」の場合は「AAA」などのランクを設定します。

指標によっては、条件 1 を設定できないものもあります。

条件 2(地域など)

条件2指標をどの地域で達成しなければならないかを設定します。

街全体にすることもできますし、特定の地域だけで達成しなければならないようにすることもできます。「品川地域で鉄道総延長 20km 以上」のような設定が可能です。

「駅の年間利用者数」の場合は地域ではなく具体的な駅、「業種別子会社」の場合は業種を設定します。

指標によっては、条件 2 を設定できないものもあります。

期限

期限指標・条件を達成するまでの期限を設定します。

まず難易度標準の期限を設定し、その後に難易度やさしいと難易度達人の場合の補正期間(プラスマイナス)を設定します。

有効/無効

年間観光客数クリア条件の有効/無効を設定します。

無効にしておいた場合、シナリオの途中でイベントを発生させて、有効化できます。

削除

間違って作成したクリア条件を削除できます。


はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)


更新履歴

  • 2022/05/03 初版。
  • 2022/05/07 シリーズインデックス作成。

はじまるA列車 自作シナリオ作成方法 まとめ(地域設定編)

前回、基本設定のうち、少なくとも取り扱い資源は設定したと思います。

メニューの順番では次は「クリア条件設定」ですが、先に「地域設定」を行います。クリア条件設定に地域が必要になる場合があるためです。

合併

地域設定地域設定メニューの先頭は「境界線」になっていますが、先に「個別設定」の中でできる合併を行います。合併してからでないと境界線を設定する意味がないためです。

マップサイズにより、最大 16(4×4)の地域があります。シナリオの内容にもよりますが、地域の数が多すぎると分かりづらいので、合併して少数の地域にすることが多いでしょう。

9地域今回は、M サイズマップの 9 地域を例にします。

画面左側に地域一覧が並んでいます。例では名前変更済で県内の位置を表す名前にしていますが、デフォルトではランダムで地域の名前が決まっています。

中央例えば「中央」の位置にある地域を選択するとサブメニューが表示されますが、サブメニューを一番下までスクロールさせると、合併ボタンが表示されます。

北を合併ここで「北を合併」ボタンをクリックすると、「中央」の北側にある「上」を吸収合併し、「中央」と「上」が 1 つの地域になります。

十字同様にして、西、東、南も合併することで、十字型の地域ができあがります。

とはいえ、実際には十字型の地域を作りたい場合はあまりないかと思います。

L字型4 つの地域を正方形に合併したい場合、例えば、右上周辺の「上」「右上」「中央」「右」を合併したい場合は、まず、中央を選択して北と東を合併します。「中央」が L 字型の地域になります。

正方形その後、左側の地域一覧で、旧「上」を選択します。表示上、旧「上」は合併後の「中央」と薄く表示されています。旧「右」も薄く「中央」と表示されていて紛らわしいので注意してください。

旧「上」で東を合併することにより、「右」も合併されて正方形になります。

かなり使いづらい操作性だと思います。

境界線

合併後、各地域の境界線を設定します。

境界線境界線ボタンをクリックしてから地図上の境界線の交点付近にマウスを合わせると、黄色い丸が表示されます。それをドラッグすることで境界線を変更できます。

地図の内側にある交点だけではなく、辺上にある交点も動かせます。

ただし、四隅でも黄色い丸は表示されるものの、四隅は動かせません。

個別設定

個別設定合併後の地域の設定をしていきます。

「名前変更」で地域の名前を設定できます。地域の規模に応じて「村」「町」などは自動的に付加されるため、それらは付けないでおきます。

ゲーム開始時の用途地域を指定することもできます。永久的にその用途地域にしたい場合は「用途地域固定」をオンにします。

「助成金傾向」でどの助成金を出すか設定します。出したくない助成金がある場合はオフにします。

逆に、なるべく出したい助成金がある場合は、他の助成金をオフにするというのもアリなのではないかと思います。例えば、住宅に集中して出したい場合は、「工業系建物」「商業系建物」「娯楽系建物」をオフにすると、住宅系建物の助成金が出る確率が上がるのではないでしょうか(未検証ですが……)。

隣接地域・海外設定

隣接地域個別設定の地域一覧の一番下に、隣接地域と海外があります。選択するとそれぞれ設定ができます。

「名前変更」で隣接地域の名前を設定できます。

「都市規模」で隣接地域の規模を設定できます。隣接していない設定にしたい場合は「なし」を選びます。

「資源の扱い」で隣接都市・海外の資源案件が決まります。例えば、「農産物」を「生産」、「水産物」を「消費」にすると、農産物の購入と水産物の売却ができるようになります。

基本設定でオフにした資源は選択肢に出てきません。

地価補正

マップ全体の基本となる地価を設定します。

発展しやすさ

発展による建物の建ちやすさを設定します。

次:クリア条件設定編

はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)


更新履歴

  • 2022/05/01 初版。
  • 2022/05/07 シリーズインデックス作成。

はじまるA列車 自作シナリオ作成方法 まとめ(ゲーム基本設定編)

前回街づくりを終えたので、いよいよゲーム作りを始めていきます。

コンストラクションメニューマップコンストラクション専用の[ゲーム設定]メニューを開きます。

ゲーム設定ゲーム設定メニューには、「基本設定」「クリア条件設定」「地域設定」「シナリオ」「機能制限」の各メニューがあります。

基本設定今回は「基本設定」について見ていきます。

基本設定はゲームの根幹となる重要な設定ですが、最初に設定すべきは「取り扱い資源」と、必要に応じて「シナリオパラメータ」のみです。取り扱い資源は、後ほど地域設定を行う際に影響します。シナリオパラメータは、後ほどシナリオを作成する際に使う場合があります。

残りは、シナリオ完成直前、もしくは、必要が生じた時に設定する、で構いません。

シナリオ名

シナリオ名を設定します。

完成後に他のプレイヤーに公開する際、最初に見られる部分ですので、分かりやすい名前にしましょう。

作者名

作者名を設定します。

従業員充足率

ゲーム開始時に、運営必要人数に対して従業員数がどのくらい足りているかを設定します。

従業員充足率標準100しかし、設定よりも実際の従業員数は少なくなるようです。状況により変わる気もしますが、一例としては、従業員充足率を 100% に設定しても、実際には、難易度標準で 83%、難易度達人で 67% にしかなりませんでした。

従業員充足率達人100同じ子会社数でも、達人のほうが運営必要人数が増えるのに従業員数は変わらず、結果として従業員充足率が下がります。

コンストラクションの時に業務効率化しておけば改善されるのかというとそうでもありません。

設定が正しく反映されるようにして欲しいものです。

なお、難易度やさしいでゲーム開始する際は従業員充足率の概念はなくなります。

社員状況

社員の仕事に対するやる気を設定します。

難易度標準でも達人でも設定は反映され、100% にすると「活気に溢れている」になります。

ここで設定しても、コンストラクション中に子会社を売却するとゲーム内時間が進んでなくても変動するため注意しましょう。

ブランド力

難易度標準における会社の知名度を設定します。駅や子会社の売上に影響する他、人員増強で集まる人数にも影響するのではないかという気がしています。

難易度やさしいだと強制的に最大、達人だと強制的にゼロになります。

公共交通利用率

公共交通利用率を設定します。

住民が鉄道やバスなどの公共交通機関を利用する割合です。乗客数に影響します。

株主信頼度

難易度標準、難易度達人における株主からの信頼度を設定します。株式公開時の資金調達に大きく影響します。

0 まで下がるとゲームオーバーになるため、慎重な設定が必要です。特に、借金シナリオなどで利益剰余金がマイナスの場合、シナリオ開始後に配当金を払えず株主信頼度が下がることが想定されます。

難易度やさしいだと強制的に最大になります。

銀行信頼度

難易度標準における銀行からの信頼度を設定します。銀行からの融資限度額に影響します。

難易度やさしいだと強制的に最大、達人だと強制的にゼロになります。

シナリオパラメータ

好感度アップシナリオで使える変数(自由に名前を設定し、使える値)を設定します。

公式ヘルプで「キャラクターの好感度として使います。会話シーンの選択肢によって値を変え、その値によって会話シーンを分岐させます」とあるように、シナリオを作成する際に様々なことができるようになります。

シナリオパラメータシナリオパラメータを使わないのであればオフにしておきましょう。オンのままにしておくと、レポート画面で使われないパラメータが表示されてしまうことになります。

西暦上限

時代の進行が止まる年を設定します。

時代を固定して遊びたい場合に設定してください。

開始年

シナリオを開始する年を設定します。マップ生成時に設定した開始年を、プラスマイナス 10 年の範囲でずらせます。

ボーナス設計図

シナリオ開始時、プレイヤーが過去に別のマップで開発した車両の設計図を持っているかどうかを設定します。

「少ない」を選んだ場合、ボーナス設計図をいくつかランダムで持っている状態でシナリオを開始します。「全て」にしても、プレイしたマップとの年代の関係によって持って行けない設計図もあります。

資本金

シナリオ開始時の会社の資本金を設定します。

初期資金がマイナスになる設定では、シナリオ登録できません。

やさしい補正

難易度やさしいを選んだ時の、シナリオ開始時の資本金に対する補正度合いを設定します。

達人補正

難易度達人を選んだ時の、シナリオ開始時の資本金に対する補正度合いを設定します。

資金差デフォルトではやさしい補正が 200%、達人補正が 70% になっています。難易度標準の資本金を 500 億円に設定した場合、やさしい資本金は 1000 億円、達人資本金は 350 億円となり、やさしいと達人では資本金に 2.9 倍程度の差が生じます。

また、補正設定は「資本金」に対するもので、「資金」ではないことに注意してください。

例えば、線路・駅・子会社などの資産を 250 億円保有している状態では、資金が差し引かれますので、やさしい資金は 750 億円、標準資金は 250 億円、達人資金は 100 億円となり、やさしいと達人では資金に 7.5 倍の差が生じます。

欠損金

会社の累積赤字を設定します。

赤字状態から始めるシナリオにしたい時に設定してください。

大きすぎると資金がマイナスになってしまうので、シナリオ登録できません。

取り扱い資源

取り扱い資源シナリオで扱う資源の種類を設定します。ここでオンにした資源のみ売買できます。

例えば木材をオフにすると、木材集積場を建設できなくなる他、売買案件にも木材が登場しなくなります。

ただし、コンストラクションモードで既に建設済の貯蔵場(木材集積所など)は破壊されるわけではなくそのまま残ります。

次:地域設定編

はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)

更新履歴

  • 2022/05/01 初版。
  • 2022/05/07 シリーズインデックス作成。

はじまるA列車 自作シナリオ作成方法 まとめ(街づくり編)

オアシス前回土地が完成したので、今回は街づくりをします。

街づくりのやり方は大きく 2 種類あります。1 つは通常のゲームモードと同じ操作での街づくり、もう 1 つがマップコンストラクション専用メニュー「個別編集」での街づくりです。

コンストラクションメニュー建造物のうち、公共施設(農業組合所等)や小さめの建物(居酒屋等)はゲームモードでは建設できない物件があり、個別編集で建設する必要があります。個別編集で建設した物件は他社所属になります。

地形に準ずる建造物(湖や川など)も個別編集です。

一方で、鉄道やバスに関すること(線路敷設等)は通常のゲームモードと同じ操作で行います。

本記事では、主に個別編集について説明します。

河川と湖

街づくりで一番最初にやるべきことは、河川と湖の作成だと思います。河川等を最初につくったほうが住宅等もイメージしやすくなるというのもありますが、特に河川は思いも寄らないマスに生成されて付近の住宅等を破壊してしまうので、後から作るとかなり手間が増えてしまいます。

[個別編集 → 自然 → 加工]メニューに河川があります。

河川配置残念ながら、河川を並べて配置しても、細切れになるだけでまともな河川になりません。

範囲河川を繋げるには、右上の配置方法メニューを「範囲」にします。

河川作成1右の図は、赤枠を範囲指定した時の様子です。残念ながらまだまともな河川になりませんが、一部の河川はつながっています。一方で、上下に勝手に河川がはみ出ています。

河川作成2はみ出しはいったん気にせず、赤枠を繰り返し何度も範囲指定すると、そのうち、赤枠内の河川がすべて接続されます。

河川作成3最後に、はみ出した河川を撤去すると、一本の河川が残ります。

マップコンストラクションの操作性は全体的に悪いのですが、中でも河川敷設は筆頭クラスと言えるでしょう。

湖については素直に配置していくだけで自動的に接続されます。

ランダム配置

河川を筆頭にイラッとする操作性のマップコンストラクションですが、もちろん良いところもあります。

ランダムマップコンストラクションで便利なのはランダム配置です。[個別編集 → 農林 → 森林2]メニュー等にランダムがあります。

山などに範囲指定でランダム森林を配置すると、さまざまな森林を一瞬で植えることができます。同じ位置に何度も配置すると、森林の成長度合いが変化します。

[個別編集 → 住宅 →一般住宅3]にある住宅のランダムは道の両側に家を配置するときに便利です。

その他の施設

娯楽その他の施設も配置できます。通常のゲームモードで建設できる子会社はもちろん、農業組合等も配置できます。

建造物がジャンル毎に分かれているのは便利です。例えば、娯楽は「海浜系」「市街系」「自然系」などと分かれていて、自然系からキャンプ場やバーベキュー場などが配置できます。

老朽化個別編集モードだと範囲指定で一気に配置できるのが便利です。また、右上の経年変化ボタンで新築以外の経年変化にすることもできます。

ずれ整地一方で、1 つ 1 つ丁寧に配置したい場合は慣れが必要です。配置したい場所とずれた場所に配置してしまった場合、少しずらして再度クリックして配置すると、元の場所が整地されてしまいます。間違えた場所に配置してしまった場合は、元に戻す(もしくは右クリック)してから、正しい場所に配置しなおします。しかし、配置前のプレビューで表示されているのか、すでに配置されているのかが分かりづらく、右クリックしすぎると個別編集モードから抜けてしまいますし、何とも使いづらい操作性です。

建物の回転は、右上の回転ボタンで行います。また、タイプ(建物の色や看板)は一定時間ごとにローテーションしますので、目的のタイプが表示されたタイミングでクリックするとそのタイプが配置されます。

操作に慣れない場合は、一般の子会社であれば通常のゲームモードの子会社建設で行うこともできます。ただし、自社子会社になってしまうので、他社にしたい場合は、後ほど売却(即時処分)が必要です。

観光碑

円舞桜[個別編集 → 公共 → 保存施設]メニューに観光碑があります。観光碑は、配置することで観光地になる特別な目印です。これにより、城、古民家集落、山、桜など、そのままでは観光地にならないものを観光地のように扱うことができるようになります。

観光碑は 1~3 まであり、それぞれ集客力が 2、3、5 となっていますが、実際に配置すると、集客力が下回る場合もあります。周囲との関係性によって、最大で 2、3、5 ということのようです。

観光碑名前変更観光碑配置後、[役所 → 観光案内 → 観光ルート]メニュー内で観光碑の名前を変更することができます。

観光碑または、観光地になる子会社(スタジアムなど)を 1 つ以上作成しておくのがセオリーと言えるでしょう。どの子会社が観光地になるのかは、wiki にまとめられています。観光地子会社は、自社子会社であれば、子会社メニューから名前を付けることができます。他社子会社の場合は名前を付けられません(自社子会社で名前を付けてから売却しても「スタジアム1」とかに戻ってしまいます)。

駅名など

停留所駅や停留所を建設した場合は、分かりやすい名前を付けておきます。

公式シナリオでは、
  • 駅 → 末尾に「駅」を付ける(例:奈桜駅)
  • バス停留所 → 末尾に「停留所」は付けない(例:奈桜駅前)
  • トラック駐車場 → 末尾に「駐車場」を付ける(例:瀬塚駐車場)
となっているようです(例外もあります)。公式シナリオの命名規則に合わせておくほうが自然な感じになるかと思います。

列車など

列車購入不可列車やバスは、デフォルトでは購入できません。

最初にプランの列車開発などで開発します(通常のゲームモードとは異なり、即時に開発完了します)。

開発後に購入・配置します。


はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)


更新履歴

  • 2022/04/30 初版。
  • 2022/05/04 駅名などを記載。
  • 2022/05/05 列車などを記載。
  • 2022/05/07 シリーズインデックス作成。


はじまるA列車 自作シナリオ作成方法 まとめ(土地造成編)

土地造成前回マップ生成したので、今回は土地造成です。

マップ生成でおおまかな地形ができたので、今回の土地造成では、土地の高低(平地、山、海)について完成形を目指します。

コンストラクションメニューマップ生成を終えるとゲーム画面になりますが、コンストラクションモードでは、通常のゲームモードよりもメニューが 3 つ増えています。そのうちの 1 番上、土地造成メニューから土地造成ができます。

盛ると削る

土地造成メニュー盛ると削るメニューで、土地の高さを上げたり下げたりできます。クリックしたところが盛り上がったり凹んだりします。

盛る・削る部分とその周囲の傾斜がどの程度急峻になるかを、傾斜の補完で指定できます。険しいにすると、傾斜が急になり、岩肌になります。

盛る右側のオフセットスライダーで、どの程度盛る(または削る)かを指定できます。指定後、「次に」クリックした地点以降にその設定が反映されます。クリックしてみて、思ったような盛り上がりではない場合は、右上の「戻る」ボタン(または右クリック)でアンドゥしてから、オフセットスライダーを調整し、再度クリックしてみて、またダメだったらやりなおし……を繰り返す必要があるため、操作性は悪いです。

直前にクリックした地点もスライダー上下でリアルタイムに盛り上がり具合が変われば、画面を見ながら良い感じに調整できたのではないかと思います。

公式ヘルプにある通り、削るで B1 以下になった地形は自動的に海となります(土地造成中は明るい茶色で表示されます)。湖を作りたい場合は、後ほど個別編集で作成します。

平ら

クリックした地点の標高に、周囲の標高を合わせます。希望の標高になっている地点をクリックしてから、徐々に塗り広げていくイメージで次々と付近をクリックしていく感じで操作すると、希望の高さに揃えられるのではないかと思います。

平ら慎重に塗り広げていかないと高さがズレてしまいます。あまりにズレると思った場合は、平らにする面積を変更してみるといいかもしれません。

なお、結果的に周囲の標高が変わらない場合でも、周囲の田畑等は破壊されて草原になってしまいます。この辺りも使いづらい仕様です。

次は街づくり

土地の高低が完成したら、次のステップとして街づくりに進みます。

街づくりをしている途中でも土地造成の修正は可能ですが、何かしらの建造物がある地点の土地造成はできないため、いったん建造物を撤去してから土地を修正し、土地修正後に再度建造物を作る、という手間が発生します。

できる限りの土地造成はこの段階で済ませておく方が効率的です。


はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)


更新履歴

  • 2022/04/30 初版。
  • 2022/04/30 細かな補足を追記。
  • 2022/05/07 シリーズインデックス作成。


はじまるA列車 自作シナリオ作成方法 まとめ(マップ生成編)

笹目川の河口A列車で行こう はじまる観光計画(はじまるA列車)で自作シナリオ「渓谷の琵城」を作成した時のことや、その後の知見なども踏まえて、自作シナリオ(ユーザーシナリオ)の作り方をまとめて整理しました。

Steam 版(Build 30257.629)をもとにしていますが、Nintendo Switch 版でも似たような感じなのではないかと思います。

なお、縮小表示されている画像はクリックで拡大できます。

基本的な流れ

基本的な流れは公式ヘルプに準じます(公式ヘルプが用意されていること自体は大変ありがたいのですが、フレーム使用なのでリンクを貼りたいときは不便ですね……)。
  • 構想
  • マップ生成
  • 土地造成
  • 街づくり(個別編集など)
  • ゲーム設定(地域設定、シナリオ作成など)
  • テストプレイ
  • シナリオ登録・公開

構想

特徴を出す手を動かす前に、シナリオの構想を固めておきます。

  • シナリオの見どころを作る(複雑な路線網、優雅な観光地、ストーリー etc)
  • 目的を作る(路線拡張、観光客増加、トゥルーエンド etc)
とあります。

例えば公式シナリオ「転換する都市」では、
  • 見どころ:臨海地区の夜景
  • 目的:工業を衰退させて商業などを発展させる
というあたりになろうかと思います。

  • 見どころ
    • 観光地:渓谷と城(琵城)
    • ストーリー:琵城にまつわる伝承(琵城小噺集)
    • イベント:傾国の美女(誰を選ぶかで結果が変わる)
  • 目的:琵城への観光客誘客
としています。

構想がブレると実作業が大幅にやり直しとなることもあります。最初の段階でしっかりと構想を固めておきましょう。

コンストラクションモードボタン構想を固めたら、タイトル画面からコンストラクションモードに入り、マップ生成をしていきます。

自動生成マップ生成では、地形を自動生成し、マップのおおまかな形を決めます。以降で、マップ生成のオプションについて説明します。

サイズ

サイズSS、S、M、L の 4 段階から選べます。

SS は縦横 80 マス、L は 320 マス(縦横 4 倍で面積 16 倍)です。ヘルプには 1 マスのサイズについて記載がありませんが、行政受託から計算すると 1 マス 50m なので、L サイズマップは 16km × 16km ということになります。

開始年

開始年1955 年~2025 年の範囲で選べます。

年代によって、使える列車や建物が異なります。

標高と平地

標高公式ヘルプによれば、標高は「基準となる標高」、平地は「開発に適した平らな土地の割合」ですが、これらの組み合わせにより生成される地形はイメージしづらいです。例えば、標高 100%、平地 100% にすると、全面的に 22F 高地の平地となるのかと思いきや、実際には 1F の平地になります。

平地アバウトな感覚としては、
  • 平地:1F 平地の割合(残りは海か高地)
  • 標高:MAX の標高(ランダムで必ずしもその標高の地形ができるとは限らない)
くらいのものではないかと思います。平地を 100% にした時点で、標高に関係なくすべてが 1F 平地になります。逆に、平地を 0% にしても多少は 1F 平地が生成されます。

平地ではない部分が海になるか高地になるか(ランダム)で、開発できる面積は変わってきます。例えば、平地 25% にした場合、残りの 75% が海だと、開発面積は 25% です。一方で、高地になった場合、高地が全て斜面だと開発しづらいですが、高地の平地(高台)になれば、そこも開発できるので、開発面積は 25% よりも多くなります。

川と湖

川川、湖の量をそれぞれ、なし、少ない、標準、多いから選べます。

湖平地の設定にかかわらず川や湖を作ることができます(平地を 100% にしても川や湖を作る設定にすると、川や湖が生成されます)。高地や斜面(滝)に川が生成されることもあります。

森林と田畑と住宅

森林森林、田畑、住宅(小道を含む)がどのくらい存在するかを指定します。公式ヘルプに「ポイント比率で計算」とある通り、それぞれの割合で計算されます。

が、恐らくもう 1 つ重要な要素があって、草原の割合もこれで決まるようです。推測ですが、
  • 100-(森林・田畑・住宅の最大値):草原の割合
  • 草原以外の部分を、森林・田畑・住宅でポイント比率計算
なのではないかと思います。

ポイント比率100例えば、森林・田畑・住宅を全部 100P にすると、森林・田畑・住宅がそれぞれ 33% ずつの面積になります。

ポイント比率50一方で、全部 50P にすると、50% が草原となり、森林・田畑・住宅は 17% ずつになります。

石油と石炭

石油石油、石炭の量をそれぞれ、なし、少ない、標準、多いから選べます。

生成

生成設定を終えたら、生成ボタンをクリックすると、設定に応じた地形が生成されます。

公式ヘルプに記載の通り、「おおまかな地形ができたら」それでよしとすべきです。細かい調整は、次以降のステップである土地造成・個別編集で作業をしていきます。

とはいえ、
  • 手動の土地造成・個別編集はなかなか思い通りにいかない(操作が難しい)
  • 一括編集もできるとはいえ、基本的には 1 マスずつの編集なので時間がかかる(L サイズだと 10 万マスを編集することになる)
  • 自動生成の森林・田畑の入り交じり具合を手動で再現するのは困難
という懸念点があります。自動生成は L サイズマップでも 10 秒程度でできますが(PC の性能によります)、手動での土地造成・個別編集は数時間~数十時間にも及びます。はっきりと土地の完成形がイメージできている場合は、なるべく近い形の土地ができるまで繰り返し生成を試みる方が、結果的には時間の節約になるのではと思います。

完成

希望の地形が生成されたら、完成ボタンをクリックします。

全面更地から始めたい場合は生成ボタンをクリックせず、いきなり完成ボタンをクリックします。


はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)


更新履歴

  • 2022/04/29 初版。
  • 2022/04/29 細かな補足を追記。
  • 2022/05/04 構想を記載。
  • 2022/05/07 シリーズインデックス作成。

興味ある持ちカラ講習会/勉強会アンケート

持ちカラ(動画持ち込みカラオケ)をしている際に講習会の話が出ましたので、まずはどんな講習会が求められているのか、アンケートを作ってみました。

【アンケート】興味ある持ちカラ講習会/勉強会
https://docs.google.com/forms/d/e/1FAIpQLSfDp5axpvr40PgzG2g79UML54j7_sAnv_SFn9AfWl7u27XdxA/viewform
  • 参加者(歌う人)向け
  • 動画職人向け
  • 機材係向け
  • 幹事向け
さまざまありますので、まずは上記リンクを見てみて、興味があったらポチってください。ニーズが多ければ開催されるかもしれません!?

締切:4/30

ストア配布のメリット

Storeニコカラメーカー 2 およびゆかりすたー 4 NEBULA は、Microsoft Store(以降「ストア」と表記)での配布となりました(引き続き無料です)。

なぜストアで配布することにしたのかというと、以下のような様々なメリットがあるためです。

インストールがさらに簡単に

これまでもインストールは簡単でしたが、ストア配布によりさらにインストールが簡単になりました。

ストアの「入手」または「インストール」ボタンをクリックするだけでインストールが完了します。

スタートメニュー自動登録

インストールすると、スタートメニューにも自動的に登録されます。

(補足)
起動時はスタートメニューから起動してください。
旧 zip バージョンの時に作成したショートカットから起動すると旧バージョンが起動してしまいます。

SmartScreen による妨害がない

これまでは、アプリを起動しようとすると SmartScreen の画面が表示されて、いくつか画面をクリックしないと起動できない場合がありました。

ストア配布により SmartScreen が表示されなくなるため、起動が簡単になります。

更新がさらに簡単に

これまでも更新(バージョンアップ)は簡単でしたが、ストア配布によりさらに更新が簡単になりました。

更新版が公開されると、自動的に更新版がインストールされますので、何ら画面で操作する必要はありません。

(補足)
旧 zip 版からストア配布版への自動更新は行われません。
ストア配布のアプリを最初の 1 回はストアで入手する必要があります。

PC 買い換え時に楽

パソコンを買い換えた時や、あるいは Windows をクリーンインストールした時など、他のストアアプリと一緒にまとめてインストールすることができます。個別にインストールする必要がないので手間がかかりません。

ストア配布リンク


METEOR vs NEBULA 処理速度比較

ゆかりすたー NEBULA が正式版となったので、前世代 METEOR と処理速度を比較してみた。USB 接続ポータブル HDD に入っている約 32,000 曲を整理するのに要した時間を測定。測定環境はこちら

フォルダー追加時の処理時間


前世代
METEOR
新世代
NEBULA
初回
新世代
NEBULA
2 回目
差異NEBULA が
何倍高速か
ファイル名検索
が可能になるまで
22 秒32 秒6 秒
- 16 秒3.7 倍高速
ファイル名検索
+属性検索
が可能になるまで
5 分 45 秒4 分 30 秒
6 秒
- 5 分 39 秒
57.5 倍高速

ゆかり用リスト作成の処理時間


前世代
METEOR
新世代
NEBULA
差異NEBULA が
何倍高速か
リスト作成時間14 秒21 秒+ 7 秒0.7 倍(遅い)

フォルダー除外時の処理時間


前世代
METEOR
新世代
NEBULA
差異NEBULA が
何倍高速か
フォルダー除外時間1 分 3 秒7 秒- 56 秒9.0 倍高速

最も処理時間を要する、フォルダー追加時の属性検索処理時間について、NEBULA の 2 回目はキャッシュを活用したことにより、57.5 倍という圧倒的な高速さで処理を終えた。

フォルダー除外時の速度もかなり高速化されている。

一方でリスト作成の処理速度は旧世代 METEOR よりも遅くなったが、時間にすると 7 秒であり、トータルでは NEBULA が圧倒的に速い。

METEOR → NEBULA のソースコード変更状況調査

ゆかりすたー NEBULA は、前世代 METEOR と比べてこちらにまとめたようなメリットを備えたうえで、前世代 METEOR の機能も網羅するに至った。

また、目には見えない内部的なところでも大幅に変更が行われており、内部の主な変更点としては、
  • プラットフォーム最新化(.NET 5 + EF Core)
  • MVVM 適応度向上
  • マイクロコア化による安定性・応答性向上
が挙げられる。

見た目はさほど変わらない NEBULA と前世代 METEOR で、ソースコードはどのくらい変化したのか、少し調べてみた。

まず、ソースコード全体の量は、以下のように変化した(行数:空行を除く)。

前世代 METEORNEBULA増加率
*.cs36,541 行41,512 行+ 13.6 %
*.xaml1,998 行1,919 行-4.0 %

見た目を決める *.xaml の量はほぼ変化していないが、内部の *.cs の量は 14% 程度増加している。内部的な変更により効率よく記述して量が減っている側面もあるのだが、機能増により全体としての量は増えたようだ。

次に、変化の内訳を調べてみた。本当はすべてのソースコードについて調べたかったが、大変すぎたので、データベースを扱う 1 ファイルだけ見てみた。

行数
前世代 METEOR 行数271 行
NEBULA でも記述が変わらない行数121 行
記述を変更した行数96 行
削除した行数54 行
追加した行数99 行
変更・削除率55.4 %
追加率36.5 %

変更・削除率は 55.4% で、ソースコードは半分以上書き換わっていた。

変更・削除率と追加率を単純に足し算するのも何か違う気はするが、単純に足し算してみると 91.9% となり、全面書き換えに近い数値となった。

というわけで、見た目はあまり変わらなくても、内部はかなり変わっていた。

GitHub の README.md と Wiki の違い&使い分け

GitHub のリポジトリにドキュメントを入れる場合、大きく分けて
  • README.md(および必要に応じてその他のドキュメント)をリポジトリに直接配置
  • Wiki を使う
の 2 つのやり方があるが、基本的な機能(Markdown で書けて、GitHub サイト上での表示・編集が可能で、変更履歴も管理される)が同じだけに、どう使い分ければ良いのかというハテナが出て来たので、調べてみた。

機能的な違い

README.md と Wiki は基本的な機能は同じであるものの、確認できた範囲では以下のような違いがあった。

README.mdWiki
記述方法の簡単変更×
ページ一覧の自動作成×
サイドバー×
フッター×
ページの階層化×
変更履歴管理リポジトリで管理
(全体+ファイル別)
ファイル別のみ

根本的には「README.md はリポジトリそのものの 1 ファイルにすぎない」という位置づけになっていて、ドキュメントに特化した Wiki との違いが生じているということだと思う。

「記述方法の簡単変更」というのは、「最初は Markdown で書いていたけど、途中で Textile に切り替えたくなった」という場合に、簡単に変更できるかという観点。

EditmodeWiki の場合、Web 上での編集時に Edit mode を選べるため簡単に変更できる。

README.md の場合は、いったん README.md を削除してから新たに README.textile を作成すれば変更は可能(Code ページできちんとフォーマットして表示される)だが、Wiki と比べると一手間余計にかかる。

「ページ一覧の自動作成」は、Wiki の場合、特に何もしなくても、Wiki の右側に「Pages」という欄が表示されるようになる。逆に、これを消すことはできず、強制表示となる。

「サイドバー」「フッター」については、Wiki の場合、「_Sidebar」「_Footer」というページを作ることにより、常に Wiki の右側・下側にそのコンテンツを表示できる。

README.md の場合は、試しに _Sidebar.md _Footer.md というファイルをリポジトリに配置してみたが、README.md 表示の際にこれらのファイルは表示されなかった。

以上のように、Wiki にはドキュメントに特化したお手軽機能が備わっている。

一方で残念なのは、Wiki はページの階層化ができない点。ページ作成時に「A/B」のような命名をしてみても階層化されなかった。

README.md の場合はリポジトリそのものなので、リポジトリにフォルダーを作って新たな *.md(なり他のフォーマットのドキュメントなり)を配置すれば、ドキュメントも階層化できる。

「変更履歴管理」については、README.md はリポジトリそのものなので、リポジトリの変更履歴を見れば内容は一目瞭然。ドキュメントファイルを新規作成したり削除した場合も、リポジトリの変更履歴で確認できる。

Wiki の場合は変更履歴管理がページごとになっているので、それぞれのページの変更履歴は確認できるが、そもそもファイルが増えたり減ったりしたことを分かりやすく確認する手段は無い模様。

使い分け

機能的な違いを踏まえた上で、README.md(+リポジトリ内ドキュメント)と Wiki をどのように使い分けるか?

正直なところ、決定的な方法は思いつかない。

1 ページで済む簡単なドキュメントならば、README.md だけで事足りるのは間違いない。

ではファイルが増えてきたら Wiki かというと、個人的にはそうでもないかなと思う。理由は、Wiki だとデザインが変更できないから。ファイルが増えるような本格的なドキュメントということであれば、Markdown お仕着せのデザインではなく、自分なりのデザインにしたい。

となると、HTML でちゃんとドキュメントを作ってリポジトリで管理、ということになる。README.md はごく簡単にして、詳しくは HTML ドキュメントをご覧ください、という誘導。

つまり、README.md(+リポジトリ内ドキュメント)陣営オンリーになり、Wiki の出番は無い。

ただ、HTML ドキュメントの欠点は、GitHub サイト上で表示されないこと。http://htmlpreview.github.io/ で表示するか(現時点で CSS は反映されない)、あるいはリポジトリをいったんダウンロードしてもらうという手間が発生する。

その点 Wiki(でもリポジトリ上の *.md でもいいけど)はお手軽で良い。しかし、デザインを変更できないという他にも、ソフトウェア配布時にローカルで読めないという欠点もある。ネットに繋がっていないとドキュメントが読めないというのは困るシチュエーションがあるし、GitHub の都合で URL が変更されたりしたらリンク切れになってしまう。また、Wiki には「リンク先を別タブで開く」といった基本的な機能が備わっていなかったりする。

というわけで、暫定方針としては
  • 簡単なドキュメント……README.md
  • 本格的なドキュメント……HTML ドキュメントをリポジトリで管理
  • Wiki は使わない
としようと思うが、課題はある、といった感じ。

他の人はどうしているか

使い分けを明確に示しているサイトが意外と無いのだが、
というような事例はあった。

ニコカラメーカー 2 が Mac + Boot Camp で動作

ニコカラメーカー 2 は Windows 10 専用ソフトであるが、M 氏は Mac 上でニコカラメーカー 2 を使用しているとのことなので、動作する様子を見せていただいた。

動作方法

Mac で Windows 用ソフトを動かすには大きく 2 種類の方法がある。
  1. Boot Camp により、独立した Windows をインストール
  2. 仮想化ソフトにより、Mac OS の上で Windows 環境を再現
M 氏は前者の Boot Camp 方式でニコカラメーカー 2 を動かしていた。

Mac のスペック

MacSpecM 氏の Mac は、
  • CPU:Intel Core i5-7267U(2 コア 4 スレッド、3.10 GHz)
  • メモリ:8GB
というスペック。

Apple のホームページは過去の製品情報がとても探しづらいのだが、こちらの Mac Book Pro 2017 かな? 巷では MPXV2J/A とか A1706 の型番で認識されているようだ(公式サイトに型番表記が無いとかダメすぎ)。だとすると、他のスペックは
  • 13.3 インチ 2,560 x 1,600 ピクセル IPS 液晶ディスプレイ
  • メモリ:8GB(LPDDR3-2133)
  • 内蔵 GPU:Intel Iris Plus Graphics 650
となる。

FnFn キーを押している間、キーボード最上段のキーの表示が変わるというギミックを備えている。面白いギミックではあるのだが、M 氏曰く、別に便利ではないとのこと。

ニコカラメーカー 2 動作

selectMacBook の電源を入れると、Boot Camp で OS 選択画面になるので、Windows を選ぶ。

desktopWindows が起動すると、普通の Windows とまったく変わらない。ディスプレイ下の「MacBook Pro」の文字が無ければ、Mac で動かしているとは気付かない。

bootingニコカラメーカー 2 起動中。

booted無事に起動!

lyricstab一通りの動作が問題なく行われていることを確認できた。

Thank you!

M 氏、貴重なものを見せていただきありがとうございました。

なお、本レポートは M 氏の環境で動作していたという事実のみであり、すべての Mac で動作するかどうかは不明です。

ニコカラメーカー 2 に限らず、私が開発している Windows 用ソフトすべてにおいて、Mac 上での動作は公式には動作対象外です。

3700X 一周年:SSD 書き込み量

今代のメインマシン(Ryzen 7 3700X)を使い始めてから、今日でちょうど丸一年。

起動に時間がかかるのと、アイドル時の消費電力が高めなのが不満点ではあるもの、全体的には快適に使えてる。

各 SSD の現時点での総書込量を記録しておく。ちなみに 3 ヶ月時点のはこちら

CC ドライブは 7,084 GB。

300 TBW のディスクなので、42 年使える計算。

DD ドライブは 2,824 GB。

400 TBW のディスクなので、141 年使える計算。

EE ドライブは 3,271 GB。

400 TBW のディスクなので、122 年使える計算。

いずれのディスクも TBW 的にはまったく問題がないが、D / E ドライブはパーセンテージが 99% に減ったのが少し気になるところ。

ついでに、USB 外付け HDD も CrystalDiskInfo しておく。

FF ドライブは新しくなった My Book Duo

およそ 110 日経過しており、使用時間としては 2,640 時間ほどになる計算だが、実際にはたったの 248 時間というのは、省電力で自動 OFF になっているからだろう。代わりに、電源投入回数が 437 回になっている。

UU ドライブはポータブル HDD。17,813 時間(2.0 年)使用。



UTAU 関連の Fantia をサーチ

Fantia_Logo_200x56自分が Fantia(クリエイター支援サイト)に登録したこともあって、「UTAU 関連の Fantia 他にもあるのでは?」と思ったので探してみた。ぼちぼちあるらしい。

ファンクラブ名の五十音順にリストアップ。

ツールなど


音源、音楽など



他にもご存じでしたら教えてください。
pixivFANBOX も今度探してみようかしら。

初代ニコカラメーカー vs ニコカラメーカー 2 速度比較

初代ニコカラメーカー(Ver 7.91 β)とニコカラメーカー 2(Ver 3.21 β)で、動画出力時の速度を比較した。

マシンスペック

速度比較を実施した PC の主な環境(構成)は、
  • CPU:AMD Ryzen 7 3700X(8 コア 16 スレッド)
  • GPU:GIGABYTE GV-N1650IXOC-4GD(GeForce GTX1650)
となっている。詳細についてはこちらの記事参照。

対象動画

Nkm1_04435初代ニコカラメーカーにて既にニコカラを作成している

Nkm2_04432ニコカラメーカー 2 でもニコカラを作成し、初代ニコカラメーカーのニコカラとなるべく近い結果になるように設定した。

AVI 出力時間

無圧縮 AVI を、初代ニコカラメーカーとニコカラメーカー 2 でそれぞれ 2 回ずつ動画出力し、平均動画出力時間を比較した。結果は以下の通り。

初代ニコカラメーカーニコカラメーカー 2
1 回目7 分 46 秒2 分 10 秒
2 回目7 分 34 秒2 分 11 秒
平均7 分 40 秒
2 分 11 秒
ニコカラメーカー 2 のほうが、初代ニコカラメーカーより 3.5 倍高速に出力された。

初代ニコカラメーカーはほぼ CPU 1 スレッドで作業しているが、ニコカラメーカー 2 では 9 スレッドで作業しているのと、GPU も活用して作業しているため、高速化されている。

Nkm1_OutputWindow初代ニコカラメーカーの出力ウィンドウ。

Nkm1_Output_AVI_CPU初代ニコカラメーカー出力時の CPU 使用率。

Nkm1_Output_AVI_GPU初代ニコカラメーカー出力時の GPU 使用率。

Nkm2_OutputWindowニコカラメーカー 2 の出力ウィンドウ。

Nkm2_Output_AVI_CPUニコカラメーカー 2 出力時の CPU 使用率。

Nkm2_Output_GPUニコカラメーカー 2 出力時の GPU 使用率。

連番 PNG 出力時間

連番 PNG を、初代ニコカラメーカーとニコカラメーカー 2 でそれぞれ 2 回ずつ動画出力し、平均動画出力時間を比較した。結果は以下の通り。

初代ニコカラメーカーニコカラメーカー 2
1 回目16 分 38 秒2 分 27 秒
2 回目16 分 04 秒2 分 23 秒
平均16 分 21 秒2 分 25 秒
ニコカラメーカー 2 のほうが、初代ニコカラメーカーより 6.8 倍高速に出力された。

Nkm1_Output_PNG_CPU初代ニコカラメーカー出力時の CPU 使用率。

Nkm1_Output_PNG_GPU初代ニコカラメーカー出力時の GPU 使用率。

Nkm2_Output_PNG_CPUニコカラメーカー 2 出力時の CPU 使用率。

Nkm2_Output_PNG_GPUニコカラメーカー 2 出力時の GPU 使用率。

連番 PNG(字幕のみ)出力時間

連番 PNG(字幕のみを透過で)を、初代ニコカラメーカーとニコカラメーカー 2 でそれぞれ 2 回ずつ動画出力し、平均動画出力時間を比較した。結果は以下の通り。

初代ニコカラメーカーニコカラメーカー 2
1 回目7 分 05 秒1 分 48 秒
2 回目7 分 00 秒1 分 47 秒
平均7 分 03 秒1 分 48 秒
ニコカラメーカー 2 のほうが、初代ニコカラメーカーより 3.9 倍高速に出力された。

出力時間まとめ


初代ニコカラメーカーニコカラメーカー 2倍率
無圧縮 AVI7 分 40 秒2 分 11 秒3.5 倍
連番 PNG16 分 21 秒2 分 25 秒6.8 倍
連番 PNG(字幕のみ)
7 分 03 秒1 分 48 秒3.9 倍

関連リンク






マシン消費電力まとめ(メインマシン:Radiant 3700X)

メインマシンの UEFI を安定の AGESA 1.0.0.4 B に上げたので、消費電力を簡単に測定してみた。

電源投入後、Windows 10 起動時はかなり上下があるが、最大で 134W。

アイドル時は基本的に 64W。先代の Core i7 マシンは 49W だったので 31% 増加。やはり AMD 系のシステムはアイドル時の消費電力が高いようだ。

tmpgencフル HD 60 fps の動画を H.264 から H.265 にトランスコード(CPU エンコード)している時は 152W。

tmpgenc2ちなみに、所要時間は予測値で 1 時間 10 分程度。

ソフトのバージョンも違うので目安だが、先代のマシンの 3 分の 1 の時間でトランスコードできる計算だ。コア数が多いので消費電力は 1.5 倍程になっているが、トランスコードにかかる全体の消費電力は半分程に抑えられる計算。

トランスコードしながら CrystalDiskMark してみると、消費電力は 165W まで増加。

watt2また、トランスコードしながら waifu2x で GPU も使うと、消費電力は 220W。

taskman2トランスコード+CrystalDiskMark+waifu2x だと、消費電力は 221W。最高消費電力はさほど増えなかったが、2 種の時よりも高い水準で消費電力が推移していた。

しかし、最高でも 221W なら、電源は 650W も要らなかったよね……。本当はもっと低い電源容量が良かったのだけど、選択肢に良いのがなく仕方なしに 650W にしたのだが、改めて、より低い電源容量をラインナップしておいて欲しかったと思った。

3 ヶ月時点の SSD 書き込み量

新パソコン(Ryzen 7 3700X)を使い始めて 3 ヶ月が経過。各 SSD の現時点での総書込量を記録しておく。ちなみに 1 ヶ月時点のはこちら

CC ドライブは 2753 GB。

300 TBW のディスクなので、27 年使える計算。

DD ドライブは 2033 GB。

400 TBW のディスクなので、49 年使える計算。

EE ドライブは 2048 GB。

400 TBW のディスクなので、48 年使える計算。

いずれもパソコン買い換えサイクルよりも長いことを改めて確認。

使用時間が 2181 時間(=91 日)という表示になっており、正しく記録されている。

Intel & AMD CPU コア数別ラインナップ比較

CPU のコア数が増えすぎて訳が分からなくなってきたので、デスクトップ向け CPU について少し整理してみたメモ。8 コア以上の CPU を整理。サーバー向け(Xeon/EPYC)や数量限定品(9900KS)は除外している。

価格については、相場月報 2019/10 版を参照している(記載の無いものは初出価格)。

HEDT(ハイエンドデスクトップ)向け

HEDT


HEDT 向けは AMD の圧勝。

24 コア以上は Intel のラインナップが無い。14 コア以下は AMD はメインストリーム向けで十分にカバーできてしまっている。

HEDT 向けで Intel の唯一の存在感は、AMD のラインナップの隙間となっている 18 コア品。

メインストリーム向け

Main


メインストリーム向けのうち、上位の布陣も AMD の勝利。

12 コア以上について AMD がしっかりラインナップしているのに対し、Intel は HEDT 向けのラインナップになってしまっているので、マザーボード等を含め価格がかなり高く付く。

メインストリーム向けのうち、8 コアは良い勝負。

8 コア 16 スレッド品は、価格の絶対値では AMD が安いが、Intel はオンボードグラフィックスを搭載している。Intel のオンボードグラフィックスに相当する外付けグラフィックスは数千円程度のため、グラフィックス込みでも価格面では AMD が優位だが、Intel のほうが TDP を抑えられる。

また、どうせグラフィックスを外付けするならある程度の性能を持つものを、と考えると、価格が 1 万円以上上乗せとなるので(もちろん性能も圧倒的だが)、悩ましい選択となる。

8 コア 8 スレッドについては Intel のみのラインナップとなる。AMD は、6 コア 12 スレッドの Ryzen 5 がカバーする領域となる。

C# 8.0 の null 安全はいろんな意味で革命だった

null 安全とは

「イマドキのプログラミングは null 安全がトレンドらしい」(参考記事:null 安全でない言語は、もはやレガシー言語だ)ということで、null 安全初心者が null 安全なコードを書いてみた。

そもそも null 安全とは、「null 参照例外(NullReferenceException)が発生しえるコードをコンパイル時にエラーにしてくれる」仕組み。つまり、コンパイルが通った時点で null 参照例外は起こりえないということになる。革命的に素晴らしいのでは?

C# においては、最新の言語バージョン 8.0 で「null 許容参照型」が導入され、これを使うと null 安全になる。

「null 許容参照型」という名前を聞いて、「参照型なんだから null が許容されるのは当たり前じゃないか」と思ったのだが、その常識が覆る。null 許容参照型を導入することにより、「普通の参照型には null を代入できなくなる」。つまり、C# という言語レベルで過去との互換性が失われる! 革命的に影響が大きい。

あまりにも影響が大きいので C# 8.0 では null 許容参照型はオプション扱いとなり、かなり限定的な環境でないと有効にならない。Visual Studio 16.3 の時点では、プラットフォームを .NET Core にしたうえで(.NET Framework でも一部機能は使えるらしい)、プロジェクトファイルを直接編集して null 許容参照型(Nullable)を有効にして、かつ、関連する警告をエラー扱いにする(参考記事:null 許容参照型)。

コード例

今までの C# のコード
String str = null;
String low = str.ToLower();
があったとして、ここまでシンプルであれば NullReferenceException を予見してコードを修正できるが、str の初期化がどこでされてるか分かりづらい場合は見逃してしまって NullReferenceException が発生するという事態に陥る。

しかし、null 許容参照型を有効にすると「普通の参照型には null を代入できなくなる」ので、str = null の時点でコンパイルエラーとなる。従って、
String str = "HOGE";
String low = str.ToLower();
のようなコードに修正せざるを得なくなり、NullReferenceException が発生しない安全なコードになる。これが null 安全か!

とはいえ、「str が null になることもある」という場合に、null 許容参照型を使う。型名の後ろに「?」を付けるだけだ(null 許容値型と使い勝手は似ている)。
String? str = null;
String? low = str?.ToLower();
str?.ToLower() の部分は、str が null であれば null が返り、null でない場合のみ ToLower() が実行されるので、NullReferenceException が発生しない。str が null の時は low も null になるので、low も null 許容参照型にする必要がある。? を忘れるコンパイルエラーになるので、やはり NullReferenceException は発生しない。null 安全すごい。

いくつかコードを書いてみた感想

null 許容参照型を有効にすると、変数が null になり得るのか否かを常に意識するようになる(というか、不適切なコードはコンパイルエラーになるので意識せざるを得ない)。

特にクラスメンバーを null 許容にしなかった場合は、コンストラクターでの初期化が必要となるので、「null 許容があるべき姿なのかどうか」をしっかり考えて選択するようになった。

関数の書き方も変わってくる。

Boolean TryParse (String s, out Hoge? result) のような関数は、返値が true の場合は result は null にはならず、それをコンパイラに教えるためには [NotNullWhen(true)] のように属性を指定する。が、そんな面倒なことをするくらいなら Hoge? TryParse(String s) のような形式に変更するほうがいいと思う。

また、型キャストの際に as 演算子を使うとキャストできなかった場合に null が返ってきてしまうので、if 文の中で is 演算子を使うスタイルに変わってきた。
private void Func(Object? sender)
{
    if (sender is UIElement element)
    {
        element.AllowDrop = true;
    }
}
sender が null ではなく、かつキャストできる場合のみ element に代入されるため、element は null 非許容となり、element のプロパティーにアクセスする際に ? は不要。

一方で、NullReferenceException にならない安全な世界ではあるものの、使い方を間違えるとエラーが埋もれるだけのより深刻な状況にもなりかねない。

呼ばれること自体に意味があるような関数、例えばユーザーへの警告表示で、null 安全ではない世界であれば、
hoge.ShowWarning();
で hoge が null の場合は例外が発生してマズいことになったのが表面化するが、null 安全な世界だと
hoge?.ShowWarning();
のようなコードとなり、例外は発生しないが、ユーザーに警告が表示されず、しかも表示されないままスルーされて問題が埋もれてしまう。

革命は 1 日にして成らず

null 安全は C# にとってあまりにも影響が大きく、ライブラリやコンパイラの対応もまだ発展途上のようだ。

例えば、メンバー変数をコンストラクターで初期化する際、コンストラクターから関数を呼びだしてそこで初期化していても、初期化していないと判定されてしまう。

また、
String[] strs = new String[3];
はコンパイルが通ってしまうが、実際には String[0] などは null であり、本来であればコンパイルエラーにしなければならないコードだ。

環境が整うまでにはまだまだ時間がかかりそうである。

とはいえ、null 安全は非常に素晴らしい仕組みだと思うので、少なくとも今後新規作成するプロジェクトでは積極的に使っていきたいと思う。

気になったこと

マルチスレッドで null 許容参照型にアクセスするとどうなるんだろうか。

想像だが、str?.ToLower() のようなコードはコンパイル時に

if (str != null)
{
    str.ToLower();
}
のように解釈されるのではないだろうか。だとすると、str が null ではないと判定した直後に別のスレッドが str を null にしたら、ToLower() 呼出の際に NullReferenceException が発生してしまわないだろうか。

ところで、Nullable の読み方って「ぬらぶる」?

1 ヶ月時点の SSD 書き込み量

新パソコンを使い始めて 1 ヶ月。各 SSD の現時点での総書込量を記録しておく。

cdm_c_presentC ドライブは 1644 GB。

300 TBW のディスクなので、15 年使える計算。

cdm_d_nanatunatuD ドライブは 1795 GB。

400 TBW のディスクなので、18 年使える計算。

cdm_e_bikiniE ドライブは 1752 GB。

400 TBW のディスクなので、19 年使える計算。

いずれもパソコン買い換えサイクルよりも長かったので一安心。

ついでに、USB 外付け HDD も CrystalDiskInfo しておく。

cdm_f_maruF ドライブは RAID ユニットで、ディスク交換したため使用時間が 14 時間に戻っている。元々は 36,222 時間だったので、ユニット全体の使用時間はプラス 36,000 時間程度。

cdm_u_kimonoU ドライブはポータブル HDD。9846 時間使用。


WPF で動画に文字や図形を合成して再生する方法

C# 動画プログラミングの 1 つです。

WPF の MediaElement や MediaPlayer で動画を再生する方法を紹介したページはいくつか見たのですが、通常再生のみが紹介されており、加工しながらの再生について言及されているページが見当たらなかったので、ここにまとめてみます。

目次


やりたいこと

overlay2動画再生時に、再生している動画の映像に、テキスト等を重ねます。

例として、映像の左上に灰色の長方形を描き、フレームレートや動画再生位置(秒数)といった文字を重ねてみます。

サンプルコード

GitHub にアップしてありますので、そちらからダウンロードしてください。

動作環境については GitHub リポジトリ内のヘルプファイルを参照して下さい。

実装の基本方針

WPF には、(動画に限らず)表示の更新を行うタイミング(つまりフレームごと)で発生するイベントがあり、それが CompositionTarget.Rendering イベントです。

このイベント内で再生中の動画をキャプチャした上で、テキスト等を書き込んでいく、というのが基本的な考え方です。

プログラムの大まかな動作としては、ドラッグ&ドロップされた動画を再生(もちろん音声も)しつつ、上記の方法で映像にテキスト等を重ねています。

プログラムの解説

MainWindow.xaml.cs の解説です。

ファイルをドロップされた際に発生するイベント Window_Drop() において、動画の再生 Play() と、重ね合わせの準備 PrepareOverlay() を行っています。

Play() は単純に、ドロップされたファイルを MediaPlayer で再生しているだけです。

今回の 1 つのポイントは PrepareOverlay() で、ここでフレーム描画イベントハンドラー CompositionTarget.Rendering の設定を行っています。

ここで設定されたイベントハンドラーは WPF での描画が必要なタイミングで常に呼びだされるため、仮に動画が再生されていなくても定期的に呼びだされます。呼びだされる頻度は環境によって異なるとのことで、私の環境では通常 60 fps 程度で呼びだされていますが、100 fps 程度に上がることもあります。あくまでも「WPF 描画のフレームレート」であって、動画のフレームレートではないことに留意してください。

イベントハンドラーとして設定された CompositionTargetRendering() の後半部分で合成を行っています。

DrawingVisual の DrawingContext に対して、動画、図形(背景の灰色四角形)、テキスト(フレームレートや再生位置)を書き込み、最後にそれらを表示用のビットマップ(mBmp)に書き込みます。

ImagemBmp は PrepareOverlay() で Image コントロールのソースに指定されているため、mBmp の内容がユーザーの目に見える形で表示されることになります。

WPF で動画を扱うメリット

WPF で動画を扱うメリットは、なんといっても手軽なことです。

加工しない再生だけなら MediaElement コントロール 1 つで簡単に動画を再生できますし、加工しても今回のサンプルコードのようにわずかなコード量で実現できます。

標準の C# 開発環境のみで実現できるため、追加のサードパーティーライブラリを用意したり、それをユーザーにインストールしてもらう(または一緒に配布する)という手間もありません。

GPULoadGPU ハードウェア支援が使える場合は、自動的に活用してくれているようです。

また、詳しくは未検証ですが、インストールされているコーデックライブラリ(K-Lite 等)も WPF 側で自動的に利用してくれているようで、扱える動画の形式も無限に広がっていきます。

WPF で動画を扱うデメリット

WPF で動画を扱うデメリットは、(動画の)フレームを厳密に扱えないのではないかということです(扱える方法をご存じの方は教えてください)。

まず、根本的な課題として、動画のフレームレートが取得できません。動画の縦横サイズ等はプロパティーで取得できるのですが、フレームレートを取得するプロパティーはありません。

また、WPF で動きのあるものを処理する際はアニメーションという仕組み(Animatable クラスないしは IAnimatable インターフェース)に則っており、動画(MediaElement / MediaPlayer)も例外ではありませんが、動きの管理が時間単位で行われています。

何らかの方法で動画のフレームレートを取得できたとしても、厳密な意味でのフレーム送りはできず、1 フレームは○○ミリ秒だから○○ミリ秒進める、というような形でのフレーム送りになるのではないかと思います(この辺りは未検証ですが)。30 fps だと 1 フレーム当たり 33.3333.... ミリ秒ですが、小数点の丸めによって微妙に進まない(または 2 フレーム進んでしまう)瞬間が発生したり、そもそも可変フレームレートだとどうしようもないのではないかと思います。

スクリーンショットの動画

このページ冒頭のスクリーンショットに映っている動画は、ダブルレンさんの「お願い☆EternalSummer!」という曲です。素敵な曲なので、是非聴いてみて下さい!


歌いたい時はニコカラバージョンでどうぞ。








マシンベンチマークまとめ(メインマシン:Radiant 3700X)

新しい Ryzen 7 3700X マシン(詳細スペックはこちら)のストレージ性能を CrystalDiskMark で見てみた。

C ドライブ(NVMe SSD)

Western Digital WD BlackWD Black SN750 WDS500G3X0C は NVMe SSD の中でも比較的高速な部類の SSD で、CrystalDiskMark の成績も良い。

シーケンシャルリード 3475MB/s とカタログスペック(3470MB/s)通りの性能が出ている。

シーケンシャルライトは 2585MB/s とカタログスペック(2600MB/s)に僅かに及ばないが十分な性能。

ランダムリードは 50MB/s 越え。

ランダムライトはなんと 200MB/s 越えで、HDD のシーケンシャルライトより速いのではないか。

D ドライブ(SATA SSD No.1)

Micron12TB では激安の Micron 1300 MTFDDAK2T0TDL-1AW1ZABYY。他のが少なくとも 25,000 円以上する中で、これだけ 20,000 円で買える。

SATA SSD としては十分な性能(というか SATA 規格の限界でこれ以上の性能が出ない)で、シーケンシャルリード・シーケンシャルライト共に 530MB/s 越え。カタログスペックは 530MB/s と 520MB/s なので、シーケンシャルライトはカタログスペックを上回っている。

ランダムリードは約 40MB/s と、SATA SSD としては最速クラスではないだろうか。

E ドライブ(SATA SSD No.2)

Micron2同じく Micron 1300。

当然ながら、性能は D ドライブと同等。

当初はシーケンシャルリードが約 400MB/s と微妙に遅かったが、これはどうやら SATA ケーブルが古かったのが悪さをしていたようだ。新しいケーブルと交換したことで、本来の性能を発揮できるようになった。

F ドライブ(外付け HDD)

WD_HDD_7USB 3.0 接続の外付け RAID HDD ユニット、Western Digital My Book Duo WDBLWE0080JCH-JESN。


HDD ということで途端に性能が悪くなっている。加えて、4 年越しの使い古し品であることも悪条件。


新品の時に測定したデータと比べると、シーケンシャルは約 2/3、ランダムは約半分に性能が落ち込んでいる。


ポータブル 2.5 インチ HDD

WD_HDD_PortableUSB 3.0 接続のポータブル外付け 2.5 インチ HDD、Western Digital My Passport。

2.5 インチなのでさらに性能が低い。

補足

ウィルス対策ソフトはインストールしただけでもストレージ性能下がるかなと思っていたが、実際はそうでもなかった。

インストール前と、インストール後に保護停止にした状態でそれぞれ SSD の性能を測定したが、有意な差は見られなかった。

なお、ウィルス対策ソフトは Kaspersky を使用している。

マシン消費電力まとめ(メインマシン:Core i7)

メインマシンの消費電力をごく簡単に測定した結果、49~104W 程度の消費電力だった。

電源投入後はかなり上下があるものの、90W くらい。

wattアイドル時は基本的に 49W。たまに上振れして、57W くらいまで上がることがある。

EncodeSettingsフル HD 60 fps の動画を H.264 から H.265 にトランスコードしている時は 104W。

EncodeLoadただし、CPU ロードは 90% 程度なので、フル稼働にはなっていない。

EncodeTimeちなみに、所要時間は予想値で 3 時間 35 分程度だった。

CrystalDiskMark してる時のも測定すればよかったな。

次のパソコンのマザボ

次のパソコンのマザーボードを何にするか検討中。

メーカーASUSASUSASRockMSI
型番ROG Strix X570-F GamingTUF GAMING X570-PLUSB450 Steel LegendB450 TOMAHAWK MAX
価格34,000 円
24,000 円
13,000 円
14,000 円
チップセットX570
X570B450B450
メモリクロック4400~21334400~21333200~21334133~2667
VRM フェーズ12+212+24+2
M.2PCIE 4.0 x4PCIE 4.0 x4PCIE 3.0 x4
PCIE 3.0 x4

巷で評判の良いマザボと、いくつかの BTO ショップ推奨のマザボを比較。

ROG Strix X570-F Gaming

ROG Strix は Wi-Fi やカスタマイズオプション満載のシリーズとのこと。オーバースペックな気がする。チップセットファンも気になる。
VRM 周りは下位とシリーズと同レベルらしい。AGESA 1.0.0.3 ABB でも WHEA が発生するという話もある。

TUF GAMING X570-PLUS

TUF GAMING は耐久性重視のシリーズとのこと。高耐久の安心感は欲しい。価格も許容範囲。チップセットファンは気になる。
スリープ後にクロックが下がらなくなる事象が発生する環境があるらしい。

B450 Steel Legend

公式に DDR4-3200 をサポートしており、実例もあるマザボ。X570 と比べるとスペックは見劣りするが、これで十分な気もする。
しかし消費電力は他の B450 と比較して高いらしい。
MicroATX の B450M は、チップセットヒートシンクが無くなり、拡張スロットとストレージスロットが減る。

B450 TOMAHAWK MAX

B450 の中でも Zen2 に合わせてきたマザボということで安心感があるが、いかんせん情報が少ない。


お見積もり。いくつかの BTO ショップで見積もってみた。データ SSD は無しにしているので、これにプラス 56,000 円くらいかかる。OS も付けるならさらにプラス 20,000 円くらい。

サイコム

使いやすいウェブサイト。やや文字が小さい。

145,810 円……Ryzen 3000 シリーズのページにある B450 チップセットのスタンダードモデル(Radiant VX2800B450A)をカスタマイズ。MicroATX の Steel Legend。メモリ DDR4-3200、2 万円引き。ケース品切れ中。電源は Antec NeoECO 650W GOLD。

146,030 円……Ryzen 3000 シリーズのページにある X570 チップセットのスタンダードモデル(Radiant GZ2800X570A)をカスタマイズ。ATX の Steel Legend。メモリ DDR4-3200、2 万円引き。電源は Antec NeoECO 650W GOLD。

159,180 円……Ryzen 3000 シリーズのページにある B450 チップセットの静音 PC(Silent-Master Pro B450A II)をカスタマイズ。ATX の Steel Legend。メモリ DDR4-3200、2 万円引き。電源は Antec NeoECO 650W GOLD。

パソコンショップ SEVEN

172,244 円……CPU 別の Ryzen 3700X から、ZEFT R7K02 の OS 無しモデルをカスタマイズ。キャンペーン 15,000 円引き。ATX の Steel Legend。メモリは DDR4-3200 が品切れで 2400。電源は Antec NeoECO 650W GOLD。Blu-ray は BH16NS58。

見やすいウェブサイト。オプションが全て全開のためやたら縦に長くスクロールが大変。

VSPEC

191,860 円……特集コーナー AMD Ryzen 対応モデルから第 3 世代 Ryzen スタンダードをカスタマイズ(AMD ハイエンドモデルから行くと第 2 世代になってしまうので注意)。SL が選べず TUF GAMING X570-PLUS。メモリは DDR4-2666。

PC ワンズ

137,159 円……フルカスタマイズ PC のメニューから BTO できる。ATX の Steel Legend。メモリは DDR4-3200。電源は NeoECO 550W。

パーツを 1 つ 1 つ指定していくのが大変なだけではなく、ブラウザを閉じるとカートの中身が失われてしまうという恐ろ仕様。心折れそう(最初折れた)。




次のパソコンを軽くイメージ その 3(2019 年 7 月)

Ryzen 3000 シリーズが発売されたので、その 2 から修正。

本体


パーツ型番想定価格(税込み)
名称次期メインマシンイメージ その 3(2019 年 7 月)
202,000 円
~252,000 円
マザーボード未選定
11,000 円
CPUAMD Ryzen 3700X
※8 コア 16 スレッド、定格クロック 3.6GHz(ブースト 4.4GHz)、TDP 65W、7nm プロセス
43,000 円
CPU クーラーCPU 付属品
0 円
セラミックグリスCPU 付属品0 円
メモリ32 GB
※DDR4-3200(PC4-25600)DIMM 16GB×2
25,000 円
システム SSDWestern Digital WD Black SN750 NVMe WDS500G3XHC
※500GB、PCIe Gen3 x4、M.2 2280
【または】
Intel Optane SSD 905P 380GB M.2
※380GB、PCIe Gen3 x4、M.2 22110
17,000 円
【または】
67,000 円
データ SSD4TB
※SATA 2TB×2
56,000 円
マウンタSSD 付属品0 円
光学ドライブ
(Blu-ray)
LG BH14NS58
8,000 円
ビデオカードPalit NE51650S06G1-1170F
※GeForce GTX1650 STORMX OC 4GB、TDP 75W、12nm プロセス
17,000 円
LANオンボード
- 円
ケース未選定
15,000 円
電源500W
10,000 円

CPU は Ryzen 3000 シリーズが発売となったので、8 コアの 3700X をチョイス。8 コア APU を希望していたが、残念ながら発売に至らなかったので、グラボは別途とする。APU の i9-9900K という選択肢もあるが、3 年停滞しているインテルはどうもねぇ、という気分的な問題。

PCIe Gen4 を使う予定はないので、マザーボードは X570 でなくて良い。価格は仮置きで ASRock B450M Steel Legend の価格にしている。

メモリは現行パソコンと同様の 32GB で据え置き。

システム用 SSD は安価に NVMe で済ませる気がしている。Optane SSD の新しいのがもし出ればそちらもよいかもしれないが……。

データ SSD は本当は 4TB×1 が良いが、まだ高いので、2TB×2 で妥協。

Blu-ray ドライブは適当なので良い。

ビデオカードは、Ryzen APU よりはマシな程度で、かつ、消費電力がなるべく小さめということで、補助電源不要の TDP 75W クラス。


周辺機器

サウンドカードを更新。
パーツ型番想定価格(税込み)
RAID ユニットWestern Digital My Book Duo WDBLWE0080JCH-JESN(流用)
※8TB、RAID 1 の運用で実効 4TB
※USB 3.0 接続
0 円
サウンドカードCreative Sound BlasterX G5(流用)
※USB 接続
0 円
スピーカーONKYO WAVIO GX-70HD(流用)
0 円
オーディオレシーバーONKYO WR-BT300(流用)
※Bluetooth で音声を受信してスピーカーに流す
0 円
ディスプレイ21.5 インチワイド液晶、IO DATA LCD-MF223XS(流用)
※HDMI 接続
0 円
ゲームコントローラーLogicool F310r(流用)0 円





M.2 SSD (NVMe) 512GB メモ

次期パソコンの C ドライブ用ストレージ、Optane がいいなと思っていたけど、NVMe SSD でもまぁいいかもと思い始めたので、512GB クラスのカタログスペックを整理。価格は相場月報 6 月号の平均価格。

ssd

現行マシンの C ドライブは 6 年間で 40TB 近くの書込になっていて、次期マシンは RAM ディスクを使わないことや動画出力が多そうなことを考えると、10 倍の 400TBW くらい欲しいけど、一覧を見ると 300TBW で妥協するほうがいいのかもしれない。

体感速度に影響するであろうランダムリードと、動画出力用にシーケンシャルライトが速いのがいいなと思うと、WD、SanDisk、ADATA の順に有力。ADATA だけずいぶん安い。

Western Digital WD Black SN750 NVMe WDS500G3XHC……ヒートシンク無し版(型番末尾 X0C)もあるので注意。1TB 版のレビュー記事

SanDisk Extreme Pro M.2 NVMe 3D SSD SDSSDXPM2-500G-J25……レビュー記事

ADATA XPG SX8200 Pro ASX8200PNP-512GT-C……レビュー記事



PetitKara のストレージ認識状況メモ

PetitKara にいくつか USB メモリや HDD を繋げた際の挙動をまとめてメモ。記憶を頼りにしている部分もあり、もしかしたら間違っている部分もあるかもしれない。

使用した PetitKara のバージョンは 1.4.19 で、WAN 側はインターネットに接続していない。

相性の悪い USB メモリ

transcendUSB メモリ A(JetFlash Transcend 2GB、NTFS、動画ファイルなし)を本体に直接挿して起動したところ、Debian のデスクトップまでは起動するが、PetitKara が起動しない。

Debian は USB メモリ A を認識していて、デスクトップに USB メモリ A のアイコンが表示されていた。

動画情報更新で読めない HDD

PetitKara が起動した状態で HDD E(Western Digital My Passport 4TB、青色、NTFS、動画ファイル 4 万個)を本体に直接挿し、動画情報更新をしたところ、10 分以上経っても動画情報更新が終わらない。HDD のアクセスランプが点滅しておらず、HDD にアクセスしている気配が無い。

セルフパワー型ハブ(Anker 10-Port USB 3.0 Hub)に HDD E を挿して動画情報更新をしても終わらない。なお、以降はすべてハブ経由の接続。

guruguru2動画情報更新を中断し、ログインして動画を検索すると、ぐるぐるアイコンから先に進まない。

HDD F(4TB、黒色)についても同様で、起動後の動画情報更新で認識してくれない。

動画情報更新可能な USB メモリ

sonyUSB メモリ B(SONY Storage Media 32GB、NTFS、動画ファイル 250 曲)は、PetitKara 起動後に挿して動画情報更新をしたら認識してくれた。

ストレージ 5 本挿し

storage5a起動後の動画情報更新ではなく、起動時に挿しておくと認識してくれることに気がついた。

USB メモリ B、USB メモリ C(水色)、HDD E、HDD F、HDD G(Buffalo HD-PNFU3、1TB、黄色、動画ファイル 1.3 万個)の 5 つを接続した状態で起動すると、Debian のデスクトップにすべてのストレージのアイコンが表示された。

41709aPetitKara でも基本的には認識されたが、HDD E については認識してくれなかった。検索結果は 42,000 件ほど。

この状態でしばらく運用していたところ、2 回ほど、曲が途中で終了してしまう状況が発生した。

Debian では認識されているが PetitKara からは認識されていない HDD E が何らか影響しているのかと思い、HDD E を外してみた。本来は外した後で動画情報更新を行うべきであるが、動画情報更新はうまくいかないことが分かっているので、動画情報更新はしていない。

notfoundすると、今まで使えていた USB メモリ B の中の動画について、検索結果には引き続き出てくるものの、リクエストしようとすると「動画が見つかりません」というエラーとなった。

USB メモリ B の中には、HDD E と同じファイルの一部が入っている形になっており、ファイル名だけで見れば HDD E と重複しているが、それが何か関係しているのであろうか。

別の組み合わせでストレージ 5 本挿し

USB メモリ B、HDD E、HDD F、HDD G、HDD H(Western Digital My Passport 4TB、黄色)の 5 つのストレージを起動時から接続しておいたところ、先ほど認識されなかった HDD E も含めて 5 つすべてのストレージが認識されたのではないかと思うが、ファイル数が多すぎて今ひとつ自信が無い。HDD E のパスをキーワードにして検索した結果の数から見て、HDD E はたぶん認識されたと思う。

100kキーワードを空にした場合、検索結果が省略されてしまっているが、10 万件ということだと思う。

5087検索結果ページ数は 5087 ページ。





Factory Town 計算ブロックでマインカートを制御する

生産物流箱庭ゲーム「Factory Town」において、マインカート(鉄道)は直進しかできない猪突猛進型のユニットですが、計算ブロックを使うことで、マインカートに様々な振る舞いをさせられるようになります。

以下の記事の内容は把握済みである前提でまとめています。

なお、Factory Town Ver 0.108m 時点(Windows 版)での情報です。画像はクリックすると拡大します。

やりたいこと

マインカートの積み荷によって、行き先を分岐させたいと思います。また、積み荷を降ろして空になったマインカートに対しては、1 台ごとに別の荷物を積むようにします。

whole2全体像が右の写真です。

カートは青白い矢印の向きに時計回りに走るものとします。

①のサイロには木材があり、②の井戸からは水が出てきます。従って、カートは木材か水のどちらかを積んだ状態で、(B) の分岐点に来ます。

木材を積んだカートは (B) を上方向に、水を積んだカートは (B) を右方向に進むようにします。

これにより、③の倉庫には木材だけが、④の倉庫には水だけが溜まっていきます。同じ線路を使用していても、積み荷の振り分けが可能となります。

積み荷を倉庫で降ろして空になったカートは、(A) の分岐点に来ます。

(A) では、上方向と右方向を交互に進ませます。これにより、1 台目のカートが木材を積んだら、2 台目のカートは水を積む、というように、2 種類の積み荷を運ぶことができます。

(補足)積み荷の振り分けは、計算ブロックを使わずとも、ソーターやプッシャーでマインカートを押し出すことにより行えます。本記事は計算ブロックの勉強用としてご覧ください。

施設の配置

fusetsu右の写真のように、施設やレールとバリアゲートを配置します。時間を止めた方がやりやすいです。

バリアゲートは物流ブロックの中にあり、設置時は「オフ」になっていて遮断機がおりた状態で通行できませんが、「オン」にすると遮断機が上がって通行できるようになるというブロックです。

サイロと井戸のレールストップは出力、倉庫のレールストップは入力に設定します。

レールの敷設についてですが、(1)-(2)-(3) の分岐部分は、(1)-(2) を先に敷いてから最後に (3) をつなぐようにします。詳しくは、マインカートの記事の「単線運用」節を参考にしてください。

同様に、(1)-(4)-(5) は (4)-(5) が先、(5)-(6)-(7) は (5)-(6) が先、(7)-(8)-(9) は (7)-(9) が先です。

カートは適当な台数(私は 3 台にしました)を、時計回りに走るように配置します。手動でバリアゲートをオンオフして、それぞれの場合でカートが詰まらずに走れるか確認すると良いと思います。

計算ブロックの配置と設定(右側の分岐)

bunki1右側の分岐(積み荷の種類による分岐)の制御を行う計算ブロックの説明から先にします。(5) から来たカートが (6) か (7) かのどちらかに進む分岐です。

カートの積み荷による分岐を行うには、計算ブロックであるエージェントトリガーを使います。エージェントトリガーは、通過したアイテムによってオンオフを出力するブロックです。

エージェントトリガーを分岐点に上乗せして配置します。簡単のために分岐点に重ねていますが、重ねたくない場合は他の場所に配置しても構いません。ただし、他の場所に配置した場合は、オフセット指定で分岐点を必ず指定して下さい。

エージェントトリガーのアイテムフィルタを「水」にします。

bunki2最後に、オンオフをバリアゲートに伝送するために、エージェントトリガーとバリアゲートをリンクします。エージェントトリガーが送信元(左クリック)、バリアゲートが受け取り先(右クリック)です。

ここまでの設定により、「エージェントトリガーを通過したアイテムが水の場合はオン、そうでないならオフ」という設定がバリアゲートに送られます。バリアゲートはオンの時は通行可能となりますから、結果として、水を積んでいる場合に通行可能となります。カートは直進と左折のどちらもできる分岐に来た場合は直進しますので、直進して (7) の右方向に進みます。

一方で、水を積んでいない場合(木を積んでいるか、または空の場合)はエージェントトリガーがオフになります。バリアゲートはオフの時は通行不可ですから、カートは左折せざるを得ず、(6) の方向に進みます。

結果として、木は上の倉庫に、水は下の倉庫に入ります。

計算ブロックの配置と設定(左側の分岐)

次に左側の分岐(交互に振り分け)の制御を行う計算ブロックの説明をします。(2) から来たカートが (1) か (3) かのどちらかに進む分岐です。

bunki3再びエージェントトリガーを使います。エージェントトリガーを分岐に重ねて下さい(オフセットをしていする場合はどこでも構いません)。

さらに、トグルを付近の適当な場所に設置します。

計算ブロックの設定ですが、左側の分岐では、エージェントトリガーのアイテムフィルタは無しのままにしておきます。こうすると、エージェントトリガーと何かが通過したときに常に信号が発生するようになります。

そして、エージェントトリガーからトグルへ信号を伝送するためにリンクします(エージェントトリガーが送信元、トグルが受け取り先)。

トグルは、何らかの信号が届くたびに、オンとオフが切り替わります。つまり、エージェントトリガーをトロッコが通過する度に、交互にオンとオフになります。

トグルの設定をバリアゲートへ伝送するために、トグルからバリアゲートへリンクします(トグルが送信元、バリアゲートが受け取り先)。

交互にオンオフが送られてくるので、バリアゲートは開いたり閉じたりを繰り返します。

動作結果

ゲーム時間を再開すると、カートが走り出します。

カートが動く様子を動画にしましたので、以下の動画を参照してください。



mokuzai上側の倉庫を見ると、木材だけが溜まっていくのが分かります。

mizu逆に、下側の倉庫を見ると、水だけが溜まっていくのが分かります。

以上により、マインカートを制御して積み荷を振り分けることができました。

単に積み荷の振り分けということでいえば、計算ブロックに限らずやり方はいくつもあり、先の補足に記したようにソーターなどでも実現可能です。

しかし、計算ブロックでマインカートの制御ができるようになることで、いろいろな夢が広がっていくのではないでしょうか。

Factory Town 計算ブロックで在庫数に応じた発送制御

生産物流箱庭ゲーム「Factory Town」における計算ブロックの使い方を整理しておきます。前回はごく基礎的な操作方法のまとめでしたが、今回は実用のイメージが湧くかと思います。

なお、Factory Town Ver 0.108m 時点(Windows 版)での情報です。画像はクリックすると拡大します。

やりたいこと

牧場が肥料を生産してベルトコンベアで流してそれを農場が受け取っている場合、農場であまり肥料が消費されないと、肥料が余ってしまってベルトコンベアが渋滞してしまいます。

ベルトコンベアが渋滞しないようにする方法はいくつかありますが、そのうちの 1 つが、「農場の入力用ストレージにある程度肥料が溜まってきたら、牧場側は肥料を送らないようにする」です。これは計算ブロックで実現できます。

kansei今回は例として牧場と農場の代わりに、「井戸が生産した水をサイロで受け取る」場合を考えてみます。

サイロに溜まっている水が 10 個未満の場合のみ、井戸はベルトコンベアに水を放出します。サイロに溜まっている水が 10 個以上になったら、井戸は放出をやめます。

余談ですが、今回もマインカートの時も井戸とサイロを例にしているのは、単に供給が楽というだけで、深い意味はありません。

施設の配置

shisetsu右の写真のように施設を配置します。時間を止めた方がやりやすいです。

井戸とサイロをベルトコンベアで結んでいます。井戸からはグラバーで水を引き出し、サイロへはプッシャーで水を押し込みます。サイロの向きはベルトコンベアに向かないようにして下さい。

計算ブロックの配置

isまず、サイロに溜まっている水の数を計測するセンサーの役割を果たす計算ブロックを配置します。

建設メニューの計算ブロックの中に、その名も「インベントリセンサー」というセンサーブロックがありますので、それを配置します。

math次に、水の数が「10 個未満かどうか」を判定する役割を果たす計算ブロックを配置します。

建設メニューの計算ブロックの中に「数学ブロック」という名前のブロックがあるので、それを配置します。ちなみに、数学というほど仰々しいものではありません。ごく簡単に数字を扱うだけのブロックです。

haichi前回も触れたように計算ブロックの位置はどこでも構いません(問題なく動きます)が、個人的には、インベントリセンサーを左、数学ブロックを右に配置すると、条件が読みやすくて好きです。

これで役者が出そろいました。

インベントリセンサーで読み取った「サイロにある水の数」という状況を入力として、数学ブロックで「10 個未満かどうか」という判断をしたうえで、井戸のグラバーのオンオフを切り替えるという出力を行います。

計算ブロックの設定

is2インベントリセンサーをクリックし、右上に出てくる小窓のオフセットの所をクリックすると、黄色い線が出てきます。

これは、インベントリセンサーが「どこの」在庫の数を調べるかを指定するものです。

is3今回はサイロにある水の数を調べたいので、サイロで「右」クリックします(左クリックではないので注意)。

is4正しく設定できると、再度インベントリセンサーをクリックして選択した際、黄色い線がサイロに向かって伸び、また、オフセットに値が入っています。

アイテムフィルタも設定して明示的に測定対象を指定することも可能ですが、今回は設定しなくても構いません。

link4次に、センサーの結果を数学ブロックに伝達したいので、センサーと数学ブロックをリンクします。センサーが送信元、数学ブロックが受け取り先なので、インベントリセンサーで左クリックし、数学ブロックで右クリックです(詳しいリンクのやり方は前回を参照して下さい)。

link5正しく設定できると、再度インベントリセンサーをクリックして選択した際、数学ブロックへの白い線が増えています(根本が太いほうがインベントリセンサー)。

math3続いて数学ブロックの設定です。数学ブロックをクリックし、右上の小窓から数学関数のところをクリックします。

数学関数ウィンドウが開き、数学ブロックで行う処理の種類を選べます。今回は「10 個未満かどうか」を判定したいので、「未満」を選びます。

math5続いて、右上の小窓から設定値のところをクリックします。

数ウィンドウが開くので、10 を入力します。

math6設定を終えると、数学ブロックの表示が「<10」というようになっています。

今回の設定が表す意味は、「送信元の数値が 10 未満かどうか」ということになります。先ほどのリンクによりサイロの水の数が送信元になっていますので、「サイロの水の数が 10 未満かどうか」を判定できることになります。

条件を満たせば数学ブロックの出力はオン、満たさなければオフになりますので、「サイロの水の数が 10 未満の場合だけオン」が出力されます。

link6その結果を井戸のグラバーに伝える必要があるので、数学ブロックとグラバーをリンクします。数学ブロックが送信元(左クリック)、グラバーが受け取り先(右クリック)です。

以上により、センサーブロックで測定した「サイロにある水の数」を、数学ブロックで「10 個未満かどうか」判定し、結果を井戸のグラバーに送る、という一連の流れが完成しました。

動作結果

res1ゲーム時間を再開すると、井戸から水が流れていきます。

最初はサイロにある水の数はゼロ、つまり 10 個みまんなので、判定結果はオンであり、グラバーが有効な状態になっています。

res2やがて、井戸から流れてきた水がサイロに入っていきます。

水が入る度に数学ブロックで 10 個未満かを判定し、結果をグラバーに送るので、伝達を示す青い線が一定間隔で表示されます。

10 個未満の場合は結果は「オン」のままなので、引き続き水は流れていきます。

res3サイロの水が 10 個溜まったところで、判定結果が「オフ」に変わります。それがグラバーに伝わると、グラバーがオフになって赤く表示が変わります。

以降、水が止まります。

res4なお、サイロにある在庫を手動でゼロに戻すと、再び水が流れるようになります。

以上により、サイロの在庫数に応じた、井戸からの発送調整が実現できました。発送をやめてもベルトコンベアに流れている分があるため、多少のタイムラグがあるので、実際にはこのあたりを工夫する必要が出てくる場合もあるかもしれません。


Factory Town 計算ブロックの一番簡単な使い方

生産物流箱庭ゲーム「Factory Town」における計算ブロックの使い方を整理しておきます。

なお、Factory Town Ver 0.108m 時点(Windows 版)での情報です。画像はクリックすると拡大します。

計算ブロックとは

計算ブロック(Computation blocks)は、物流の状況に応じた調整(アクション)を自動的に行うためのブロックです。「農場で使う肥料は十分にあるから、牧場からの肥料発送をやめよう」とか、「普通は直進しかしないマインカートを状況に応じて分岐させよう」などということができるようになります。

現在の状況という「入力」を元に、必要に応じて「判断」を行い、アクションという「出力」を行う。これを実現するのが計算ブロックです。入力も出力も原則として「オン/オフ」で表現されるので、一般的に論理回路と呼ばれます。Minecraft では Redstone 回路と呼ばれて人気ですが、Factory Town の計算ブロックは
  • 基本的な機能が 1 ブロックにまとめられている
  • 配線が簡単(配線のためのブロックスペースが不要)
という特徴があり、Minecraft よりも回路を組む敷居は低いのではないかと思います。

シンプルな入出力を行う

switch1一番シンプルに計算ブロックを使ってみます。

スイッチ(右の写真の左側のブロック)とランプ(右側のブロック)が 1 つずつで、スイッチを押すと、ランプが光ったり消えたりする、という簡単なものです。

toggleスイッチは「トグル」という名前のブロックになります。建設メニューの計算ブロックでトグルを選択して配置します。

lampランプは「論理ランプ」という名前のブロックです。同じく建設メニューの計算ブロックから選択して配置します。

スイッチとランプの位置関係は適当で構いません。

さて、2 つのブロックを配置しただけでは連動しないので、連動するようにリンクを張ります(配線します)。

linkトグルを左クリックして選択状態にしてから、マウスカーソルを論理ランプの上に持って行くと、「論理リンクを追加」という表示が出ます。この状態で「右」クリックすると、リンクが張られます。

必ず、トグル(入力元)で左クリック→論理ランプ(出力先)で右クリック、の順番です。

link2リンクが張られると、改めてトグルを選択した際に、トグルと論理ランプが白いカーブで結ばれている表示になります。入力元であるトグルの方が太い線になっています。

補足ですが、リンクを張ってあればきちんと動作するので、ブロック同士の位置関係はどんなものでも構いません。逆に、隣同士に配置したとしても自動でリンクが張られるということはありません。

さて、トグルをマウスで選択しマウスカーソルがトグル上にある状態で、Enter キーを押すと、トグルのマークが赤い禁止マークから緑のチェックマークに変化します。

link3同時に、カチッと音をたてながら青いビームが論理ランプに飛び、変化が論理ランプに伝わり、論理ランプが青く光ります。

Enter キーを押す度にトグルの表示が変わり、併せて論理ランプの表示も変わります。

なお、Enter キーを押すまでにマウスカーソルがずれてしまうと、トグルのオンオフは切り替わるのに論理ランプの表示は変わらなくなってしまうので注意して下さい。また、Enter キーはテンキーの Enter キーではなく大きい方の Enter キーを使って下さい。

migishitaさらに言うと、トグルを選択すると画面右下にトグルのオンオフを切り替える小窓が表示されますが、この小窓でマウスを使ってオンオフを切り替えると論理ランプの表示は変わらないので注意して下さい。

バージョンアップするに従ってこの辺りは改善されるとは思いますが、現状ではトグルの扱いに注意が必要です。

とはいえ、実際には手動でトグルをいじることはないので、実用上はあまり問題にはならないかと思います。

以上が、1 入力 1 出力という一番シンプルな計算ブロックの使い方となります。「入力のオン/オフに応じて出力がオン/オフ」されました。これを発展させていくと、実用的な使い方ができるようになります。

月別アーカイブ
記事検索
最新コメント
  • ライブドアブログ