ストレンジャーシングス シーズン4 観終わった ＜ネタバレ含む＞

タイトル通りシャドールが楽しい。
メインにプディンセスが入らなかった世代のマドルチェ使ってたライトユーザ復帰勢なんだけど、マスターデュエル（MD）を切っ掛けに遊戯王をやってみたらまあ楽しい。 
4月まではマドルチェでプラチナ1まで行けたり行けなかったりと悪くない感じだったんだけど、今月のパック追加で相剣が追加されて事情が変わった。 
比較的安定して立つ2妨害がキツすぎる。うららが効かないしヴェーラーも手札効果は当たらない、ニビルも微妙で泡影がようやく刺さるかもしれない。 
トークンコレクターが流行る理由が分かるくらい相剣の安定感で1妨害で止まる現状のマドルチェだと勝負になるまでがしんどすぎた。 
テーマ内で完結してるから自由枠多いし多分上手い人はダイヤでも勝負できてると思う。
<img src="/img/yu-gi-oh-master-duel-202205311430/IMG_2270.PNG" alt="マドルチェ・プディンセス">
というわけで、知り合いが使ってたり融合フェスがあったりで丁度良かったからシャドール組んだ。 
上記の通りエンジョイ勢に近いからあまり構築や立ち回りが上手くないけどある程度妨害も越えられるから後手でも捲れることがあるのはとても偉い。 
体感では安定感に難がある気がするけど上振れも考えると勝てない相手いないんじゃないのこのテーマ。強いて言うならバックメインで動いてくる罠バーンとかメタ系は辛いと思うけど、そこはどのテーマも大体同じでしょう。
<img src="/img/yu-gi-oh-master-duel-202205311430/IMG_2273.PNG" alt="エルシャドール・ネフィリム">
融合テーマだから当然手札の消費が激しいものの、墓地に落ちるのもアドだからそこまで気にならない。最悪ビースト落として補充もできるのはとても偉い。 
なによりマドルチェでは後から湧いて出ても使い道が一滴かツイツイのコストくらいにしかならなかったニビルくんがネフィリムの素材になれるのが偉すぎる。融合テーマは偉い。
<img src="/img/yu-gi-oh-master-duel-202205311430/IMG_2272.PNG" alt="原子生命態ニビル">
誘発チェックも優秀で、ハンド次第ではあるもののメガネ（アレイスター）採用型ならメガネ出して確認できるしシャドールフュージョンもうららチェックできる。 
融合でシャドールモンスター落としても優先権が相手に移る前にチェーンを好きな順番で組めるからある程度誘発から守れるのも偉い。墓穴の使命者はプレミだから諦める。
<img src="/img/yu-gi-oh-master-duel-202205311430/IMG_2271.PNG" alt="エルシャドール・ミドラーシュ">
当然融合モンスターも強い。 
基本的にはよく使われるミドラーシュ・ネフィリム・アプカローネあたりが強いんだけど、現環境だと特にミドラーシュが強いんじゃないかと思ってる。
対相剣に於いて先攻でミドラーシュを立たせておくと捲り札がテーマ内ではエクレシアから妖眼くらいしか思いつかない。汎用含めると泡影とか一滴とかヴェーラーとか色々あるものの、採用率が高そうなライストとサンボルが通らないのはめちゃくちゃ偉い。実際に特殊召喚制限の印象が強すぎてライストとサンボルを無駄に撃たれたことがあった。完全に隠された効果。対相剣で滅法強いもののデスフェニ環境だからフューデスあったらおしまい。
そんな感じでメガネシャドール回してたものの、前述の通り安定感が微妙な気がしてメガネ外した。 
メガネループは強いし単体で1妨害立てられるのはとても偉い、召喚魔術の墓地融合も偉い。でもメルカバー立っただけでターンエンドが辛すぎた。 
除外無効は強いけど手札コストがしんどいのと1妨害だけで止められる環境じゃなくない？そもそも光使うからネフィリムと食い合うのも辛い。使った後のヴェーラーも素材にできるの偉いけどルークでネフィリム出した方が続きそうな盤面が多かった。ただ、打点に難のあるシャドールにアウゴエイデスの存在は強みだと思う。
<img src="/img/yu-gi-oh-master-duel-202205311430/IMG_2274.PNG" alt="召喚師アレイスター">
というわけでメガネに不満を覚えたので、MD上では新規カードもらった烙印とデスピア詰め込んだ烙印デスピアシャドールを組んだ。融合フェスの報酬はなくなった。 
60枚だから全然安定しないし芝刈り来ないで滅茶苦茶辛い。ただし回るようになったら強かった。正確にはデスピアも強かったんだけどデスピアの融合系効果がシャドール融合魔法と違って汎用も呼べるのが強かった。
でもやっぱり安定しないからシャドール要素抜いた烙印デスピアにした。現状の烙印デスピアは見た感じラビヌメワンキルと普通にビートの両プランで殴っていくのが強そうだけど、烙印デスピアにした理由がマスカレイドバーンで相手を倒すプランだったからラビヌメは入らない。ただし先行じゃないと最大効率取れないし上振れじゃないと3体どころか2体もしんどいのでその場合はクエリティスで濁す。3体立ったときは相手は4回までしか効果使えなくて詰むから滅茶苦茶強い。
<img src="/img/yu-gi-oh-master-duel-202205311430/IMG_2275.PNG" alt="赫灼竜マスカレイド">
ひたすらマスカレイドを立てることだけ考えてやってたら月末になんとかダイヤ帯までは上がった。ナーフが決まっていたエルド・ドライトロンあたりは月初に上げ切りたい、他テーマ使ってる人はナーフ後に上げ出してるだろうから月末はその辺の人たちがいなくなって多少ゆるい環境なんだろうけどそれでも辛かった。 
とりあえず放置botどうにかしてください。面白くないので。
今シーズンはこんな感じでやってきたけど、来月（ショップの期限的に）新規来るだろうしそれ次第ではマドルチェに帰ったり別のテーマ使ったりしたい。そろそろスモールワールドとか欲しいんだけど来る気配ありますかね？

