マイクラ 1.18.1 の話

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

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

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

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

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

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

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

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

鉱石分布の変更

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

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

雨・雷雨が頻繁になった

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

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

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

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

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

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

オオカミの字幕が変?

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

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

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

また以前は他のブロックの先にある音が、結構数ブロック以上離れた遠い距離からも聞こえていたものが、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 1Gプラン(今ここ)

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

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

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

結論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

現在のマイクラには、C++でコーディングされた「統合版」(Bedrock Edition, 通称 BE)と「Java版」(Java Edition, 通称 JE)の2種類がある。
歴史的には「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 は、前述の通り、このようなスタイルのゲームの開発言語としては向かない、ボトルネックになっている事がという事が立証されている。これは今後致命的になると思っている。

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

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

今後加筆修正する可能性があります。
あと一部誤解している点もあるかも。。。

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

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

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

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

100サイズ以上で送る

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

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

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

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

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

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

個人的な心構え

気長にやる

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

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

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

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

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

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

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

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

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

買取ルールは絶対に守る

これは鉄則

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

同じ品物は送らない

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

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

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

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

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

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

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

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

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

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