[LibGDX] Создаем клон Flappy Bird — Zombie Bird

Это просто… просто… Эпичный пост! Поделите на несколько частей, прошу. Где-то на дне третьем-четвёртом начинается взлом мозга и текст перестаёт читаться.

З.Ы. По теме — недавно начал присматриваться к libgdx, тем более (по секрету, никому не говорите), dim_s упоминал о прикрутке оного к Jphp.

Ого. Действительно огромная статья, но и занимательная. Пост месяца, я б сказал. Спасибо! Как раз интересовал libGDX.

на глаз ширина экрана примерно 135-136 пикселей

Зорький у вас глаз :)

Воу! Серьезный докУмент! Спасибище! :)

PS:
Когда уже придумают заливку данных с компа прямо в мозг?! >__<
Авторы DIY хаба, ну же!

Кстати, и когда уже libGDX начнет поддерживать WP? :(

Интересная статья, спасибо. Я использую другой фреймворк для игр и тоже делал клон этой игры. Было интересно узнать и сравнить как то же самое делается в LibGDX и Java. Как и предполагал кода больше, но можно настроить всё намного тоньше.

Спасибо! Именно libGDX сейчас и хочеться поучить. Как всегда, вовремя!

Прочел статью, заметил несколько интересных моментов:

1) Импорт проекта. Как замечено в статье, используется Gradle, поэтому и импортировать проекты нужно именно как Gradle. То есть, нужно установить Gradle плагин, после этого использовать Import->Gradle->Gradle Project. Способ, что в статье, вряд ли будет работать. Еще — скриншоты явно не чистого Eclipse, а Android Studio. Разве что Android Studio автоматически умеет определять тип проекта и импортировать его.
Вот пруф из официальной вики libGDX —

А дальше по тексту сказано — «Откройте gdx-setup-ui.jar, как мы проделали это в Дне 2.». И приводится другой скриншот, из старого установщика. То есть, в libGDX есть два установщика. Устаревший делает все как сказано в туториале сначала, и не требует Gradle. Но у в статье перемешаны скриншоты из нового и старого, а инструкции все для старого.

2) Использование стандартных коллекций — не лучшее решение. В libGDX есть свои коллекции с преферансом и поэтессами. Из плюсов библиотек — они экономнее относятся к памяти (при итерировании for(String s: array) не создается новый итератор, а переиспользуется текущий), интерфейс обьективно удобней (тот же Array можно использовать и как массив, и как стек), удобная работа с пулами (можно сразу освободить Array обьектов в пул).
Ссылка на коллекции в libGDX —

3) Использование Gdx.app.log(«GameScreen FPS», (1/delta) + "") — это «самопальное», хоть и правильное решение. Для этих целей в libGDX есть стандартный класс —

4) «Я забыл упомянуть (вы скорее всего уже и сами поняли), что мы будем использовать Y-Вниз» — по умолчанию в libGDX используется система координат, где (0, 0) — левый нижний угол, то есть У-вверх.

5) Самопальный AssetLoader — это подходит лишь для небольших проектов. В libGDX есть встроенный менеджер ресурсов — AssetManager, который позволяет грузить текстуры, звуки, шрифты и другие ресурсы. Менеджер расширяемый, можно писать свои загрузчики для собственных типов ресурсов. Также он позволяет делать асинхронную загрузку (можно делать загрузочный экран с отображением прогресса). Ссылка —

6) Использование ShapeRenderer — это неэкономичная штука. Если хотите залить задний фон чем-то — лучше используйте для этого SpriteBatch с текстурой. Также совместное использование SpriteBatch и ShapeRenderer может вызвать проблемы. ShapeRenderer рекомендуется использовать для отладки. Вот здесь люди жалуются на медленную скорость работы ShapeRenderer —

Вообще, такое впечатление, что автор статьи использовал какую-то старую версию libGDX. Эту же игру можно было бы очень просто написать, используя Stage и Actor. Отпадает сразу целая куча проблем:

1) Мультиэкранность — Stage умеет автоматически растягивать экран, сохраняя пропорции
2) Проблема с Y-down — не нужно вращать текстуру
3) Удобный ввод — уже реализован удобный UI с кнопочками, скроллами, текстовыми полями и всем таким
4) Tween Engine — не нужно его использовать, есть механизм Actions, который и удобней, и быстрее, и экономичней (Actions возвращаются в пул после использования).

Также я не уловил момента с текстурой. Как я понял, там текстурный атлас — но не увидел файла описания к этому атласу. Если его нет, а мы указываем вручную координаты нужных кусков — это рукалицо. Я так делал когда-то тоже, это получается ужас в сопровождении. Есть утилита GdxTexturePacker — она делает атласы, потом одной строчкой кода они грузятся. Есть встроенные в libGDX классы которые тоже умеют делать атласы.

Использование wav — как по мне, лучше использовать mp3. Банально занимает меньше места, а за счет того, что звуки можно грузить в отдельном потоке, паралельно с текстурами, загрузка не займет больше времени, а результирующий файл игры будет меньше.

Не сочтите, что я придираюсь, это хорошо, что появляются такие статьи. Дело в том, что я пишу на libGDX уже три года, и такие мелочи замечаются на автомате. Данную игру можно сделать за день, используя все возможности libGDX, а не используя его лишь как рендерер.

В общем, за статью как переводчику вам плюс, но данную игру можно было бы написать намного проще. Если кому-то будет интересно — могу на днях написать более правильный, на мое мнение, туториал.

Спасибо за прочтение столь длинной простыни текста!

Я знаю, тут больше про код… Но не могли бы вы дать пару ссылок на хорошие статьи про «разочарование-награда-зависимость»?
Догадываюсь, что даже на хабре были подобные, но не могу найти.

А пост шикарный, да:)

Я попробовал пройти этот туториал, но он реально устарел. libGDX генерит немножко другую структуру, все билдится не так гладко, как хотелось бы, в общем на 6 дне оказалось, что сгенеренные конфиги не могут найти картинку в соседнем модуле, а так как я в мире джавы новичок — не смог даже нормально нагуглить решение.

Я уж думал что это original content. Но к середине статьи закралось сомнение. И оп, точно, перевод!
Но всё равно спасибо за труд!