Pull to refresh

Comments 12

Нужно не краткое введение, а полномасштабное…
В принципе, по своему API MOAI точно такой же, как Cocos2D или вообще любой другой 2D движок. Имеет смысл разве что сделать туториал на русском, но на английском они уже есть. Хотя возможно что-нибудь подобное сделаю :)
У каждого есть свои особенности и подводные камни. Это всё хотелось бы узнать.
Ну… к примеру, у MOAI явно выражена модульная архитектура, большинство полезных плюшек — интеграция с фейсбуком, tapjoy и прочее реализуется при помощи плагинов. К примеру, даже звук можно подключить используя две разные библиотеки — fmod или untz. Что касается движка физики- используется Chipmunk.
Из непривычного в MOAI — необычное именование объектов. К примеру, спрайт называется prop. В туториале поясняется, почему так — в реальных приложениях в sprite запихивают кучу дополнительных свойств, превращая его в игровой объект. К тому же, под спрайтом часто понимают саму текстуру, что также вносит путаницу. В целом, именование классов в MOAI выбрано, чтобы по смыслу максимально кореллировало с терминами OpenGL.
Одним словом, MOAI довольно низкоуровневый фреймворк, поэтому API его сделано так, чтобы это взаимдействие не вуалировалось.
Прошу прощения — используется Box2D движок физики. Хотел написать, что Chipmunk не используется, но вместо этого машинально написал все наобарот :)
Пример его «низкоуровневости» хотя бы в том, как реализована сборка под различные платформы. В MOAI под любую платформу должен быть запущен объект MOAISim, который представляет собой что-то наподобие виртуальной машины, хотя в реальности MOAISim сделан по принципу паттерна Адаптер.
Этот MOAISim запускает в себе Lua код из main.lua файла (на самом деле, если посмотреть исходники, за непосредственно запуск отвечает код в библиотеке AKU, и именно там идет разделение по плафтормам, но это не суть важно).
Сборка под конкретную платформу сводится к тому, чтобы во-первых собрать сам MOAI (и MOAISim), упаковать Lua код в приложение, а также связать железо с соотвествующими вызовами в MOAI. Последним занимается код, написаный в нативном для конкретной платформы виде. К примеру для андроида можно увидеть, что Android Host представляет собой стартовый Activity, в котором запускается Moai через JNI.
Для iOS — это AppDelegate, в котором происходит примерно то же самое. Естесственно, хосты-заготовки уже есть, но часто их нужно адаптировать под свои нужды. К примеру, затачивать под Landscape/Portrait и т.п.
Теме не менее, по своим возможностям, он практически идентичен Cocos2D. Те же спрайты (только названые по-другому), те же Action (с ease функциями), та же возможность загружать текстуры в виде разделных картинок, так и кучу спрайтов в одной текстуре. При этом логика пишется на Lua, что очень сильно ускоряет разработку.
На практике, скорость разработки заметна ускоряется еще и из-за возможности запускать примеры прямо на компьютере — сборки MOAI есть практически под любую платформу. По крайней мере, Windows, Linux, Mac OS X, Android, iOS, windows phone и blackberry — на счет работоспособности двух последних не в курсе, но сборки есть.
Ну и есть возможность использовать дополнительные библиотеки вроде RapanUI — они действительно уменьшают количество кода при разработке.
Вопрос к автору и/или тем, кто имел дело с этим фреймворком.
Если я правильно понял, то он работает как LUA интерпретатор, т.к. JIT запрещён, а в статику (как Marmalade или Xamarin) он не компилит. Как у него со скоростью?
MOAI целиком написан на C++, Lua используется только для написания логики самого приложения. К примеру, вызов функции загрузки спрайта из Lua — это просто биндинг, то же самое касается анимаций и пр. Поэтому, проблем с производительностью не будет.
Но если нужно написать какую-то тяжелую функцию, например, если вам нужен bson парсер, то реализовывать ее придется на C++ и делать биндинг. В принципе, это стандартный подход при разработке приложений на скриптовых языках — если не хватает производительности, то конкретный участок переписывается на C/C++.
На практике, у меня в приложении есть реализации бинарного протокола, который я полностью реализовал на Lua, каких-то проблем с производительностью я не заметил.
Это фреймворк только для игр или обычные приложения тоже можно писать?
Это прежде всего игровой движок. Т.е. обычные приложения тоже можно писать, но это имеет смысл, только если будет специфическая графика, не похожая на родную для каждой из платформ. К тому же, приложение всегда будет использовать OpenGL, так что для обычных приложений — это не самый лучший вариант.
Sign up to leave a comment.

Articles