投稿者: かず

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

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

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

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

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

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

    アプデの話

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

    Forge

    41.0.100 の話

    1ヶ月経過してもβ版

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

    やっちまった

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

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

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

    OptiFine との同居不可

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

    追加された仕様とかの話

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

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

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

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

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

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

  • エアコンの室外機、冬場は凍結することがある

    エアコンの室外機、冬場は凍結することがある

    少し古い記事ですが、良記事なので。

    そもそもエアコンは、室外機で室内と屋外の温度差を熱交換して冷やしたり暖めたりするので、そもそも気温差のない状態では熱交換の効率が悪くなるため、冷えにくくなります。

    そして「冷えにくいから」と言ってエアコンを強くしたり、長時間運転すると、今度は室外機本体や廃熱フィンなどが温度差によって結露し、これが結氷に繋がりエアコンの効きが悪くなったりします。

    この室外機の結露⇒結氷による「効かない」トラブル、冬場は特になりやすく、暖房運転・雨天・高湿・などでも発生します。

    でもって対策ですが、正直あまりオススメな手段はないです。
    例えば、室外機を大型なものにしたり、業務用にすれば、低能力で稼働するようになるため、これらのトラブルは減少しますが、高額です。

    室外機にお湯をかけるのは、結氷を溶かす効果が一時的にありますが、気温・天候次第で今度はかけたお湯が冷めて、そのまま結氷するし、そもそもお湯との温度差が金属の膨張収縮を促すことになり、場合によっては故障や低寿命に繋がります。

    結局のところ、窓を開けて外気を直接取り込むのが一番良いと思います。

  • 動画を見て思ったこと。

    今回の話題、資本主義というか人間社会であるなら、どこでもある話ではないかと思います。

    権力を有する者と技術知見を有する者とのバランスというのは会社組織だけでなく、ちょっとした仲間関係から国家レベル、資本主義・共産主義など、社会ではどこでもある話ではないかと。

    自分も技術者・知見者の端くれとして人生を送ってきましたが、様々な会社と話をしてきました。
    結局のところ、経営を全面に出すと技術知見を有する人が離れていく傾向が多い気がした。その原因は、技術知見者の意見を尊重したり、関係をはじめとしたバランスを保てなくなることが、ほとんではないかと思う。
    とはいえ技術知見者側の性格というか(言葉は悪いが)偏屈な方も多いので、正直お互い様であるような気もする。

    とは言え、いずれにせよ所属している会社であれば、個人的には一緒に仕事できるか、できないかという話に行き着くのではないかと。
    個人も会社を選ぶ権利はあるので、デメリットはそれなりにあるかもだけど、究極(?)としては、最終的に伸るか反るかの判断は、自分にあるわけで。

    翌々考えてみると、ごく当たり前な話ではあるんですが、その「ごく当たり前」を自分自身、見失うことがあるんだよなぁ(感慨)

  • BkBsfilWrapper

    Becky! でスパムフィルタを実現するためのプラグイン。
    公開されてからかなり経過してるのと、フィルタのコアとなる bsfilter を最新(とはいえ、こちらもかなり前)のものを使おうとするとインストールの際に Ruby もインストールする必要があるなど、若干クセがあるので、備忘録がてら記事にした次第。

    同じ bsfilter ライブラリを利用したプラグインとして、bkbsfilter なるものも以前あったようだが、こちらはサイトが閉鎖された模様。
    おそらく現在で bsfilter を利用した Becky! プラグインの唯一なものではないかと。

    インストール手順などは上記プラグイン配布元の解説があるので、そちらを参照の事。

    上記サイトとは別に bsfilter、さらに bsfilter の最新版を利用する場合は Ruby もインストールする必要あり。

    上記サイトから最新版をダウンロードすればよいかと。

    Ruby のインストール手順については、別途ググってインストール。
    ただしインストールの際は、Ruby 2系を使用すること、最新バージョンの Ruby 3系は不可。

    Ruby 2系を使うこと、Ruby 3系だと正しく動作しない

    bsfilter 自体が 2系時代(しかも初期)に作成されたもの。
    そして Ruby は2系 ⇒ 3系になった際にサポートされなくなった機能(仕様? 文法?)があるようで、それらが影響しているのかはわからないが、bsfilter スクリプトが途中でエラー終了してしまう。

    これらは Becky! に bkbsfilter プラグイン導入後して動作させると、受信時の動作が明らかにスローダウンするうえ、フィルターに一切引っかからないなど挙動が起こすので容易に分かる。
    もしこの挙動が確認されたら、Ruby のバージョンを疑うこと。

    ちなみに Ruby 3系と2系を同一マシンにインストールしても問題なさそう。
    BkBsfilWrapper 上で使用する Ruby は、プラグインの設定内でプログラムパスを直接指定する設定する。そのため環境変数 Path の影響を受けないように実装されている。

    もし開発環境としてRuby 3系を利用している場合は、別ディレクトリに Ruby 2系をインストールすれば同居可能。
    (同居については、この記事の主体ではないので省略。2系⇔3系の切替方法や Path の変更方法など色々調べたうえで、自己責任で。)

    Ruby 2系のバージョン

    執筆時点での Ruby 2系のバージョンは最新版の 2.7.5 を利用しているが、今のところ動作に問題はなさそう。

  • マイクラ 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 ではかなり近くのブロックに来ないと聞こえなくなった気がする。

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

    水流

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

    溶岩

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

    マップについて

    マイクラはプレイヤーの移動にあわせて、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 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 は、前述の通り、このようなスタイルのゲームの開発言語としては向かない、ボトルネックになっている事がという事が立証されている。これは今後致命的になると思っている。

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

  • 三重、弾丸帰省。再

    実家のオヤジが退院したのだが、頸椎の疾患の影響で、寝たきりではないけど、歩行困難(移動は基本、車イス)など、介護が必要な状態なったので、様子見にレンタカー弾丸帰省することに。

    これはその際の記録。

    オヤジは元々持病もあるので、この先のことは判らないけど。
    まぁ「それはそれ」、別の話という事で。

    レンタカーの話

    以前は近所にトヨタレンタカーがあったので、複数日利用とか商用車利用の際はそちらを使っていたが、閉店してしまい。

    もともと自分が住んでいる場所には、レンタカーやらカーシェアスポットが多いので、競争率は高い。

    そんな中、トヨタレンタカーはメーカー系ということで、車両を準備する能力は高いのだから、本来であれば、ディーラーを利用するなどして駐車場確保さえできれば、最強のレンタカー業者になれるはず。

    でもどのメーカー系レンタカーがそれをやらないのは、おそらく「レンタカーの普及=新車が売れない」というジレンマを抱えているからだと思う。

    そのため今回は、ニッポンレンタカーをはじめて使ってみた。
    まぁ老舗チェーンなので、トヨタレンタカーとサービス自体は遜色ないのだが、予想通りというか、カーナビが使いにくかった。

    カーナビ

    ニッポンレンタカーは基本、ECLIPSE(デンソーテン)のカスタマイズ品(機能制限版)を採用しているのだが、カーシェアを使っていると carrozzeria (Pioneer) が搭載されていることが多い。

    そのため純正も含め、他社製品のカーナビは、どうしてもUIの使用感が異なるため、まずこれが使い難く感じてしまう。

    しかもニッポンレンタカーの場合、機能制限が結構キビしいのか、ナビそのものの仕様なのかは分からないが、色々と細かな調整ができない。
    たとえば、オート・サウンド・レベライザー(車速・走行音に応じて音量を調整する機能)などが調整できなかったり、(こちらもナビの所為なのかは不明だが)ラジオが聞き取りづらくなる場面が多かった。

    特にラジオの性能については、carrozzeria ではそう感じる事が少なかっただけに、残念な気がした。

    でも最近は、ラジオ聞かない人も多いのか?
    だからメーカー自体も性能追求が適当になってるのかも?

    利用した車種

    シエンタ、7人乗りのタイプ。
    シエンタはフルフラットシートにできないものの、コの字型に畳んで、床面や荷室部分を荷物やクッション等で埋め、厚めのマットを入れれば、座面は斜めにはなるものの、就寝可能。個人的にはコレでかなりイケる。

    でも最近は5人乗りタイプ FUNBASE もある。
    こちらのほうはセカンドシートが凹み収納でき、フルフラットになるうえ、室内高も稼げることもあり、居住性は高い。

    ちなみに就寝定員は、5ナンバー車の場合は大人2名が限界。個人的には1名で贅沢快適に使うのがベスト。

    仮眠であれば、座席定員のままでもイケるかもだけど、そこそこ快適な就寝を目的とする場合、既成車両での就寝はかなり限界がある。

    大人2名+未就学児1名ならアルファードなどの3ナンバー車、それ以上の車中泊の場合はキャンピングカーをレンタルしたほうが良いと思う。

    またシエンタは、レンタカーとして大量に導入された時期のモデルの場合、クルーズコントロールが標準装備されていない。そのため運転は普通に必要。(最新モデルは知らん)

    ガソリンとか燃費とか回転数とか

    普通車の場合、関東⇒東海圏超えたあたりで給油が必要なのだが、シエンタも概ねそれに沿ったレベル。片道で1度給油が必要。

    ちなみにカタログ燃費で20km/L前後のところ、高速道の巡航走行で15km/L前後だったので、これもほぼ想定内の結果。

    高速道のエンジン回転数は、新東名の 120km/h 巡航走行 で 2000rpm 強で安定する。

    帰りは中央道経由で戻ってきたのだけど、坂道などでも、それほど気後れするような挙動はなかったと思う。
    とはいえ3ナンバー車や走り重視の車ではなので、それらに比べれば加速は劣るけど、別に困るほどでもない。
    「速い車は、とっとと抜いていけ」というスタンスで車線を譲るメンタルで運転すれば問題ない。

    ちなみに今回は自分1人だけの移動で家族乗車がなかった。
    そのぶん荷重も少なかったから、運転も快適だった可能性もあるのかも?

    準備まわり

    セットアップに時間がかかる

    仮眠前提の装備で出発するときは、いつもそう。永遠の課題。
    夜間の仮眠のため、寝具やシェードなどはアウトドア並みの機材を持ち出した。
    そのためセットアップにどうしても手間がかかってしまい、出発が遅れてしまった。

    この辺り、前準備をもう少しできないか試行錯誤してるのだけど、なかなか難しい。

    忘れた物

    虫刺され薬

    車には必須。虫除けスプレーしてても、蚊には刺されます。対策してても刺されるときは刺される。
    なので、小さくても1つないと困ります。

    あったほうが便利なもの

    虫除け機器

    「どこでもベープ未来」とか「カトリス」とか。
    人体用の虫除けスプレーは持ってたけど、衣類や肌がベタ付くので、それとは別に虫除け機器もあったほうが良い

    ちなみに屋外(キャンプなどの完全アウトドア)であれば蚊取り線香もいい。
    でも今回は車内で使うので、非加熱・非ボンベ式のものが良いかと。

    スペースクッション

    寝台にする際、座面以外の部分にクッションなどの「詰め物」がないと、マットレスが沈んでしまい、具合が悪い。
    荷物などがあればそれを詰めれば良いけど、そうでない場合は、空気で膨らませることができるクッションなどあったほうが良いかも。

    充電式空気入れ

    マキタ MP100DSH が気になっている。(やり過ぎ)
    クッションを膨らませる際に便利。

    フロントカーテンを抑えるための小道具

    仮眠用にカーテンを所持しているのだが、フロントガラス用カーテンは傾斜に合わせて、斜めに抑える道具が必要と感じた。

    まぁ小物類の収納をうまくやって、就寝時はそれらをダッシュボード上に設置できれば良いとおもうので、その方向で検討してみようかと。

    持っていかなくても良かったもの

    パソコンまわりの小物

    事前にバタバタしたため、厳選できなかった。
    コード類やUSBメモリ、マウス、モバイル機器など、もっとスマートにしたい。

    次持って行くもの

    ビデオカメラ用の架台

    ダッシュボード上固定用。
    以前購入したものが、使用開始5分で雲台下の部分がへし折れた。
    そのため急遽架台を撤去し、カメラをダッシュボード上に直置き。でもそのままだと車の動きでカメラが暴れてしまうので、滑り防止に小物を置いてみたが、結局暴れてしまい、複数回映像が傾いてしまった。

    次回購入の際は、ビデオカメラは重いので、ちゃんとした土台を購入したほうが良さそう。

    余談

    新東名の3車線化、全線120kmは強力

    3車線化が整備された効果は、やはり大きかった。

    今回は深夜帯の走行に終始したので日中の状態は分からないが、深夜帯はトラックが多く、乗用車はかなり少ない。
    そのため以下の「暗黙のルール」が確立されている状態になっていると感じた。

    • トラックは第1第2走行車線をほぼ占拠。
    • 120km 走行が容易な乗用車は、ほぼ追越車線走行。
    • 後方から高速車が来たら、追いつかれる前に第2走行車線に退避する。
      速い車とは張り合わない。とっとと退避して、先へ行かせる。「事故ろうが捕まろうが自業自得、知らん」のスタンスが大事。

    ただし新東名は長距離区間ということもあり、また開通後の微調整なのか、工事している場所も多い。
    そのため2車線、場合によっては1車線になる事もあるので、交通情報や前方には常に注意する必要がある。

    それに夜間でも交通量がそれなりに多い。
    中には「何をしたいのかよく分からない」運転をする車両は何処にでもいるので、その辺は注意が必要。

    今回仮眠した場所

    新名神、鈴鹿PA(下り)

    深夜到着・夜明け前出発なら大丈夫かも知れないが、普通車の仮眠は、正直お勧めできない。
    理由としては、盛り土をした高台に設置されたPAだから。
    朝日をモロに浴びるし、それを樹木がほぼ一切ない。
    そのためエンジン停めたままでは、とてもじゃないが、室温が急上昇し寝ていられないくなる。

    仮眠するなら、湾岸長島PAがオススメ。
    こちらは駐車場周辺に樹木が植生されてるし、高台ではないので。

    中央道、小黒川PA(上り)

    山間部かつ大型車が駐車できない「離れ」の駐車帯があるので、個人的には、かなりお気に入りの仮眠場所。

    最近SICが設置され、その影響で「離れ」の駐車帯が減ったうえ、SIC利用者が意外に多いので、以前にくらべれば静粛性は減った。
    ただそれでも、まだ個人的には便利に使わせて貰ってる。

    ただし夜間は売店等が閉まるので、自販機(飲み物)以外の食料調達が困難になるのが難点。
    あとハイシーズンや週末は、おそらく利用者が増える。そのため「離れ」に駐車できない場合もある。

    ちなみにこのような「離れ」や「樹木植生」があって、仮眠し易いPASAはいくつかある。個人的には以下が候補。

    • 北陸道、黒埼PA(下り)(新潟、離れ)
    • 上信越道、妙高SA(上下、離れ)
      (冬期は積雪のため、おそらく利用できない)
    • 東関道、酒々井PA(上下、植生)
    • 中央道、双葉SA(上り、植生)
    • 東名、富士川PA(下り、植生)

    ただし雨天荒天時は、木々から落ちる雨粒音がうるさいので、あくまで天候次第。
    個人的に天候が悪い場合は、宿泊施設か某満喫チェーンを利用。