カウンター

  • 26549総訪問者数:
  • 6今日の訪問者数:
  • 55昨日の訪問者数:
  • 40一日あたりの訪問者数:
  • 0現在オンライン中の人数:
  • 2014年9月21日カウント開始日:

SkyBlocks

SkyBlockの導入が出来ないか検証してみた。
どうしてこうマルチサーバ前提に作られていないのか・・・

  ワールド 前提 報償 他ワールドと
インベ分割
JoeSkyBlock v1.0.4 自動生成
(自作も可)
有り
(必須では無い)
無し 出来る
uSkyBlock v.0.9.6 自動生成 無し 有り 出来ない
Mini-SkyBlock v0.2 今居るワールドに作る 無し 有り 出来ない
askyblock V2.5 自動生成 無し 有り 出来ない
IslandWorld v4.5 事前に生成 有り 有り 出来ない

 

Joe's SkyBlock

非常にシンプル。報償は無いが、SkyBlockへの参加・戻り時のインベントリの棲み分けがちゃんと出来てる。
flyやEnderChestの使用禁止、土地の保護も出来てる。
死んだときにSkyBlockと非SkyBlockのインベントリが逆転してしまうバグがあるのが致命的。

uSkyBlock

SkyBlock onlyのワールドしか作れない

Mini SkyBlock

要するに今居るワールドに小さい島を作るだけ。ぶっちゃけ、プラグインが無くても作れる。
報償機能が便利な程度

A SkyBlock

GUIメニューがあるなど機能としては完成度が高い。
他のワールドとは棲み分けが不可。

IslandWorld

Dynmapとの連動など非常に高度。
Skyblockとしての出来は良いが以下の事ができない

  • SkyBlockへの移動・戻りができるが、インベントリの中身を棲み分けられない(単純に消すのは出来る)
  • ワールドは事前に作成

プラグインResidence

プラグイン:Residence_v2.6.6.6.jar
サーバ:spigot-1.7.10-R0.1-SNAPSHOT_1641.jar

ResidenceはTownyのような町作り系のプラグインですが、Townyよりシンプルかな。結局使わなかったので、簡単にご紹介だけ。

使い勝手的にはWorldGuard(region)の逆という感じ。

どういうことかというと、regionは保護されてない土地に対して範囲を指定して保護するプラグインだけど、Residenceは保護されている土地に対して自分が使いたい土地を範囲で取得する感じです。なので、regionとTownyのいいところを両方持ち合わせている感じですね。

  • regionと同じ感じで細かく範囲を指定できる(Townyはチャンクだけ。Residenceはチャンクを範囲で指定もできるし、特定の立方体範囲もできる)
    しかも、WorldEditCUIにも対応してるみたい。
  • 初期状態でワールドでの建築を拒否にしておけば、事実上荒らしの被害を受けない。(許可しない限り他者に建築を許可しないし、範囲を指定しないと自分自身も建築できないから)。この辺はTownyのメリットと同じ。

シンプルさではTownyよりも使い易いんだけど、必ず初めに範囲指定しないと建築できない煩わしさはTownyと同じで、管理者としては気にしなければならないポイントですね。デフォルトでワールド建築許可にしたらregionと何も変わらないし。

regionよりも安全に、且つTownyほど複雑にしたくないなら、間違えなくこれを選択した方がいいです。

