LOMの武器強化自動化したよ

lomの武器強化の自動化その２

前回おおまかな仕様についてまとめたけれど今回はおおまかな実装の話

前回レシピ生成まで自動化しようと思ったんだけど効率悪すぎて止めました。

つまり、処理で生成させるより自分でレシピ作った方が早いって事です。

計算はしないほど高速なので計算は最後の1回だけに絞りたい

計算せずに処理するには？

じゃあどうするの？いたって簡単。必要素材を参照すれば良いだけです。

鍛冶システムは難しいと思われていますがみんなが思っているほど難しいシステムではありません。

今回は処理速度と軽量化の為に単Lv上限9としてるので更に簡単なパズルです。

サイトの方にも載せてますがLv9に必要なのはE256で、副原料Eの上限もE256なので更に簡単です。

(もうちょっと詳しく言うと副原料Eのみ上限自体はE288まで可能)

つまり、ランダム性はないのでレシピさえ作れば必要な個数もその素材内のLv上限を決められるという話です。

「でも、それが分かってるならそもそも自動化する必要性ないのでは？」

はい。その通りです。

前回の記事で記載した通り意味が無いと思っていたので自動化してなかったわけです。

覚える必要なのは「輝きx4＞補助SPx3＞精霊金貨」たったこれだけなので。

これを繰り返せば確実にLv9になるものの流石に効率が悪い。閑話休題。

エネルギー計算をせず、攻撃力計算もしないで持ってるアイテムだけでLv上限を特定する方法

先に述べた通り、Lv毎レシピがあれば必要アイテムをだけ見るだけでレシピが自動化できます。

「レシピの自動化をするのにそのレシピを事前に作るって事？」

はい。その通りです。

「でもそのためには大量のレシピを事前に作る必要があるのでは？」

はい。その通りです。

「そんな事したら事前準備がかなり面倒臭いのでは？」

はい。超絶面倒臭いですが逆に言えば、それは作成側が鍛冶システムを完全に熟知して想定される効率的レシピを全て作れば良いだけなので難しくはないです。

計算して都度Eを比較するよりも、特定属性のLv上限のアイテムが存在しているかだけを見るだけの方が遥かに高速です。

属性には強弱関係もありますが、別にそれもシステムを熟知して効率的順番に並べれば良いだけです。

チャートの組み方も全て公開してるので事前に基本的な効率チャートを作るのは簡単だと思います(絶望的に面倒臭いだけで)。

正直これだけでも割と十分です。

ただ、これだけだと一つがLv9でもう一つがLv1みたいな偏りが出ます。

もっと、攻撃力を上げる

さて、LOMの鍛冶システムは属性Lvの合計が高いほど攻撃力が高いです。

そして、Lvが上がるほど必要素材が爆発的に増えます。

特に抵抗8以上のLv8、Lv9などでは直接Eに関与しない輝きを強制除外回避の為に大量に使います。

つまり、高いLvを崩して使用可能な素材をリリースして低いLｖを複数上げた方が良いという事です。

Lv上限下から見るか、上から見るか

平均化した方がよいと言いましたが考え方は2通りあります。

1つは各属性をLv1が可能か？Lv2は可能かと低いLvを各属性チェックしていく方法。

もう一つは一旦Lvを限界まで消費させて、低Lvの為に上のLvを削る方法。

正直どちらで良いですが今回は高Lvを削る方法で実装しています。

低Lvから上げる場合毎回各属性を舐める必要がある事と何処で終わるのかを予測しにくいからです。

高Lvから削る場合、もしその時点で上限ならその場で確定するからです。

更に言えば、上限から削るのでチェックする組み合わせがどんどん減る為です。

まとめ

• 前回よりより高速な仕様に考え直した
• ギリギリまで一切の計算をせずアイテムの数しかチェックしない事で超高速化している
• Lvを平均化する事でLvの合計を極力最大にしている

「LOM鍛冶ナビゲーター」まぁ、そんな感じで一先ず作ったのでよしなに使ってみてください。レシピ定義はもう少し直すかも。

LOMの手持ちから可能範囲の上限攻撃力レシピをだす方法とか

LOMレシピ自動化してみようか？ってはなし

タイトル通りですが今回は制限強化の自動化をする場合どういう工程を考えるかなって話。 

条件とか

(武器鋭さx主原料鋭さ+武器重さx主原料重さ+武器腕力x主原料腕力+武器技巧x主原料技巧)÷128x {(成長抑制値+属性Lv合計) ÷ 成長抑制値}= 攻撃力

表記が長くなるので以降は基本武器側を大文字アルファベット・主原料側を小文字アルファベットで表します。

(Axa + Bxb + Cxc + Dxd)÷128x {(S+L) ÷ S}= 攻撃力

レジェンドオブマナにおける攻撃力計算は上記通り。

所持アイテムによって所持内で最も攻撃力が上がるパターンを提出する場合どういう処理をすれば良いか

