MinecraftのModding環境の構築手順についてのメモ。

後編的なやつで、Forgeを導入してリリースファイル作成まで。

Eclipseの準備などは1つ前の記事を参照してください。

対象

Javaで開発ができる
IDE(Eclipse)が使える
Google先生と仲がいい

あと、Gitについても少しだけ書いています。

準備するもの

EclipseとJDK
MnecraftForgeのsrc版(開発用)

やだやだEclipseやだIntelliJ IDEA使いたい

開発用ワークスペースを作成後、gradlew ideaコマンドでそれ用の開発環境が生成されます。あとはインポートして使ってください。起動構成などは自分で作成する必要がありますが、検索すれば沢山情報は見つかります。

それか、最近IDEAわいわいしていたこのあたりを見たり、チュートリアル作成の進捗確認をしてきて、どうぞ。

GradleIDEは要らないの？

リリースファイル生成や、ライブラリやForgeの更新時に、コマンドプロンプトでの操作が殆ど不要になるので、あったほうが便利です。ですが、使い方の日本語情報がまだ少ないようなのと、自分自身、説明書けるほど使いこなせていないので、今回は説明を端折りました。使えるなら導入をおすすめします。マーケットプレイスからインストールできるので、導入自体は簡単です。

プラグインをインストールしたら、Eclipse上でプロジェクトを右クリックし、「構成」→「Convert to Gradle Project」でプロジェクト構成をGradleプロジェクトにできます。

インストール直後のままだと、JDKがみつからなかったり、日本語を含むソースのコンパイルで文字コードが原因で失敗する事があります。その場合、build.gradleを修正したり、Eclipseの設定からJDKの指定や、JVM引数を足してあげれば、Eclipse上からビルドしてくれるようになります。

build.gradleを更新して保存するだけで、自動で依存関係が解決されるのは、ちょっとワクワクする感じでした。(maven未経験)

手前味噌な参考情報

Forgeのインストール

以下の順で、簡単に解説します

Forgeのファイルを任意のフォルダーに配置
コマンドプロンプトからGradleを実行しEclipse用の環境を生成
EclipseでインポートしてMOD開発を行う
デバッグ起動してみる

1. Forgeのファイルを任意のフォルダーに配置

好きなフォルダーにForgeのsrc版のZIPファイルを展開します。

Javaはファイル名が冗長になりやすいため、ドライブ直下など、あまり階層の深くない場所に配置するのをおすすめします。

今回は、Fドライブの直下にMod用フォルダーを作成し、その下に対象Modの開発環境を作成しました。 ZIP展開直後のフォルダーのスクリーンショット

なお、ライセンスやクレジット、changelogは今後必要としないファイルなので、削除してOKです。

2. コマンドプロンプトからGradleを実行しEclipse用の環境を生成

以下、F:\mod\TestModに展開したものとし、説明していきます。

コマンドプロンプトを開いて、上記のフォルダーに移動します。

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\username>f:

F:\>cd mod\TestMod

F:\mod\TestMod>

gradlew eclipseコマンドを実行し、Eclipse用の開発環境を準備します。

F:\mod\TestMod>gradlew eclipse
****************************
 Powered By MCP:
 http://mcp.ocean-labs.de/
 Searge, ProfMobius, Fesh0r,
 R4wk, ZeuX, IngisKahn
 MCP Data version : unknown
****************************

(以下必要なファイルがなければダウンロードが行われ、必要なファイルが生成され、開発環境が構築される)

BUILD SUCCESSFUL

Total time: xx.xxx secs
F:\mod\TestMod>

ForgeのGitHubのREADMEや、その他環境構築の解説記事などでは、最初にsetupDevWorkspaceタスクを実行する手順として書かれて居ることが多いです。

しかし実はsetupDevWorkspaceタスクは、eclipseタスクの依存タスクなので、明示的に指定しなくても勝手に実行されます。なので個別に実行する必要はなかったりします。(でもideaタスクは依存してないみたいなので、両方実行しないとダメっぽい。なんで統一されてないんだろう…。)

フォルダーの中は、こんな感じになりました。

gradleコマンド実行後のフォルダーのスクリーンショット

増えたファイルやフォルダーは、Gradle(ForgeGradle)によって自動生成されたものです。また、元からあったeclipseフォルダーの中に、assetsフォルダーなんかも生成されています。

これで、Eclipseを使った開発用の環境が生成されました。

ついでにソース管理もやっちゃう？

ソース管理を行うのであれば、このあたりで一度コミットをしておくとよいかもしれません。何も変更してない状態のコミットがあれば、途中でなにかやらかしても、最初まで立ち戻るときに役立ちます。