シャドールは楽しい

Gutenberg 周りはそこそこアップデートすること、TypeScript を公式でサポートしていない事からあんまりお勧めできません。 
また、私自身が WordPress の現状を追えていないことからあまり正確でない情報が含まれている場合があります。 
一応本記事の内容は動作を確認しているものです。言うまでもないと思いますが、内容について間違い等があっても責任は負いかねます。
tsconfig.json は <code>tsc --init</code> の標準出力で、 <code>jsx</code> の値だけ <code>react</code> に変更。
パッケージは以下を使用。
<ul>
<li>webpack</li>
<li>webpack-cli</li>
<li>@wordpress/scripts</li>
<li>@wordpress/dependency-extraction-webpack-plugin</li>
<li>react</li>
<li>react-dom</li>
<li>ts-loader</li>
<li>terser-webpack-plugin</li>
</ul>
CSS の出力や画像の出力が含まれていないため、必要に応じて <code>mini-css-extract-plugin</code> や <code>file-loader</code> 等の webpack の loader をインストール。
webpack の設定ファイルは <code>@wordpress/scripts</code> の付属の設定ファイルは使用しない。
<pre><code class="language-js">const path = require(&quot;path&quot;);
const DependencyExtractionWebpackPlugin = require(&quot;@wordpress/dependency-extraction-webpack-plugin&quot;);

const TerserWebpackPlugin = require(&quot;terser-webpack-plugin&quot;);

module.exports = (env, argv) =&gt; ({
 entry: {
 editor: path.resolve(__dirname, &quot;src&quot;, &quot;editor.ts&quot;),
 script: path.resolve(__dirname, &quot;src&quot;, &quot;script.ts&quot;),
 },
 output: {
 filename: &quot;[name].js&quot;,
 path: path.resolve(__dirname, &quot;dist&quot;),
 },
 target: [&quot;web&quot;],
 optimization: {
 minimizer: [
 new TerserWebpackPlugin({
 terserOptions: {
 sourceMap: env.development,
 },
 }),
 ],
 },
 plugins: [
 new DependencyExtractionWebpackPlugin(),
 ],
 devtool: env.production ? &quot;source-map&quot; : false,
 module: {
 rules: [
 {
 test: /\.tsx?$/,
 exclude: /node_modules/,
 use: [
 {
 loader: &quot;ts-loader&quot;,
 options: {},
 },
 ],
 },
 ],
 },
 resolve: {
 extensions: [&quot;.js&quot;, &quot;.jsx&quot;, &quot;.ts&quot;, &quot;.tsx&quot;],
 },
 optimization: {
 splitChunks: {
 name: &quot;vendor&quot;,
 chunks: &quot;initial&quot;,
 },
 },
});
</code></pre>
エントリーポイントを 2 つ (<code>entry.ts</code>, <code>script.ts</code>) を用意することで、公開画面で動作するスクリプトと管理画面のスクリプトを出力する。 
<code>DependencyExtractionWebpackPlugin</code> は名前の通り WordPress のコアに組み込まれている js ファイルの依存解決を自動化できるプラグイン。webpack のバージョン等の関係で上手く動作しない場合がある。
次に、上記で出力される js ファイル等を WordPress に登録する。以下はプラグインとして作成する場合を想定しているため、出力位置や環境に応じて適宜変更。
<pre><code class="language-php">add_action('init', 'register');

function register()
{
 $editor_asset = require plugin_dir_path(__FILE__) . 'dist/editor.asset.php';
 $script_asset = require plugin_dir_path(__FILE__) . 'dist/script.asset.php';

 wp_register_script(
 'plugin-vendor-script',
 plugins_url('dist/vendor.js', __FILE__),
 [],
 filemtime(plugin_dir_path(__FILE__) . 'dist/vendor.js')
 );

 wp_register_scriot(
 'plugin-script-script',
 plugin_url('dist/script.js', __FILE__),
 array_merge($script_asset['dependencies'], ['plugin-vendor-script']),
 $script_asset['version']
 );

 wp_register_script(
 'plugin-editor-script',
 plugins_url('dist/editor.js', __FILE__),
 array_merge($editor_asset['dependencies'], ['plugin-vendor-script']),
 $editor_asset['version']
 );

 register_block_type(
 'plugin/blocks',
 [
 'editor_script' =&gt; 'plugin-editor-script',
 'script' =&gt; 'plugin-script-script',
 ]
 );
}
</code></pre>
<code>[name].asest.php</code> は <code>DependencyExtractionWebpackPlugin</code> から出力される php ファイル。中身を見ると <code>dependencies</code> と <code>version</code> がキーになった配列。そのまま <code>wp_register_script</code> に設定できる。
カスタムブロックは <code>editor.ts</code> へ記述。
<pre><code class="language-tsx">import React from &quot;react&quot;;
import {
 BlockEditProps,
 BlockSaveProps,
 BlockAttribute,
 BlockConfiguration,
 registerBlockType,
} from &quot;@wordpress/blocks&quot;;
import { PlainText } from &quot;@wordpress/block-editor&quot;;