ぬるぽ(エラーとの付き合い方)

 ∧_∧    
 ( ´∀`)< ぬるぽ 

  ( ・∀・)   | | ガッ 
 と    )    | | 
   Y /ノ    人 
    / )    <  >__Λ∩ 
  _/し’ //. V`Д´)/ 
 (_フ彡        / 

マイクラサーバを運用する上で欠かせないのがプラグインやModだと思いますが、旨く動かないことも多いので、これらとどう付き合って行くかがマイクラサーバ運用の肝の一つだと思います。
本当はプラグインのソースまで読めればベストなのですが、さすがにそこまでは厳しいという人も多いと思いますので、エラーメッセージの読み方についてつぶやいてみます。

とても難しい内容だと思ってますが、サーバの管理をするなら避けては通れない道だと思うので、がんばって理解してみて下さい。

Javaとマイクラ

まず、マイクラサーバの仕組みを紐解いてみます。マイクラサーバはJavaで動いてます。なので、Javaとマイクラサーバがどのように関連しているかを知ることが大切です。
※このイメージが出来てないと、エラーログの意味がわからないので。

JavaはSun マイクロシステムズが・・・そんなことはどうでもいいや。一言でJavaと言いますが、プログラム言語、実行環境、開発キットを示す場合があります。なので、言葉の意味について整理してみましょう。

  • Java言語・・・プログラムを開発する為のプログラム言語。
  • Java実行環境(Java Runtime Environment/JRE)
  • Java開発キット(Java Development Kit/JDK)

なにそれ?って感じですが、プログラム言語については多くを語る必要は無いと思うので割愛します。
JDKに当たる物は別にJava特有では無く、Java以外の言語にもあるので珍しい物ではありません。要するにプログラム開発者向けのパッケージです。ただ、Javaの場合、開発者だけでなく使用者へ求められる場合も希にあります。JDKには(たしか)JREも含まれてるので、JDKがあればJREは不要だったはずです。(おぼろげ)

重要なのはJREです。
マイクラを代表とするJavaプログラムは、Windowsだけでなく、Unix/LinuxやMacでも動きます。本来これはOSの仕事でありつつも非常に難しいことで、Windowsが登場する以前は、ハードウェア毎にソフトウェアが売ってたくらい難しいことです(例えばNECパソコン用のゲームとか)
OSが進化することで、このようなハードウェアの違いをOSが緩和してくれてますが、やはりWindows専用ソフト、Mac専用ソフトが登場しています。
Javaは、そういったOSの違いを緩和してくれることを主軸に作られたプログラム言語なんですが、そのOSの違いを緩和する仕組みとしてJVM(Java仮想マシン)というのが存在してます。そういうJavaプログラムを実行する環境がJREです。

だからそれが何か?と思われるので、マイクラなどを含めたJavaプログラムの実行環境を絵面にするとこんな感じになる訳です。
minecraft_env
JDKはJREなどを含めた開発者向け便利ツールで、本来的には実行そのものに影響する物では無いので、ここでは省略します。

前述で、OSはハードウェアの違いを無くし、JavaはOSの違いを無くすと書きましたが、要するに、プログラムとハードウェアの間に立ってお互いの翻訳してるだけです。これと同様に、マイクラサーバにはプラグインを導入できませんが、これはBukkitやSpigotが間に立ってやり取りをしてくれているからなんです。

JREが重要というより、この構造が後述でもとても重要な意味を持ってくるので、ざっくり理解しておいて下さい。

そもそもエラーって何?

まぁ、プログラムが旨く動いていないことなんですが、エラーについても少し深掘りが必要です。
サーバの動作がおかしいときはだいたい以下の様な「ERROR」表示がでます。出ないで落ちる時もあります。

[10:53:10] [Server thread/ERROR]: Could not pass event BlockBreakEvent to HawkEye v1.6.2 org.bukkit.event.EventException
        at uk.co.oliwali.HawkEye.listeners.HawkEyeListener$1.execute(HawkEyeListener.java:60) ~[?:?]
        at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:62) ~[spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at org.bukkit.plugin.SimplePluginManager.fireEvent(SimplePluginManager.java:509) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:494) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.PlayerInteractManager.breakBlock(PlayerInteractManager.java:264) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.PlayerInteractManager.a(PlayerInteractManager.java:192) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.PlayerConnection.a(PlayerConnection.java:565) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.PacketPlayInBlockDig.a(PacketPlayInBlockDig.java:41) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.PacketPlayInBlockDig.handle(PacketPlayInBlockDig.java:65) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.NetworkManager.a(NetworkManager.java:186) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.ServerConnection.c(ServerConnection.java:81) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.MinecraftServer.v(MinecraftServer.java:734) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.DedicatedServer.v(DedicatedServer.java:289) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.MinecraftServer.u(MinecraftServer.java:584) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.MinecraftServer.run(MinecraftServer.java:490) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at net.minecraft.server.v1_7_R4.ThreadServerApplication.run(SourceFile:628) [spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]Caused by: java.lang.NullPointerException
        at org.bukkit.craftbukkit.v1_7_R4.block.CraftBlock.getRelative(CraftBlock.java:179) ~[spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at org.bukkit.craftbukkit.v1_7_R4.block.CraftBlock.getRelative(CraftBlock.java:175) ~[spigot-1.7.10-R0.1-SNAPSHOT_1649-20141001a.jar:git-Spigot-1.7.9-R0.2-207-g03373bb]
        at uk.co.oliwali.HawkEye.blocks.BedBlock.getCorrectBlock(BedBlock.java:48) ~[?:?]
        at uk.co.oliwali.HawkEye.listeners.MonitorBlockListener.onBlockBreak(MonitorBlockListener.java:49) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor206.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_65]
        at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_65]
        at uk.co.oliwali.HawkEye.listeners.HawkEyeListener$1.execute(HawkEyeListener.java:57) ~[?:?]
        ... 15 more

エラーの出方も様々で、多量に出る物や、1回出た後に何事も無く 動き続けるもの、プラグインが切り離される場合など様々です。
ログにはいろんなタイプのエラーが出ますが、実はこれはエラーでは無く、例外処理と言います。一行目の末尾に「Exception」と書かれていますが、これを直訳すると「例外」です。
BukkitやSpigotのプラグインで出るエラーはほぼこの「例外処理が発生した」と言ってます。あるいはクラッシュしてダウンすることもありますが、それは後で書きます。

