「ゲーム」タグアーカイブ

すみません、エロゲ中心です。m(_ _)m

トラップを作る必要性

ちょっと考えてみた。

記事は後日追加する可能性があります。

トラップタワー

いわゆる「TTT」（天空トラップタワー）を作る必要性。
経験値を取得するためや、装備の修繕によく使われるパターンなのだが、制作する手間の割には、あまり利用する頻度が高くない。

というのも、そもそもマイクラの場合、経験値を貯めまくるのは効率が悪いし、そもそも経験値は金床などで消費するために存在するので、わざわざ TTT を制作して経験値を貯める必要はない。

それよりは、大々的に農業と畜産を行ったほうがいい。
その作物を村人（農民）と取引したほうが、エメラルドも貯まるし、経験値も貯まる。
それに牛やニワトリを処しても経験値は貯まるし、収穫した作物を与えれば、新たな牛やニワトリも生まれる。肉は食料や村人の取引材料になる。

農業・畜産の欠点は、自動化するまでの手間と、たとえ自動化したとしても、今度はそれを取引する村人までの間は、プレイヤー自身が収穫物を持って移動しなくてはならないため、その辺りが面倒な事と、１日あたりの取引回数に制限があるため、劣化した装備を修繕するには若干手間がかかること。

でも収穫可能な食物を一通り自動して作成しておくのはクラフト面・取引面で色々と便利なので、個人的にはこちらに力を入れた方がよいのではないかと思う。

それに TTT は、作成する場所まで移動しなくてはならないし、場合によっては周辺のmob湧き潰しなどの対策も必要で、かなりの労力がかかる。

まぁ「TTT はロマン」という考え方もあるので、その場合は止めようがないけど。。。

スライムトラップ

スライムを倒すと取得することが可能なスライムボールは、スライムブロックや粘着ピストンなどで必要になる。

そのため大量に必要な場合は、どうしてもトラップが必要になるのだが、これが 1.19 辺りからハードルが上がった気がする。

理由としては、Y軸が深層化したことと、その影響で地下に大規模な洞窟や廃坑ができまくってしまい、それが影響して、様々なmobが湧く余地ができてしまった。

これを防ぐためには、湧き潰しを徹底するしかないのだけども、これがかなり面倒。
洞窟などの地下構造物は入り組んでいるし、埋め戻すにしても、山を切り崩す必要があるし。
コマンド一発で埋めてしまうのでもアリだけども、できればサバイバルに徹したい自分としては、ね。

マイクラのマルチプレイサーバにおいて特定エリアが重いとき

この記事は実例やマイクラの特性をもとに記事にしたものです。
今後のバージョンアップなどによって内容を更新する場合があります。

記事の内容は、Java Edition のマルチサーバを利用している人向けの内容として記事にしています。
一部は Bedrock Edition（統合版）やシングルプレイの場合でも当てはまる箇所はあると思いますが、仕様や実装が異なる場合もありますので、ご注意ください。

必ずすべての記事内容を確認してください。
記事上部で記載した指摘事項だけが原因ではないことが、よくあります。

最近、Youtube などでマルチプレイサーバを実況するなどが多くなり、その際に特定のエリアで遅くなるなどの不具合を見かけることが多くなってきた。

これらは、通常のマルチプレイサーバでも見かけることがあるので、それらの原因をちょっとまとめておこうかと思い記事にした次第。

そもそも論

サーバは、プレイヤーPCほどの CPU スペックは本来必要ないのだが、それでも最低スペックというのがある。

メモリ容量
ストレージはSSDとすべき（HDD非推奨）

このあたりはマイクラサーバーの処理を安定させる要素の中で、かなり重要なので、良く考えるべき。

特にクラウドサーバや VPC サービスを利用している場合

これらスペックについては、かなりシビアに影響する。
というのも、そもそもクラウドやVPCは、あくまで「仮想サーバ」。
当然ホストサーバが複数の仮想サーバの稼働状況を監視しながら、動的に処理能力を割り当てるので、ホストサーバ全体の処理負荷が高い状態になれば、それだけ処理は重くなる。

そしてこれらはおそらく、契約プランによってサーバのグレードが変わる。
つまり「お金」で解決するしかない。

そこに繋がる「回線」も重要

あとクラウドやVPCでどうしても逃れることができないのが、ネットワーク回線の問題。
いくら高額なクラウドやVPCを契約利用していても、そこに繋ぐための回線が雑魚では意味がない。

昨今は光ファイバーのプランであっても、激安を謳って提供しているプランもあるが、通信品質については、正直おすすめできない場合が多い。
個人的には高くても、NTTが提供しているフレッツ網のサービス、しかもマンションに住んでいたとしても、個宅向けのプランを導入するのをお勧めする。
（ただしマンションによっては、個宅向けの光回線が敷設できない場合もある。マンション管理人や不動産会社に必ず確認すること。）

ゲームのどのワールドでも全体的に処理落ちや動作遅延が発生する場合

ここからは本体の問題。まずは CPU のスペック不足を疑ってみる。
Linux系であれば top, vmstat, sar, free といった各種コマンドで確認する。

特に昔から運用している場合、ver.1.17 あたりから処理負荷の高めな要素が増えているので、そもそもバージョンアップによるスペック不足も疑ったほうがいいかも。

特定のワールド・エリアで処理落ちや動作遅延生じる場合

その場所にある「何らかの要素」を処理するために大量のメモリを消費
↓
メモリを食い潰した時点でメモリスワップが発生
（メモリの内容をストレージに退避する処理が発生）
↓
しかもスワップ先が HDD 領域の場合などの遅いストレージ

という流れで、特定のエリアに入った途端、急激にスローダウンする場合がある。

この場合の対策としてはメモリを増設する、または処理落ちや遅延が生じるようなアイテムの利用や密集状態がワールド内で発生していないか確認し、それを解消するのが、有効な対策となる。

同一ワールド内でも、お互い離れた場所でプレイしている場合

同一ワールド内かつ比較的同じ場所でプレイしている場合、サーバーが処理するエリアは１箇所で済むので、余程複雑な処理（たとえば、複雑な回路を動かす、大量の看板やチェストを設置しているなど）をしていなければ、サーバーはお互いのプレーヤーで必要な共通の情報を「よしな」に合理化して処理するので、処理落ちのリスクは低くなる。

逆に、複数のエリアでプレイヤーがそれぞれの活動をする場合は、処理は重くなる。

特に問題となるのは「ワールドを新規に広げる行為」。
例えばバージョンアップなどで新しいバイオームが追加された場合、それらを探すために、同時に四方八方に分かれて行動することがある。
当然ながらサーバーはそのプレイヤーそれぞれで、新規に踏み入れたチャンクをどんどん生成することになるので、処理落ちのリスクは高くなる。

たまに配信でみかけるのは、ワールドの描画が間に合わない状態でエリトラで飛んでいたら、いきなり山が現れて激突したり、地中に描画されて生き埋め状態になったりなど。

そうなると座標を控えてもいない場合も多く、拠点は遙か手前の場所だったりすると、散乱した持ち物を探せなくなったり、それらを探しているうちに時間切れで消えてしまうこともあるので、そもそも注意が必要。