type Props = {
 text: string;
};

const attributes: {
 text: BlockAttribute&lt;string&gt;;
} = {
 text: {
 type: &quot;string&quot;,
 source: &quot;text&quot;,
 selector: &quot;.className&quot;,
 },
};

const edit: React.FC&lt;BlockEditProps&lt;Props&gt;&gt; = ({ attributes, setAttributes }) =&gt; (
 &lt;div className=&quot;className&quot;&gt;
 &lt;PlainText
 onChange={ text =&gt; setAttributes({ text }) }
 value={ attributes.text }
 placeholder=&quot;&quot;
 /&gt;
 &lt;/div&gt;
);

const save: React.FC&lt;BlockSaveProps&lt;Props&gt;&gt; = ({ attributes }) =&gt; (
 &lt;div className=&quot;className&quot;&gt;{ attributes.text }&lt;/div&gt;
);

const config: BlockConfiguration&lt;Props&gt; = {
 title: &quot;Block name&quot;,
 category: &quot;Category name&quot;,
 attributes,
 edit,
 save,
};

registerBlockType(&quot;blocks-name-space/block-name&quot;, config);
</code></pre>
<code>attributes</code> や <code>config</code> 型の設定はあってもなくても。<code>type Props</code> と <code>attributes</code> の内容が被ってるので何か上手い設定方法があるかもしれない。 
元々カスタムブロックが書けるのであれば TypeScript への移行は難しくないと思う。 webpack の設定が WordPress の独自のプラグインを使っていたり最新版への互換が微妙だったりするところがしんどい。

WordPress カスタムブロック with TypeScript

PV等でバレてる程度のネタバレを含みます
予告編観たときは気になっていたものの、公開日以降は忘れていた。世間的にはエヴァが話題を掻っ攫っていて、ゲームの実写化という ある意味保証された 映画が元から映像作品として作られたものに対応しないことは、仕方ないと言えば仕方なかった。 
ただ、私は ある意味保証された 映画が好みな事と、映画に誘ってくれた人がいた事から観ることにした。
結果として、期待していた内容を超えた素晴らしい内容だったと言わざるを得ない。 
実にモンスターハンターらしい映画だったと思った。一方で、モンスターハンターを題材とする必要がなかったと主張する気持ちも分かる。 
というのも、あまりにモンスターの討伐数が少なすぎることや狩猟武器があまりに貧弱すぎることなど色々な要素がゲームと一致しない。 
しかし、試聴した方や各メディアで紹介を見た方はよく思い出して欲しいのだが、そのそも映画「モンスターハンター」はゲームのようにモンスターハンターの世界で生まれ育った人間がモンスターを狩ることを職業とした物語ではない。現実世界（をモデルとした世界）で兵士として生きるミラジョボヴィッチがモンスターハンターの世界へ転移する話なのだ。そんな現実の人間がモンスターに轢かれ、食われ、投げ出され、引き裂かれたら当然死ぬだろう。モンスターハンターの世界であれば多少吹っ飛ばされて転がるだけで済むが、映画「モンスターハンター」ではそうではないのだ。
私が「実にモンスターハンターらしい映画だった」といった理由がここにある。初めてモンスターハンターに触った時は持っていたのに、長年シリーズを続けることで慣れてしまい忘れてしまった「死ぬだろこれ」を映像化してくれたのだ。しかも、ミラジョボヴィッチ一行が異世界へ転移するという導入を用意することで、見事に作品内で説明している。これは私としては非常に好印象である。 
確かに、 実写化 という字面だけを見れば「創作の世界を現実の物を使ってなるべく忠実に再現する」と解釈するのも当然かもしれない。だが、この映画「モンスターハンター」は「創作の世界を現実の基準に落とし込む」ことを目指した作品だ。前者を望んでいた人も多いのかもしれないが、後者も確かに実写化だ。賛否はあるかもしれないが、（実際少し調べた感じ 2:8 くらいだと見積もるが……）正しく実写化で「モンスターハンターである必要があった」そして再三になるが、「実にモンスターハンターらしい映画だった」。
上映が終わった後、スクリーンから出た私は爆笑してた。

映画「モンスターハンター」を観てきた