例外処理って何?ってことなんですが、本来エラーとはプログラムがそれ以上動作できない様な事象のことを指します。例えばコンピュータは「10÷0」という計算をすることが出来ないんですが、それをやらせるとエラーで止まります。(パソコン付属の電卓などでも出来ないので試してみるとわかりやすいかも)
「エラーで止まる」と一言で言いますが、これは大変なことで、最近のパソコンではいくつも同時にプログラムが動いてますが、これら一つでもエラーが起きるとパソコン自体が止まることを意味します。Windowsなんでしょっちゅうエラーが出るので、その度に止まってたら話になりません。
例外処理というのは、プログラムの途中で想定外の事が発生したことを見越して、その想定外が発生したらその種類毎に問題を解消する処理をさせる処理のことを言います。
絵に描くとこんな感じです。

minecraft_exe

なので、プラグインのエラーはほとんどが「想定外のことが起きたよ」と言ってるだけで、その想定外の内容を知らせてくれてるだけです。
問題なのは、Java以外にもこの例外処理というのが使えるのですが、最近は「例外処理が発生することを見越してプログラムする」ということも少なくないので、短絡的に「エラー→ダメ」とは言い切れない実情があります。

何が起きたかを掴む(マイクラクラッシュ編)

さて、話をマイクラに戻しますが、要はエラーなどのログから、何が発生したかを掴めれば、対処がしやすいかも?ってことです。
本当は、何故例外が発生したか、それに対してどうしたかまで掴めればいいのですが、そこまで理解するのはちょっと難しいです。少なくとも後者はプログラムを読まないとわからない事が多いですしね。

先ずは上記の例外処理の例に行く前にマイクラ自体の「クラッシュ」について語ってみます。
例外処理というのは「例外処理というプログラムが動いている」ので、そもそもプログラムが止まっている訳ではありません。マイクラサーバ自体が止まる(クラッシュ)というのはつまり例外処理すらできなくなった、あるいは例外処理の中でプログラムの続行が不可能と判断された場合です。
つまり、どこで問題が起きているかというとここです。

minecraft_env2

プラグイン自体がマイクラプログラムを止める時もありますが、それはそれでログに出ますが、よほどの事が無いとそんなことはしないでしょう。
私が経験したのでは、

  • ハードウェアがぶっ壊れてた。
  • OSの動きの問題(すごく重い・メモリが足りない)。

と言うのが大勢です。ハードウェアについてはマイクラの挙動に関わるのはCPU、メモリ、マザーボードくらいなので、その辺を怪しむべきですね。ちなみに1日3,4度サーバがダウンすることがありましたが、そのときはマザーボード(メモリスロット)の故障でした。この辺はmemtest86などの検査ツールが便利ですよ。
ちなみに「Javaのバグ」や「Javaがちゃんとインストールされていない」の可能性もありますが、私はまだ当たったことがありません。

あと、ForgeやModはインストール時にマイクラのプログラムを置き換えるようなことをするので、プラグインにおけるBukkitやSpigotのような緩衝材となるプログラムが存在しません。だからこれらの致命的なエラーの場合は誰も緩衝材になってくれないのでマイクラ自体が止まることも多いです。

何が起きたかを掴む(プラグインの例外処理編)

マイクラサーバの動作は以下の様にループしてて、イベントが起こり都度処理をする仕組みになってます。

minecraft_event

イベントというのは例えばマイクラの中で場所を移動したりとか敵に攻撃したりとかそういうことです。処理は、場所の移動、ダメージの計算などです。
同じ例外処理のメッセージが多量に発生するのは、つまりこのループの中でエラーが発生し続けていて、それを解消できていないということになります。

問題はその「イベント(切っ掛け)」が何なのか?なんですが、単にプレイヤーが移動したとか、Mobが移動したなど、いろいろ考えられます。
逆に1回しか出ない例外は、コマンドの実行に起因してたり、1回の例外で復旧できた(例えばプラグインの切り離しもそう)場合です。

早速、例外処理の読み方を見ていきましょう。上の方に書いたメッセージの読み方です。

先ず、一行目にどういう例外処理が発生したかがメッセージとして出ます。

[10:53:10] [Server thread/ERROR]: Could not pass event BlockBreakEvent to HawkEye v1.6.2 org.bukkit.event.EventException

これはHawkEyeというプラグインで、BlockBreakEventが失敗したという例外処理「org.bukkit.event.EventException」が発生したという意味だと思います。
本当にプログラムに精通した人じゃ無いと正確な意味はわからないので、文言から何が起きたかを予測してみましょう。
HarkEyeというプラグインはプレイヤーの挙動をデータベースに記録していくプラグインで、当然ブロックを壊した際にもその記録がされます。だから、それが失敗したんでしょうね。

これだけでもある程度原因を調べられそうですが、二行目以降も見ておきましょう。

at uk.co.oliwali.HawkEye.listeners.HawkEyeListener$1.execute(HawkEyeListener.java:60)
at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:62)
~略~
at net.minecraft.server.v1_7_R4.PlayerInteractManager.breakBlock(PlayerInteractManager.java:264)
~略~

大分省略しましたが、一番目の行がエラーの発生箇所を示してます。HawkEyeListener.javaというプログラムの60行目でエラーが出ましたよという事です。
ちなみに「uk.co.oliwali.HawkEye.listeners.HawkEyeListener」とか「org.bukkit.plugin.RegisteredListener.callEvent」とかというのは、Javaというプログラムはプログラムを部品として開発して結合して動かす仕組みを取ってますが、そのプログラム部品の名前です。プログラム部品の名前が被ると困るので、頭にURLを逆にしたような文字をひっつけることが推奨されてます。私がJavaプログラムをつくるとしたら「jp.d77.云々」って名前になるんでしょうね。