組合せは主原料55種類・副原料120種類・各副原料は99個まで所持できる・投入順序性が必要・攻撃力最大時のレシピは保存しておく

なお、最大チャートは特定の副原料を100個以上使う場合もあるがあまりにも組み合わせが増えるので上限は99とする。

つまり所持数は「120x99＝11880」

個の上限を99に制限しても組み合わせは「11880!/(99!)^120」。

更に、攻撃力が途中で伸びない場合「0～11880」の範囲で投入をやめるパターンがある。

既に肉の重複を抜いている状態かつ100以上アイテムを使うという想定を抜いて絞ってもこれなので総当たりは100%現実的じゃない。

なのでもう少し踏み込んでもっと上限を絞る必要がある。

どうすれば良いか

一旦思考停止するならBFを除くアルゴリズム

枝刈り、動的計画、分枝限定、貪欲→ビーム、山登り、焼きなまし、タブー(除外)、遺伝、粒子、蟻コロ、A*→IDA*

ただ、基本的に相性が悪い。

精霊を入れて抜けるまでレベルアップ判定があるので1回置きに切り取れず、積む検索なら数手先までをみてから枝を切り捨てる必要がある。

主原料特性もあってタブーの特定も大変だし、厳密性のある探査も厳しい。

例えば枝を切り落とすにしても鏡なしかつ材料が豊富というパターンもこのゲームの特性上多く

その場合に1レベル上げるのに下段ループの数十手が必要になり枝を切り落とすまでの範囲が広すぎる。

ビームにしても範囲が広すぎる。

じゃあ範囲を絞ろう

根本的に範囲を絞るべきであるのは確実でじゃあ範囲ってどれくらい絞るのか。

• ベストパターンは共通化しても上限は600ステップ前後で強化上限に到達するのでそれより長いのは無駄
• 鏡なしのパターンにしても最大でも1200ステップ前後なのでそれより長いのは無駄
• 少なからず2000ステップを越えるようなパターンは全て打ち切るべき

上限探査を600～1500くらいまで絞ればまぁまぁアルゴリズムで絞れる気はします。

いやまぁ根本的に論理的に解けるパズルを総当たりするのが効率が悪いと言ったらそれはまぁそうですが。

なので更に上限を絞りましょう。

ベストパターンではそもそも100個を超えるパターンがあるのでアイテム豊富という状態を余り考慮しないで絞りましょう。

そもそもアイテムが充実してるという前提なら最適化した固定パターンを作ってあるのでそちらのほうが効率が良いです。

現実的条件は副原料の基礎エネルギーの範囲Lvを上限に処理を絞るくらいが丁度良いかと思います。

また、基本的に吸収の考慮もしません。

小ステップパターンにおいては吸収すると素材が減るわけで必要エネルギーも効率が悪いので。

上限は「9-9-9-9_9-9-9-9」が現実的です。

ここまで条件を絞ればかなり現実的になります。

エネルギーの上限は288と256です。

全てをアルゴリズムで解決させる前半の探査説明は将棋のルールを教えずに将棋として進めるパターンを探すみたいな無謀さでしたがやはりある程度はルールは流し込まないと良い結果が出ない。

副原料エネルギーを上限とするなら考慮ステップ範囲は8ステップ範囲です。

具体的には「輝きx4＞補助SPx2＞精霊＞輝き」「輝きx4＞補助SPx3＞精霊金貨」これを最大パターンとします。

これくらいになればビームサーチなどの枝の切り落としがかなり効果的に機能するかと思います。

未来8ステップ以内にレベルアップしないパターンは全て枝を切り落としてOKとなります。

何故かというと本来デメリットの切り落とした枝の先にある更に良い未来の可能性は存在しない為です。

探査範囲についてもう少し言えば、8ステップxLv9x8属性=576ぐらいが上限としてベターかなと思います。
まぁ、低Lvは直ぐ上がるので実際には更に少ないステップで打ち切って良い。

Lv9が上限の基礎強化は150ステップ前後で強化上限になるのでなんなら200ステップくらいで打ち切っても良いと思っています。

評価方法を考えよう

さて、ここまで上限切りの話で、次に評価方法です。

最初に示した通り式は「(Axa + Bxb + Cxc + Dxd)÷128x {(S+L) ÷ S}」です。

これをはつまり「性能積和x倍率」という式です。

この2つのうち最善仕上げも公開済み通り補正最大パターンは固定です。

そして性能積和補正は属性Lv上昇より上昇率が高い。

基本システムでも説明していますが、属性Lvを少し上げるくらいなら僅か5ステップで終わるこれだけで良いです。

なので先に持ってる副原料で最も情報補正が高いアイテムを先に確保します。

次に1レベル毎上昇率を確定。端数は消えるので出来れば55程度の平均を生成。

攻撃力は初期値と係数Kで決まるので単純に伸びが良いだけだけではダメ。

例えば初期値はアダマンタイトが大きいがディオールなどは初期値が低くても係数で最終攻撃力が上回る。