余談だけども

OSや導入しているパッケージ類についてパッチが提供されている場合は、アップデートしたほうがいい。

というのもアップデートによって、バグが改善されることが、間接的に処理の改善に繋がることがある。

ただし、これは別に「バージョンアップしろ」という意味ではなく、あくまでアップデート・パッチ対応をしろという意味。
アプリケーションの推奨バージョンに倣ったバージョンであれば、バージョンアップまで行う必要はない。
OS 等を無闇にバージョンアップしてしまうと、OS 側のメモリ消費増加や処理が重くなる可能性がある。
（無論 OS にもサポート期間があるので、それに倣う必要はある。）

配信でマイクラサーバを扱うのであれば

クラウドや VPC を利用したほうが手間がかからないし、契約や運用も楽なのはわかるけど、長期に渡って運用したり、箱単位でマルチサーバを利用するのであれば、実機（オンプレミス）でサーバを準備したほうが、安定性は格段に高い。

Javaまわり

Java Edition は文字通り Java というプログラム上で動く。
そのため Java そのものの仕様や特性が、ゲームサーバの挙動にとても影響する。
そして Java という言語、マイクラ開発当初はゲーム開発のうえで先見性があったのだが、今となってはそうではもない。
むしろゲームシステムを Java で制作する場合、そのパフォーマンスを発揮するには「足枷」とすらなり得てしまう。

それでもマイクラのサーバプログラムは、まだ Java の特性を許容した実装が為されているし、Java で開発されてるがゆえ、mod 追加などの自由度が高いのも事実。

この辺りのバランスや動向にも注意を払う必要がある。
これらの理由から Java そのものについても、バージョンアップやパフォーマンスアップデートがあるので、状況を見て、定期的にアップデートしたほうがいい。

マルチプレイサーバの起動オプション

Java のプログラムは、起動時に「メモリ割り当て」をオプションで行うことができる。Minecraft も然り。
通常の Java プログラムおいて、これらを意識する必要はないのだが、ゲームサーバにおいては、このオプションを設定し、サーバの物理メモリに応じた領域を確保したほうが、パフォーマンス向上に繋がることが多い。

これ以外にも、起動時の際に最適なオプションが存在しているので、ハードウエアの仕様に合わせて、それらオプションを設定することをお勧めする。

ゲームの中の状態

建築物や装置が密集している

マイクラはプレイヤーのいる位置を基準にして、その周辺に設置されている建物や装置を含めたワールドの処理を行っている。

そのため、プレイヤーの存在する位置にそれらが多く存在する場合、処理がかなり重くなる原因になる。

複雑な建築物は、存在するだけで負荷がかかることもあるが、特に装置を設置している場合は、未使用時は停止できるような回廊にすることをお勧めする。

チェスト・旗・看板・額縁・ホッパー・…などなど

これらはマイクラサーバにおいて、かなり負荷が高い。

mobの湧き状態

マイクラには、mob の湧く距離が決まっている。これらの特性は別記事で照会しているので、そちらを参照してほしい。

特に気になるのは、mob は地下にも湧くという事。
1.17 以降で地下洞窟が大量に生成されるようになり、1.18 からは、Y軸が更に深くまで生成されるようになった。
しかも1.18 の地下拡張は、1.17 までで生成されたワールド場でも拡張されるため、より深い場所で mob が湧いている可能性もある。

地下洞窟や地下建造物

要するに、地下空洞があると、その場所の１ブロック毎に明るさや mob 湧きの試行などが行われることになる。
これら単体では処理負荷が高くなくても、多くなれば負荷になることがある。
これらに最も効果的なのは「埋め戻し」だが、現実てきではないことも多いので、せめて拠点については、湧き潰し（松明による明るさの確保）をしたほうが良い

水流・溶岩流

整地や景観を整えるために、表面だけ埋めることがあるとは思うが、特に水流・溶岩流になっている場合は、通常のブロックで埋めていまうことをオススメする。
というのも（溶岩流はアイテムを落としても燃えるだけなので、水流に比べて処理は軽いと思うのだが）水流は、流れや流量といった内容を計算処理しているため、特に複雑な状態で水面だけを埋めてしまった場合、負荷に繋がるおそれがある。

これも最も効果的なのは「埋め戻し」。特に砂漠バイオームで入手可能な「砂ブロック」は、これら埋め戻しにとても効果的。

ワールドの状態を把握するための裏技

「スペクテイターモード」の使用をおすすめする。いわゆる「神視点モード」。
プレイヤーが存在した状態で、この状態を動かせば、地中の状態だけでなく、mob の湧き状態も含めて把握することができるようになる。

ただしこのモードは、ワールドの状態を簡単に把握できてしまうモードのため、配信でマイクラをプレイ実況している場合は「チート技」となってしまう。

そのためこのモードを利用する場合は、あくまでサーバ管理者に限定して利用し（そうでない場合は、利用する条件を厳しく決めた上で運用し）、ゲームプレイの方向性を見極めたうえで、プレイヤー（配信者）に伝える要否も含めて、十分検討すべきだと思う。

現状自分も、このモードは、厳密なルールに基づいて運用している。

VTuber 推しになって気がついたら数年経過。。。

コロナ禍によって働き方が大幅に変わってしまい（個人的には望んでいた働き方になったので、その点に文句はないのだが）、その過程で VTuber 推しになった。

まぁハマった発端は、ホロライブのマイクラ配信（シュバンゲリオンとかペコスバ戦争とか、ホロライブ大運動会とかの頃。詳しくはこの頃（2020年ごろ）の切り抜き参照）という極めてありがちな導入でしたが、あれからはや数年、すっかり視聴コンテンツがアニメ・マンガから VTuber に移ってしまった。

2.5次元的な世界としては、キズナアイなどの先駆者などが沢山いたんだけど、当時はどうも、あの3Dの不自然な動きや姿勢を変えるときのキャラのバランスなどがダメで没頭できなかったんだけど、Live2D の進化によって、そして演者の動き方が人間的であっても、実際のキャラクターはアニメーション的な動きに寄せられたこともあり、その辺りが気にならなくなった。

そして本来 YouTuber の十八番だったバラエティ的な要素が、VTuber に（一部は形を変えて）吸収されたこと、そして昔のライブキャスト的な要素やチャット機能などによって、視聴者との距離感も縮んだことも、ハマった原因なのかも知れない。

個人的には業界推し

なんかこう書くと「後方腕組みオジサン」みたいで微妙なのだが。
実際のところ、特定の推しキャラがあるわけでも、いわゆる「箱推し」でもない。
至って個人的な完成に基づいて、色々なコンテンツを見て渡っている。

箱単位だと、ホロライブ、にじさんじ、774 inc.、ぶいすぽっ!、ViViD、のりプロ

まぁ仕事や作業の傍らで見ている事が多いので、自ずとその時間帯に活動しているタイバーのコンテンツを見るわけで。

その際に、仕事の邪魔にならない程度の活動をしているコンテンツを提供してくれている VTuber が、強いて言えば推しなのかも。