プログラム部品がプログラム部品を呼び出して処理しているので、一行目の「HawkEyeListener.java」を呼んだのは二行目の「RegisteredListener.java」の62行目だよってことを示してます。つまりこの長いメッセージはそれぞれ誰に呼び出されたかを遡って表示してます。いい加減長いので最後は「… 15 more」って省略されちゃってますが

エラーから原因を調べる際には、ログからヒントを読み出さなければなりません。だから、一行目や二行目でわからない場合はその下の方を追っていくと、何かヒントが見つかるかもしれませんね。また、以下の図の様に、

minecraft_env

プラグインのエラーを呼び出したのはBukkitやSpigot、それを呼び出したのはマイクラ自身・・・とより深い層まで追うことも出来る訳です。
さて、あとはマイクラの仕組みなどを考えながら原因を探らなければなりません。上記のHawkEyeの場合はブロックの破壊を記録出来なかった訳ですが、1回出ただけなら偶然バグに当たったなども考えられますので、様子を見て考えるのも手でしょう。繰り返し出るなら特定のブロックに起因してるかもしれません。全てで出るならそもそもプラグインとしてまともに動いていないと判断する必要もあります。
プラグインがまともに動いてないなら、切り離すなり、バージョンアップ(あるいはバージョンダウン)を検討する必要もあるかもしれませんね。

もう少し、ケース別に例を見ていきます。

例外メッセージの一行目に設定ファイル名や設定項目が出てる場合

設定ファイルの書きそんじを怪しみましょう。ミスってる場所を示してくれる場合もあります。単純な文字コードが間違ってるとかカッコを忘れたりとか様々です。

java.lang.NoClassDefFoundError: org/bukkit/craftbukkit/v1_7_R2/…

プラグインが動かそうとしたbukkitのバージョンに対応してない時に出ます。
マイクラで例えばサーバが1.7.4の環境で1.7.2のクライアントが繋がったりとか、逆に1.7.9は繋がらないとか経験したことがあると思います。
これは、1.7.2は1.7.R1、1.7.9は1.7.R4というような内部的なバージョンが存在している訳なんですが、プラグインがそういうバージョンに依存する作りになってる場合、アンマッチだとこれが出ます。だから、サーバが1.7.10でプラグインが1.7.9のが出てれば、表向きのバージョンは違いますが内部バージョンが同じなので動く場合があります。

あるプラグインの例外で別のプラグインの名前が出てきた

別のプラグインが前提になってるにもかかわらず前提プラグインが無い場合に出ます。

何かエラーにメッセージ的な内容が含まれてる

ちゃんと翻訳して読むとわかる場合があります。例えば、「データファイルが無いです」というのは結構ありがちです(無いので作ってくれている場合は次回以降表示されない)

Outofmemoryとか

その名の通り、メモリ不足で止まったなど。

プラグインのプログラム部品名が別のプラグインと被ってる

過去に一度あったのですが、プログラム部品の名前が被ってたというのがありました。これはエラーから直接わからなかったですね。例外メッセージとプラグイン名でググったらそういう投稿を見つけてわかった感じです。
対処もプラグインプログラムの修正でないと直らないです。

何が起きたかを掴む(Mod編)

Mod系はちょっと難しいです。何故ならやはり例外処理を出す事が多いのですが、かなり深い場所でのメッセージの場合が多く、読んだだけでは理解できなかったり、理解できても対処しようが無いことが多いです。メッセージをそのままググって他の人も同じような目に遭ってないか調べてみるのがいいかもしれませんね、、、。

ですので、Mod系を大量に導入する場合は1つ導入しては起動というのを繰り返し、どのModが原因となってるのを掴むのが手っ取り早い場合も多いです。
マイクラのプログラムを書き換えるという特性上、書き換えたのを別のModがさらに上書きしてしまうこともありがちです。(その場合は導入順序の見直しで直る場合もあります)

 

と、、、ちょっと難しい内容でしたが、マイクラのサーバ管理をする上で、プラグインのエラーと付き合わなければならないので、この辺の知識が必要になってくると思います。逆にエラーの原因が掴めなくてあえなくサーバ閉鎖、、、、なんてのも少なくありません。
エラーログは何だかわからないメッセージの羅列で読むのもおっくうかと思いますが、読めるようになるのも慣れなので、わからなくてもなるべくがんばって読み解くようにしてみましょう。

ちなみに、タイトルに書いたぬるぽとは、NullPointerExceptionという例外の一種で、データの所在を示す情報(ポインター)がNull(=0/空)のまま処理すると出る例外です。原因はプログラマのミス(バグ)が大多数で、Javaに関わらず近年の様々なプログラム言語でとても出やすい例外です。マイクラでもこれはソコソコでる事がありますが、内容の通りそのメッセージから対処するのは困難かもしれませんねぇ。