<a href="http://acca-anime.com/">ACCA13区監察課</a> を見た。
ずっとローテンションで会話劇がメインなので地味っちゃ地味だけど政略で殴り合う感じで雰囲気は好みだった。雑に説明すると、中央の役人が地方を周って不正がないか査察する話。タイトルの通り13区ある国が舞台になっていて、1クールのサイクルと一致していたためか綺麗に纏まっていた。終盤の展開が早めなとこやなんとなくご都合主義っぽい流れがちょっと残念ではあった。この雰囲気であればもう少し分かりやすい伏線張っていて欲しかった。原作ではちゃんと描かれていたのかもしれない。
言い方が良くないが、キャラ付けが諄い人物が少ない所も良い。私見だが、壮年のキャラクターのビジュアルはあざといと言えばあざといかもしれない。凄い持ち上げて褒める作品ではないけど、誰かに「何か面白い作品ある？」って聞かれた時に気軽に挙げられる感じ。

2021年3月16日の日記

ブルーアーカイブのリリースから怒涛の緊急メンテ、不具合ラッシュで意気消沈したところへウマ娘のリリースでソシャゲ界隈が大移動している。我らがアークナイツくんは、密林イベが終わり同時開催していたケオべの迷宮が引き続き開催中だ。 
正式名称「ケオベの茸狩迷界」はメインのゲーム性に付与する別のゲーム方式としてはとてもよくできていると思う反面、私の頭ではワンプレイ一時間前後かかるため、理性（所謂スタミナ）消費を含むと結構な時間を取られる。最近のソシャゲの方向性は拘束時間を少なくする方向にあるため、相対的にしんどさが目に付くところが残念だ。とはいえゲームに上乗せしたゲーム、尚且つソシャゲとしてはかなりゲーム性に寄った作りになっている。実際に良い意味で「常設にしろ」と言っているプレイヤーも少なくない。（時間が足りない等の良い意味には含まない意見もある、私も両方の意味で常設してほしい） 
マルチエンディング、隠しエンディングやドロップするイベント用アイテムの収集等のやり込み要素も多く、時間が取りづらい身としてはこちらも良い意味でも悪い意味でもいい加減にしろと思ってしまう。イベント期間は今週の水曜までなので、なんとかイベント報酬くらいは全回収したい。
前述のウマ娘だが、友人に尋ねられたものの私も彼もともに「プレイしない」方向で一致した。 
彼の理由は委細までは承知していないが、私は「界隈の盛り上がり方が辛すぎる」が理由だ。逆張りと取って貰っていいと思うんだが、嫌悪している訳ではない。なんというか「少し距離を置きたい」が近い感情かもしれない。一番の理由は、過去にある界隈でしんどい目に遭っていて、その上でその辺の界隈がウマ娘に移動していそうな流れが見受けられるのが大きい。「嫌いな人間が好きなものが嫌い」というなんとも器が小さい理由だが、器が小さいことは自覚しているし趣味の世界の私情だ。私自身は、この仕様もない精神性は諦めることにしている。
これも完全に私情だが、ウマ娘を始めとする一連の Cygames を持ち上げる流れは非常に気に食わない。 
確かに現在では国内ではある程度のサービスを継続できる企業ではあると思うものの、グラブル7周年では <a href="https://relink.granbluefantasy.jp/">Relink</a> の内容がなく、4年前に CBT を行った<a href="https://lostorder.jp/">LOST ORDER</a>に至ってはそれ以来なんの情報もない。正直 Relink はプラチナゲームズが抜けた時点で良くて様子見だと思っているのでなんでもいいんだが、プラチナゲームズ、松野泰己と吉田明彦を起用して頓挫の報告すらない LOST ORDER に関しては形容し難い憤りを感じている。
故に、複数を掛け持ちしているとはいえ何の動きも見せない KMR を称賛する風潮が気に食わない。頓挫したなら頓挫したと言ってくれ。
後半はタダの愚痴だった。こんな乱文書いている暇があったら、頭にキノコを生やしてこよう。

2021年3月15日の日記

もう二月だ。早い。
この環境が一年近く続くとはあまり思っていなかった。 
古では、 重症急性呼吸器症候群 (SARS) みたいな名前の感染症が流行った記憶があるが、当時の雰囲気もこんな感じだっただろうか。
今年に入り、感染者数の最多記録を更新したり、地方でも独自基準の警戒レベルが引き上げられたりと、メディアを通じて大変な様子が流れるものの、長すぎるこの環境で危機感との関係も倦怠期に入った感じだ。 
とはいえ、全く警戒しない訳でもなく、外出するにもマスクはするし、例年年明けに合わせて行っていた初詣も（別の事情もあるが、）少し時期をずらして参拝した。
在宅勤務になって久しく、家財を買い替えたり友人に売ったりと内装も変わったものの、仕事用のデスクを買う機会を延々と先延ばしにしている。 
自身の体調を考えれば、さっさと買い換えた方が良いと思いつつ、なんだかんだで座椅子と、ノート PC が辛うじて乗る程度のちゃぶ台みたいな奴に甘んじている。
掲題の通り、特に明確に書きたいものがあって書いている訳ではなので適当な記事構成になっているが、仕方ないので諦めるしかない。 
昔から、文章の構成は（校正も）課題ではあるのだが、私は長期休暇の読書感想文も書けないクソガキだった頃から進歩していない。 
今年の目標にしようかとも思うのだが、私は恐らくこのウェブサイトを、数ヶ月放置し、ドメインの更新を忘れ、適当なタイミングで基盤の作り直しを始めてリセットするだろう。できない事は目標にしてはいけない。
しかし、まあ、できないかもしれないが目指すのは問題ないと思うので、出来る限り何か書いていきたいと希望だけ申し述べて、本年のご挨拶とさせていただきます。
本年も何卒よろしくお願い申し上げます。