逆に言えば比較時にABで初期値が低く係数も低ければその時点で除外出来ます。

Kの基本値が決まればあとは何レベル上げられるだけが問題になる

アイテムが充実なら基礎パターンを当てれば良いが抵抗値の必要Eは2倍になる関係上「ただ攻撃力を上げる」だけならばどれか属性1つを上げるより平均的にレベルを分配した方が良い。

更に言えば、未来性＝再強化を可能にするかという視点もある。

基本システムで説明している通り、属性ロックがある為、もし未来性を残すなら平均分配よりも対抗属性は強化しない方が良い。

ただ、今回の目的はただ手持ちのアイテムでどれくらい強くできるかなのでそれは無視。

使い捨て前提で持ってる副原料で極力最大になる様にするのが恐らくベスト。

属性Lvに関係するのは素材一覧にまとめてある通りだけど、単なるスライドとエネルギーとしある程度は総当たりしてよい。

まとめ

• ステップ上限は600で打ち切り
• 上限を256・288までにして吸収を考慮しない
• 仕上げの上昇率・1Lv毎上昇率と初期値が評価値になる
• 属性レベルは平均的に上がるパターンを優先する
• 攻撃力を直接比較するのではなく係数とLv合計

評価でなんで攻撃力をみないかというと性能基準値が一時的に低下して攻撃力が下がっている可能性がある。なので初期値と上昇率での評価が必要。

補足

・「今あるものだけで強化する需要」限定とする

・基礎強化パターンを目的に副原料を少し集めた方が最終的にたぶん効率が良いが目を瞑る。

・強化結果の補足としては仕上げ最適解の副原料をすすめる。各強化パターンの上限攻撃力を補足。

・シミュレーターに実装してある、無属性・補助なしALL5・基礎E・クイック999の手順のアイテム集める方が最終効率は良くなる

何で今まで作らなかったの・・・？

構想自体はまぁあるにはあったのですがそもそも今まで作ってなかったのはまず手持ち全アイテムを入力が面倒くさいという所。
次に本文でも書いてますが効率が悪いからで、普通に作成済みの手順のアイテムを集めた方が作る時ものちのプレイ効率も良いから。
根本的な話をすれば仕組みはパズルみたいなものなので総当たりなんて事をせずとも仕組みさえ理解してれば手持ちから普通に順序だてて最良パターン作れるから。
そしてそれらの理由から需要は低そうだなって思っていたから。

じゃあなんで纏めたのかと言えばどうやら需要があるかもしれないみたいなのを感じたので自分ならどんな感じに仕様を落とし込むかなって一旦メモ書きみたいな？

ESLintを入れてみた話

 タイトル通りです。デフォルトのハイライト機能というか未使用変数判定が出なくなって対処方法を探ったけど結局見つからず、なんかもっとちゃんとしたものがあると言う事で入れる事に。
Microsoft製なので最低限怪しい拡張機能のバグを踏むこともないかなと。

ESLintを入れよう

最初はただの便利なハイライト機能なのかと思ったらそういうモノではない。
node.jsがなんのライブラリなのかと思うくらい違う話。

インストールだけなら簡単いつも通り左の検索から拡張機能を選択してインストールするだけ。
ただし、そのままでは使えない。設定ファイルなどを作らなければならない。
まずは「Ctrl＋@」で画面下にconsoleを出す。
実行カレントは作ってるコードの親あたり。実際の作業場所は1つ深く掘ってた方が良いかも。

「npm init @eslint/config」を実行

『pm : このシステムではスクリプトの実行が無効になっているため、ファイル C:\Program Files\nodejs\npm.ps1 を読み込むことができません。詳細については、「about_Execution_Policies」(https://go.microsoft.com/fwlink/?LinkID=135170

) を参照してください。

発生場所 行:1 文字:1

+ npm init @eslint/config

+ ~~~

    + CategoryInfo          : セキュリティ エラー: (: ) []、PSSecurityException

    + FullyQualifiedErrorId : UnauthorizedAccess』

はい。ダメです！
単純にセキュリティで弾いてくれていますね。
「PS＞」と表示されてる通りパワーシェルは許可しないと実行権限がありません。
なので一時的に緩和します。

Set-ExecutionPolicy RemoteSigned -Scope Process

コマンド	意味
Set-ExecutionPolicy	PowerShellのスクリプト実行制限（ポリシー）を変更する
RemoteSigned	ローカルのファイルは許可、ネットからのファイルは署名を必須にする
-Scope	変更する「有効範囲（スコープ）」を指定する宣言
Process	「今開いているこのターミナルの画面（プロセス）だけ」を対象にする

こんな感じ。そして先ほどのコマンド「npm init @eslint/config」を実行。

ここから英語で質問が続きます。

「@eslint/create-config というツールをダウンロードして実行してもいいですか？」

『Node.js v22.14.0

npm error code 7

npm error path C:\alldata\website\bsc

npm error command failed