サーバを考える

滅多に書かない鯖管のつぶやき二回目です。
今回はマイクラサーバを建てる上でのハードウエアをどう考えるかについてつぶやいてみようと思います。

お金がジャブジャブにあればお金を掛けてリッチなサーバを建てればいいんですが、そうも行きません。限られたお金を使って必要最低限のリソース(CPU、メモリ、ディスク、電気、etc…)を買う必要があります。
ってことで、マイクラサーバを建てる場合の考え方を書いてみようと思います。

» サーバを考える の続きを読む

マルチサーバ化

マインクラフトをマルチサーバ運営する方法について語ってみたいと思います。

マルチサーバと言っても、マルチワールドやマルチができるサーバのことではありません。マインクラフトサーバ(bukkitやspigotなども同様)を複数起動して運営することです。単一の物理サーバに複数のマインクラフトを立ち上げる事もあるし、物理サーバを分けて運営することもできます。物理サーバを分けた場合は、データ連係をどうするかが多少面倒になりますね。

そもそもなんでマルチサーバ運営を考える必要があるのか?

  • 負荷分散。PvPサーバ運営者が気にする点かな。
  • 複数管理者連携。
  • バニラサーバとModサーバ運用←私はこれ
  • その他(ログイン人数を合算させたりなど、見た目上一つにしたいとか)

ちなみにかなり面倒なので、心して掛かった方がいいです。
以下、考えなければならないことと、実現方法です。

ベースシステム

サーバを束ねるには、親となるシステムを構築する必要があります。マインクラフトクライアントからはそこにログインし、そこから適切なサーバへ振り分けられます。

  • マインクラフトサーバ
    bukkit…プラグインが豊富なサーバ。広く使われてるので情報が多く扱いやすい。
    spigot…bukkit互換の軽量サーバ。後述のcauldron、BungeeCordとの親和性が高い。
    forge…Modサーバを作るためのフレームワーク。Modの前提となっている場合が多い。また、クライアント側にもModが必要となるので、参加者側のハードルが上がる。当然、bukkitプラグインなどは使えない。
    cauldron…spigot+forge。以前はMCPCという名称だった。
  • マルチサーバ管理
    BungeeCord…複数のマイクラサーバを連動させることができる。見た目上はバニラでは無いサーバに見えてしまいますが、ログイン先がバニラならバニラで入れます。サーバ間移動も相手がオフラインだったり、前提Modが必要だったりする場合は移動しないよう制御をしてくれます。

BungeeCordの説明は過去に書いてるのでそっちを見て下さい。
単純に入れればマルチサーバ化できる訳では無く、前提がいろいろあるので注意が必要です。

データ連動

サーバが違うとデータも別扱いです。お金、経験値、アイテムなどです。
ちなみに同じデータファイルを複数のサーバで共有した場合、競合が発生して高い確率でデータが壊れるか、書き込みができなくなります。なので、通常のデータ連係はデータベースを使わなければなりません。

幸いにもbukkit系のプラグインはデータベースに対応しているものが多いので、それを使っていきましょう。データベースの種類はSQLiteかMySQLがほとんどです。
MySQLの方がサーバを建てなければならないなど難易度が高いですが、使い方を覚えてしまえば連携のしやすさはこっちが容易です。
SQLiteはサーバが必要無い為、使用するのは容易ですが、サーバが無い分、マルチサーバからアクセスするのが難しいです。っていうかそもそもどういうやり方がいいのか想像付きません。

私の管理しているサーバでは以下の連動ができることを確認してます。それ以外もできるかもしれませんが、未検証です。

  • お金
    CraftConommyを使ってます。元々Essentialsを使ってましたが、これはDBに対応してませんね。CraftConommyはDBに対応してるし、Essentialsのお金データをインポートできるので楽です(他の経済プラグインも対応してます)。
    なお、変換の際にプレイヤー名にハイフンかアンダーバーが使われてると勝手に変換される(どちらかというとEssential側の仕様)ので、注意して下さい。
  • mcMMO、Jobs
    これらもDBに対応しており、複数サーバから同時にアクセスできます。私のサーバはJobsを連携してませんが、これはゲーム性の観点でしてないだけで、技術的にはできます。

注意しなければならないのは、例えばTownyの様なプラグインはデータ連係できますが、サーバ間データ連動ができないので問題が起きます。例えばサーバ二カ所でTownyを起動した場合、税金は二重課金されます。さらにお金が連動できていなければ片側のサーバでお金不足になる事もあります。

HarkEyeなども連動できそうですが、怖いのでやってません。

念のため補足しておきますが、DB連動できたとしてもお互いのトランザクション処理がちゃんとできているかは別問題です。上記のレベルであれば今の所問題は起きてません。

機能連携

ゲームでの機能連携ですが、だいたい以下の方法でできます。詳しくは過去のコンテンツを見て下さい。

  • Dynmap
    Dynmap-MultiServerを使う事で連動できます。
  • 投票
    BVotifierでできます。Votifierと連動もできます。
  • チャット
    CloudChatというツールでできます。私は使いたいと思ってますがまだ使ってません。ローマ字変換とか無いので。
  • サーバ間ゲート
    TeleportSignsでできます。他にもHomeコマンド連動とかできるのも有るみたい。