あけましておめでとうございます

定期的にリセット癖を発動するのでまた作り直した。
Next.js の v10 がリリースされたらしいが、変更点よく分かってないしゼロから構築しなおしたから、体感として何が変わったかはよく分かってない。<code>unified</code> というか <code>remark</code> 周りのバージョンも上がってるようで、 <code>remark-frontmatter</code> が動かなかったので適当にプラグインっぽいの噛ませた。他にも <code>remark-footnotes</code> と <code>remark-math</code> がうまく動いてないのは確認してるけど、使う機会があまりなさそうだったので放置。
<pre><code class="language-typescript">import unified from &quot;unified&quot;;
// @ts-ignore
import syntax from &quot;micromark-extension-frontmatter&quot;;
import fromMarkdown from 'mdast-util-from-markdown';
// @ts-ignore
import frontmatter from 'mdast-util-frontmatter';

const frontmatterPlugin: unified.Plugin&lt;any&gt; = (options: any) =&gt; {
 const transformer: unified.Transformer = (tree, file) =&gt; {
 return fromMarkdown(file, {
 extensions: [syntax(options)],
 mdastExtensions: [frontmatter.fromMarkdown(options)],
 });
 };

 return transformer;
};

export default frontmatterPlugin;
</code></pre>
内容は <code>mdast-util-frontmatter</code> のサンプルコードを <code>unified</code> 用にラッパーに突っ込んだだけ。そのうち <code>remark-frontmatter</code> が修正されると思うので間に合わせで。
記事自体は Markdown でローカルに持っている物を Netlify でビルドするようにしている。Vercel じゃないのはそのうち別の何かを Vercel でやってみたいと思ってるので。思ってるだけで予定ないけど。
<code>remark-frontmatter</code> の代替品を作る上で <code>AST</code> (Abstract Syntax Tree) を見る機会があったんだけど、JSON (Object) になってるから、他で何か HTML を加工する際にも <code>AST</code> に変換かけてから加工した方が使い勝手いいんじゃないかと思った。思ったけどそこまでするなら普通に DOM API にアクセスしてデータ加工した方が早そうって結論になった。

こんにちわ

数年振りに発売日に買って発売日にプレイしたゲームかもしれない。
今まで出来ればディスク版を買いたいと思ってたんだけど DL 版で買った。 
ディスク版の方が DL 版より容量節約できると思ってたんだけど、PS4のデータ整理してたら各ゲームのデータ量が DL 版とディスク版で大差無いような大きさになってる事に気づいた。 
ディスク版も本体のメモリにデータ移してるって知らなかった。キレそう。
残りのマップ踏破率的に中盤の後半くらいまで進めたと思う。
純洋ゲー和風ゲーって珍しいゲームだけど、日本（というか時代劇）の表現としてはそこまで大きく違和感がないのは関心した。 
もちろん細かい所を探せば間違った表現や史実と矛盾が出るような所もあるんだろうけど、そもそもそんな知識を持ち合わせていないので問題ない。 
ゴースト・オブ・ツシマに関しては、搭載されている黒澤モードが表しているように雰囲気を楽しむゲームだと認識している。 
時代劇、というより黒澤映画で観せる侍の表現をゲームとして落とし込む事を目標としているのではないかと思う。
とはいえゲームとしても高水準であることは間違いなく、オープンワールドの剣戟アクションとして正しく面白いゲームだ。 
先行して発売された SEKIRO とどうしても比べてしまうものの、総合的な手触りは違うものになっているし、優劣をつけるには軸が違う気がする。
舞台は鎌倉時代中期の元寇がモデルになっている。 
義務教育の日本史や世界史で習うので、大体の人が知識としてなんとなく覚えているんじゃないだろうか。 
私は正直な所、元寇の言葉自体は覚えているものの、詳細は全然覚えてない。神風が二回吹いたとか何とかって記憶はあるが。 
史実はあくまでモデルであり、実際の史実に則しない架空の人物群が登場する。 
この架空の人物が、境遇もキャラクター性もブッ飛んでるのに、自分の中になんとなく存在する中世の人物観と妙にマッチして妙な説得力を成立させている。多分時代劇のせいじゃないかと思うんだけど。 
特に政子殿（北条ではない）が気に入っている。境遇が境遇故にかなり狂戦士、復讐鬼と化しているが、フォーカスされたクエストを進めると唯の復讐鬼ではなく割と思いやりのある叔母様であることが分かる。
戦闘アクションもしっかり作り込んでいる。
複数の武器種に対し刀一本で対応するギミックとして用意された型のシステムや弾き、回避の使い分けも刀での斬り合いを上手くゲームとして成立させていると思う。 
まあ、弾きと回避や危険行動（攻撃）の表示に関しては既視感がないとは言えないものの、逆に言えば馴染みやすい仕組みだったのは良いのか悪いのか……。
一番驚いたのが、この手のオープンワールドでありがちなクッッッッッッッッッッッソ長いはずの読み込み時間が非常に短かった事だ。 
特にPS4なんかのCSでは数分単位で待たされ、ファストトラベルするより走った方が早いような事も多いオープンワールドでは珍しく、ロードでのストレスを感じさせないくらいに早い。 
ついでにゲームを中断して別のアプリケーション（YouTube）を起動したあとに戻ってきてもちゃんと再開できた。確かゲームによっては終了させられる事もあったかと思ったんだけど、この辺の仕組みどうなってるんだろう。
上述の通りゲームとして高い完成度になっていると思う反面、あまり新しいと思える要素が少なかったと思う。 
オープンワールドでありがちなランドマークの発見や敵拠点の制圧、クエストを受けておつかいに奔走する、探索で手に入る素材から武具の強化等々探索自体に目新しさを感じられなかった。 
戦闘システムも前述の通りで、敵の所持武器に対し特攻を持った型を用意するのは面白いと思ったものの、それ以外の要素は目新しい要素がなかった。
いや、一騎討ちは珍しいかもしれない。あと↑一騎討ちじゃないイベントボス用の一騎討ち。あれはなんて呼べば良いんだ。後者に関しては何となくソウルキャリバー感じたんだけど。
総評としては、PS4末期のオープンワールドとしての総決算であり終着点。 
どこかで書いた通り、日本が舞台の上で翻訳の水準も高いため洋ゲーが苦手でも比較的入りやすく、読み込みが短くゲーム以外の場面でストレスを感じる要素がそこまで多くないため、オープンワールド未経験でも入りやすいよくも悪くもフラットなゲームなんじゃないかと思う。 
言い方アレだけど取っ付き易いにわか向けのゲーム、逆に言えば初心者から（史実以外の部分で）うるさいオタクまで広い層がプレイしやすいゲーム。 
私の認識が間違ってなければ、日本の大衆娯楽をゲームに落とし込んだ作品なので国外ではどうなのかは何とも言えないけど、国内だと多分そんな感じじゃないかな。