ここでは、Gitの導入方法については特に説明しませんが、ソース管理にGitを使う場合を、簡単に紹介しておきます。Guiツールを使ってやったほうが楽ちんですが、スクリーンショットの準備が面倒だったので、コマンドプロンプトからやっちゃいます。

また、Gitリポジトリを作成したあとに、Eclipseでプロジェクトを右クリックし、「チーム」→「プロジェクトの共用」から、EclipseでGitに接続できるように設定出来ます。こうすることで、変更したファイルがわかるようになり、Eclipse上からコミットなども行えるようになります。

1. リポジトリ作成

F:\mod\TestMod>cd ..

F:\mod>git init TestMod
Initialized empty Git repository in F:/mod/TestMod/.git/

2. コミット対象を確認してみる。

F:\mod\TestMod>git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       .classpath
#       .gitignore
#       .gradle/
#       .project
#       .settings/
#       build.gradle
#       build/
#       eclipse/
#       gradle/
#       gradlew
#       gradlew.bat
#       src/
nothing added to commit but untracked files present (use "git add" to track)

管理不要な、自動生成されたファイルなどローカル開発環境固有のものがいっぱいあります。

リポジトリを外部公開しないのであれば、ローカル依存の設定ファイルなどもコミットしてしまったほうが、変更の追跡や設定のロールバックなどもしやすく、便利な場合もあります。しかし、GitHubなどにPushし外部公開するのであれば、ローカル依存なファイルはコミットしないほうがいいでしょう。

3. 余計な物が多いので無視設定を追加

外部公開する場合を想定し、.gitignoreファイルを作成して、無視対象を追加していきます。

F:\mod>cd TestMod
F:\mod\TestMod>echo /.classpath>>.gitignore
F:\mod\TestMod>echo /.project>>.gitignore
F:\mod\TestMod>echo /.settings/>>.gitignore
F:\mod\TestMod>echo /.gradle/>>.gitignore
F:\mod\TestMod>echo /bin/>>.gitignore
F:\mod\TestMod>echo /build/>>.gitignore
F:\mod\TestMod>echo /eclipse/>>.gitignore

ものぐさなので、コマンドプロンプトから直接書き出していきました。

“.classpath”、”.project”、および”.settings/“フォルダーは、eclipse用のプロジェクト設定ファイル、または設定ファイル用のフォルダーです。いずれも自分専用の開発環境用の設定なので、このあたりは個々の開発者が管理すべき内容であり、公開予定のリポジトリにはコミットするべきではありません。

“.gradle/”フォルダーは名前の通りgradle用で、一時ファイルやログなどが出力されます。これもバージョン管理を行うべきではないため、無視対象に含めます。

“bin/”フォルダーは、今はフォルダーも作成されていませんが、Eclipseで自動ビルドを行った際にクラスファイルが生成される場所になります。クラスファイルはソースがあれば生成でき、バージョン管理対象ではありません。

“build/”フォルダーは、Gradleでビルドを行う際の、一時ファイルや生成したファイルの出力先になっています。

“eclipse/”フォルダーは、ダウンロードしてきたassetsや、Eclipse上でサーバーやクライアントを起動した際の、セーブデータファイルなどが生成される場所です。

.gitignoreファイルが生成できたら、もう一度確認。

F:\mod\TestMod>git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       .gitignore
#       build.gradle
#       gradle/
#       gradlew
#       gradlew.bat
#       src/
nothing added to commit but untracked files present (use "git add" to track)

これで必要なファイルだけが変更対象になりました。

4. ステージに追加しコミット

さくっとステージングしてコミット。

F:\mod\TestMod>git add .

F:\mod\TestMod>git commit -m "initial commit"
[master (root-commit) 42591b1] initial commit
 10 files changed, 904 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 build.gradle
 create mode 100644 gradle/wrapper/gradle-wrapper.jar
 create mode 100644 gradle/wrapper/gradle-wrapper.properties
 create mode 100644 gradlew
 create mode 100644 gradlew.bat
 create mode 100644 src/main/java/com/example/examplemod/ExampleMod.java
 create mode 100644 src/main/resources/mcmod.info

これで、最初のコミットが作成されました。

以降、上記ファイルが変更されたか、新しいファイルが追加された場合、差分などが簡単に追いかけれるようになります。

※サンプルModは、あとでどのみち削除するので、コミットする意味はないです。git add ～で対象を選んでステージングするか、一旦全部追加したあとにgit rm --cached ～などでステージからサンプルModだけを削除し、コミットした方がいいかもしれません。

3. EclipseでインポートしてMOD開発を行う

ここからは、Eclipseでの作業です。

個人的にはこの方法は好みでないので、自前でワークスペースを用意し、起動構成などを作成するつもりですが、簡単な導入ってことで、今回はForgeについているワークスペースを使っていきます。

