Particle эффекты в мобильных играх

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

Погуглив некоторое время, я пришел к выводу, что мне необходим редактор частиц и библиотека их визуализации, совместимая с OpenGL ES 2.0, интеграция которой в движок пройдет с наименьшими трудозатратами. Согласитесь, ведь это удобно иметь возможность настроить все параметры эффекта и в пару кликов интегрировать его в игру.

Итак, я посоветовался с коллегами, они посоветовали посмотреть в сторону Particle Deisgner от 71Squared и Magic Particles от Astralax.

Particle Designer

Particle Designer выглядел довольно соблазнительно, к тому же я уже был знаком с их продуктом Glyph Designer.

Из больших плюсов Particle Designer:

  1. внушительный список интеграции с популярными фреймворкам
  2. красивый и удобный дизайн
  3. приличная библиотека эффектов.

Из минусов:

  1. отсутствует информация о базовой интеграции с OpenGL (в нашем случае у нас был самописный движок на C++).
  2. DemoApp на сайте был на Objective C (для нас минус, так как ориентируемся мы на с++)
  3. Программа работает только под Mac.

В целом мне все понравилось и я был уже готов перепилить/нарыть версию для C++ и работать с ним, но в последний момент коллега все же настоял на Magic Particles.

Magic Particles

Ну, скажу сразу прямо: я доволен что мы выбрали этот продукт. Поначалу возникли сложности, в частности с тем, что у MagicParticles был враппер под OpenGL fixed pipeline, что меня расстроило, и пришлось переписывать враппер на OpenGL ES 2.0. Не знаю как у других, но у меня возникают трудности при отладке OpenGL кода, так как не часто приходится писать OpenGL код, и, как обычно бывает, написал и забыл. О сложностях с OpenGL я расскажу в отдельной статье.

Итак, пришлось писать враппер для iOS под OpenGL ES 2.0, это заняло не очень много времени, приблизительно пару дней. В ходе написания пришлось вникнуть в структуру работы библиотеки и параллельно консультироваться с автором продукта. На удивление, он оказался доброжелательным и общительным человеком и помогал по всем вопросам, возникающим у нас по работе библиотеки и программы.

Кстати, после моего обращения автор программы посмотрел в сторону мобильных платформ и сделал новый враппер, поэтому, скорее всего, вам будет легче чем мне.

Из плюсов отмечу:

  1. хорошая библиотека эффектов
  2. средства по оптимизации текстур
  3. широкий выбор настроек эффектов
  4. различные врапперы для отрисовки, из которых можно слепить, по сути что угодно
  5. компилируемый формат эффектов, все компилируется в один файл, в т.ч. и текстуры, что может повысить производительность

Из минусов:

  1. работает только под windows (особенно меня огорчило)
  2. после долгой работы редактор частиц начинает жутко тормозить
  3. некоторые настройки далеко не интуитивны

На что стоит обратить внимание

Так получилось, что мы разрабатываем прототип игрушки на еще неоптимизированном движке, поэтому у нас присутствует довольно большое количество лишних прорисовок, да и вообще OpenGL вызовов. Я точно неуверен из-за этого ли, или по другим причинам  в игре изрядно упала производительность, когда мы начали использовать частицы, но проблема была и нам пришлось браться за оптимизацию.

Тормоза сильно были заметны только на iPhone 4S (минимально мы на него ориентировались) на iPhone 5 было заметно намного меньше, но все таки жутко раздражало. Вообще автор программы написал неплохое руководство по оптимизации эмиттеров для игр, куда мне следовало бы посмотреть первым делом, тогда бы я возможно не столкнулся со следующими проблемами.

Размер текстур

Да, да, первым делом мы уперлись именно в это, и это правда очень сильно влияет на скорость. Все просто:

чем больше соотношение размер частицы / размер текстуры, тем эффективнее будет прорисовка.

Еще удобно, что большинство эффектов не требуют изображений высокого качество, поэтому когда частицы больше размера текстуры и текстура растягивается, OpenGL размывает их и получается все довольно красиво. В идеале, если частица должна смотреться четко, то текстура должна быть размером 1:1.

Количество частиц

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

Используйте как можно меньшее количество частиц, позволяющее достигнуть приемлемого вида эффекта. Опыт показал, что уменьшение количества частиц зачастую практически не влияет на качество эффекта, но, соответственно, повышает производительность.

Прорисовка

Разумеется, в моем случае, наибольшую эффективность имела оптимизация прорисовки эффектов. В нашей 2D игре все эффекты находятся на одном слое по отношению к зрителю, а также ресурсы эффектов находятся в одном атласе, поэтому первое что приходит в голову - это рисовать их в один проход, что и было сделано. Но я столкнулся с одной проблемой - один и тот же эффект может включать частицы с используемой интенсивностью и без нее, то есть разные частицы могут иметь разную glBlendFunc.

В связи с этим я решил разделить эффекты на два слоя - без интенсивности и с интенсивностью, и рисовать их в два прохода, соответственно. Но это стало возможным только в рамках задач текущего проекта, так как в нем все эффекты не включали смешивания слоев с разными режимами блендинга. Саму прорисовку я так же оптимизировал, используя VAO, в итоге, все в совокупности дало резкий прирост производительности и нормальную скорость.

В итоге что дают нам частицы?

Мы имеем возможность дизайнить эффекты в отдельном редакторе и в пару кликов встроить их в игру, не заморачиваясь с их отображением. Все сводится к тому, что мы просто запускаем эффект с нужным именем и в нужном месте, что, несомненно, избавляет нас от большого геморроя.

Из минусов могу отметить только то, что используя такой подход, не получится добиться единообразия использования эффектов, например, с flash-версией игры.