そういった点では現状、ゲーム実況、しかも Minecraft（マイクラ）や Ark などのいわゆるサンドボックス系にて雑談やコラボ配信している位のコンテンツが好み。

ただし別に、他のジャンルのコンテンツを見ないわけではなく、流れで見ることも多々ある。
それに面白ダイジェストの切り抜きも見るので、そういった意味では、とにかく「食い散らかしている」感じ。雑食。

ただコンテンツを見ていて最近ホントに思うのは「オタクのトレンドは完全にアニメ・マンガから VTuber に移ったなぁ」という点。

もちろん今もでも、面白いアニメ・マンガのコンテンツはあるのだが、全体的なトレンドが VTuber に移動してしまったため、たとえ VTuber が面白いアニメ・マンガを紹介したりコンテンツ内で取り上げたりしても、大多数の視聴者は、それらはもはや宣伝の対象でしかなく、主体ではなくなったと状態で見ているんだと思う。

ここで余談

子供の頃からのトレンドの変遷を考えてみた。

鉄道（見る鉄⇒Nゲージ⇒乗る鉄）⇒マンガ・ゲーム（少年マンガ⇒少女マンガ⇒EVAとかファンロードとか声優とか色々雑多⇒コミケ・同人誌）、そして⇒VTuber

個人的な年齢を考えると、これが人生最後のトレンド大転換になるのではないかと感じている。

スライム（mob）のスポーンを再考察

ここでは Java Edition の話をしますが、Bedrock Edtion（統合版）でも数値や条件は異なるものの、ある程度は参考になる考え方だと思います。

理由は、1.18 あたりのバージョンアップからスライムチャンクが機能しなくなったから。

スライムが全く湧かなくなってしまった………

理由はおそらく以下

Y座標が 0〜256 だったのが、1.18 で -64〜320 に広がったから。
- ここでは特に「地下」が広がった点が、重要な要因。
今まであまり歩き回っておらず、ワールドが生成されていなかったから。
他の mob 湧きに影響する。

Y座標（上下座標）の話

ちなみに 1.17までで生成されたワールドも、1.18 にバージョンアップし、ユーザがログインしたタイミングで、ワールドの生成条件に従って、追加された地下についてもワールドが大幅に広がる（追加生成される）ようになった。

しかも 1.18 からは、鍾乳洞（Dripstone Caves）などのかなり大規模な洞窟バイオームが生成になった。その影響で大きな空洞が作成されるようになったため、そちらに mob が湧くようになってしまったのが影響している。

ちなみに 1.17 以前は、地上を規準としたバイオームが生成されていた（地上が河川バイオームであれば、それは地下（岩盤）まですべて河川バイオームだった）。
しかしながら、現在はそうとは限らず、別途「地下バイオーム」が設定されるようになった。
そのため地上と地下では、異なるバイオームが生成される場合がある。

ワールド生成の影響

今まで拠点を中心に、ブランチマイニングしつつ必要な建築や装置を作成していた。
そのため、個人的にあまりワールドを広げていなかった。
（まぁマイクラ経験も浅いし、これは個人的なプレースタイル都合の話なのだが。）

しかも最初はPC環境が貧弱だったことから、描画距離もかなり狭くしていた。
そのため、そもそも生成されているワールドが狭かった影響もあり、mob 湧きが制限されていた。

しかしながらプレーするにつれ、行動範囲も広がり、またPC環境も大幅に整備したことにより、描画距離を広くした。

これらの影響によりワールドも広がったため、そこに mob が湧く余地ができてしまったことも要員だと思われる。

範囲に重点を絞った mob 湧き条件の話

マルチプレイの場合、サーバ環境の設定や他のプレーヤーの行動状況にも左右される可能性があるため、一概には言えません。

ワールド生成の条件

そもそもワールドが生成されていない場所に mob は湧かないので、まずは最初に影響するのは「これ」になる。

そして生成は「描画距離」に影響し、その公式は「描画距離×2-3」とされている。

つまり Java 版の描画距離は 12 チャンクが初期値（既定値）なので、それを規準に考えると、（また水平方向の場合は 1 チャンク＝ 16 ブロック平方なので）

12×3-3=21チャンク＝336ブロック

という形でワールドが生成されている。

……と、ここまで書いたものの、基本的に次に書いている「mob の湧き条件」よりは広いので、これが mob 湧きに影響していることはかなり少ない

mob 湧きの条件

こちらは純粋な湧き条件。とはいえかなりややこしいのだが。

プレイヤーから「25 〜 128 ブロックの球形」範囲にスポーンする。チャンク換算でおよそ 1.6〜8 チャンクの範囲。
湧き条件に適したブロックの上であること。
- 透過ブロックや下付ハーフブロック、ブロックのない空間でないこと。
  （ただし空中や水中で湧くmob など、一部 mob については条件が異なる。）
mobの大きさに応じた空間。
- mob のサイズよりも小さな空間にはスポーンできない。
日光があたる場所においては、明るさ 7 以下。
- つまり、夜または雷雨状態の中。
地下の場合は明るさ 0
- 以前は明るさ 7 以下だったが、1.18 からはこの条件に変わった。
バイオームに毎に設定されたスポーン確率。
- 湧き条件がバージョン毎に調整・変更される場合あり。
地域難易度。
- ワールドのプレイ時間や月齢・難易度などを元にした複雑な計算式。
- この項目は、概ね「mob が武器を装備した状態でスポーンする確率」といった「副次的な条件」としてよく使われるが、スライムの場合はスポーンする際の「大中小サイズ」に影響する。

…… 以上が代表的な条件。これ以外にも細かな条件がある模様。

スライム特有の湧き条件

しかもスライムの場合、バイオーム毎に設定されている mob の「スポーン確率」とは別に、さらに以下のいずれかでしか湧かない「追加条件」がある。

沼地バイオーム
- Y=50〜70、明るさ 7 以下
それ以外のバイオーム
- Y=40 未満のスライムチャンク

一般的にスライムトラップを作成する場合、（拠点近くにあれば別だが）沼地バイオームをわざわざ探し、そこに設置するのは面倒。
そのため、通常のバイオームの地下（Y40以下）にトラップを作成することが多いと思う。

あと、これは自分が個人的に感じているだけの話なのだが

（確証はないが）どうも他の mob の湧き条件に比べると「低い」気がしている。
というのも、湧き条件とは別にスライムの場合「大きさ」が影響しているのではないかと。
スライムの場合、大中小があり、それぞれ 2.0808、1.0404、0.5202ブロックのサイズとなっている、しかも小数点以下見ていただくと判る通り、それぞれ 3、2、1 ブロック立方のサイズが必要。

これと「地域難易度」が影響しあって、以下のような状況が発生しているのではないかと。

規準となる湧き場所（洞窟内）にて
mob の湧き条件で「スライム」湧きが「確立」
↓
地域難易度にて「大サイズ」
↓
3ブロック立方の十分な湧き空間が存在しない
↓
スライムの湧き「失効」

これが影響して、洞窟内には結果的に1ブロック四方で湧くことのできる他の mob が沢山湧いてしまっているのではないかと思っている。

対策