運用

マルチサーバを運用する上でいくつか気になることもあると思います。思いつく限り書き連ねてみようと思います。

  • ロビーとなるサーバは安定させるべき
    単体でロビーサーバがあるのがベターですが、Modサーバなど安定しないサーバがある場合、ログインできなかった場合の待避サーバが設定できますので、そこにロビーサーバなどの安定したサーバを指定すべきです。そうすることで一カ所のサーバが死んでもプレイヤーは別のサーバで遊ぶことができます。
  • BungeeCordの扱いが難しい
    これが止まるとどのサーバにも入れません。また、管理者コマンドが少ないので、何かあったときに自由がきかないでやむを得ず再起動しなければならなくなる曲面も多いです。
  • ワールド名は同一にしない。
    同じ名前のワールドがあるとおかしな動きをする物があります。特にデフォでworldという名前が使われているので、ここがネックになる場合があります(server.propertiesで変えられます)
  • サーバ同士の連動性
    例えばMySQLのDBサーバを建てた場合、マインクラフトサーバを上げたまま、DBサーバを止めてはダメです。ちゃんと、
    マインクラフトサーバ停止→DBサーバ停止→DBサーバ起動→マインクラフトサーバ起動
    という順序を踏みましょう。停止は多少前後しても影響は少ないですが、起動は前後を間違えると確実にエラーが多発&ゲームに影響がでます。
    ちなみに私はJobArrangerというジョブコントローラを使って前後を管理してます。
    jobarrenger

BVotifier

BVotifier_v1.0.7.jar

Japan Minecraft Serversなどの外部サイトで投票してもらってそのお返しにアイテムを渡したりできますが、仕組み的にはVotifierなどのプラグインで受信し、その情報をSimpleVoteListenerなどでコマンド化してます。

BungeeCordでマルチサーバ化してる場合は、何もしなければ当然どれか一つのサーバでしか投票を受信できません(サーバ分だけ投票サイトに登録すれば別だけど)

それを一回の投票情報を複数のサーバに分散できるのがこのBVotifierです。BVotifierはBungeeCordのプラグインとして動作します。
既にVotifier運用しているなら導入は比較的楽です。何故ならこのプラグインはBVotifier→Votifierという連動をするので、Votifierも必要になるからです。
導入方法も簡単で、BVotifierをBungeeCordとマインクラフトサーバのpluginsディレクトリに置くだけです。Votifier側の設定はいじらないで連動してくれます。(※マインクラフトサーバ側は、Votifier.jarを消して、BVotifier.jarを有効にするが正解かも)

ただし、ポート情報はバッティングしてはならないので、適当にずらして下さい。

設定は本当にこれだけ。なお、ログインしてないと投票してるように見えないですが、ログインすれば投票したことがわかります。

Dynmap-MultiServer

Dynmap-MultiServer_0.5.0.jar

dynmap-multiserverマルチワールドではなく、マルチサーバです。BungeeCordなどでマルチサーバ運用をする場合、Dynmapも複数に分かれてしまいます。それを束ねて一つのWebサーバにするのがこれです。

これ自体、何かのプラグインではなく、単体のJavaプログラムとして動作します。(BungeeCordと連携する訳でも無いです)
主立った動かし方は以下の通り。

  1. ダウンロードして起動する。エラーで落ちるけど、この際にconfig、log、webディレクトリが作られる。
    java -jar Dynmap-MultiServer_0.5.0.jar
  2. configをいじる。
  3. 各サーバのDynmapをJsonFileClientUpdateComponentで動作させる。
    「- class: org.dynmap.InternalClientUpdateComponent」って設定とそれ以降の段落?の設定を全てコメントアウトし、「- class: org.dynmap.JsonFileClientUpdateComponent」って設定項目とそれ以降の段落(もともとコメントアウトされてる)を有効にする。
    設定変更後にdynmapをリロードすると反映されるが、この段階でdynmapをブラウザで見れなくなります。
  4. どのサーバのでもいいので、Dynmapの設定ディレクトリ以下のwebディレクトリを、Dynmap-MultiServerのwebディレクトリにコピーする。これは、Dynmap-MultiServer経由でWebを見る際のHTMLやCSSファイルを参照する為だと思います。
    なので、webディレクトリ配下のtilesディレクトリ(マップの画像が格納されたものすごくファイルサイズの大きいディレクトリ)のコピーは不要。
  5. Dynmap-MultiServerを起動させる。UNIX系ならコマンドの最後に&を付けてバックグラウンドで起動してあげればいいです。
    java -jar Dynmap-MultiServer_0.5.0.jar &

config/main.ymlの書きっぷりは以下の様な感じ

config/main.yml

Webserver:
IP: 0.0.0.0
Port: 8123
webDir: web/
Title: Dynmap
WorkerThreads: 16
DynMap:
– Folder: /mcserver1/plugins/dynmap/web
UpdateInterval: 4
– Folder: /mcserver2/plugins/dynmap/web
UpdateInterval: 4

