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