Eclipseを起動し、F:\mod\TestMod\eclipseフォルダーをワークスペースに指定します。

ワークスペース選択ダイアログ

ワークスペース設定は新規作成になるため、これまで開発に使っていたワークスペース設定がある場合、諸々の再設定が必要となります。(エディタ背景を黒にしたりとか！)

一部の設定は、設定エクスポート→インポートで引き継いだり、パースペクティブの設定などワークスペース切り替え時にコピーし持ち越すことも出来ますが、できないものは手動で設定するか、ワークスペースの.metadata/フォルダー以下の設定ファイルを、手作業でコピーすることで引き継げます。ただしコピーは、設定値をみて必要なファイルのコピーや設定値のマージを行う必要があり、項目多数で説明のしようもないので、詳細は省略します。多分、よくわからなければ、一から再設定したほうが楽です。

Eclipseが起動したら、こんなかんじの表示です。ただし、ビューやツールバーなど、パースペクティブ内の状態は、個々の環境で異なるかと思います。

Forgeのワークスペースに切り替えた直後のEclipse ※この画像では、パースペクティブをJavaに切り替えてあります。

あとは、プロジェクト名”Minecraft”を、Mod名など任意の名前に変更し、ソースフォルダーの、サンプルModを参考に、自分独自のModを作成していくだけです。(サンプルModは不要になったら、パッケージごと削除しちゃてOK)

なお、ソースコード内に日本語を含める場合は、文字コードをUTF-8にするようにしてください。MS932で突き進みたい場合、ビルド時の文字コード問題を頑張って解決する必要があります。

また、おそらくFMLの修正漏れだと思いますが、Forge977付属のワークスペースを使うと、以下の不要なリンクフォルダーが生成されてしまいました。

common
jars
lib

これらのリンクフォルダーはに参照されず、リンク先も見つからない状態になっているため、削除してしまって問題はありません。(タブン)

4. デバッグ起動してみる

テスト実行は、Eclipse上の緑色の三角のボタン、またはデバッグ実行用の虫のマークのボタンから行えます。

なお、ForgeGradle対応後のForgeにも、マイクラを起動できるまでのワークスペース設定が付属しています。

Eclipseの起動構成

もちろん自前で起動構成の作成を行ってもいいのですが、その手順はあちこちで紹介されているみたいなので、省略します。また、ここで使用されている起動構成を真似れば、自分で作成することも出来ます。

クライアントの起動

上記からClientを選択するだけです。

参考までに、起動構成(上記画像の「実行の構成」または隣のボタンの「デバッグの構成」)のキャプチャーを紹介しておきます。

実行の構成ウィンドウでClientの構成のメインタブ内容

実行の構成ウィンドウでClientの構成の引数タブ内容

なお、クライアントの生成するセーブデータなどのファイル群は、全てeclipseフォルダー直下にぶちまけられてしまいます。

2つ目の画像の一番した、「引数」タブの、「作業ディレクトリー」を任意の場所に修正することで、出力されるファイルの場所は変更できます。ただし、assetsへの参照ができなくなり、正しく動作しなくなる可能性があるため、おすすめはしません。

assetsもきちんと動かせば、タブンいけるんじゃないかな？(試してはないですが、おそらくrunフォルダーに変更してそうなModのbuild.gradleを見た感じ、build.gradleでassetDirを変えれば、いけそう…？)

なお、同じ名前の起動構成が複数表示されていますが、どちらも同じファイルを指しているので、気にしなくてOKです。これは、現状とプロジェクトの中にワークスペースが存在する、不思議な構成になってしまっているため、Eclipseがeclipse/.metadata/フォルダーの中にある、ローカルファイルに保管されている起動構成の設定ファイルの実態を、見つけてしまっているために起きているのだと思われます。

なので、ローカルファイル保管の起動構成を修正した場合、構成ウィンドウを開き直すと、ファイルを参照している起動構成も更新されます。

※ただし、逆は開きなおしても更新されていませんでした。起動構成を修正する場合は、「共通」タブの「保管」先が、ローカルファイルになっているものを修正したほうが、よさそうです。

※あと、自環境では起動中に何かエラーメッセージが出ていました。起動はでき、Modもロードされてるっぽいので、とりあえず忘れることにしました。

サーバーの起動

クライアントと同じですが、初回のみ、一度起動したあとに生成されたサーバー設定を変更し、起動し直す必要があります。

クライアントと同様に、サーバーの起動時にも、eclipseフォルダー以下に、サーバーの設定ファイル群がぶちまけられます。そのなかにあるserver.propertiesファイルで、online-modeの値が、デフォルト値のtrue(有効)になっているので、ここをfalse(無効)に設定してください。