つまり、スライムチャンクを設置した場合、最低でもその周囲８チャンクについては、地下も含めて湧き潰しが必須となる。

またスライムの湧き条件が Y=40 未満のスライムチャンク（または Y=50〜70、明るさ 7 以下の沼地バイオーム）のため、スライムトラップを作成する場合、岩盤までにある洞窟はすべて湧き潰しを行う必要が出てくる。

また同じく、河川や海にいるイカやタラ・鮭・熱帯魚などの mob なども影響しそうなため、これら水中についても湧き潰しをする必要がありそう。

基本的な湧き潰しとしては、松明を建てるのが最も効率的だと思う。
ただしスライムについては、明るさに関係なく、空間さえあれば洞窟内でも湧いてしまう。

そのため、スライムトラップで確実にすべてのスライムを湧かせたいのであれば、トラップの周囲８チャンク内にある洞窟という洞窟は、すべて埋め戻す必要があるという事になる。

（まぁ実際のところ、それはさすがに時間の無駄。なので松明だけで置き、多少空間のある洞窟があって、そこにスライムが湧いてしまっても、無視するということになるとは思うが。）

要するに

ゲーム進行により開拓が進んで、さらに 1.18 になって、色々と「めんどくせー」ってなった、というお話。

マイクラ 1.19 にアプデしてみた。

こちらの記事は今後随時追記していきます。

こちらは Java Edition に関する記事です。統合版とは仕様が異なる点がある場合がある等、ご注意ください。

大型アプデからおよそ１ヶ月経過したので、アプデしてみた。

ちなみに１ヶ月空けたのは、自鯖で spigot 使ってたり、大バグを警戒しての理由。
あと、Dynmap や OptiFine, Forge といったプラグインや mod の 1.19 対応を待っていたから。

アプデの話

基本的には、1.17 ⇒ 1.18 にアプデした時と手順は同じ。
今回 Java のアプデは必要なかったので、そのぶん手順は減ったけど、modのアプデが、現時点では一部間に合っていない。

Forge

41.0.100 の話

１ヶ月経過してもβ版

いつ安定版になるんやろか。

やっちまった

Spigot をアプデして、クライアントはノーマルな状態で動かしたら問題なかったのだが、その後β版 Forge をインストールしたところ、起動時に見事クラッシュ。

おそらくその出かけた普通の自分の場合、手懐けたネコの種類（ネコの柄）が、すべて Tabby になってしまっている。
でもって data コマンドで調べてみたところ、CatType というネコの種類を指定する値がどうも見つからない。
おそらくこれが原因で CatType=0 つまりTabby になってしまっている模様。

これがクラッシュの影響なのか、β版を入れた影響なのかは判らない。

OptiFine との同居不可

1.18.2 の環境では Forge の中に OptiFine も同居できたが、1.19 対応の現バージョンでは同居不可。起動時に Java がクラッシュする。

追加された仕様とかの話

泥ブロックとかカエルとか古代都市の話は、他サイトの記事で沢山取り扱われているので割愛。

チェスト付きトロッコ・ホッパー付きトロッコ・かまど付きトロッコ・TNT付きトロッコ、破壊時にトロッコと別々に分解されなくなった

なので一度これらの合体トロッコを作成すると、永久にそのまま使うことになる。
これが意外と鬱陶しい。

というのも、ここ数年のバージョンは（地下が深くなったり、バイオーム分布の影響で？）地下廃坑がかなり多く生成されやすくなった感じがするので、地下の湧き潰しがてらブロック収集していると「チェスト付きトロッコ」が割と見つかる。

これが今まではチェストとトロッコに分解できたので、それぞれ別用途に流用できたけど、今後は永久に「チェスト付きトロッコ」のままなので、使い道が限定されてしまった。

個人的にチェスト付きトロッコの使い道は、現状ほぼゼロ。
そのため当面は死蔵品。今後チェスト付きトロッコを使うような仕掛けを作る機会は…あるのかなぁ…

マイクラ 1.18.1 の話

この記事は、今後随時追加・変更・訂正・削除する可能性あり。
また 1.18 の頃の話も含まれている。
そのためこの記事はマイナーバージョンの変化も含めて、一つの記事で流動的な内容を取り扱っているため、他のバージョンとは挙動などが異なる場合あり。
さらに掲載後の時間経過によって、最新版を対象とした記事でなくなる。
これらに十分注意し、記事を参照すること。

Java版（JE版、Java Edition）の記事。
統合版は若干仕様が異なる場合があるので、注意。

Y（上下）座標が拡大された。
バイオームの新設や整理が行われた。

この辺の話は、調べればよく聴く話だと思うので割愛。

敵 Mob の明るさに関するスポーン条件が変更になった

今までは明るさレベルが７以下がスポーン条件だったが、これが０でないかぎり、つまり光源ブロックからの明かりが少しでも当たっていれば、敵 Mob はスポーンしなくなった。

そのため、今まで湧き潰しが甘い箇所箇所が近くにあったりすると、クリーパーが湧いたりして、いきなり背後で爆発に巻き込まれるとかあったが、このような事態は、かなり減った。

むしろ地上拠点など、湧き潰しされてる空間上での不意な「湧き」がかなり少なくなってしまったので、当初は「アップグレードのバグか？」と思ったぐらい。

鉱石分布の変更

すでにブランチマイニングされているエリア（チャンク）は、掘ってなくてもワールド（ブロックの情報）が生成済のため、それが書き換わることはない。
しかしながら、今回追加した Y=0 より下の層や未踏のエリアについては、プレーヤーの移動によって追加生成されるのだが、その際注意しなくてはならないのは、鉱石分布の変更。

特にダイヤモンド鉱石の場合、今までは Y=1～15 に分布していたが、1.18 では Y=16 以下、しかも深くなるにつれ、出やすくなるように変更された。
（ただし溶岩溜まりなどの Y 座標は 1.17.1 と同じなので、深層を掘る際のマグマダイブは従来通り注意が必要だし、横掘りや上掘り時の注意も必要）
それ以外の鉱石についても、一定数の生成頻度とは別に、出やすい高度の傾斜が追加された。
そのためブランチマイニングなどの効率重視の場合、目的の鉱物別に高度を変更する必要があるなど、適宜方針変更する必要が出るくると思う。

雨・雷雨が頻繁になった

1.17.1 において雨・雷雨がほとんど降らなかったが、1.18 では、割と頻繁に降るようになった。

落雷も 1.17.1 に比べると、かなり頻繁に発生するようになったので、木造の設備や植生などについては、火災対策が重要になると思う。

遠くのブロックが霞むようになった

~~1.18 からは描画距離の設定や考え方が変更されたようで、単にアップグレードすると、遠くの景色が霞むようになった。~~

~~おそらくこれは、ＰＣのスペックによって左右されるのだと思うが、非力な環境だと、この霞み具合がさらに広がった。~~

（1.18.1 にて改善されました。1.17.1 とほぼ同じ描画距離になったと思います）

オオカミの字幕が変？

普通に吠えて（元気で）も「オオカミが息切れする」と表示される。（字幕のバリエーションがトンでる？）