npm error command C:\WINDOWS\system32\cmd.exe /d /s /c create-config

npm error A complete log of this run can be found in: C:\Users\master\AppData\Local\npm-cache\_logs\2026-06-18T04_08_33_535Z-debug-0.log』

詰まる所「package.json ファイルがないため、ESLintを初期化できません」

であるならば「npm init -y」を実行

三度目のなんとやら「npm init @eslint/config」を実行

やっと質問に入れました。
↑↓キーで選択するだけです。スペースキーを押すと選択肢を追加可能。

「ESLintをどのように使いたいか？」
「To check syntax and find problems」（構文チェックと問題の検出を行う）

プロジェクトで使用しているJavaScriptの「モジュールシステム」
・「JavaScript modules (import/export)」
・「CommonJS (require/exports)」
記載されている通りですがjs内で(import/export)を使ってるなら上、古いjsしかなくrequireがあるなら下だと思いますが、基本的には上で良いと思います。

フレームワークの選択
素のjs(バニラjs)なら「None of these」
フレームワーク使ってるな2つから選択

TypeScript使ってるか？
使ってないならno

プログラムは何処で動かす？
・Browser: Webサイトを作っている場合は、これを選びます。

・Node: サーバーサイドのプログラムや、Node.jsでツールを作っている場合はこれを選びます。
どちらもやってる場合はスペースで両方チェックも出来ます

「依存パッケージ」を今すぐインストールするかどうか
まぁ普通にYesで。

どのパッケージマネージャーを使ってインストールするかを尋ねられています。

ここまで npm を使ってコマンドを実行してきたので、そのまま npm が選択された状態で Enterキー を押してください。

終わり

設定を変更したい時は最初に指定したカレントにある「eslint.config.mjs」を編集します。

なんと・・・入れたけどやっぱり該当ファイルのチェックがされない。
もう詰んだ。むりぃ・・・・

無名関数とラムダ式に違いはあるのか否か

知らない誰かに怒られそうだと思うけど。
【「無名関数＝ラムダ式」違いはない。】で大丈夫です。

ラムダ式って一体何のか？

数学における【「ラムダ (λ)」計算】が関数の構造を持っていて利便性がある為プログラムのラムダ式の基礎になっています。
しかし、根本的に、数学のラムダ式とプログラミングにおけるラムダ式は違うものです。

数学の純粋な世界から、各プログラミング言語の実用的な仕様へと形を変える中で、元々のルールは大幅に変更されています。

そのため、「本来のラムダ式とは～」という学術的な話を持ち出すこと自体が、プログラミングの現場においてはあまり意味を成しません。

「無名関数＝ラムダ式」違いなどない

それで最初に話したところに戻りますが「プログラミングにおけるラムダ式」とは結局のところ「変数=無名関数」この形です。
実際に変数に入れる必要はないですが「この形で処理できる式が記述できるかつ、その結果を受け取る事が出来る事」です。

この条件が定義です。
【「変数=無名関数」＝無名関数＝ラムダ式】という事です。
当然ながら「無名関数＝ラムダ式」ではないという事を言う人もいるだろうしラムダ式は無名関数の一部であるといういう人もいると思います。

ですが先に述べた通り根本的に本来の数学のラムダ式は違って各言語のプログラム仕様に変更されてるため、無名関数が使えるならどれもラムダ式に違いはないです。

あとは、元のラムダ式にどれくらい近いか？くらいしか焦点をあてる所がないです。

仮にプログラムの内部仕様的にthisがとれるとかとれないとか、挙動の違いがあるとしても言語別のプログラム仕様の誤差でしかなく「変数=無名関数」が出来るのであればそれはラムダ式だし、逆に「変数=無名関数」が出来ないのならそれは無名関数でもないしラムダ式でもないです。

通称の差でしかない

さて、それを踏まえたうえで、もう少し無名関数を絞って一般的には・・・みたいな一般論の話をしましょう。
おおまかには「1行で書ける」「引数を渡せる」「名前が無い」「式の結果を直接受け取れる」「引数は1つ」「引数の渡し方が=>とか->である」
まぁだいたいこんな感じです。

言語の種類によっては仕様的に呼び方をラムダ式とそうじゃないものやPythonのようにそもそもlambda という記述が明示的なものもあります。
先ほども言いましたがプログラムのラムダ式は通称に過ぎません例えば、Pythonは一行でなければなりませんがjavascriptのアロー関数はそんな事はありません。
Pythonの様に制限されるものこそラムダ式だ！！というならjavascriptにラムダ式は存在しません。
別にそう考えてもよいですが、あくまでも最初に言った通り「変数=無名関数」なればよい程度で言語の仕様で結構内部的な仕様は異なりますし、それぞれラムダ式の実際の定義方法(記述方法)が違うので誤差です。
javascriptで

let a = e => e + 2; // ①
let a = (e) => { return e + 2 } // ②
let a = (e) => { let b = 2; return e + b } // ③
let a = function(e) { return e + 2 } // ④