GHOST OF TSUSHIMA

<a href="https://nextjs.org/">Next.js</a> で作り直した。
<a href="/posts/gatsby">Gatsby</a> とあんまり変わらなくて、違いは graphql を使うか node でゴリゴリに書いた API とやりとりするかくらい。 
SSG は自分の知る範囲では <a href="https://ja.nuxtjs.org/">Nuxt.js</a> の方が多い気がするけど、 <code>vue</code> か <code>react</code> かの違い程度なので好みかな。
SSG は小さい案件だと便利だと思うんだけど、弊社基本クライアントが自分で記事投稿したいってケースが多いので出番が少ない感じ。
<code>react</code> の方が <code>typescript</code> の対応が早かったのでこっちを選んだ感じ。
ついでに <code>mdx</code> に対応しようと思ったんだけど上手く動かないのでとりあえずそのままにしてる。
記事一覧を引っ張る API とかも処理がメチャクチャ重いので気が向いたら最適化したい。

Next.js

React ベースの SSG 。 
Gridsome の React 版にあたり（こっちの方が先だけど）、使いやすさ的には Vue と React の関係に近い。 
Plugin で諸々の機能拡張を行えるのも大体同じ。
慣れの問題かもしれないが、 node のカスタマイズが Gatsby の方が分かりやすかったかもしれない。
作り変えた理由は、 WordPress の Gutenberg が React ベースなため、 React のコンポーネントを作る事が増えたため、サイト全体をコンポーネントとして作る事を改めて確認するためとか、単純に React でコンポーネント作るのに慣れるとかその辺。粗 Function Component で構築したから触ってないけど ComponentWillMount とかオミットされて「ほーん」ってなった。
ついでに Atomic Design とか FLOCSS もなんとなくやろうとしたけど、 Gatsby と Atomic Design を上手く解釈できなかった事、 styled-components を使った為 CSS を使わなかった事で両方ダメだった。
CSS in JS は 1 ファイルで完結するため見通しが良くなる代わりに上手く構築しないとファイル内が煩雑になりそう。
Gatsby 自体は人気なだけあって分かりやすい &amp; 作りやすいんじゃないかと思うけど、以前使っていた hugo の方がビルドのスピードは早い。流石 Go 。 
ただし、 PWA や SPA に近い動きがほぼ標準でできるので（やってないけど）、その辺は大きい。
フロントエンドの内容をそのまま使えるので、主だった可搬的な学習コストは graphql くらいだと思うけど、こちらはただの問い合わせ言語なのでそこまで難しくない。 
どちらかといえば Gatsby API 経由での graphql のカスタマイズが手間か。
gatsby-source-wordpress を使えば Gatsby と WordPress の連携も出来るので、 webhook を使えば CI 通してデプロイとかできると思う。けど、多分今の環境では実案件で使う機会がない。
単純な静的サイトの納品の場合は選択肢の一つになりうるかもしれないけど、 create-react-app Next Nuxt gridsome と他の選択肢も多いので、どのレイヤーから構築が必要かで使い分ける。

Gatsby