気にすべき点はポート番号と「DynMap」以下に各サーバのDynmapディレクトリを書き連ねるというところ。
また、運用する上で気にしなければならない点は以下のところかな。

  • 上記の通り、Dynmap-Multiserverを動かすサーバから各Dynmapのディレクトリが見えないとダメです。1台のサーバにマインクラフトサーバを複数建てるなら全然問題無いですが、サーバそのものを分ける場合は、ファイル共有なり、NFSなりでディレクトリを共有しないとダメです。
  • Webの画面設定が結構難しいです(設定ファイルが無いので)。webディレクトリをコピーする前に、ある程度設定してしまいましょう。
  • 各Dynmapのバージョンを合わせないとダメです。ちょっと苦労したのは、バニラサーバとModサーバとでバージョンが合わなかったこと。これは各Dynmapの「web/standalone/dynmap_config.json」の中の「coreversion」を見てますので、私はここの数字を変更して起動してます。
  • Dynmap-Multiserverの起動障害のうち、カレントディレクトリをjarファイルのあるディレクトリにしておかないと起動に失敗することがありました。
  • Dynmap-Multiserverを起動すると特定のサーバで存在しないワールドデータを見に行って落ちる事象が起きました。どうやって直したかわすれたけど、確かweb/standalone/dynmap_ワールド名.jsonってファイルが影響してた気がする。
  • JsonFileClientUpdateComponentを有効にした場合によくあるんですが、マップ上のプレイヤーの所在がよくわからなくなることがあります。未だに原因はよくわからないんですけどね。
    ※JsonFileClientUpdateComponentは、そもそもWebサーバ機能をapacheなどの外部サーバに委託する時に使う設定なんですが、apacheでも同様の事象が起きていたので、この問題はDynmap-Multiserver側の問題では無いと思います。

起動したらconfigに設定したポートへブラウザ経由でアクセスすると、全サーバのワールドが混ざって閲覧できるようになります。

BungeeCard / TeleportSigns

BungeeCard_build#1013
TeleportSigns_v1.3.2

BungeeCardはサーバ間ゲートですね。プラグインではなく、Bukkitやspigotと同様に単体で可動するJavaサーバです。
よく、PvPサーバなどで見かけますが、ロビーサーバやゲームサーバなど一つのサーバ内で納められない場合や、全然別の他サーバとのサーバ間接続に使われますね。絵に描くと以下の様な感じ。

bungee

絵面的にはBungeeCardへログインしているように見えますが、入り口としての橋渡しになってるだけで、ログインすると直ぐにロビーサーバへ接続されます。
TeleportSignsは移動用のゲートを看板で実現するプラグインですね。BungeeCardはコマンドでサーバ間を移動するので、それをしやすくするだけのものです。

実現方法や機能制限などを纏めると以下の様な感じ。

  • BungeeCard自身が独自のポート番号を持つので、同じサーバ上のマイクラサーバが居るなら、その番号とは別にしなければならない。
  • BungeeCardを経由しなくても各マイクラサーバへのログインは可能(ただしそれは推奨できない。詳しくは次項以降)
  • 1.7の後半のバージョンから、マイクラサーバが個人情報をUUIDで管理するようになったが、BungeeCard経由だとUUIDが変わるので、運用中のサーバにこの機能を追加すると「お初さん」になってしまう。回避するには以下の設定が必要。
    ・spigotサーバを使って、設定ファイルspigot.yml内のbungeecordをtrueにする。
    ・BungeeCardのconfig.ymlのip_forwardをtrueにする。
  • 各サーバはonline-modeをfalseにしなければならない。(server.propertiesか、起動オプション-o trueを付ける)
  • どこのサーバに居ても外部から見えるサーバ全体のログインプレイヤー数はカウントされる。
  • MinecraftForgeの入ったクライアントだとログイン時のサーバ一覧にバニラ(V)かどうかの表示がでますが、バニラでは無いという表示になってしまいます。それでもロビーサーバがバニラならバニラで入れるし、そのほかのサーバがModサーバならサーバ間移動の時に遮断されます。

ちなみにspigot.ymlのbungeecordをtrueにすると、BungeeCord経由でなければログインできなくなります。何れにしろonline-modeを切ると管理者アカウントを奪われる危険性があるので、直接ログインはしない運用にするのが吉ですね。