とかで①はラムダ式だが②と③と④はラムダ式じゃない！！みたいなのは誤差ですよ。
言語によっても仕様がばらけるしラムダ式と無名関数に差なんてないです。
せいぜい無名関数っていうやつの1行版がだいたいラムダ式と呼ばれることが多い程度で結局通称に過ぎません。

なので、プログラミングでこれをラムダ式に・・・とかいう会話がでたら、あぁ無名関数の事なんだなって思えば十分です。

最後に

もし、ラムダ式を理解出来てるが無名関数ってなんだと思ってるならラムダ式の事なんだなって思えばいいし、無名関数を理解してる人がラムダ式ってなんだってなってる場合はなんだ無名関数の事なんだなって思えば十分です。
注意点としては手前で言っている通り、その言語のどの無名関数が通称ラムダ式って呼ばれているか程度は一応調べた方が会話に語弊が生まれないと思います。
とはいえ、どちらにしても「変数=無名関数」この事に過ぎないので難しい話ではないです。

例えばjavascriptとかだと無名関数な会話では「コールバック」とか「アロー関数」とか「IIFE」とか単純に「無名関数」が・・・とかあり、thisがとれるとか差はありますが無名関数としての本質的な違いはありません。

明確に「プログラミングにおいてラムダ式とはどの言語においてもこういう仕様でなければならい」というものが存在しないし、各言語の仕様もバラバラ。
なので仮に本当にそういうものがあったとしてもそれらは守られてないので「無名関数とラムダ式」は似て非なるものみたいな意見は無意味だなって思います。

Schema.org(構造化データ)を学ぶ

現在Googleが推奨する構造化データを学んでみた話

タイトル通りですが基本的に一般人は気にする必要はないです。理由は３つほど

• ・検索のページランク自体には直結しない
• ・なのに記述を間違えると怒られる
• ・リッチリザルトは実務系しか強化されていない

リッチリザルトと構造化データの関係

リッチリザルト レポートの概要
「https://support.google.com/webmasters/answer/7552505?hl=ja」

構造化データ自体はだいぶ前から存在しており、情報を構造化して機械が理解しやすい様にすると考えれば基本的には十分です。

リッチリザルトは構造化データの「対象となる一部」から検索結果の見た目を強化する機能です。
これ自体はページランクに影響しないが検索結果が装飾される事でクリック率が上がり結果的にSEOに繋がる。

つまり、「構造化データ」は様々な情報を整理できるがそもそもリッチリザルトは一部しか対応してないので一般人が使うような内容には影響がないというわけです。

Schema.orgってなに？

構造化データを定義（Structured Data）している所です。
構造化データを定義を入れる時にこのサイトに構造情報があるという「"@context": "https://schema.org",」を指定します。
ですが現状ここしか指定出来ません。保証される構造情報を提供してるのがここしかないからです。

元々は Google・Microsoft・Yahoo・Yandex が共同で立ち上げたプロジェクトですが現状はほぼgoogleの影響で決まります。
そのためgoogleが構造化を推奨を強くしているわけです。

余り良くない事もあります。

リッチリザルトが実務ベースが強く、構造化データは多くの情報を定義出来るにお金になるProduct（商品）、JobPosting（求人）、LocalBusiness（店舗）、Recipe（レシピ）と言った所しかリッチリザルトされません。
FQAなども信頼の高いサイト以外は無意味になったし、How-toも廃止。
百歩譲ってリッチリザルトが実利を取るのはいいですが、構造化データ自体10年以上ほぼ変わらない構造化データなどがあります。

