Михаил Деревянных

Работал с двумя движками. На LibGDX писал свою первую мобильную игру. На Cocos2d-x делаем сейчас с небольшой командой по-настоящему глубокую и обширную, если так можно выразиться, аркаду. По этому опыт работы с этими двумя движками есть. Буду писать только по различиям.
LibGDX:

• Если хорошо знаешь Java - выбирай его, не задумываясь
  
• Есть немалое количество туториалов на тему этого движка и готовых игр, а так документация на хорошем уровне
  
• Не требует высокого уровня программирования
  
• К сожалению, многие фреймворки, различные расширения для игр, анимационные стандарты, рекламные сервисы не поддерживают движок
  
• Это джава. Она всегда лагает. Её с плюсами даже сравнивать нельзя
  
• Частенько придется писать платформозависимый код, как на Java для Android, так и на Objective-C для iOS
  

Теперь о Cosos2d-x:

• Знаешь C++ - выбор сделан
  
• Очень производителен в 2д разработке. Обходит по скорости даже юнити, про libgdx даже молчу. Но нужна ли тебе такая производительность?
  
• Из-за того, что движок очень популярен, поддерживается большинством фреймворков, рекламных сетей, но ни так, как юнити. Это все же надо понимать.
  
• Полностью кроссплатформенный. Есть даже встроенные средства для добавление поддержки внутриигровых покупок для iOS и Android одновременно, без написание кода под каждую ОС.
  
• Открытый код. Постоянно развивается засчет этого движок.
  
• Отличная архитектура у движка
  
• Пи#здец, как мало туториалов и статей. А документация просто ужасная
  

А что тут такого особенного? Мы создаем некий класс Map, который хранит в себе:

• Текстуру (или айди текстуры, я не помню уже, как там устроено в libgdx, или же ты её при создании объекта назначаешь)
  
• Массив, содержащий вот эти кнопочки, при нажатии на которых игрок попадает на новый уровень). Эти кнопочки расставляются автоматический на основе ранее заготовленных данных. Эти данные - обычный массив, содержащий информацию о номере уровня(ну или названия, как тебе удобнее), на которой игрок перейдет, а так же хранящий координаты расположения этой кнопки на текстуре (эти данные ты можешь в каком-то конфиге хранить удобного для тебя формата, json на пример, и при запуске игры их парсить)
  

Ничего такого сложного нет... С первого взгляда может показаться тебе громоздким, но по сути нет.

1. Если в игре не используется физ. движок Box2D, то коллизия определяется простыми проверками x, y двух объектов. Т.е. строиться некий цикл:
for(int i=0; i second_object.x && first_object.x < second_object.x + second_object.width && firs_object.y + first_object.height > second_object.y && first_object.y < second_object.y + second_object.height)
collisia = true;
}
}
Но такой способ подойдет не всегда, и если ты создаешь платформер, то чаще всего лучше воспользоваться движком Box2d. Именно в твоем случаи с вращением лучше его и использовать.
2. Box2d - suvitruf.ru/2012/12/22/2764
habrahabr.ru/post/162079
(вроде от одного автора)