Пишем игру для Android c помощью AndEngine. Часть 1

[Artouiros]

Как же я ждал, когда кто-то расскажет про гейм дев на андроиде. Благодарю.

[spam]

Хорошо, но мало, жду следующей части.

[MAGnitos]

Ога, маловато. Потренироваться хочется…

[stepango]

Ждал подобных комментариев, вторая часть на подходе:)

[helm2004]

SourseFroge (:. А за статью благодарю.

[helm2004]

Извиняюсь, SourceFroge.

[stepango]

Спасибо, исправил.

[S0ulReaver]

Интересовался движком, но когда увидал скорость на простейшей демке — ужаснулся. Мб мой кривокод, но вроде не было ничего сверх. Кроме того почему-то при движении спрайтов наблюдал некоторую дёрганность.

[Alex42rus]

С нетерпением буду ждать еще. Прям то что надо!

[OlexU]

Работал с этим движком, в принципе для простым игр с небольшим количеством спрайтов работает вполне сносно, даже на слабых устройствах. Из своего опыта могу сказать что для того чтобы сборщик мусора не 'насолил' вдальнейшем, лучше регионы текстур сделать public static, и вызывать как член класса, а не через метод, конечно нарушается инкапсуляция, зато скорость возрастает, что важно для конечного пользователя. Вообще в разработке Java игра под андроид лучше по возможновти:
1. Делать все статичным
2. Делать вызовы членов класса, вместо методов
3. Абсолютно нигде не использовать списки и коллекции (List, Collection), а только массивы

[stepango]

Вы правы, эти советы можно найти на developer.android.com/ А по поводу третьего пункта, к сожалению, вся отрисовка в AndEngine использует вложенные списки, в связи с этим и потери в скорости, как плата за универсальность.

[stepango]

Помимо того что кокос в глубокой альфе и последний коммит был почти год назад?:)

[stepango]

Есть еще libgdx делал на нем одну мелкую игрушку, тогда он мне показался медленным и сложным. Конкретно эти движки не сравнивал.

[romeo_ordos]

libGDX

[stepango]

Извиняюсь за дезинформацию. Cocos2d-android активно развивается, смотрел не в тот репозиторий github.com/ZhouWeikuan/cocos2d

[romeo_ordos]

Писали проект на этом движке. Зависли на низкой производительности средне-ценовых девайсов. Движок очень легок в изучении и довольно гибок, но для чего-то серьезного его использовать не получится.

[rimmer]

У меня вопрос. Почему Camera всегда 800х480? Я просто не силен в этом, прошу объяснить, что это за зверь.

[romeo_ordos]

Необязательно 800x480. Можно использовать любое другое разрешение. Я, например, для Desire юзал 666x400. Все зависит от игры, которую вы делаете.

[Kirhgoff]

Я еще не попробовал библиотеку, но по-моему, Camera — это вроде как viewport — та область, которую пользователь видит на экране. Если большая карта, что не влезает на весь экран, камера может ездить по ней вместе с прогуливающимся персонажем.

Вот тут сорцы

[irafa]

использовал движок в 2х играх, впечатления только положительные. Автор движка очень активно его развивает, есть библиотеки для работы с Живыми обоями, Дополненной реальностью и т.д. Пробывал другие 2D физические движки, этот лучший.
Но ушёл на Unity 3D так как возможностей AndEngine уже не хватает.

[stepango]

Отсутствие поддержки 3d конечно минус AndEngine.

[Homakov]

скажите, а можно игры на titanium /appcelerator делать?

[stepango]

Я не вижу никаких препятствий:)

[IgorMats]

Я немного не понял, а зачем следить чтобы текстуры не пересекались?

… ure, activity, «gfx/laser_gun.png», 800, 0)…

Тут же вроде как последние 2 аргумента это posX и PosY, как получается что 800? За пределами экрана? Знаю, что нет. Можете объяснить?

[stepango]

В итоге на всю игру у нас всего одна текстура размеры ее в нашем случае размерами 1024х512 когда рисуется какой нибудь объект — рисуется часть этой текстуры-атласа. Ширина первой текстуры расположеной в атласе 800 пикселей, тоесть 0-799 если мы расположим текстуру начиная с 800 пикселя они не будут пересекаться и следовательно не будет никаких сюрпризов при отрисовки этой части текстуры. Вы можете сами поэксперементироваь и посмотреть что получится если текстуру лазерной пушки разместить в 0:0.

[IgorMats]

Да, действительно. Глупый оказался вопрос :)
Спасибо огромное!

[uncleLem]

Я тут начал разбираться с AndEngine и заметил, что разработчики не сильно заморачиваются с обратной совместимостью: некоторые классы переименовываются, некоторые методы становятся @Deprecated и т.п., что, в комплекте с отсутствием документации сбивает с толку. С одной стороны хорошо, что проект развивается, а с другой — подобные статьи теряют актуальность. Из того, что сейчас заметил:

Texture => BitmapTextureAtlas
TextureRegionFactory => BitmapTextureAtlasTextureRegionFactory

Пока что все. Если еще что-то замечу — отпишусь. Может, в будущем это кому-то сэкономит немного времени.