例えばVideoGameなどの構造はボードゲームなどの物理ゲームをベースに作られほぼ更新がありません。
ゲームアイテムの説明をするページを作る時にgameitemというプロパティはあるがメインに置くカテゴリが無いです。
存在しないアイテムなどの場合は「"mainEntity": {"@type": "Thing","name": "ゲームのアイテム名",」のようにThingしかないです。
また、同様にその説明に入れる情報は階層としてPropertyValueにするしかありません。

更に2026年今現在のAIに構造化データを作らせるとProductなどとあり得ない提案をして来たりします。
しかしそれらは実際の商品に対するものなのでゲームアイテムがリッチリザルトなどされるとショップを偽装するサイトとして評価が下がります。
ここらへんが最初に書いた通りの「一般人は気にする必要はないです」という事です。
あと記述も厳密でhtmlと違いカンマ一つ違うだけでエラーします。
変に構造化データを入れてページの信頼を落とすより、構造化を入れない方が大半の一般人には正しいです。

当然ある程度は構造化データに更新を求めて提案がされていますが主にgoogleがそれを取り合っていない為、構造化の追加もされてないのが今現在です。閑話休題。

構造化の構造について

さて話を戻して構造データについて。

Thing (最上位：すべての基本)
┃
┣━ Action (動作：検索、購入、予約など)
┃
┣━ CreativeWork (著作物・創作物)
┃   ┣━ Article (記事)
┃   ┃   ┗━ NewsArticle (ニュース記事)
┃   ┣━ Recipe (レシピ)
┃   ┣━ WebPage (ウェブページ)
┃   ┗━ Movie (映画)
┃
┣━ Event (イベント)
┃   ┣━ BusinessEvent (ビジネスイベント)
┃   ┗━ EducationEvent (教育イベント)
┃
┣━ Organization (組織)
┃   ┣━ Corporation (企業)
┃   ┗━ LocalBusiness (地域のお店・施設)
┃       ┣━ FoodEstablishment (飲食店)
┃       ┃   ┗━ Restaurant (レストラン)
┃       ┗━ Store (小売店)
┃
┣━ Person (人物)
┃
┣━ Place (場所)
┃   ┗━ AdministrativeArea (行政区画：市町村など)
┃
┣━ Product (製品・商品)
┃
┗━ Intangible (無形のもの)
    ┣━ ListId (リストの識別)
    ┃   ┗━ ItemList (リスト全般)
    ┃       ┗━ BreadcrumbList (パンくずリスト)
    ┣━ Enumeration (列挙型：在庫状況など)
    ┣━ Language (言語)
    ┗━ StructuredValue (構造化された値：評価、価格など)
        ┣━ AggregateRating (合計評価)
        ┗━ PriceSpecification (価格詳細)
    

全部ではありませんが主要なツリー構造はこういう感じです。
共通プロパティは「name (名前), url (URL), image (画像), description (説明)」
これらを使ってサイトの構造を定義します。初手は

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  ...内容
</script>

これです。
ページの情報はhtmlのその一つであっても個々に見ようとするので基本的には「"@graph": [...]」が必要になります。
更に言えばgraphで繋いでも情報が分散するのでidが必要になります。
面倒臭そうに見えますか？はい、実際に面倒臭いです。

ページ構造で必要なのは主に

• パンくずリスト(最低限これだけあればいい)
• メインコンテンツ(mainEntity)

形式的には

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "BreadcrumbList",
        "itemListElement": [
          {"@type": "ListItem", "position": 1, "name": "top", "item": "url"},
          {"@type": "ListItem", "position": 2, "name": "階層", "item": "url"},
          {"@type": "ListItem", "position": 3, "name": "現在", "item": "現url"},
        ]
      },
      {
        "@type": "コンテンツのタイプ",
        "url": "現url",
        "name": "ページのタイトル",
        "description": "ページの説明",
        "mainEntity": {
          ...内容
        }
      }
    ]
  }
  </script>

基本一般人が使うのはBreadcrumbList (パンくずリスト)とArticle (記事)ぐらいだと思います。
もうちょっと構造を複雑にしてみましょう。

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "WebSite","@id": "サイトのurl#website",
        "url": "サイトのurl",
        "name": "サイトの名前",
        "description": "サイトの説明",
        "inLanguage": "ja-JP"
      },{
        "@type": "BreadcrumbList","@id": "#breadcrumb",
        "itemListElement": [
          {"@type": "ListItem", "position": 1, "name": "top", "item": "url"},
          {"@type": "ListItem", "position": 2, "name": "階層", "item": "url"},
          {"@type": "ListItem", "position": 3, "name": "現在", "item": "現url"},
        ]
      },{
        "@type": "WebPage","@id": "現ページurl#webpage",
        "url": "現ページurl",
        "name": "ページのタイトル",
        "description": "ページの説明",
        "isPartOf": { "@id": "サイトのurl#website" },
        "breadcrumb": { "@id": "#breadcrumb" },
        "about": {関連の情報},
        "mainEntity": {"@id": "現ページurl#main-categories"},
        "hasPart": [ { "@id": "現ページurl#submenu" }]
      },{
        "@type": "ItemList","@id": "現ページurl/#main-categories",
        "name": "攻略主要カテゴリ","description": "攻略主要カテゴリの説明",
        "itemListElement": [
          {"@type": "ListItem","position": 1,"name": "メインリンク１","url": "url"},
          ...略
          {"@type": "ListItem","position": 8,"name": "メインリンク8","url": "url"}
        ]
      },{
        "@type": "ItemList","@id": "現ページurl#submenu",
        "name": "サブ","description": "サブの説明",
        "itemListElement": [
          {"@type": "ListItem","position": 1,"name": "サブリンク１","url": "url"},
          ...略
          {"@type": "ListItem","position": 5,"name": "サブリンク５","url": "url"}
        ]
      }
    ]
  }
  </script>

・トップの指定。url#websiteは各ページ統一が必要

・isPartOfでどれに属するかを指定

・aboutで関連の情報を追加

・mainEntityをidで指定

・hasPartを使い同様にこのページ内に付属するコンテンツを指定

これくらい出来れば基本的には良いんじゃないかなと思います。

合わなかったゲームとかの話

ゲームを楽しむには素養が必要という話 

今回はプレイして個人的に合わなかったゲームのお話。
別にゲームが悪いのではなくで自分に適性がないなと思ったゲーム