online-modeを無効にしたあと、Eclipseからサーバーを起動して、クライアントを実行し、localhostに接続を行うことでマルチプレイでのテストも行えます。

起動構成はこんなかんじになっています。

実行の構成ウィンドウでServerの構成のメインタブ内容

実行の構成ウィンドウでServerの構成の引数タブ内容

リリースファイル作成

自分のMod用に、build.gradleファイルを編集する。
gradlewでビルドタスクを実行する。

build.gradleの編集

サンプルModをそのまま残しているため、以下のように修正してみました。

--- a/build.gradle
+++ b/build.gradle
@@ -18,8 +18,8 @@
 buildscript {
 apply plugin: 'forge'

 version = "1.0"
-group= "com.yourname.modid"
-archivesBaseName = "modid"
+group= "com.example.examplemod"
+archivesBaseName = "examplemod"

 minecraft {
     version = "1.7.2-10.12.0.977"

groupには通常Modのルートパッケージを、archivesBaseNameにはリリースファイルにつけるファイル名の接頭辞を設定します。

GroupIDの詳細については、build.gradleにコメントで記載されている、Mavenのガイドや、Mavenについて説明しているサイトなどを参照してください。

Gladleラッパーの設定を修正

Javaのソースコードに日本語が含まれる場合、エンコード設定を変更する必要が有るかもしれません。デフォルトのエンコードは環境のデフォルトとなっており、Windows環境ではMS932(Shift_JIS互換のエンコード)になってしまいます。

「エラー: この文字は、エンコーディングMS932にマップできません」

このメッセージが出る場合、build.gradleに以下を追加すると、Javaのコンパイルがutf-8になり、エラーを回避できるようになります。ただし、JavaのソースコードがUTF-8でないといけません。

[compileJava, compileTestJava].each{ it.options.encoding = 'UTF-8' }

build.gradleに日本語が含まれてるとタスクが実行できなくなった

日本語を含む場合、その前後行が読めなくなったりして、正しくタスクが実行できなくなったり、ビルドスクリプト自体が読めなくなったりします。

もし日本語を含めるのであれば、build.gradleをUTF-8で保存し、gradlew.batのDEFAULT_JVM_OPTSに、-Dfile.encoding=UTF-8を追加することで回避できます。

diff --git a/gradlew.bat b/gradlew.bat
index aec9973..88f1f51 100644
--- a/gradlew.bat
+++ b/gradlew.bat
@@ -9,7 +9,7 @@
 if "%OS%"=="Windows_NT" setlocal

 @rem Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
-set DEFAULT_JVM_OPTS=
+set DEFAULT_JVM_OPTS=-Dfile.encoding=UTF-8

 set DIRNAME=%~dp0
 if "%DIRNAME%" == "" set DIRNAME=.

gradlewファイルは、Windows環境では影響ありませんが、リポジトリを公開する予定があるなら、あわせて修正しておくほうがいいかもしれません。

ビルドタスクの実行

コマンドプロンプトから、buildタスクを実行してください。

F:\mod\TestMod>gradlew build

作成されたjarファイルはbuild/libs以下に、Jarファイルとして生成されます。(たぶん)

なお、2014/01/02の11時時点で、Forge977および982、ForgeGradle1.1のSNAPSHOTな環境で試してみましたが、再難読化(reobf)のタスクで失敗してビルドが成功しませんでした。ForgeやFGのIssue、Forgeのフォーラムでは解決済みという回答が見つかるのですが、上手く行きません。

後日ちゃんと動作したらこの部分は書きなおそうかとおもいます。

Forgeの更新

build.gradleを任意のテキストエディタ開いてください。

以下の箇所を、更新したいForgeのバージョンに修正します。

 minecraft {
     version = "1.7.2-10.12.0.982"
}

build.gradleを修正したら、再度gradlew eclipseを実行して、.classpathなどを更新し、最新の状態をプロジェクトに反映させてください。

これマジで神ですね。٩(๑╹ヮ╹)۶

( っ’ω’c)ﾞ

あとがき

また余計な情報足しすぎて長文になってしまった。ビルドこけるのにハマってめっちゃ時間もかかったし。成長ない氏…。

上記とは関係ない、めっちゃ余談だけど、環境構築中にEclipseプラグインLimyのライセンスがGPLになってるのに気づいた。EPLとGPLって非互換だから、プラグインをGPLで公開してもEclipseじゃ使えないんじゃ…って思ったけれど、例外規定ってのがあるみたい。

Limyがそうなのかはわからないけど、なるほどそういうのもあるのかーって勉強になったので、カテゴリ外だけどついでにメモ。(･ω･)

AwAlog

めもちょー

ちゃちゃっとマイクラMOD開発環境をつくる(2)

対象