水流や溶岩など環境音の聞こえ方が変わった？

溶岩や水流などの環境音に指向性が追加された？
以前は 360° どの方向を向いていても、環境音は聞こえていたのだが、1.18 になってから後方の環境音が聞こえなくなった。

また以前は他のブロックの先にある音が、結構数ブロック以上離れた遠い距離からも聞こえていたものが、1.18 ではかなり近くのブロックに来ないと聞こえなくなった気がする。

また「聞こえない＝字幕にも表示されない」ため、調子にノってマイニングしていると、いきなり「溶岩ドバァ」とか溶岩遊泳とか落下の憂き目に遭ってしまう。

水流

プレイヤーの向いてる方角によって聞こえたり、聞こえなくなるような効果が追加された？

溶岩

地中にある（渓谷や洞窟などの空間がない）溶岩ブロックについて、音が聞こえなくなった？
併せて字幕も表示されなくなった？

マップについて

マイクラはプレイヤーの移動にあわせて、seed値に沿って動的にワールドが生成されていく。

厳密にはプレイヤーの移動にあわせて、プレイヤーの存在する位置周辺のチャンク（感覚的には遠景でみえる景色の数チャンク先）が生成される。

そして前バージョンで生成されたワールドについては、アプデ以降も基本的には変更されない。

逆に未踏破のエリアは、新バージョンの設定で生成されることになるため、いきなりバイオームが変化するような場所が生じることもある。

また 1.18 では地下も拡張されたため、1.17で生成された地下世界の下に、1.18 で追加された深層地下が広がっている。

【以下、引き続き気づいた点について、随時記事を追加・変更する予定。】

Spigot 1.17.1 ⇒ 1.18 アプデしてみた

Minecraft Java版も 1.18 になり、Spigot も 1.18 が公開されたので、うちの貧弱環境で動作するのかも含めて、早速アップデートしてみた。

ちなみにシングルで遊ぶのであれば、自分のPC上で「シングルプレイ」で普通に遊ぶのが、あくまで一般的なはず。
最近のゲーミングPCであれば、スペックとかも問題ないはず。

この記事は、Spigot サーバをわざわざ建てて、マルチ環境でシングルプレイするという奇特な人（私）を前提とした内容。
なので、その辺の無粋なツッコミは、なしの方向で。

もうメモリ1Gではムリです。

今まで「さくらのVPS 1Gプラン」で稼働させてましたが、1.18 へのビルド・アップグレードについては、なんとか可能。
しかしながらゲーム中の動作中、以下のような事象が発生していた。

移動やブロック破壊中などの動作が、固まる。そして数秒前の状態に戻る。
チェストやインベントリを開くことができない。
新規エリア（チャンク）移動の際、トロッコやボートなどの速い速度で移動すると固まったり、ゲームが強制切断される。
普通に移動したり、ブロックを破壊していてもゲームが強制切断されることがある。
強制切断後、再接続できない。

このような状態になっていると、往々にして Spigot サーバーのコンソールに、以下の過負荷警告が繰り返し表示されることがある。

> Can't keep up! Is the server overloaded? Running XXXXXms or YYY ticks behind

【意訳】
もうついていけねぇ！　サーバーが過負荷じゃね？　XXXXX ミリ秒または YYY ティック遅れてる。
（ティック：ゲームの処理単位、マイクラだと1/20秒単位）

つまり現実時間軸に対して、ゲーム内の処理量が多すぎて時間が追いつけていないという状態。
これが積み重なるとゲームは処理落ちを跳ばして無理矢理、時簡短縮をしたり（プレイヤーは見かけ上、コマ落ちやキャラがワープしたように、移動や操作前の状態に巻き戻されたように見える）、ゲームが強制終了してしまう。

ちなみにこの事象、1.18 ほどではないにしろ 1.17.1 でも発生していた。
それでも 1.17.1 の場合、個人的にはシングルプレイで利用するかぎり、まだ耐えられる程度だったが、1.18 では頻発するため、さすがにストレスがキビしい。

いずれにせよ、この現象はメモリ不足や処理の過負荷が原因。
1.18 にはアップグレード（ビルド・インストール）できるものの、プレイは現実的ではないという結論。

対策、カネで解決するしかない。

そのため、急遽 VPS のプランを 1G ⇒ 2G に変更。
その結果、頻発していた負荷警告は（発生はするものの、1.17.1 の時よりも少ない状態に）収まった。

この状況から、今後のマイクラ JAVA 版は、普通にゲームするだけでも、少なくとも2G以上のプランが必須となってきそう。

ちなみに Spigot の動作スペックを少し調べてみたが、どうやら最近は 2GB 以上のメモリを最小としている模様。
もしかしたらメモリ 1G での挙動させる猛者はいるのかも知れないが、普通に Spigot をセットアップしてあくまで標準的に利用する場合、メモリ 1G での動作は無理だと思う。

あと以前の記事にも記載した通り、自分が利用しているサーバは契約自体が年間契約のものを流用した関係と、AWSなどを再契約した場合、またイチからサーバを構築しなくてはならない。
そのため今回は緊急避難的にスケールアップで対応し、契約満了までは利用することにした。

しかしながら 1G⇒2G へのプラン変更は、概ねどこの VPS サービスもそうなのだが、利用料金がほぼ倍になってしまう。正直なところ、お値打ち感はない。

なので個人的には契約満了後、AWS（EC2）に切り替え、かつ弾力的にインスタンスの開始/終了ができるようなシステムを構築する方向で、費用圧縮を考えている。

1.17.1 ⇒ 1.18

そして本題です。

まずビルド・実行にあたり、Minecraft 1.18 は java 17 のバージョンが必須となる。
そのため、まずは java のバージョンを 16 ⇒ 17にアップグレードする必要がある。

でも、何はともあれ、まずはバックアップから。

# sudo su
# cd /opt
# cp -a spigot spigot.1.17.1
# exit

自分の場合、spigotを導入している /out/spigot ディレクトリ配下を、権限そのままで、ごっそりコピー。

ちなみに apt コマンド等は Ubuntu 20.x.x の場合。
CentOS や Windows など、各自のOS環境や権限、ディレクトリ構成などによって、手順やコマンドや手順は異なる。
そのあたり、各自で適宜調べて実施する必要あり。

次にパッケージインデックスを更新。

$ sudo apt update

ついでに、他のアップグレードがある場合、必要に応じて更新。

$ sudo apt upgrade

自分の場合、最も環境変化の影響の少ないアップグレードをしている。（余計な機能は追加しない。）

本題に戻り、OpenJDK 17 をインストール。

$ sudo apt install java-17-openjdk

最後に Java 17 になったか、バージョン確認。

$ java -version

これでjava 17.x.x がバージョン表示されればOK。

次にビルドツールを最新化。

$ cd spigot
$ rm BuildTools.jar
$ wget https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar

このビルドツール、頻繁に更新されていて、古い BuildTools.jar だと最新版のビルドができない場合が多い。
なので BuildTools.jar は、常に最新版を使う。