Mortal Shell（モータル・シェル）

ソウルライクなゲームでレベルの概念はない。
ただし武器などの強化要素、シェルと言われる肉体強化などはありある程度緩和出来ている。
感想とか見ると硬化とかがあるのでソウル系より全然簡単だよみたいなレビューをみて丁度数百円で買えるほどのセールだったのでお試しで購入。

パリィの受付が本当に短くてだいぶ難しい。
数発で死ぬし回復手段が乏しい。
回避行動は○ボタン短押し、少しでも○ボタンが長いとダッシュになる。
この時点でなかなかの慣れが必要。
シェルを2つほど解放(最初のシェルを足すと3つ)して少し進めた時点で個人的に楽しむのが難しそうだなと。

パリィミスの硬直は滅茶苦茶長い。逆に回避の無敵時間は長め。
回避が強くなかったならそもそももっと序盤で諦めてたと思う。
3つのシェルになっても長剣一本で行動差もなくて、新鮮さも得られず一応倒しては死んでを繰り返せばある程度強化は出来るんだけどター獲得量が少なくて面倒さの方が高くなってしまった。

ソウルライク特有なのかは分からないけど全体的に説明がないので良く分からないが戦っている感じでモチベを上げれなかった。
そして最低限の目的地も分からず完全に迷子。

スタミナ制限が厳しくて２・３回攻撃＋回避でほぼ使い切る。
それ以上攻撃するとスタミナが切れて剣すら振れなくなる。
これに関してはスタミナ制自体が個人的に向いてないのかもしれない。
パリィが1ミスが不利すぎるので１・２回攻撃→回避を延々と繰り返す事である程度は進めたけど他に本当にやる事がない。

今回は勝てなくてイライラというよりは単調過ぎて移動も戦闘も飽きてしまった面が大きい。
画面にほぼランドマークが無くて自分が何処に居るか分かり辛く、同じような画面が続くので飽きてしまう。
マップ表示なしにするなら、もうちょっとわかりやすいランドマークを配置して欲しかった。
本当に小さな段差も上がれない所も怠い。
ちょこっと降りた瞬間戻れないの悲しい。

死にゲーなのにロードが長い。
ソウルシリーズもそうなのか分からないけど、さっさと再開させて欲しい。
それとPS4だけど敵描画が遅く誰もいないと思って進んだら敵がふわぁと表示されるのもなんだかなぁと。

たぶん本当にソウルシリーズとか好きな人には面白いんじゃないかな。
L1＋R1で必殺技みたいなのもあるし、硬化はワンエッセンスになってソウルライクに慣れてるなら楽しめそう。

htmlタグの構造

htmlの正しい構造について考える

今回はhtmlの正しい構造について説明します

<body>

<header>

<nav>

  <ul>

    <li>メニュー項目</li>

  </ul>

</nav>

</header>

<main>

<h1>記事のタイトル</h1>

<p>ここにはリード文が入ります。</p>

<section>

<h2>章のタイトル</h2>

<p>文章の段落。</p>

<h3>小見出し</h3>

</section>

<aside>

<p>補足情報など</p>

</aside>

</main>

<footer>

<p>&copy; サイト名</p>

</footer>

</body>

header「ヘッダー」

大抵のサイトでは上部に固定するメニュー部分と考えて良いです。
ここにH1を入れるという考えも一応ありますが、基本的にはページを跨ぐ不変的メニューエリアである場合が多いし、h1を混ぜるのは非推奨です。
H1をここに入れたらページ毎にヘッダー内に書き換えが発生するので面倒です。

また、古いサイトなどにあるロゴなどにh1を指定するような事は止めてください。
H1は後で説明しますがページ全体の主題なので正しくありません。

ヘッダーとかはそもそな話、htmlの構造としてありまりにもヘッダーメインフッターという構造だったため必要になってHTML5で実装されたものです。
そういう意味では昔は本当にシンプルな文章しか想定してなかったのが今はナビが必要になった結果ですね。

nav「ナビゲーション」

主にリンクを纏めるのに使いますがnavタグがありすぎてもダメなのでおおまかにはヘッダー配下にナビを置いてメインメニューの固まりとして使うのが大半だと思います

ul・li「リストタグ」

正直な所「ヘッダー＞ナビ＞リスト＞リンク」という構造はほぼ固定です。
少しかっこよく言えばデファクトスタンダードです。

奇抜なデザインにしたいという願望が無い限りは安定でこの形です。
リストタグ自体は説明文系を挟まない端的な単語の列挙に使います。
ただ逆に言えばリンク群を配置するという時は単語列挙となり結果的にリストになります。

なのでそれが一番最初に使う位置としてはヘッダーナビリンクという感じこの上部で紹介。
構造としてはほぼほぼ定着しています。

リストかテーブルか？と悩んだ時はそれに補足する内容があるかで考えて下さい。
そして、補足や関連する内容が小さければテーブル、文章のような大きさならhタグ系になります。