冗長なので書き直し。
<h2><a id="" class="anchor" aria-hidden="true" href="#"></a>基礎</h2>
<a href="https://webpack.js.org/">webpack</a> は バンドラ、トランスパイラ と呼ばれるツール。 <a href="https://www.npmjs.com/">npm</a> 等のモジュール管理ツールでインストールした js モジュール群を単一ファイル、或いは複数ファイルにまとめたり、 <a href="https://www.typescriptlang.org/">TypeScript</a> 等の AltJS をトランスパイル（変換）する。
類似ツールとして <a href="https://gruntjs.com/">Grunt</a>、 <a href="https://gulpjs.com/">gulp.js</a> が存在する。こちらは タスクランナー と呼ばれたり(する|した)。
<h2><a id="" class="anchor" aria-hidden="true" href="#"></a>前準備</h2>
<a href="https://nodejs.org/ja/">Node.js</a> で動作する。 <code>npm</code> は <code>Node.js</code> で動作するモジュール（パッケージ）管理ツール。 
<code>webpack</code> 自体も <code>npm</code> でインストールする。
<a href="https://webpack.js.org/guides/installation/">Installation | webpack</a>
バンドルについては主の <code>js</code> ファイルから <code>require</code> や <code>import</code> で読み込むことで <code>webpack</code> で適宜バンドルされる。 
また、読み込み時にインラインで記載したパラメータ（QueryString?）や <code>webpack.config</code> 等の設定ファイルの内容に基づいて各種 <code>loader</code> 経由でトランスパイルされる。
<a href="https://webpack.js.org/concepts/loaders/">Loaders | webpack</a>
<code>npm-scripts</code> に記載する事でもある程度対応できるが、ファイル読み込み時に逐次記載する手間や全体の見通しが悪くなる事を考慮すると <code>webpack.config</code> を作成する事が望ましい。
<h2><a id="" class="anchor" aria-hidden="true" href="#"></a>設定</h2>
<a href="https://webpack.js.org/configuration/">Configuration | webpack</a>
上記記載の通り <code>webpack.config</code> を作成する。また、 <code>webpack</code> コマンドについてはオプション等もある事から <code>npm-scripts</code> の使う。
環境については <a href="https://github.com/survivejs/webpack-merge">webpack-merge</a> を利用した設定ファイル自体を分ける方法、 <code>webpack</code> の <code>env</code> を利用して設定ファイル内で変更する方法がある。ケースバイケースで対応する。
<a href="https://webpack.js.org/guides/environment-variables/">Environment Variables | webpack</a>
<h2><a id="loaders" class="anchor" aria-hidden="true" href="#loaders"></a>Loaders</h2>
トランスパイルする対象のファイル名 + <code>loader</code> で大体見つかる。類似のものがある場合や長期間メンテナンスされていないものもあるため注意。
<h2><a id="plugins" class="anchor" aria-hidden="true" href="#plugins"></a>Plugins</h2>
<a href="https://webpack.js.org/concepts/plugins/">Plugins | webpack</a>
<code>webpack</code> の機能を拡張するもの。
<ul>
<li><a href="https://github.com/webpack-contrib/mini-css-extract-plugin">mini-css-extract-plugin</a></li>
<li><a href="https://github.com/jantimon/html-webpack-plugin">html-webpack-plugin</a></li>
</ul>
あたりは使用するケースが多い。
<h2><a id="" class="anchor" aria-hidden="true" href="#"></a>注意点</h2>
バージョンが変わると <code>config</code> ファイルの記述方法が変わる事がある。また、各 <code>loader</code> が動作しなくなることもあるため、（ <code>webpack</code> に限った話ではないが）バージョンアップには十分注意すること。 
<code>Node.js</code> のバージョンアップで動作しなくなる場合がある。 <code>npm rebuild</code> 、あるいは
<pre><code class="language-bash">npm cache clean --force
rm -rf node_modules
npm i
</code></pre>
で大体直る。直らなかった場合、 <a href="https://github.com/nodenv/nodenv">nodenv</a> 等のバージョンマネージャも検討。
<h2><a id="" class="anchor" aria-hidden="true" href="#"></a>使うべき事例（雑感）</h2>
基本はトランスパイル機能を目的に使用する。 <code>webpack</code> でバンドルした各ライブラリはグローバルからの参照が（未設定では）できないため、 <code>JavaScript</code> での実装に重きを置かないWeb制作等の場合は周知のコストやイレギュラー対応の方が高くつく可能性がある。 
<code>js</code> や <code>css</code> ( <code>PostCSS</code>、 <code>Sass</code> 等) のトランスパイルに留めるのであれば大きく問題にはならない。
静的サイトの出力（テンプレートファイルから <code>HTML</code>の出力） は <code>gulp</code> に分がある気がする。 <code>publicPath</code> の概念が分かりづらい。 <code>webpack</code> で無理矢理独自の生成タスクを作るくらいなら、要件が許せば最初から <a href="https://www.staticgen.com/">Static site generator</a> の導入や <a href="https://jamstack.org/">JAMstack</a> にするのも手。その場合、置き場所（webサーバ）はそこまで選ばないが、開発環境や学習コストには配慮すること。

webpack