以下、設定方法です。

  • TeleportSignsを使うなら、BungeeCordのconfig.ymlのpermissionsにあるbungeecord.command.serverはadminに移すべき。看板を使わなくても誰でもテレポートできちゃうっぽいので。
    また、以下の様な設定にすると、指定したプレイヤーだけがadmin permissionsに設定されたコマンドが使えますね。

    groups:
    プレイヤー名:
    – admin

  • config.ymlのlisteners設定の意味は以下の様な感じ。
    max_players…最大ログイン数だが、これは表示上だけ。実際には個々のサーバの上限が制限となる。
    fallback_server…ロビーサーバが死んでしまっている時に接続するサーバ名。
    host…BungeeCord自体の接続設定「0.0.0.0:25555」みたいにすると「25555」ポートで接続可能となる。
    default_server…ロビーサーバ
    motd…マイクラのクライアント側に表示させる紹介文
  • config.ymlのserversは、接続するサーバ分全て記入する。

    サーバ名:
    address: 192.168.xxx.xxx:25553  ←マイクラサーバのIPとポート
    restricted: false
    motd: ‘サーバ説明’  ←サーバの説明。ほとんど表示されることは無い。

  • ちなみに、config.ymlにもonline_modeの設定がありますね。当然、trueで運用すべき。
    ip_forwardについては上に書いた通りです。

鯖管のつぶやき

私の周りでマインクラフトのサーバを建てる人が多い気がするので、実際に公開マイクラサーバを建てるというのはどういうことかというのを経験を元に書いてみたいと思います。
まぁ、サーバを2つ立ち上げたとはいえ、まだ公開サーバ管理者歴半年の若輩者ですがご参考まで。

ちなみに実際にサーバを建てても公開しない・内輪だけって人も居ると思いますが、このコラムでは公開サーバを建てる前提で書いてます。

で、一回目のコラムは「何故サーバ管理者をかって出たのか?」というネタ。私の場合は以下の理由です。

  • サーバ管理が楽しいから(元々サーバを持ってた)
  • 好きなマイクラサーバが作れるから
  • 以前入ってたサーバが管理者のミスで巻き戻ったあげく、バックアップもろくに取って無くてせっかく作った物が戻らなくなってついカッっとなって。

元々趣味というか自分のスキルアップというかそんな感じでサーバを持ってたのですが、ゲームサーバを管理するというのがどういうことか?というのにはちょっと興味があった訳です。

あと、マイクラサーバはプラグインで結構カスタマイズができますが、実際にサーバを建てる人の楽しみってこれじゃないですかね?私もいろんなオンラインゲームをやってきましたが、いつかは自分好みのサーバを建ててみたいと夢見てた(実際にWebゲームくらいは作った事があります)訳ですが、それを実現するのにまさに好都合ですね。マイクラ鯖は。
マイクラ鯖を管理してるとよくわかりますが、ゲームとしてのマイクラは普通の人は1~2ヶ月くらいで一旦飽きます。当然それより長い人・短い人・’しばらくして戻ってくる人も居ますが、だいたい1~2ヶ月っていうのが平均みたいです。少なくとも「マイクラサーバを建てるという楽しみ」は1~2ヶ月程度では飽きないですね。っていうか公開サーバを建てるのにはそのくらいの準備期間が必要ですけどね。当然人に寄りけりですが、サーバを建てるというのはそのくらい楽しめます。

ちなみに巷のマイクラ鯖には「管理者が管理者に飽きてしまって、別の人に管理を委譲している」という例がソコソコあるようです。
当然そういうサーバはハードの管理者とマイクラの管理者が別です。どうも私が以前居たサーバもソレで、結局どっちの管理者もちゃんとバックアップの管理をしてなかったようで、結果的に大規模な巻き戻しが発生したようです。
なので、私の管理してるサーバはバックアップはかなりしっかりしてるつもりです。定期セーブは当然として、1時間毎のバックアップ(12世代)と、日次の外部バックアップ(10世代)、月次のバックアップ(消してないので残り続けてる)をしてます。
ちなみにクラウドストレージも使って本当に家の外へのバックアップも試したいなぁとも考えてます(むしろ安全よりも技術的な興味に近いw)

と、まぁいきなり長文となってしまってアレですが、次回に続きます。

VideoPad

videopad

Avalonサーバの紹介動画を作りたかったんですが、ムービーメーカは表現のしかたがそろそろ限界で、がんばっても似たような動画しか作れなくなってきたので、探してみました。

で、たどり着いたのがコレ。ちなみにどこかに無料って書いてあった気がしたけど、有料なのね。

やや使い慣れる必要はある物の、ムービーメーカに近い感覚で作れるので慣れやすいですかね。動画の画面が2つ有りますが、左が選択レイヤーのプレビューで、右がレイヤー合成後のプレビューなので、この辺の使い勝手もとても良いです。

難があるとすれば、テキスト一つ一つが画像扱い?のような位置づけで、コメントが多い動画を作るのがちょっと大変です。後はBGMが個々のシーンに合わせて希にぶった切られるのも使いづらいかな。エフェクトもシーン毎に設定するので、「纏めて全部に設定」ってのができないです。

ただ、エフェクトの設定は各レイヤー毎にかなり細かくできるので、時間を掛ければ様々な表現ができますので、ツールとしてはシンプルでいいですね。個人的に「ボタン一つで様々な事ができちゃう系」は好きじゃ無いので、そういう人にはお勧めです。

ちなみに作成した動画はこちら。

ニコニコ動画へのアップも初めてチャレンジしてみました。結構エンコードの制約とか厳しくて難しかったけど、「つんでれんこ」を使ったらあっさりアップ可能な形式が作れました。

4 / 512345