Ответ 1
Я думаю, что в этот момент будет хороший выбор. Вот почему...
Я не использовал Libdx, но я просмотрел их сайт. Я думаю, что оба проекта выглядят неплохо. Если бы я выбрал Game Engine, мое решение сводилось бы к особенностям, стабильности и поддержке.
Начиная с поддержки, оба проекта, похоже, имеют довольно преданных участников. Майкл Бэйн из PlayN - это машина кодера. Марио из BadLogicGames (libgdx), похоже, довольно предан. У обоих проектов есть здоровая группа участников и защитников.
Что касается особенностей, они, похоже, довольно равномерно совпадают. Оба сделают создание 2D-игры, большой опыт. Libgdx, похоже, имеет преимущество на третьем фронте, но если вы ожидаете, что сможете легко создать игровой опыт KILLER 3D, ни одна из них не сделает тяжелую работу для вас. Libgdx, похоже, не так давно представляет собой 3D-инструментарий, как говорят JMonkey, которые также не могут конкурировать с коммерческими наборами.
Если честно, если вы пытаетесь создать коммерческую 3D-игру, чтобы конкурировать с другими коммерческими предложениями, вам придется лицензировать коммерческий 3D-движок (и иметь довольно компетентную команду). Ни один проект не предоставит инструменты, необходимые для быстрого и быстрого запуска красивых изображений... по сравнению с движком Unity.
http://www.youtube.com/watch?v=Fc9m0Z1GDg8
Ребята из PlayN, похоже, гораздо более осторожны в попытках предложить хорошие 3D-API без ущерба для 2D API и опыта работы с ними. Здесь вы можете прочитать их осторожную дискуссию о том, как лучше всего открыть слой OpenGL ES 2.0.
Подход Libgdx кажется более агрессивным по сравнению. У обоих есть плюсы и минусы. У меня есть некоторые 3D-вычисления в моей игре, используя Vecmath, сидящий поверх PlayN. Этот код, вы можете смешивать и сопоставлять там, где это возможно.
Учитывая, что они являются довольно схожими структурами с точки зрения цели и исполнения, вероятно, будет справедливая битва перекрестного опыления. Вы можете видеть здесь, что большие части поддержки Maven для Libgdx были скопированы из конфигурации PlayN.
http://www.badlogicgames.com/wordpress/?p=2707
Кроме того, libgdx поддерживает только iOS из-за работы, которую Майкл (PlayN) создал для создания IVKM. Затем Марио пришлось добавить поддержку JNI для своих возможностей С++.
http://www.badlogicgames.com/wordpress/?p=2791
Оба проекта знают о другом и взаимно узнают о том, как каждый из них движется вперед.
С точки зрения стабильности, лучше всего оценивать успешные проекты, которые есть у каждого. Tupsu и AngrybirdsChrome на PlayN, Ingress и другие на Libgdx.
PlayN - это чистый java, поскольку он сидит поверх Android/html apis и т.д. Libgdx, похоже, имеет некоторые С++ на некоторых платформах. Это очень зависит от того, что вы делаете, т.е. Для Интернета никакие модули С++ не могут быть скомпилированы GWT. Кроме того, Java имеет сопоставимую скорость с С++ (как правило, немного медленнее, а иногда и быстрее), что позволяет держать GC в состоянии ожидания и не догматично о том, как вы используете язык.
Сказав это, С++ может по-прежнему использоваться в некоторых случаях использования.
Кто-то ответил, что Libgdx может поддерживать огромную пропускную способность спрайтов на одноядерных телефонах, подразумевая, что это связано с С++. Это НЕ область, где libgdx использует С++. См. Функции.
http://libgdx.badlogicgames.com/features.html
Оба фреймворка, вероятно, будут работать аналогично с точки зрения спрайта. Здесь вы можете повеселиться с тестом производительности веб-сайта PlayN. Нажмите на счетчик статистики, чтобы увеличить число.
http://samskivert.com/playn/perf-test/
У обоих есть такие вещи, как меню UI, которые сидят поверх фреймворков.
В конечном счете, я придерживаюсь PlayN, потому что я не вижу реальных причин для переключения и того, с чего я начал. Ваш пробег может отличаться.