Розробка інді-гри на Starling, або друге життя Flash

З точки зору графіки більшість інді-ігор завойовують свою популярність не кількістю полігонів в кадрі або супер-якістю текстур, а незвичним підходом до арту і увагою до дрібниць, причому більшість використовує тільки 2D графіка. На мій погляд, для проектів у такому стилі відмінно підходить Flash. Під флешем в даному випадку слід розуміти не тільки плагін для браузерів, який поступово здає свої позиції і поступається місцем HTML5, а саму «еко-систему», яка дозволяє використовувати можливості і «ідеологію» флешу для розробки під десктоп і мобільні платформи. Мова піде про Adobe AIR (кроссплатформенне середовище для запуску додатків) і фреймворку Starling, що використовуються в розробці інді гри.

Під катом - приклади практичних рішень та анімації ефектів.

З вектора до растру

Проект являє собою просунутий порт колись популярної флеш-гри для Steam, зрозуміло, в розширеному вигляді (наприклад, число рівнів збільшилося з 30 до 200 +), і багато «підводних каменів» довелося обходити заново, вже на іншій платформі.

У початковій флеш грі використовувалася растеризація контенту при старті програми (точніше, при першому переході з головного меню на екран вибору рівень). Кожен кадр з кожного MovceClip'a зберігався в окремому об'єкті BitmapData. Зрозуміло, рішення було дуже «сокирою», але для простий флеш гри підходило непогано.

У варіанті гри для Steam (а згодом, можливо, і для мобільних платформ) цей варіант не підходить з двох причин:

1. Великий обсяг займаної пам'яті після растеризації. Дані в MovceClip в Starling передаються через масив текстур. Текстура може бути не тільки завантажена з файла, але створена з використанням даних з BitmapData. Правда, такому випадку варто пам'ятати, що Starling (точніше, stage3D, на якому він побудований) використовує текстури висотою і шириною рівного ступеня двійки. Тобто. зображення розміром 130x160 пікселів матиме «розмір» у пам'яті рівний 256x256.

2. Ще один мінус - велика кількість draw call'ів. На щастя, у Starling є автоматичний батчинг зображень (виведення декількох спрайтів за одне звернення до графічного API), якщо вони знаходяться всередині однієї текстури.

Вирішення проблеми: використання текстурних атласів.

Спочатку планувався варіант генерації атласів «на льоту», використовуючи DynamicTextureAtlas, а вся графіка гри зберігалася б у векторному вигляді.

Після тестового запуску з'ясувалося, що ресурси flash-гри (у вигляді swc - бібліотеки класів із закритим вихідним кодом) повинні мати чітко визначену структуру, що не підходило для вже наявних напрацювань. Також з'ясувалося, що перетворення вектора на растр (по суті - відмальовка кожного об'єкта покадрове, причому саме засобами Flash) займає досить багато часу, і, чим більше був розмір об'єкта в грі, тим більше часу займала растеризація (зрозуміло, що розміри всіх елементів в пікселях для екранів роздільною здатністю 800x480 і 1920x1080 будуть відрізнятися в рази).

По суті, це вбивало всі плюси використання векторної графіки, а саме - масштабованість без втрати якості. Вихід був один, класичний - використання заздалегідь створених текстурних атласів.

Від анімації - до частинок

Після збереження всієї графіки у вигляді png файлів і створення атласів з'ясувалося, що близько 70% місця займають кадри різних ефектів, причому часто досить простих. Вирішення проблеми було очевидно - заміна об'ємних анімацій (перетворених з вектора) в анімації, створені зі складових частин. Це дає істотну економію місця, тому що, скажімо, ефект вибуху зірки (показаний нижче), збережений покадрово і поміщений в атлас, займав би текстуру розміром 1024x1024 пікселів, яка б зайняла в пам'яті 4 Мб, тоді як складові частини анімації сумарно займають не більше 128x128 пікселів.

Приклад частини текстурного атласу з окремими кадрами анімації:

І складові частини ефектів:

Створення редактора часток

Спочатку я планував використовувати базове розширення для Starling (Particle System), але після збору тестового проекту виявився ряд речей:

1. Навіть найбагатший вибір налаштувань не дає того, що можна самому змінити в коді. Наприклад, формулу зміни швидкості польоту частинки.

2. Редактор «заточений» в першу чергу на реалістичний показ постійних джерел частинок. Приклад - полум "я палаючої свічки. У нашій же грі більшість ефектів по суті є вибухами.

Приклад ефекту з редактора Particle System:

У підсумку було вирішено використовувати самописний редактор ефектів.

Плюси - можливість підключати не тільки систему частинок, але і додати спрайти-підкладки з змінюваними скейлом, швидкість повороту і альфою, а набір параметрів створений виходячи з бажань дизайнера. Кожен з ефектів складався з декількох шарів. 3 нижніх шари - для окремих спрайтів, які змінюють свій скейл, кут повороту і прозорість. 3 верхніх - для партіклів, які, як правило, розлітаються з однієї точки.

Приклади ефектів

Порівняння ефектів з флеш-версії і зроблених в редакторі:

1. Анімація вибуху (ліворуч - флеш версія):

2. Анімація взяття об'єкта (зірки), ліворуч - флеш:

Окремим плюсом версії з частинками є налаштовуваний елемент випадковості - кожен вибух/ефект (одного типу) виглядає за різним, оскільки кількість частинок, їх розмір і швидкість варіювалися в певних межах, що задаються в редакторі.

Ефекти обробки зображень

Ще один плюс роботи зі Starling'ом - доступні «з коробки» ефекти обробки зображень. Дані ефекти в грі використовуються в декількох місцях, наприклад, після виграшу і появи меню результатів сам фон рівня (і об'єкти, що залишилися на ньому) поступово змінюються.

Спочатку ми, так само як і у флеш-версії, хотіли зробити ефект, коли картинка рівня поступово «заблюривається», обертаючись по годинниковій стрілці (все це йде «фоном», під меню результатів рівня). Але у версії зі Starling використання цього ефекту дуже різко зменшувало fps, навіть у PC-версії гри (з 50-60 до 2-3 кадрів на секунду).

Замість цього було вирішено використовувати ефект «вицвітання» (йде «змійкою» зліва направо і зверху вниз за елементами), змінюючи прозорість об'єкта і дані матриці фільтра ColorMatrixFilter, що дозволило зробити досить видовищний ефект без просадки fps.

Висновки

На закінчення можу сказати, що вся еко-система Flash дозволяє дизайнеру і програмісту «спілкуватися однією мовою» при створенні і поліруванні графіки, що дозволяє приділяти більше уваги дрібницям, які і створюють атмосферу гри, а проблеми з продуктивністю, що виникають при «сокирних» рішеннях, змушують шукати обхідні шляхи і іноді змінювати деякі концепції, що часто йде на користь кінцевому продукту.