サイトのトップへ戻る

libGDX ドキュメント 日本語訳

サイト内検索

libGDX への貢献活動

libgdx への貢献活動は簡単です:



API の変更と追加

public APIを変更したり新しいAPIを追加した場合は、それらの変更内容をリポジトリのルートにあるCHANGESファイルに記載するようにしてください。 CHANGES ファイルに加えて、blogTwitterでも変更内容を公開してコミュニティ全てに周知してください。

他の開発者の知恵を借りたい場合は、Github上でプルリクエストを送信して会話するか、このサブフォーラム上で新規スレッドを作成してください。 You will need special forum permissions, write an e-mail to contact at badlogicgames dot com and tell me your forum id. You should also subscribe to that forum via e-mail, there's a button at the bottom of the page. You can also drop by on IRC (irc.freenode.org, #libgdx), where most core devs are lurking.



コード提供者ライセンス同意書

Libgdx には Apache 2.0 ライセンスが適用されています。 コードを提供する際には、コード提供者ライセンス同意書(CLA)に署名していただく必要があります。 規約をプリントアウトして空欄を埋めて、そのコピーを[Libgdx] CLAという題名を付けてcontact@badlogicgames.comへ送信してください。

コード提供者ライセンス同意書(CLA)に署名していただくことで、我々はあなたのコードの使用や配布ができるようになります。 このライセンスは通常実施権(non-exclusive license)なので、コードに対する権利は全てあなたに帰属します。 これは、重要なコードを提供した人が後からそれを取り返そうとするのを防ぐためのものです。



Eclipse フォーマッター

libgdx のコードを編集する場合は、リポジトリのルートティレクトリにあるEclipse フォーマッターを使用してください。

フォーマッターを使わないと、開発者であるネイト氏に非常に迷惑をかけてしまいます。

IntelliJ IDEAを使用している場合でも、Eclipse コードフォーマッターを使用することができます: この記事を参照してください



コードスタイル

Libgdx には公式の標準コーディング規約はありません。 大抵は通常のJavaスタイルに従っているので、あなたもそうしてください。

やって欲しくないことがいくつかあります:

  • アンダースコアを付ける
  • ハンガリアン記法を使う
  • フィールド変数や引数に接頭辞を付ける
  • 中括弧で改行する

既存のファイルを編集する場合は、そのファイルで使用されているコードのスタイルに従ってください。 可読性を損なわないのであれば、中括弧は省略しても構いません。

新しくファイルを作成する場合は、ここで見られるようなApache ファイルヘッダを追加してください。

新しくクラスを作成する場合は、少なくともクラスの使用方法やスコープについて説明するためのクラスドキュメントを追加してください。 メソッドの使い方が一目で分かるような場合はJavadoc を省略できます。

あなたが追加するクラスが明示的にスレッドセーフである場合は、Javadocに明記してください。 コードベース上で負荷の高いロックの数を減らすため、既定ではクラスはスレッドセーフではないものと見なされます。



クロスプラットフォームの互換性

GWT バックエンドでは全てのJava機能をサポートしている訳ではありません。 汎用のコードを記述する場合は、いくつかの一般的な制限事項について注意してください:

  • 書式指定。 String.format() は使用できません。代わりに StringBuilder を使用するか、 文字列を直接連結してください。
  • 正規表現。パターン処理マッチング処理の基本的な機能が提供されています。
  • Javaリフレクション。 代わりに com.badlogic.gdx.utils.reflect パッケージ内のユーティリティを使用してください。
  • マルチスレッド。タイマーのみサポートしています。

新たにクラスを追加する場合はそれらにGWT との互換性を持たせるか決め、GWT モジュールへの要素を含めるか除外するかしてください。

特定の互換性やネイティブコードが原因で、(Matrix4 や BufferUtilsのような)いくつかのクラスはGWTバックエンドではエミュレート環境で動作します。 これらのクラスを編集する場合は、その変更がエミュレートバージョンでも動作するか確認してください。



パフォーマンス上の考慮事項

Libgdx は、ブラウザ(JavaScript!)を含むデスクトップと携帯端末の両方で動作するように設計されています。 While the desktop HotSpot VM can take quite a beating in terms of unnecessary allocations, Dalvik and consorts don't.

いくつかガイドラインがあります:

  • 可能な限り、一時的なオブジェクトの割り当てを避ける
  • ディフェンシブコピーは作成しない
  • ロックを避ける。明示的に指定しない限り、既定ではlibgdx のクラスはスレッドセーフではありません
  • ボックス化されたプリミティブ型は使用しない
  • com.badlogic.gdx.utils パッケージのコレクションクラスを使用する
  • フレームごとに何千回も呼び出される可能性のあるメソッドでは引数チェックを実行しない
  • 必要であればプール処理を使用する。APIが複雑になるので、可能であればユーザーがプール処理に触れられないようにする。


Git

libdgx チームメンバーのほとんどは Git 初心者なので、今は使い方を地道に学んでいるところです。 間違いが発生した場合のリスクを減らすため、プルリクエスト(pull requests)はできるだけ小分けにして実行してください。 一度に3000ものファイルを変更したりすると、上手くマージされない可能性があります。

APIに大幅な変更を加える場合、我々は新しくブランチを切ります。新たなAPIを追加する際には、追加対象にするブランチに間違いがないか確認してください。

マスターリポジトリへのプルリクエストは、実装される前に複数の中心的コード提供者によってチェックされます。 内容が不十分だったり不適切だった場合は、あなたのマスターリポジトリへのプルリクエストを拒否することがあります。 拒否されたとしても怒らないでください。 Libgdx は世界中の何千ものプロジェクトで使用されており、適切で安定したものにする必要があるのです。

LibGDX ではForked Public Projectの手法が使われています。 このページのチュートリアルが、このプロジェクト形式に関連するGit コマンドを理解するのに役立つでしょう。




エンジェル戦記