必ず Spigot 公式が提供している jar ファイルをダウンロードして使用すること。
BuildTools.jar をググったりして探すと、野良サーバの jar ファイルがヒットすることがある。これがセキュリティ上とても危険。
必ず公式サイトからダウンロードしているか、URLを確認すること。

そしてビルド。

$ java -jar BuildTools.jar --rev 1.18

これによって、Spigot 1.18（Spigot-1.18.jar）がビルドされる。

次に、既存のワールドデータや設定ファイルなどを、1.17.1 ⇒ 1.18 にアップグレードしつつ、spigot サーバを一旦起動。

$ java -jar spigot-1.18.jar --nogui --forceUpgrade

このタイミングで、現時点でのワールドデータやプレイヤーのデータがすべて書き換わる。

ちなみにこのアップグレード作業、ワールドの広さによって、かなり時間がかかる。
もしかしたら半日以上とか、かかるかも。
自分の場合、まだ数百座標単位しか展開していない。
しかしそれでも 15 分ぐらいかかった。

だからといって、上記コマンドを入力したら、絶対に途中で止めず、辛抱強く待つこと。
途中で止めると、ワールドデータが破損する可能性があり、その場合、二度と起動できなくなる可能性すらある。

バージョンによっては、上記アップグレードコマンドにて操作終了後、何もしていないのにメモリ不足などの例外エラーで終了したり、コマンドの入力挙動がモッサりして不安定になることがある。
自分の環境では、1.18.1 アップグレードの際に発生した。
ただ今のところアップグレード時のみ生じている問題で、OSごと再起動し Spigot を通常起動させた状態では安定。
少しゲームプレイしたかぎり、問題も起きていない。むしろ動作が軽くなった気がする。現状様子見。

無事に起動が確認できたら、一旦停止。

> stop

Spigot を終了させる。
そして最後に –forceUpgrade オプションなしの状態で Spigot を再起動。
これで問題なく起動し、ゲームにログインインして普通に操作できれば、アップグレードは無事終了。

以上アップグレードの作業そのものは、特段難しくはない。
しかしながらアップグレード前に、記事冒頭の記載通り、サーバースペックの問題を確認・解決する必要がある。

マイクラサーバ、立ち上げの試み

この記事は、今後更新される可能性があります。

サーバのインストール手順については、ググると先達の Web 記事がいくつかヒットするので、ここでは解説していない。
あくまでプラン選択の経緯を記事にしてみた。

また、利用したマイクラサーバは Vanilla（バニラ）ではなく、今後の利用を考えて、Spigot を選択。

さくらのVPC 512MB プラン

以前は512MBなど、低スペックなVPCサーバでも利用できたようなので、元々所有していたサーバ契約を流用して、インストールを試みてみた。

ビルドは何とか成功、でも起動しない。

コンパイル時にもメモリ不足のエラーが表示されたが、無理矢理ビルドすることは可能。
しかしながら、サーバ実行（起動）の過程でメモリ不足となり、立ち上がらなかった。

さくらのVPC １Ｇプラン（今ここ）

こちらのプランだと、サーバも起動できる。
ところがプレイ中、ボートやトロッコなどで高速移動すると、処理落ち（移動が巻き戻ったり、切断、例外発生によるサーバーエラー終了など）が頻発。

原因がメモリ制御なのか、処理速度（CPU）の問題なのかは不明だが、いずれにせよ、メモリ１Ｇであっても、新規ワールド（空間）への立ち入りや複数人でサーバに接続すると、かなり不安定になるのではと思う。

現状、拠点でブランチマイニングや、精々近所の村や洞窟探索を中心にプレイしてるので、何とか動作している。
しかしながら飽き足らなくなれば遠征することになると思う。
おそらくそれは、時間の問題かと。

結論

メモリは最低でも１Ｇ以上必要、ただし限界は近い

おそらくクラウドサービスを利用してマイクラサーバを立ち上げる場合、CPU やハードディスク容量については、一定以上のプランを利用すれば、ほぼクリアできることが判明した。

しかしながら Java を利用しているため、初期のモジュールビルドにも、マイクラサーバの実行にも、とにかくメモリを喰う。

おそらく２Ｇ以上のサービスを利用するのが安泰だと思うが、そうすると今度は、費用面が問題になると思う。
例えば、さくらインターネットの場合だと、プランを１Ｇ⇒２Ｇにすると、基本料金がほぼ倍になる。
ざっくりだが、年額でおよそ１万⇒２万の差。
いくつか他の VPC 事業者もみたが、ほぼ同じ傾向。

個人的にはAWS（EC2）に移行しようと思ってる

ちなみに仕事用を中心に、オンプレサーバをクラウドに移行したので、玉突きで空いたオンプレサーバをマイクラサーバにしようかとも思った。

しかしながら、オンプレサーバのディスクをSSDに換装したり、電気代などの維持費を考えると、先のクラウド移行した理由が破綻してしまう。
なので今のところは、AWS（EC2）などのインスタンスの自由度が高いクラウドにマイクラサーバを移行することを検討中。

ただし、正直なところ AWS のようなクラウドサービスは、一般的な VPC サービスに比べて、設定や操作が煩雑なのと、費用面のコストが見えにくいので、かなり躊躇している。

しかしながらインスタンス（CPU やメモリのスペック）切替が容易なところは正直魅力的だし、バッチを頑張って作れば、未使用時にはサービス停止して、費用節約も不可能ではない。

でもまぁ、さくらインターネットのVPC契約を１年契約にしてしまったため、とりあえず、解約時期までにEC2環境を整備しておこうかと考えているところ。

マイクラおじさん、はじめました。

最近この歳になって、VTuber にハマってしまい。
その影響で、今さら Minecraft にハマってしまい。

…この流れで察することができる人は、そこそこいるのではないかと。

という事で、今回は環境の話。

現在のマイクラには、C++でコーディングされた「統合版」（Bedrock Edition, 通称 BE）と「Java版」（Java Edition, 通称 JE）の２種類がある。
歴史的には「Java版」がルーツだが、ゲーム機やタブレット端末では「統合版」のみ利用可能、対して PC では「統合版」「Java版」の両方が利用できる。

なぜ「統合版」のみがスマホやゲーム機に対応したのか考えてみたが、おそらく Java Runtime Environment（JRE）がボトルネックになっているものと思われる。

Java とマイクラ（というかゲーム）は愛称が良くなかった

そもそも Java は、Oracle の方針など諸々の経緯から、現在「事実上」PC 向けのプログラミング言語になりつつあり、スマホなどのモバイル機器やゲーム機などの環境、特にゲーム分野においては距離を置かれつつある。

