現時点では、どちらを選んでも良いと思います。これが理由です...
私は Libdx を使用したことはありませんが、彼らのサイトは熟読しました。どちらのプロジェクトもかなりうまくいっていると思います。もし私がゲームエンジンを選ぶとしたら、機能、安定性、そしてサポートにかかっています。
サポートから始めて、両方のプロジェクトにはかなり献身的な貢献者がいるようです。PlayN の Michael Bayne はコーダーのマシンです。BadLogicGames (libgdx) の Mario はかなり熱心なようです。どちらのプロジェクトにも、貢献者と支持者の健全なグループがあるようです。
機能に関しては、かなり均等に一致しているようです。どちらも 2D ゲームの作成を素晴らしい体験にしてくれます。Libgdx は 3D の最前線で優位に立っているように見えますが、キラーな 3D ゲーム体験を簡単に作成できることを期待している場合、どちらのフレームワークも手間のかかる作業は行いません。Libgdx は、商用キットと競合できない JMonkey ほど長い 3D ツールキットではないようです。
正直なところ、商用 3D ゲームを作成して他の商用製品と競合する場合は、商用 3D エンジンのライセンスを取得する必要があります (そしてかなり有能なチームが必要です)。どちらのプロジェクトも、美しい画像をすばやく作成して実行するために必要なツールを提供しません... Unity のエンジンと比較して。
http://www.youtube.com/watch?v=Fc9m0Z1GDg8
PlayN の担当者は、2D API とその使用経験を損なうことなく、優れた 3D API を提供しようとすることについて、より慎重になっているようです。ここでは、OpenGL ES 2.0 レイヤーを公開するための最善の方法についての慎重な議論を読むことができます。
比較すると、Libgdx のアプローチはより積極的であるように思われます。どちらにも長所と短所があります。PlayN の上にある Vecmath を使用して、ゲームで 3D 計算を行っています。それはコードです。実行可能な場合は、組み合わせて一致させることができます。
それらが目的と実行の点で非常に類似したフレームワークであることを考えると、相互受粉がかなり発生する可能性があります。ここで、Libgdx の Maven サポートの大部分が PlayN の構成からコピーされたことがわかります。
http://www.badlogicgames.com/wordpress/?p=2707
さらに、Michael (PlayN) が IVKM を作成したため、libgdx は iOS のみをサポートします。その後、Mario は C++ 機能の JNI サポートも追加する必要がありました。
http://www.badlogicgames.com/wordpress/?p=2791
両方のプロジェクトはお互いを認識しており、それぞれが前進する方法から相互に学習しています。
安定性に関しては、それぞれのプロジェクトが成功していることが最もよくわかります。PlayN の Tupsu と AngrybirdsChrome、Libgdx の Ingress など。
PlayN は、Android/html API などの上にある限り、純粋な Java です。Libgdx には、一部のプラットフォームで C++ が含まれているようです。これは、何をしているかに大きく依存します。つまり、Web の場合、GWT で実際にコンパイルできる C++ モジュールはありません。さらに、Java は C++ に匹敵する速度 (通常は少し遅く、場合によっては速い) ですが、GC を寄せ付けず、言語の使用方法について独断的ではありません。
そうは言っても、特定のユース ケースでは C++ が依然として役立つ場合があります。
他の誰かが、Libgdx はシングルコアの電話で巨大なスプライト スループットをサポートできると答えており、これは C++ によるものであることを示唆しています。これは、libgdx が C++ を使用している領域ではありません。機能を参照してください。
http://libgdx.badlogicgames.com/features.html
どちらのフレームワークも、スプライトのスループットに関して同様に機能する可能性があります。ここで PlayN の Web パフォーマンス テストを楽しむことができます。数値を増やすには、統計カウンターをクリックします。
http://samskivert.com/playn/perf-test/
どちらにも、フレームワークの上にあるメニュー UI などがあります。
最終的に私は PlayN を使い続けています。切り替える本当の理由はまだ見当たらず、それが私が始めた理由です。あなたのマイレージは異なる場合があります。
私は libgdx に一票です。libgdx は playn よりも広範で、非常に活発なコミュニティがあり、playn でサポートされているほぼすべてのプラットフォーム (一部のサポートは近日公開予定) をサポートし、ドキュメントも充実しています。さらに、特に Android をターゲットにしている場合 (質問が示唆するように)、むしろ libgdx がそのための事実上のフレームワークであると言えます。
私のチームはすでに libgdx で開発を行っており、うまく機能しています。物理演算用に box2d を追加でき、デバッグに悪い Android エミュレーターは必要ありません。すべてはJavaで行われ、プロジェクトをAndroidプロジェクトにインポートするだけで、選択した任意のデバイスで試すことができます. また、windows/web プロジェクトもあり、iOS は間もなく登場します。libgdx を選択することをお勧めします。
私は libgdx を使ったリリースゲームを行ったことはありませんが、私の投票は得られるでしょう。間違ったフレームワークを選択すると、どのプラットフォームでも成功するゲームを開発できなくなるリスクを考慮する必要があります。playn を見たところ、ドキュメンテーションがなく、ユーザーグループの活動がなく、十分に進んでいないようです。両方のプラットフォームをサポートするはずの Cocos2d-x も考慮する必要があります。少なくとも Android 側でゲームを書くためのプラットフォームとして libgdx は止められないと感じています。
libgdx は、一部が C++ で記述されているため、非常に高速です。このフレームワークを使用すると、1 つのコアの電話で数百のスプライトをスムーズに移動できます。インストールと操作は簡単で、コミュニティはすべての質問に迅速に回答します.
libgdx を使用して大規模な戦略的オンライン ゲームを作成します。それは素晴らしいです。これは速い。サポートは良いです。ドキュメントは以上です。ios は robovm でサポートされ、まもなくマルチ OS エンジンも libgdx に実装されます。Javaに堪能な場合。libgdx が最良の選択です。
私はこれまで Libgdx しか使ったことがないので、この 2 つを実際に比較することはできません。Libgdx については、開発を開始する前に確認できるリソースと例が非常に多くあります。多くのサポーターがわかりやすいチュートリアルを書いているので、かなり習得しやすいです。