main「メインコンテンツ」

ページ全体のメインとなる部分をこの部分に入れます。
ヘッダーにH1を入れた場合は

H1「主題」

ページ全体の何が書いてあるかという主題です。
idと違ってH1を複数使う事に対して絶対的な禁止とまではならないものの、事実上ページには1つだけ使ってください。
また、Hタグは階層的に１・２・３...と必ず階層構造が必要です。
H1から飛んでH3など飛んだりはしませんし、H1タグの上にH2タグを配置したりもしません。話の重要度とかの数値ではなくあくまでも文章構造による連番の階層構造です。

H1～H2の間「リード文」

Hが各構造のタイトルではあるが、H1の直下は実は基本的に内容を入れる所ではない。
本当に内容が1つしかなく章を分ける必要がない。またはツール等のでタイトルしかないような場合を除けば情報を表示し始めるはH2からというのが正しい構造。
その為、H1～H2の間はこのページではこういう内容について記述しますという端的な説明と目次を入れるの基本的な構造となります。

ｐ「段落」

最初にpタグを入れるのがリード文の部分だと思うのでここで紹介。
1つの文章の区切りがpタグです。改行はbrを使ってください。ある程度長い文章の文節がこのpタグで区切るという感じです。

文章全般は全てpタグです。pタグが無くてもhtmlに文章は乗せれますが調整したくなった時にcssで調整できなくなるのでやめましょう。
ブログとかだと改行（br）しか存在してない場合もありますが、本来は文章の区切り区切りおきにpタグで区切りのが正しいです。
また、タグを直接見てる側としてはpで区切ってれば分の移動が楽。

section「セクション」

大きな章の区切りに使います。
大きな区切りであれば一応使ってよいという事にはなっていますが、基本的には直下にHタグがほぼ必須と言えます。
ただし、H1自体はページ全体を表すものなので通常sectionでは囲みません。
また、基本的な章の大きな区切りはH2であり、H3以降は細分化する内容となる為基本的な利用方法としては <section><h2></h2><h3></h3>...</section> という構造になります。
明らかに情報量が多いH3などがあれば別ですが基本的にはH2とセットという認識でOKです。

H2「章」

実際の内容を書くのはこのH2からという事になります。
主題のおおまかな内容をH2で区切り更に細かい分類がある場合はH3を使います。
ただし、区分されるものが簡潔で補足するような文章などが無い場合はリストタグを使ってください。

H3～H4「項・細目」

章を更に分割して説明が長くなる場合は分割します。
<section><h2></h2><h3></h3>...</section>
<section><h2></h2><h3></h3><h4></h4>...</section>
みたいな感じにセクション内で個々に深堀りする構造が基本です。

article「アーティクル＝記事」

基本的には一旦使わないでので大丈夫です。
ブログやニュースや掲示板などサイト内で更に記事として独立する内容を入れる時に使います。
body内bodyみたいな気持ちです。1ページが独立してしまう記事などはbody直下をarticleで囲んで普通のhtmlみたいに書くと思って問題ないです。
先ずは基礎がないと使う事がないので一旦存在しているという程度に今は認識してください。

aside「アサイド＝関連」

メインの文脈からは外れるが、関連性のある補足情報に使用します。
用語解説、関連記事へのリンク、サイドバーなどに使います。
あとは関連が薄いものとして広告などのエリアとしても使われるけどあれは補足じゃないしどうなんだろうか・・・と思っているものの、簡単に言えば隔離エリアとして許されている。

footer「フッター」

基本的には最低限入れるのはコピーライト。
あとはいわゆるフッターメニュー。大抵の場合サイト内循環を促すのに大量のメニューがある。

div「意味を持たないタグ」

divが過去にも説明しているが事実上のデザインタグ。無色透明の箱だと思って良い。
好きなサイズをつくり好きなようにサイズを変更し好きなように着色変更する。
タグで足りない要素全てdivとspanが担っている。

span「意味を持たないタグ」

インラインタグで改行されません。
つまり、文章などの装飾タグです。
インラインで行う足りないタグの全ての担っている。

<body> (ページ全体)

<header>

<nav> (ナビゲーション)

<ul> <li> (メニューのリスト)

※H1を入れるのは非推奨。共通メニューを置く場所。

<main> (メインコンテンツ)

<h1> (ページに1つだけの主題)

H1～H2の隙間 (リード文：内容の端的説明。必要なら＋目次)

<section> (意味のある章の区切り)

<h2> (章のタイトル。ここから内容が始まる)

<p> (文章の段落。1つの意味のまとまり)

<h3> (さらに細かい項目の区切り)

<section> (意味のある章の区切り：このように複数でもよい)

<h2> (章のタイトル。ここから内容が始まる)

<p> (文章の段落。1つの意味のまとまり)

<h3> (さらに細かい項目の区切り)

<aside> (補足情報・サイドバー・広告など)

<footer> (コピーライトや補助メニュー)

</body>