その理由として、 JRE（いうか Java）は、スマホやゲーム機の場合、原則としてハードウェア側に Java (JRE）が「別途」インストールされていることが前提となる。
この「別途」というのが曲者。
たとえば Java のバージョンアップに対応する必要が常に生じるわけで、デバイスによってはそれが難しい場合がある。
しかも Java は（表現の適切かは、さておき）「半分コンパイルしたプログラムを半分インタープリターで動かす」つまり「ランタイムプログラム」というアーキテクチャー上、動作時のメモリと CPU の負担が大きい。

Java 版のゲームプログラム側でこれらの差異を補完することは、できなくはないとは思う。
しかし当然ながらアプリ本体が巨大化するだろうし、レガシーな機種を意識する必要が生じてしまうため、ゲームの発展を考えると、それが「足枷」にもなってしまう。

オフィスなどの業務システムについては、今まで C/C++ 言語などでの生じていた開発コストが、Java の登場と発展によって削減されたり、オブジェクト指向の概念の加速化など、プログラミングの世界において貢献した点は色々とある。
ただゲームなどの機種（スペック）差や、挙動がシビアなソフトの開発には向かなかったという事だと思う。

JRE は際限なくメモリを喰う

メモリ制御が重い

Java においてもメモリ制御は、プログラミング次第で柔軟にできる。しかしながら、この処理が正直、重い。

これはマイクラのプログラミング上の問題でもあるのだが、たとえばマイクラは、一般的な RPG などとは異なりワールドの生成が、キャラクターの移動に応じて、動的に生成される。
このワールド情報、一度生成されてしまえばデータが保存されるので、それ以降はデータの読み込みのみになり、負担は下がるのだが、それでもメモリを大量に消費したり、解放する場面がある。

こういった場面は他のゲームでもあるとは思うが、前述の通り Java はランタイムプログラム経由という構造上、その処理がどうしても遅くなってしまう。

メモリを喰う

ただでさえ JRE の動作だけでもメモリを喰うのに、マイクラ本体を稼働させるのに、さらにメモリを喰う。

これをスマホやゲーム機など、性能差のあるデバイスで採用するのは、おそらく現実的ではなかったのだと思う。

そのため「統合版」は、C++ で作成され、かつ、各デバイス毎に対応したことにより、ラグなどを生じない形でのゲームを展開することができた。
おそらく、この選択肢がより現実的だったのだと思う。

ただし Java 版にもメリットがある

それは Java にすることによって、「有志」が独自の機能を追加することが容易になった点にある。

これは自前のサーバを立てることも可能にし、自前のサーバー上でワールドを構成、しかもマルチプレイをすることが可能にした。
しかも、それぞれ別々のワールドを、ポータル（穴）を経由して接続することも可能。
それ以外にも様々なプラグインなどが展開され、独自の拡張・発展を続けている。

ちなみに「統合版」も Microsoft が独自に提供している Minecraft サーバサービス等を利用しており、それを利用すれば、マルチプレイが簡単にできる。（ただし有料サービス）

さらに「統合版」の場合、様々なイベントや追加 Mod が提供されており、いわゆる大衆的なゲーム要素を公式が提供するという、本来のゲームサービスの姿となっている。

Java 版の未来

正直なところ、個人的には悲観的に考えている。

現在 Minecraft は Microsoft が買収し、サービスを提供している。
そして開発形態も、以前は「Java 版」でアップデートされた機能を、各デバイスなどのプラットフォーム版（「統合版」になる前の姿）に移植される形だったが、現在は「統合版」で実装された機能を「Java 版」に移植するという「逆の流れ」になってしまった。

これはおそらく、開発コストなどを踏まえた結果だと思うが。Java 版の開発が後発になった事に、正直不安を感じている。

「統合版」で実装された機能が「Java 版」で実現できなくなる未来

現時点でも「統合版」と「Java 版」の間では、細かな機能や挙動が異なる部分が既に生じている。
そもそも Java は、前述の通り、このようなスタイルのゲームの開発言語としては向かない、ボトルネックになっている事がという事が立証されている。これは今後致命的になると思っている。

「『統合版』だけあればいいんじゃね？」という流れに向かうのはとても自然な気がするのだが、この考えは杞憂なのだろうか。。。

駿河屋通信買取のポイント

追補記事として「駿河屋通信買取のポイント（2024年現在の追補・訂正）」を追加しました。

一部誤解している点あるかも。。。

駿河屋の通信買取の場合、「あんしん買取」の場合は３千円以上の買取、「かんたん買取」の場合は商品点数が３０点以上であれば送料無料。
ただし、いくつか守るべきルールがある。

「ゆうパック」の「着払い」で送る

ヤマトや佐川急便など「ゆうパック」以外で送付した場合、送料無料にはならない。

また、元払い（発送人が送料を支払った状態）で発送しても、送料の買取時精算はしてくれない。

100サイズ以上で送る

「あんしん買取」かつ３千円買取がほぼ確実な場合であれば、１００サイズ以下で送付しても問題はない。

必ず「１箱あたり３千円を余裕で超える額」を目安に送ること。

よく誤解されがちだが、「あんしん買取」の場合は「３千円以上の見積であれば、すべて送料無料になる」わけでではない。
品物の状態によっては買取額が「減額」されることだって十分にあり得る。
そして最終的に買取額が３千円に満たない場合になってしまった場合、送料が買取額から「天引き」されるおそれがある。

さらに「送付の際に適当な箱がなかったから」などの理由で複数口で送ってしまった場合にも、買取額が「１箱あたり1,500円」に満たない場合は、逆に送料が請求されてしまうので、注意。

大量の物品を送るときは注意

種類によっては、１回あたりの買取数を制限している場合がある。
よく確認すること。

個人的な心構え

気長にやる

「査定が遅い」「連絡がない」とかいうツイートなどをたまに見かけるが、こう言った短気または文句の多い方々には、心身によろしくないので、通信買取はお勧めしない。

買取依頼する品物の種類の量、繁忙期（コミケなどの大規模同人誌即売会の開催日前後）などにおける買取依頼の場合、見積提示が遅れたり、買取依頼（送付）してから、査定・買取額確定までに時間がかかることは、よくある話。
自分の場合、見積り依頼⇒買取完了まで最大１ヶ月近くかかった事もある。

個人的には通信買取は「忘れてても別にいいや」ぐらいの気長な感覚でやるのをお勧めする。

あまり高額買取に拘らない

中古買取全般で言える事だが、「自分の感覚よりも６５％ぐらい低い査定になる」と思っていたほうが、心のストレスになりにくいかと。

実際のところ、ニッチ。希少な品物であれば買い取り価格は高くなるが、駿河屋で取り扱っているマンガ・アニメ・ゲーム・同人という分野は、たとえニッチな品物であっても、需給が成り立たないような品物については、二束三文の買取になる。

それ以外にも、流通量が多いもの（たとえば同人の場合、大手サークルなど発行部数が多い作品など）や、紙製品の多い分野なので、品物の状態（劣化具合）など、場合によっては買取価格が付かないこともある。

基本的に中古買取に利益性は、ほぼ皆無

中には利益をあげるような「プロ」も確かにいると思うが、そういう特殊な人達の事を考えるのは時間の無駄。
あくまで「不要品を上手に処分する」程度で考えるのが良いかと思う。

買取ルールは絶対に守る

これは鉄則。

たとえば駿河屋で買取していない一般の生活雑貨や衣料品は送らないとか、買取依頼の書類は適切に準備する、適切な整理・荷造りを行う、などといった決まり事は必ず守るべき。
相手との商取引の効率を重視・尊重する点からも最も重要。

これは一般的な商取引でもそうなのだが、客は店よりも立場は上ではない。この点をはき違えている人は、商取引だけでなく、人とのコミュニケーションの在り方など、基本的な部分から考えを改めるべき。

あとこれもよく誤解されているが、買取を依頼するのは「個人」であるのに対し、買取店は会社であり「組織」である。
「個人」は小回りが効くし自由度は高いけど、会社や企業という「組織」は、ルールに則って運営されているものなので、個人に比べて自由度は低いもの。
よく自身の都合とか、自分が有利だったり、自分の効率を優先する形で物事を進める方がいるが、これらは往々にして迷惑なことが多い。相手の都合に配慮して取引をすることが必要。

まぁ「心象」だけでビジネスは成立してはいないけど、「心象」はビジネス上において重要なポイント。

「店頭買取」「通信買取」どちらを選ぶ？

正直なところ、何とも言えない。
なので以下は、あくまで個人の推測。

商業作品の場合であれば、買取相場をオンラインで確認することも可能だと思う。ところが同人作品のように、バーコードや商品コードのないような物品の場合、いちいちオンラインでは査定していないのではないかと思う。

そうなってくると、店頭の買取担当者の「目利き」に一存することになってくる。
別に店頭買取担当者の「目利き」を疑っているわけではないが、担当者だって人間である。個人差として習熟度や得意不得意はあるはず。

これは、おそらく通信買取でも同様の状況が生じているとは思う。
ただし通信買取の場合、「目効き」のスタッフが複数人いる場所での査定を行っているはず。
その場合、たとえ習熟度が低かったり、不得意分野のスタッフが査定にあたっていても、熟練・得意分野のスタッフに確認しやすいと思うのは、邪推だろうか。

確かに送料の問題はあるが、その点を考えると、通信買取のほうが高額になる可能性は高いかと。

自分なりのベストプラクティス

「あんしん買取」に「かんたん買取」を追加して通信買取する

駿河屋には「あんしん買取」という買取額の事前見積するシステムがある。
これは買取を依頼する側（つまり我々自身）が、駿河屋の買取Webを使って検索し、買取依頼する品物の査定額を調べてから、その内容に沿って送るというもの。
（ただしこの時点での査定額、あくまで買取予定額。実際の買取額は、品物を送付して状態を査定してから決定となる。状態が悪いなどの理由で実際の買取額が減額されることはある）
これを使えば、買取最低額はクリアできるし、現実の買取相場も把握できる。
（幻想を抱かずに済むという意味も、多分にある。）。

その点を利用して「あんしん買取」でおよそ１万円分の品物を準備。残りは「追加分」として、それ以外の品物と一緒に箱詰めして送っている。

しかしながら「同人作品」などをはじめとして、品物にJANコードや商品型番などが付属していない品物もある。
それに「そもそも検索するという『手間』」も含め、買取検索の利用には「限界」がある。
なので、自分の場合は、１回の発送（１箱分）あたり５千～１万円前後を目処に「あんしん買取」の品物を設定している

「あんしん買取」には「追加分」として「かんたん買取」依頼品を同梱することが可能

個人的には、上記「あんしん買取」の買取金額を目処に買取を依頼。
実際に送付する際には「かんたん買取」の「追加分」を含めて大きめなダンボール箱に同梱して、発送している。

通常「かんたん買取」のみで発送した場合、３０点以上の買取であることと、買取金額が1,500円未満だと、送料が請求されてしまう恐れがある。
しかも「かんたん買取」は、事前に買取金額が判らないからので、発送時点で送料がかかるかどうかも不明。

これを回避するため「あんしん買取」で送料無料となる３千円をクリアし、そこに「かんたん買取」分を追加することで、なるべく多くの品を一度に発送できるようにしているというからくり。

若干面倒なように見えるが、同人グッズなどをはじめとする買取価格を検索しても見つからないような品物については、この「追加分」として同梱することで手間を省略し、なるべく多くの品物を一度に送って買取を依頼することができる。

ちなみに「買取検索」でヒットしないものは、個別に問い合わせて買取金額を確認することができる。
だが、同人グッズのような品物を個々に問い合わせて金額を確認することは現実的ではないし、往々にして「現物確認しないと査定できない」「０円買取」と言われるのがオチなので、手間を考えると、とっとと送ってしまうのが良いと思う。

箱は最大100サイズ超ぐらい、重量 20kg 前後を目標

若干大きめではあるが、容積や箱の運搬などを踏まえると、これ位のサイズが最も現実的ではないかと思っている。
自分の場合、近所の小さな郵便局に持ち込んで発送しているのだが、窓口や保管場所が大きくないし、ほぼ女性職員で占めるため、検量などで手持ち可能な限界として、このサイズ・重量に配慮して送っている。

発送物によっては、このサイズ・重量にならない場合もある。あくまで目安。

ゆうパックは30kgまで遅れるのだが、20kg超えると、いよいよ１人では持ち運べなくなってくる。それぐらいの重量。

ちなみに小学1年生手前の平均体重が20kg。成長面において「だっこ」の限界ライン。
（20kgだって結構な重さがあるし、個人差によって持ち上げられないとは思うが。。。）

同じ品物は送らない

単なる「記憶違い」や、同人の場合は「共同購入などのミス」によって、品物をダブって購入所持している場合がある。
この場合、同じ品物を送らないように配慮すること。

複数個の同一品を買取依頼した場合、店からしてみれば「不良在庫」に繋がるリスクが生じる可能性だってあるわけで。
その点から買取金額が下がったり、場合によっては買取不可となる可能性もあるので注意。

「あんしん買取」の見積依頼は月金土日曜日に出す、祝日にも注意

見積依頼を出してから見積金額が表示されるまで、概ね２日～４日ほどかかる。

あくまで経験からの「およそ日数」。
買取窓口が繁忙なタイミングによっては、それ以上かかることもある。

あとこれが大事なのですが、見積金額が提示されてからは５日以内に荷物を必着させないと、見積金額での買取が保証されなくなる。
しかも最終的に提示される買取金額も、個々の買取金額ではなく、総額表示のみになってしまう場合あり。

この辺を加味すると、火水木曜日あたりに見積依頼した場合、回答が週末に掛かってくる可能性が生じる。
そうなると郵便局が休業日のため月曜日まで発送を待つ必要が出てくる。
結果、その影響により「５日以内の必着」に遅延するリスクが発生する。

なので、この曜日のタイミングにも十分注意すること。
同じ理由で年末年始やゴールデンウイークなどのタイミングにも十分注意。（自分は連休に見積依頼することは避けている）

でも、たとえ５日以内の必着から遅れたからと言って、経験上「１日程度」であれば、総額表示の買取にはなってしまうものの、ほぼ買取金額に近い金額での買取になると思う。
（こんな「つまらない事」で客と揉める気は、店にはない思う。。。）

ただし、相場が日々変化するような品物、例えばコミケ直後の同人誌や、入手困難な最新ゲーム機器など、「転売ヤー」の餌食になりそうな品物の買取の場合は別の話。
タイミングに左右される品物の買取において遅延して、買取価格が安くなってしまうのは、買取を依頼する側の自己責任。