TypeScript初心者。 
静的型付けの経験はほぼ皆無。 
さすがに基本的な型は分かる。 
Gutenberg は良く分かってない。 
画像設定させたりテキスト入力させたりが限度。
ts のトランスパイラやカスタムブロックを WordPress へ組み込む方法については省略。
以上、ご留意。
ブロックエディタの定義ファイルは <code>@types/wordpress__block-editor</code>。
<code>edit</code>, <code>save</code> に返すクラスコンポーネントは　<code>@wordpress/element</code> の <code>Component</code> を継承すると楽。 
React から引っ張ってきても良いけど型の設定が面倒臭い。
edit は <code>BlockEditProps</code>, save は <code>BlockSavePorps</code> をジェネリクスとして設定する。 
BlockEditProps と BlockSaveProps は <code>@wordpress/blocks</code> に定義されている。
BlockEditProps と BlockSaveProps には <code>attributes</code> の interface をジェネリクスとして設定する。
設定は @wordpress/blocks の <code>BlockConfiguration</code> を設定する。 
ジェネリクスは上記で設定した attributes の interface。
attribues の各プロパティには @wordpress/blocks の <code>BlockAttribute&lt;型&gt;</code> を設定する。（この辺なんか違う気がしてる）
<code>icon</code> は @wordpress/blocks の <code>BlockIcon</code> を設定する。
最悪 <code>@types/wordpress__block-editor</code> を頑張って読めばどうにかなる。 
JSX のコンポーネントなのでなんとなくで割と書ける。 
分かり辛いのは動的な部分、 <code>attributes</code> の扱い。
以下のサンプルは動作未確認。
<pre><code class="language-tsx">import { Component } from '@wordpress/element';
import {
 BlockEditProps,
 BlockSaveProps,
 BlockAttribute,
 BlockIcon,
 BlockConfiguration,
 registerBlockType
} from '@wordpress/blocks';
import { PlainText } from '@wordpress/block-editor';

interface Attribute {
 text: string;
}

interface AttributeEntity {
 text: BlockAttribute&lt;string&gt;
}

const icon: BlockIcon = 'layout';

const attributes: AttributeEntity = {
 text: {
 type: 'string',
 source: 'html',
 selector: '.text',
 },
}

const edit = class extends Component&lt;BlockEditProps&lt;Attributes&gt;&gt; {
 render () {
 const { className, attributes, setAttributes } = this.props;

 return (
 &lt;div className=&quot;text&quot;&gt;
 &lt;PlainText
 onChange={(text) =&gt; setAttributes({text})}
 value={attributes.text}
 /&gt;
 &lt;/div&gt;
 );
 }
};

const save = class extends Component&lt;BlockSaveProps&lt;Attributes&gt;&gt; {
 render () {
 const { attributes } = this.props;

 return (
 &lt;div className=&quot;text&quot;&gt;
 { attributes.text }
 &lt;/div&gt;
 )
 }
};

const config: BlockConfiguration&lt;Attributes&gt; = {
 title: 'テキスト',
 category: 'layout',
 icon,
 attributes,
 edit,
 save,
};

registerBlockType('gcb/text', config);
</code></pre>

Gutenberg のカスタムブロックを TypeScript で書く

サイトジェネレータを <code>Gridsome</code> に載せ替えた。 
前の <code>hugo</code> については開発用のビルトインサーバも出力も早く不満はなかったが、<a href="https://qiita.com/rana_kualu/items/915345b8f3f870cfe2aa">こんな記事</a>を見つけたのでノセられた。
<a href="https://gridsome.org/">Gridsome</a>
先の記事に書いてある通り、 <code>Gatsby</code> の Vue 版のようなもので、 GraphQL を使ってテンプレートから静的ファイルを出力する。 
<del>出力後のファイルを見てみると、 Gridsome がデータソースを GraphQL に変換後に json として出力、後はいつもの動きをしているっぽい。</del>
2020年1月24日 追記
（ <a href="https://graphql.org/">GraphQL</a> は API? サーバに問い合わせる仕組みで Gridsome はデータクエリを投げると json データが返ってくる。RDBMS に於ける SQL のような問い合わせ言語のようなものか？）
追記ここまで
プラグインを経由することで色々なソースや API を使えるようで、 API の取得が極端に面倒になった Instagram やそもそもがフロント混みのブログシステムである WordPress 等もある。 
特に WordPress は、システム自体は特定のクライアントからのアクセスのみを許可し、クラウド上でビルド、デプロイを行えば、顧客には WordPress の管理画面を提供しつつ、静的なサイトとして運用することもできたりするんじゃないかと思った。（ WordPress にも API あるけど） 
このサイトは Markdown をソースとして利用できるプラグインがあったためそれを利用している。 
既存の記事の移行が（記事数が少なかった事も相俟って）比較的簡単に行えたのでありがたい。
とは言え途上のプロジェクトのようなので、実務としての利用はまだ見合わせた方がいいんじゃないかと思う。 
もし似たコンセプトのプロジェクトを探していて、 Vue に凄い拘りがなければ Gatsby の採用も検討したい。
このサイトのレポジトリは<a href="https://github.com/irnagisa/roundabout">ここ</a>

Gridsome

作り直しました。 
引き続き何卒よろしくお願い申し上げます。