Що таке “Кубок ігрового спалаху”?

Кубок ігрового спалаху (вочевидь, назва пішла від дослівного перекладу англійського Flash Game Contest) – це конкурс так званої “швидкої розробки”, який організовується російською спільнотою флеш-розробників на базі тематичного форyму FlashGameDev.ru.

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

Судять конкурс 11 членів журі, імена яких в сфері флеш-розробників відомі кожному. Скажімо, до цьогорічного складу журі входили Максим Гринів (львів’янин, автор Contre Jour, iPad Game of the Year 2011), Євген Кузьмін (автор популярної гри для iPhone та iPad Cover Orange, загальний прибуток від продажу якoї вже перевищив $1 000 000), Валерія Малаєва (ідейний натхненник та організатор найбільшої на теренах Східної Європи конференції для розробників флеш ігор FlashGAMM). Всіх судей перелічувати я не буду, але сподіваюся, ви можете уявити рівень цих людей у сфері розробки ігор. Був серед них і Антон Карлов – успішний розробник та автор мого улюбленого блога про флеш, який я раджу читати кожному, хто мріє створювати ігри.

Перший “Кубок ігрового спалаху” проводився у серпні минулого року, але тоді через відсутність часу у мене не було можливості взяти в ньому участь. Для того, щоб ситуація не повторилася, я заздалегідь взяв відпустку на основній роботі на час проведення другого конкурсу. Початок був запланований на третє січня.

Тему – “Подорожі в часі” – учасники дізналися в ніч з 2-го на 3-тє січня, і конкурс був офіційно розпочатий. А це означало, що опівночі з 9 на 10-те січня розробники повинні були завантажити готову гру на ігровий аукціон FlashGameLicense.

До участі в конкурсі в категорію “Одинаки” (коли над грою працює одна людина) зареєструвалося більше 40 учасників (я брав участь саме в цій категорії). В категорію “Пари” (коли над грою працює міні-команда: програміст та художник) зареєструвалося близько 15 команд. Втім, до фінішу дійшли не всі. Але про це – згодом.

Підготовка та старт

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

Тож напередодні конкурсу, відійшовши від святкування Нового Року, я почав посилено шукати навчальні матеріали та статті про створення платформерів. Майже весь день 2-го січня я працював над прототипом. Це було досить ризиковано, оскільки теми конкурсу я ще не знав. Але було сподівання, що такий універсальний жанр, як платформер, буде можливо пристосувати практично до будь-якої теми.

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

Виглядало це досить “страшно”:

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

О 12-тій ночі я був втомлений але задоволений, оскільки певного прогресу таки вдалося досягнути. Приблизно в цей час стала відома тема, і конкурс почався. Але звісна річ – після цілого дня за комп’ютером я не міг думати ні про що інше, окрім сну.

День 1 (вівторок): Концепт, головний герой, карта

Прокинувшись зранку, я практично зразу приступив до розробки. Першою справою потрібно було вигадати концепцію гри. На щастя, ідея не змусила себе чекати. Найкращою реалізацією теми “Подорожі в часі” мені здалася можливість головного героя (ГГ) повертатися в минуле, при цьому стаючи молодшим. Крім того, ця концепція відкривала можливість збільшувати швидкість та спритність ГГ, коли він стає молодшим і таким чином відкривати для нього недоступні раніше локації.

Для образу ГГ я не придумав нічого кращого, ніж старий дід з палицею, який мріє повернути час назад і знову стати молодим. Спершу він рухається повільно і практично не може стрибати, але згодом, знаходячи магічні артефакти, починає бігати швидше і стрибати вище. Карта побудована таким чином, що в деяких місцях спритності ГГ не вистачає, щоб пройти далі. Це значить, що потрібно “помолодшати”.

Найбільше часу першого дня я потратив на створення карти, повністю намалювавши її на папері. Виглядала вона так (сканера немає, тому вибачайте за якість):

Не менше працював над програмною реалізацією карти, а особливо – прокрутки. Від ідеї робити плавну прокрутку відмовився зразу, але навіть миттєве переключення екранів, коли ГГ підходить до краю видимої області, викликало в мене достатньо труднощів. Тільки через кілька годин роботи з кодом все запрацювало так, як потрібно.

Останнє, що я зробив першого дня – це намалював ГГ і повністю анімував його (три стани – біг, стрибок та стан спокою).

Окрім того у вівторок моя дружина поїхала в гості до мами, тож наступні кілька днів я був відданий сам собі – кращих умов для повного занурення у розробку не вигадаєш.

День 2 (середа): Продовження роботи над картою, візуальне представлення героїв

Намалювати карту на папері виявилося набагато простішим, ніж реалізувати це програмно. В моєму випадку карта складається із великої кількості прямокутних блоків, яким можна задавати довільні розміри, і зіткнення з якими постійно “перевіряє” ГГ. Але оскільки редактор карти спеціально для цієї гри я не робив, то розміщувати блоки доводилося вручну. Для кожного такого блока потрібно було визначити правильні розміри, розрахувати координати і прописати в коді.

На роботу з картою пішло 5 чи 6 годин, але все одно зробив лише третину від запланованого. Для того, щоб трішки “відійти” від математичних обчислень, вирішив взятися за малювання альтернативних “амплуа” головного героя: молодий чоловік та маленький хлопчик.

Разом з анімацією на це пішло близько 5 годин. Вочевидь, потрібно розвивати навичку малювання. Поки що це виходить занадто повільно.

Вирішив, що не піду до ліжка, поки не реалізую перший артефакт – один з двох бонусів, який робить ГГ молодшим і дозволяє йому стрибати вище.

День 3 (четвер): Нарешті закінчив карту. Робота над точками для збереження та перешкодами

Зранку в четвер повернувся до карти, поставивши перед собою ціль закінчити її до вечора. Якщо раніше у мене ще виникали думки про те, щоб зробити кілька рівнів, то в цей день я остаточно від них відмовився – було очевидно, що не встигну. Тож взявши волю і калькулятор в кулак, я продовжив вираховувати положення для блоків, будуючи карту екран за екраном.

Цього ж дня я зробив другий артефакт, який на 30% збільшував швидкість ГГ, дозволяючи йому перестрибувати більші “провалля”. І зібравши залишки сили волі вирішив сьогодні ж запрограмувати точки для збереження (респавни) та перешкоди (шипи). Щоправда графіку для шипів вдалося намалювати тільки наступного дня, тому на наведеному нижче зображені вони представлені рожевим кольором.

День 4 (п’ятниця): Графіка. Перші “вороги”

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

Наступний крок – графіка для карти. Часу дуже мало, тому вирішив обмежитися травою. Окрім цього потрібно знайти рішення, яке дозволить більш-менш ефективно “натягувати” графіку на карту. Зупинився на окремому контейнері для графіки, який відображається поверх “фізичного” світу і змінює картинку відповідно до екрану, на якому в даний момент знаходиться герой. Очевидно, рішення не найбільш вдале – але максимально просте і втілюється досить швидко.

Дивовижно, як сильно видозмінюється гра, коли додаєш кілька елементів графіки. Банальна трава на платформах робить ігровий світ набагато “живішим”. Ех, шкода, що немає часу на задні фони – з ними все було б ще красивіше.

Приступаю до ворогів. Оскільки ідея гри крутиться навколо часу, а ГГ прагне повернутися в минуле – то й ворогами будуть різноманітні годинники. На ділі їх вийшло тільки два: агресивний будильник, який рухається вперед і назад на обмеженій території та грізний настінний годинник, який стріляє по ГГ своїми стрілками.

День 5 (субота): Вороги, виправлення багів, озвучка, закінчення гри

Зранку повернулася з поїздки дружина, а о 6-тій годині наступного ранку нас чекає потяг – їдемо до бабусі на Різдво. Часу практично не залишилося.

Субота, мабуть, була найпродуктивнішим днем. Якщо протягом попередніх чотирьох днів я працював по 12-14 годин, то в суботу – 18.

Якщо у п’ятницю я зробив логіку та графічне відображення ворогів, то в суботу розмістив їх на карті. Також додав фінальний артефакт на місці фінішу. Гра майже повністю закінчена. Нарешті її можна “пройти” і навіть отримати від цього задоволення.

Приступаю до роботи над звуками. В попередніх іграх на це витрачалося не менше 3-4 днів. Тепер же, на жаль, я не можу дозволити собі такої розкоші. Потрібно повністю закінчити систему звуків до того, як ми поїдемо в село, інакше не встигну – повертаємося в понеділок і в той же день до 12 ночі за московським часом гра повинна бути викладена на FGL.

2-га година ночі, а звуки готові тільки на 70%. О 6-тій потяг. Що ж, схоже сьогодні сну не буде. Дружина вирішує підтримати мене у моєму нелегкому починанні і також не лягає спати.

4-та година ночі – звуки закінчив. Залишилася година на виправлення деяких найбільш очевидних “глюків” і пора поспішати на вокзал.

День 7 (понеділок): Екрани старту та закінчення гри. “Вказівники руху”. Фінал!

Неділя пройшла в приємному спілкуванні з ріднею за святковим столом. Повернулися до Києва під обід в понеділок. До закінчення конкурсу менше 12 годин.

Втім, зробити залишилося не так вже й багато: екрани старту та закінчення. Крім того – розставити “вказівники руху” – таблички на “кордоні” екранів, коли не зовсім зрозуміло, куди стрибати. Гра готова.

Нарешті роблю “іконку-логотип” для гри і завантажую на FGL за 1 годину до закінчення конкурсу. Тепер можна зітхнути спокійно. Далі справа за журі!

В очікуванні результатів конкурсу

Як я вже й говорив, далеко не всі учасники зуміли дійти до фіналу. Серед одинаків фінальну версію своєї гри на FGL виклали всього 15 конкурсантів, серед пар – 7.

До обов’язків журі, окрім, власне оцінки ігор, входили створення скрінкастів – 5-хвилинних відео-роликів, на яких вони грають в конкурсні ігри і коментують їх. Власне, про скрінкасти хочеться сказати окремо, оскільки це була одна з основних причин, чому я вирішив взяти участь в конкурсі. Адже одна справа, коли розробник самостійно оцінює свою гру (що у 99% випадків виходить вкрай необ’єктивно), і зовсім інша – коли вашу гру оцінюють визнані експерти у цій сфері.

11 відео-роликів, в яких вашу гру критикують справжні професіонали – що може бути більш цінним для розробника? Скрінкасти дозволяють поглянути на власну гру “збоку” і одразу побачити всі її сильні та слабкі сторони. Іноді хочеться “підказати” людині, яка грає – але це неможливо. І це правильно – тому що так само ви не зможете підказувати реальним гравцям.

Що цікаво, більшість огріхів здаються цілком очевидними. Стає дивно, як можна було не звернути на них увагу під час розробки.

Оскільки учасники журі знімали своє відео неодночасно – кожного дня з’являлося по 2-3 нових ролики. Процес перегляду був надзвичайно цікавим, а очікування – сповнене нетерпіння.

Щоб зрозуміти, як скрінкасти виглядають на практиці, пропоную два конкурсні огляди моєї гри:

Результати

Тепер найцікавіше – цифри. Моя конкурсна гра When I Was Young набрала 7,03 бали з 10 можливих, що дозволило їй посісти 3-тє призове місце. Для мене це був надзвичайно приємний і несподіваний сюрприз. Перше місце з результатом 8,45 зайняла гра YZX розробника Disco Fish. На другому з результатом 7,48 опинилася гра A Friend For The Ages розробника dennatolich.

Ознайомитися з повними результатами конкурсу можна на блозі Flash Game Blogs.

Висновки

Як я вже згадував вище – огляди експертів дозволили побачити багато моментів, які можна допрацювати. Наприклад, більшість учасників журі стикалися з труднощами, намагаючись перестрибнути ями з шипами. І хоча в момент розробки я свідомо зробив ями широкими, оскільки на цьому була зав’язана значна частина геймплею (герой не повинен перестрибувати деякі перешкоди до тих пір, поки не візьме відповідний апгрейд) – та все ж після конкурсу під враженням від скрінкастів я все-таки значно спростив перестрибування ям з шипами.

Також після оглядів я в деяких місцях змінив ландшафт карти, щоб зробити його більш “дружнім” і “логічним”.

Ну і насамкінець, дехто з представників журі нарікав на відсутність графіки “заднього фону”. Над цим я також попрацював, додавши рослинність (дерева та кущі), хмари, а також текстуру грунту.

Після конкурсу

Щоб довести гру до фінального вигляду і зробити її цікавішою я додав ігровий таймер. Тепер можна проходити гру на швидкість, від чого залежить фінальна нагорода: дерев’яний, бронзовий, срібний чи золотий кубок.

Для збільшення часу, який гравці проводять у грі я додав фінальний бонус у вигляді збільшення швидкості ГГ після проходження гри. Іншими словами, тепер, якщо гравець дійшов до фінішу і починає проходити гру вдруге – він отримує невеликий бонус до швидкості, що дозволяє побити власний рекорд. Таке нововведення не вимагає особливих зусиль від розробника, але може суттєво підняти привабливість гри.

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

Крім цього було зроблено багато дрібних вдосконалень. Адаптовано деякі звуки. Покращено систему керування героєм та виправлено всі (сподіваюся) “глюки”.

Наразі гра перебуває в процесі торгів на аукціоні FGL і очікує свого спонсора. Зіграти в неї можуть всі, хто має аккаунт розробника на FGL. Посилання на гру: When I Was Young

Трейлер гри, знятий спеціально для потенційних спонсорів:

Якщо у вас немає розробницького аккаунта, але ви хочете зіграти – реєструйтеся на FGL як гравець (при реєстрації там є відповідний пункт), додавайте мене у друзі (заходьте у мій профіль і тисніть Follow This User), дайте знати, що ви зареєструвалися, через приватне повідомлення (Send Private Message у моєму профілі на FGL) і я відкрию для Вас доступ до гри. Буду вдячний за відгуки.

Інші записи на цю тему:

• Чому мене навчила розробка флеш-гри, або Практика – найкращий вчитель!
• Хто готовий віддати гроші за вашу гру? або Кілька слів про спонсорів та типи ліцензій
• Редизайн першої гри: Графіка має значення!
• Використання Flash IDE + FlashDevelop. Базова структура флеш-проекту.
• Wacom Intuos 4 та Samsung XL2370 – подарунки на День Народження

Хто не знає, Flash GAMM – це конференція для професійних розробників flash-ігор, соціальних та мобільних ігор, аудиторія якої значною мірою складається з інді-розробників (тобто людей, які роблять ігри самостійно або ж у невеликій команді). Валерія Маллаєва (один з організаторів та ідейний натхненник конференції) наголосила, що сьогодні Flash GAMM є найбільшою ігровою конференцією для інді-розробників на просторі колишнього СНД.

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

Коротко про доповіді

Оскільки виступи відбувалися у три потоки, мені вдалося побачити лише незначну частину з них. Тому розповідаю лише про те, що здалося найцікавішим:

Максим Гринів (Mokus) про цілісність при розробці інді-ігор

Макс (до речі, представник української спільноти розробників, львів’янин) здобув популярність після того, як з надзвичайним успіхом випустив гру Contre Jour для iOS. На конференції він виступив в ролі капітана очевидності і розповідав про цілісність при розробці інді-ігор. Втім, як це зазвичай буває, очевидні речі часто забуваються першими. Тому нагадування від Максима було надзвичайно доречним.

Власне, доповідь зводилася до того, що все у грі повинно бути цілісним:

• платформа (розробник повинен чітко розуміти, для якої платформи він випускає гру. Продукт, створений для iOS не зможе стати популярним на десктопі і навпаки. Не кажучи вже про такі екзотичні платформи, як, наприклад, Kinekt);
• аудиторія (розуміння того, для кого ви робите гру також дуже важливе. Не варто намагатися задовольнити всіх – вам це все одно не вдасться. Тож найкраще – зосередитися на своєму ключовому споживачеві і зробити для нього все можливе);
• керування грою/персонажем (по суті те саме, що й платформа. Наївно сподіватися, що ви зможете зробити успішний 3D-шутер від першої або третьої особи на мобільному iOS пристрої. Керування не те…);
• геймплей (не варто гнатися за великою кількістю ігрових механік. Головне – щоб наявні ідеально взаємодіяли між собою);
• графіка (графіка не обов’язково повинна бути ідеальною (надзвичайно красивою і реалістичною), але вона повинна бути цілісною. Наприклад гра Shift стала суперхітом, хоча графіка в ній елементарна).

Доповідь Максима створила найбільший ажіотаж. Кількість народу, якому не вистачило місця і який стояв під стінами зашкалювала.

Мерлін Гор з Flash Game License розповідав про те, як забезпечити своїм іграм спонсорство

Відверто кажучи, від представника FGL я очікував куди більш змістовної і цікавої доповіді. Виступ же Мерліна Гора звівся до розповіді про функції системи FGL, про які кожен флеш-розробник знає “з пелюшок”.

Серед цікавих цифр, озвучених Мерліном:

• кількість розробників, зареєстрованих на FGL – 20 000;
• кількість спонсорів – 4000;
• кількість продаж (deals) за час існування сервісу – 6000 (з них за минулий рік – 1900);
• рекордна вартість ліцензії – $70 000.

Алекс Ничипорчик зі Spil Games поділився секретами, як задовольнити 150 мільйонів користувачів

Алекс поділився статистикою порталів мережі Spil Games і його доповідь виявилася найцікавішою з тих, на які мені сьогодні пощастило потрапити.

Коротко факти:

• за останній рік Spil Games ліцензували 1000 ігор (тобто майже 3 гри на день, круто!);
• наступного року планують ліцензувати 500 ігор. Скорочення пов’язане зі зміною стратегії компанії. Тепер Spil Games будуть більше орієнтуватися на мобільні ігри, iOS, Apple Store та мікроплатежі;
• 70% розробників ігор, які отримали спонсорство Spil Games – представники колишнього СНД (тобто для нас попередня новина подвійно сумна);
• “щоб зробити успішну гру потрібно не стільки зациклюватися на розробці, скільки на створенні впізнаваного бренду” (наводив у приклад гру Snail Bob, яка по суті стала таким брендом);
• радісна новина – в наступному році Spil Games планують відмовитися від свого API. Тобто ніяких більше перекладів на 50 мов, впроваджувати які доводилося розробникам;
• якість флеш ігор вже зараз досить висока, а в майбутньому буде тільки зростати (треш не пройде);
• розробникам варто створювати крос-платформенний дизайн геймплею (щоб можна було і на флеш-порталі розмістити, і в Apple Store успішно продавати);
• тестувати ігри потрібно на “не геймерах”…

Представник Alternativa Platform Дмитро Сергієв розповів про нову розробку Alternativa Physics, яка стане доступною розробникам вже за тиждень. Особливо нічого з цієї доповіді не запам’яталося. Було багато коду та пояснення, яким чином можна просто створювати 3D-об’єкти з фізикою на Flash. Ну і звісно – демки – як же без них.

Потім слухав Сета де Конінга (Jaludo), який говорив про успішні флеш-ігри та Конрада Холубека (Games Passport), який розповідав про монетизацію ігор на автономних сайтах.

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

Із цікавого – прогнози розвитку ігрового ринку. Конрад наголосив на тому, що найбільш суттєво будуть зростати моделі Free2Play, соціальні ігри, а також, зрозуміла річ, мобільні ігри. При цьому ринок консольних ігор скоротиться (не дуже сильно, але все ж).

Було цікаво почути і про те, що 65% всіх гравців у світі – це жінки (злам стереотипів). Але ще цікавіше – що саме жінки приносять 75% прибутку з мікротранзакцій (чоловіки всього 25%, що для мене стало справжньою несподіванкою).

Круглий стіл “Маркетинг ігор” (Петро Харитонов, Андрій Фадєєв, Станіслав Роднянський, Антон Волков, Анастасія Бабкіна), організатори чомусь вирішили проводити у малому залі. Наслідок – відсутність місць. Я сидів в останньому ряду і не міг навіть розгледіти учасників дискусії.

Втім, конкретно для інді-розробників цей круглий стіл мав хіба що потенційну цінність, оскільки йшлося на ньому переважно про просування соціальних ігор і захмарні бюджети у 300 000 на маркетинг. Я, правда, так і не зрозумів, у доларах, чи все-таки у рублях.

Слоган круглого столу: “Ви повинні витратити на маркетинг стільки ж, скільки витрачаєте на розробку“.

Наприкінці розгорілася цікава дискусія про те, чи потрібні видавці для того, щоб видавати ігри, чи можна все робити самому. Моя думка залишилася незмінною – великі компанії/команди можуть справитися власними силами. Одинакам же вдасться заробити більше, якщо вони звернуться по допомогу до видавців.

Як бачите, попри мою обіцянку писати коротко, все одно тексту вийшло більше, ніж достатньо. Завтра, на жаль, не зможу відсидіти цілий день – потраплю тільки на ранкові доповіді. Якщо почую щось варте уваги і якщо аудиторії цього блога такі звіти цікаві, можливо також напишу.

Інші записи на цю тему:

• Turtle Dreams to Fly: Реліз!
• Уроки Flash
• Як правильно вбудувати flash-контент у ваш сайт: Вставка swf-файлів з допомогою SWFObject 2
• Організація візуальних об’єктів методами ActionScript 3: Display Object, Display Container та Display List
• Хто готовий віддати гроші за вашу гру? або Кілька слів про спонсорів та типи ліцензій

Дивне запитання! Навіть першокласник відповість, що результатом цього виразу буде 0.3. Втім, як виявилося, алгоритми ActionScript 3 не завжди дружать з традиційною логікою. Якщо ви спробуєте провести подібне обчислення у AS3, то отримаєте результат: 0.30000000000000004.

Подібна похибка виникає через обмеження розміру пам’яті, яку AS3 виділяє для збереження змінних типу Number (тобто чисел з комою). Наприклад, щоб точно зберегти значення числа “Пі”, системі знадобилася б безкінечна кількість ресурсів. Звісна річ, що це неможливо. Тому в AS3 (як і в будь-якій іншій мові програмування) під кожен тип змінної відведена строго обмежена кількість байтів. Отже так чи інакше, доводиться округлювати “безкінечні” числа.

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

Давайте розглянемо наступний код:

var i:int;
var divisor:Number = 10;
var multiplier:Number = 0.1;

for (i = 0; i<10; i++) {
	trace (i/divisor);
}

trace("");

for (i = 0; i<10; i++) {
	trace (i*multiplier);
}

Для спрощення коду використовуються цикли, про які ми побіжно говорили в статті про анімацію вибуху.

В першому циклі ми ділимо числа від 0 до 9 на 10, а в другому – множимо той самий ряд чисел на 0.1. Оскільки результат ділення на 10 повинен бути ідентичним до результату множення на 0.1 – ми повинні бачити однаковий ряд чисел. Втім, при виконанні цього коду отримаємо наступний результат:

0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9

0
0.1
0.2
0.30000000000000004
0.4
0.5
0.6000000000000001
0.7000000000000001
0.8
0.9

Як бачите, при множенні на десятковий дріб (число 0.1) ми отримали кілька “артефактів” у вигляді незначних похибок. Спрогнозувати їх появу практично неможливо, але одне можна сказати напевне – при роботі з типом Number у ActionScript час від часу будуть проявлятися подібні неточності.

Втім, не менш важливо звернути увагу і на те, що при діленні ряду цілих чисел на 10 (у першому циклі) жодних похибок ми не отримали.

Пояснюється це просто: в першому випадку обидва числа були цілими. А в другому ми множили ціле число на десятковий дріб, що призвело до некоректної роботи алгоритму і вилилося у похибки.

Як виправити неточності при роботі з десятковими дробами

У більшості випадків точність алгоритмів AS3 буде для нас повністю задовільною. Адже погодьтеся, похибка у 0.0000000000000001 не вплине на фінальний результат роботи нашої програми.

Але бувають ситуації, в яких виникнення подібних “артефактів” все-таки дуже небажане. І з однією із них я зіткнувся, працюючи над грою Symbiosis.

Уявіть, що вам потрібно показувати гравцеві певні характеристики його юнітів (наприклад, атаку чи захист) із точністю до одного числа після коми. Зрозуміла річ, що відображення цих характеристик буде вбудовано у графічний інтерфейс. І уявіть, що в полі, де повинна показуватися атака, припустимо 3.5, раптом з’явиться число 3.5000000000000001. Неприємний глюк, чи не так?

Округлення числа Number до десяткового дробу з визначеною кількістю знаків після коми

Знаючи, що ділення цілого числа на ціле число кратне десяти ніколи не дає похибок, ми можемо створити функцію, яка завжди повертатиме коректне значення з визначеною кількістю знаків після коми.

До речі, цю саму функцію можна використовувати замість штатного в ActionScript 3 методу Math.round, який округлює числа до цілого значення. В нашому випадку функція повертатиме контрольоване дробове значення. Наприклад, таким чином ми зможемо округлити число “Пі”, як до 3.14159, так і до 3.14, тоді як Math.round завжди повертатиме строго 3.

Ось як виглядає сама функція:

public static function roundToDecimal (base:Number, decimalPlace:int):Number
{
	return Math.round(base * decimalPlace)/decimalPlace;
}

Давайте розберемося з її роботою.

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

Функція приймає два параметри:
base – це число, яке ми будемо округлювати;
decimalPlace – це число, кратне 10, яке визначатиме, скільки знаків після коми ми хочемо отримати (наприклад, 10 дасть нам 1 знак після коми; 100 – 2 знаки після коми; 1000 – 3 знаки після коми і так далі).

Припустимо, ми хочемо округлити число 5.324569 до двох знаків після коми. В такому випадку ми повинні передати методу відповідні параметри:
roundToDecimal (5.324569, 100);
base = 5.324569
decimalPlace = 100

Розглянемо, що відбувається далі:
1. Перша дія – множення base на decimalPlace: 5.324569 * 100 = 532.4569
2. Після цього в методі використовується штатний Math.round щоб округлити число. Отримуємо 532
3. Наступний крок – ділення на decimalPlace: 532/100 = 5.32

Як бачите, ми отримали потрібний результат – десятковий дріб з двома знаками після коми – при цьому не зіткнувшись з жодними “вибриками” AS3 у вигляді незрозумілих похибок.

Можна проапгрейдити функцію roundToDecimal, щоб замість не зовсім очевидного числа кратного десяти вказувати конкретну кількість знаків після коми (1, 2, 3 … і т. п.). Ось як вона виглядатиме:

public static function roundToDecimal (base:Number, decimalPlace:int):Number
{
	var divisor:int = Math.pow(10, decimalPlace);
	return Math.round(base * divisor)/divisor;
}

Функція Math.pow() повертає значення першого числа – 10 – піднесеного до ступеню decimalPlace. Таким чином, якщо decimalPlace = 1 – отримуємо 10; 2 – 100; 3 – 1000 і так далі.

Сподіваюся, ця стаття була корисною і допомогла розібратися з деякими похибками типу Number, які виникають у AS3. Якщо у вас залишилися запитання щодо роботи функцій – ласкаво прошу у коментарі.

Ну і традиційно, буду радий, якщо ви станете постійними читачами блога про флеш, підписавшись на RSS.

Інші записи на цю тему:

• Динамічне додавання MovieClip на сцену. Робота з символами MovieClip методами ActionScript 3
• Умовні вирази (conditionals) та оператори в ActionScript 3. Використання конструкцій if … else та switch … case
• Генерування випадкових чисел у ActionScript. Як використовувати метод Math.random
• Урок 2. Слухачі подій (Event Listeners) та події в ActionScript 3. Координати сцени та рух!
• Вступ до ActionScript 3: Що таке вбудована мова програмування у Flash та чим AS3 відрізняється від AS2

На жаль, “рідний” код, який генерується програмою Adobe має одразу кілька недоліків. Передусім – він неуніверсальний. Вам доведеться дублювати частину коду для вставки флеш-контенту, щоб останній правильно відображався у IE. При цьому деяких проблем все-одно не уникнути.

По-друге, код, отриманий внаслідок компіляції флеш-контенту у Flash IDE використовує теги, які не відповідають стандартам W3C.

Ну і нарешті, при використанні стандартних для класичного Adobe коду тегів <object> та <embed> можуть виникати проблеми виявлення версії флеш-плеєра, встановленого у користувача, та коректного завантаження флеш-кліпів. З подібною проблемою я зіткнувся, працюючи над розробкою ігрового порталу Jar of Games, який на 90% складається з флеш-контенту. Якщо у Firefox flash-кліпи оброблялися коректно, то IE починав показувати флеш тільки після того, як гра повністю завантажилася (а повинен був показувати прелоадер під час завантаження).

На щастя існує спосіб уникнути всіх перелічених вище проблем вбудовування флеш-контенту, отримавши при цьому безліч додаткових переваг та бонусів – SWFObject. Якщо ви пройдетесь по провідних сайтах, які багато працюють з флеш-контентом (таких як топові ігрові портали), то побачите, що всі вони використовують саме SWFObject для вставки флеш-кліпів. Тобто по факту SWFObject вже став стандартом у цій сфері.

Ось ще кілька аргументів на користь SWFObject:

• він більш оптимізований та гнучкий, ніж будь-який інший спосіб вбудовування Flash-плеєра;
• він є універсальним рішенням для всіх HTML, Flash та JavaScript-розробників;
• він припиняє використання “специфічної” розмітки для деяких браузерів, при цьому даючи змогу використовувати стандартну розмітку та альтернативний контент;
• використовує ненав’язливий JavaScript та найкращі практики JavaScript;
• простий у використанні.

Робота з SWFObject

SWFObject це джаваскриптовий файл, який дозволяє вирішувати практично всі проблеми, що виникають при вбудовуванні флеш-контенту. Завантажити його можна на сторінці проекту SWFObject в Google Code. Там само ви знайдете і детальний посібник для початківців і повну документацію по SWFObject англійською мовою.

Остання версія SWFObject 2 дозволяє вбудовувати Flash двома методами:

1. Статичний метод публікації Flash та альтернативний контент вбудовуються з допомогою стандартної розмітки, а JavaScript використовується лише для вирішення проблем, які неможливо подолати інакше.

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

Втім, “користувачі”, які виключають JavaScript у своїх браузерах – не наша аудиторія. Практика показує, що як правило так поступають зовсім не люди, а різноманітні спам-боти. Тому я не розглядатиму роботу статичного методу публікації в рамках цієї статті. Якщо з якихось причин ви хочете використати саме статичний метод – зверніться до документації, посилання на яку я вже дав вище.

2. Динамічний метод публікації базується на заміні альтернативного контенту Flash-контентом у випадку, якщо на комп’ютері користувача встановлена достатньо нова версія Flash-плеєра та є підтримка JavaScript.

Основні переваги динамічного методу публікації полягають в тому, що він дозволяє обійти механізми активації активного контенту в IE 6, 7 та Opera 9+, а також чудово інтегрується в JavaScript програми.

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

Крок 1. Створення альтернативного контенту.

Передусім, потрібно знати, що динамічний метод публікації втілює принципи так званого “прогресивного покращення” (progressive enchancement). Використовуючи його ви не в буквальному сенсі вставляєте флеш-контент у сайт, як це було при використанні традиційної розмітки, а замінюєте альтернативний HTML-контент флеш-контентом у випадку, якщо є достатня підтримка JavaScript та Flash.

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

Отже, при використанні динамічного методу публікації перше, що потрібно зробити – це створити HTML контейнер з альтернативним контентом (ним може бути текст, зображення чи будь-який інший стандартний HTML-контент) і задати для нього id. Наприклад, так:

<div id="alternativeContent">
<p>Текст альтернативного контенту</p>
</div>

Цей блок ви повинні розмістити в тому місці на вашому сайті, де в майбутньому повинен з’явитися flash-ролик. Альтернативний контент користувач побачить тільки у випадку, якщо можливостей його комп’ютера не вистачає для перегляду флеш-ролика (наприклад, якщо він використовує застарілу версію flash-плеєра або його браузер не підтримує JavaScript). Власне, текст альтернативного контенту зазвичай і є вказівкою користувачеві, що у нього недостатньо інструментів для перегляду флеш-контенту з пропозицією завантажити останню версію flash-плеєра або увімкнути JavaScript.

Крок 2. Підключення бібліотеки SWFObject

Бібліотека SWFObject складається всього з одного зовнішнього файла, який ви повинні завантажити на свій хостинг і підключити в коді (я роблю це в блоці head). Ось як виглядає стрічка підключення скрипта:

<script type="text/javascript" src="swfobject.js"></script>

Відповідно, якщо файл swfobject.js знаходиться не в кореневій папці вашого сайту – до нього потрібно прописати шлях у директиві “src”. Наприклад, якщо swfobject.as знаходиться в папці scripts, то директива виглядатиме наступним чином: src=”scripts/swfobject.js”.

Крок 3. Заміна альтернативного контенту флеш-контентом.

Останній крок – це власне заміна альтернативного контенту флеш-контентом, якщо версія flash-плеєра виявилася достатньою. Ось як виглядає цей метод:

<script type="text/javascript">
swfobject.embedSWF(swfUrl, id, width, height, version, expressInstallSwfurl, flashvars, params, attributes)
</script>

У цього методу п’ять обов’язкових та чотири необов’язкових параметри.

Обов’язкові:

• swfUrl – URL swf-файла;
• id – id HTML-контейнера з альтернативним контентом, який буде замінений на флеш-контент;
• width – ширина swf-файла;
• height – висота swf-файла;
• version – версія флеш-плеєра, необхідного для даного SWF (формат major.minor.release)

Необов’язкові (їх ми також не будемо детально розглядати в рамках цієї статті, просто озвучимо):

• expressInstallSwfurl – задає URL вашого express install SWF та активує Adobe express install;
• flashvars – змінні, які передаються у ваш flash-додаток у вигляді пар “ім’я:значення”;
• params – елементи params вкладені в object у вигляді пар “ім’я:значення”;
• attributes – атрибути елемента object у вигляді пар “ім’я:значення”.

Код заміни альтернативного контенту в нашому прикладі виглядатиме так:

<script type="text/javascript">
swfobject.embedSWF("myContent.swf", "alternativeContent", "300", "120", "9.0.0");
</script>

Тож загальний html з повним кодом вставки swf з допомогою SWFObject 2 міг би виглядати, наприклад, наступним чином:

<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  <head>

    <script type="text/javascript" src="swfobject.js"></script>

  </head>
  <body>

    <script type="text/javascript">
      swfobject.embedSWF("myContent.swf", "alternativeContent", "300", "120", "9.0.0");
    </script>

    <div id="alternativeContent">
      <p>Текст альтернативного контенту</p>
    </div>

  </body>
</html>

Сподіваюся, ця стаття була для вас корисною та зрозумілою. Якщо після її прочитання залишилися додаткові запитання щодо вставки флеш-контенту з допомогою SWFObject – не соромтесь задавати їх у коментарях.

Інші записи на цю тему:

• Основи Flash та ActionScript: Типи файлів, з якими повинен навчитися працювати флеш-розробник
• FlashGAMM Kyiv 2011: Враження від першого дня
• Організація візуальних об’єктів методами ActionScript 3: Display Object, Display Container та Display List
• Turtle Dreams to Fly: Статистика та висновки після релізу
• Turtle Dreams to Fly: Реліз!

Клас DisplayObject є базовим для всіх об’єктів, які можуть бути візуально представлені у флеш-кліпі. Наприклад, будь-який MovieClip чи Sprite, з якими нам доводилося працювати раніше, також належить до об’єктів відображення, хоча насправді їх перелік куди ширший. Згадайте хоча б статтю про динамічне додавання MovieClip на сцену методами ActionScript 3. Зірки, які використовувалися у наведеному там прикладі також належать до об’єктів відображення.

Розуміння концепції списку відображення (display list) та ролі об’єктів відображення у створенні flash-програм надзвичайно важливе для кожного початківця, який прагне навчитися програмуванню на ActionScript. Адже по суті кожна програма, написана на ActionScript 3.0 має власну ієрархію об’єктів відображення, яка включає повний набір візуальних елементів. Це базова концепція, зрозумівши яку, ви наблизитесь до розуміння принципів функціонування AS3-програм та навчитесь з легкістю маніпулювати будь-якими візуальними об’єктами всередині власної програми.

Візуальні елементи можна умовно поділити на три групи:

1. Сцена (Stage). Це основний контейнер для всіх об’єктів відображення. Сцена завжди знаходиться в основі ієрархії візуальних елементів і тому будь-яка flash-програма може включати лише одну сцену.
2. Об’єкт відображення (Display object). У ActionScript 3 всі без виключення елементи, які можуть бути візуально представлені на екрані, належать до типу об’єктів відображення та є успадкованими від класу DisplayObject. Форми (Shapes), фрагменти кліпу (Movie clips), спрайти (Sprites) і навіть текстові поля (Text fields) по суті є об’єктами відображення. І це лише невелика частина від загальної їх кількості.
3. Контейнер об’єктів відображення (Display object container). Об’єкти відображення можуть бути розміщені тільки всередині контейнерів, основним з яких є вже згадана нами сцена. Втім, не тільки сцена може фізично містити візуальні елементи. Деякі об’єкти відображення (Movie Clip, Sprite) водночас можуть бути контейнерами для інших об’єктів відображення. Наприклад, ви можете розмістити довільну кількість форм, кліпів чи текстових полів всередині іншого кліпу чи спрайта. Такі об’єкти відображення, розміщені всередині контейнера, називаються дітьми (children) цього контейнера і записуються до списку дітей (child list).

Список об’єктів відображення (Display list)

Список об’єктів відображення у ActionScript завжди включає в себе всі видимі елементи вашої програми. Найпростіший спосіб зрозуміти принцип формування списку об’єктів відображення – уявити собі структуру дерева, в якій сцена є стовбуром (основою), гілки – контейнерами об’єктів відображення, а листя – самими об’єктами відображення. У дерева є тільки один стовбур, але може бути бути скільки-завгодно гілок. На одній гілці може рости багато листя, а також інші гілки. Але ніколи гілки не ростуть на листі.

Наведена нижче діаграма демонструє приклад гіпотетичної ієрархії об’єктів відображення у SWF-файлі:

Діти (тобто будь-які об’єкти відображення всередині контейнерів) завжди візуально знаходяться вище, ніж їхні “батьки” (тобто сам контейнер). Якщо ж контейнер містить багато об’єктів відображення (дітей) то вище будуть знаходитися ті об’єкти, які були додані в контейнер пізніше. Кожному такому об’єктові присвоюється свій порядковий номер (починаючи з нуля). За допомогою коду ActionScript ми можемо впливати на порядок розміщення візуальних елементів у списку відображення.

Як додавати об’єкти (display object) в список відображення (display list)

Що ж, сподіваюся, я не надто втомив вас “сухою” теорією. Зараз ми спробуємо створити просту флеш-програму, яка продемонструє всі переваги використання об’єктів відображення та списку відображення, а також керування ними методами ActionScript 3.

Створіть новий флеш-файл, в якому створіть три символи MovieClip: чотирикутник, коло та трикутник. Для зручності можете розфарбувати їх різними кольорами. А також не забудьте під час створення символів експортувати кожен з них для використання через ActionScript. Про те, як це зробити, написано у вже згаданій раніше статті. Я назвав символи Square_mc, Circle_mc та Triangle_mc відповідно. Приставка _mc дозволяє легко орієнтуватися, що ми маємо справу з Movie Clip-ами. Це додає читабельності нашому коду, особливо, якщо останнього буде дуже багато.

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

Тепер приступаємо до написання коду. Якщо у попередніх статтях код ми писали безпосередньо у кадрах fla-файлу, то тепер настав час переходити до створення окремих as-файлів. Пора звикати до нормальної роботи зі зручними інструментами розробки і нарешті відмовитися від убогого редактора коду у Flash IDE.

Для роботи з as-файлами вам знадобиться редактор FlashDevelop. Про те, як налаштувати FlashDevelop, структурувати as-файли та підключити файл до проекту я писав у статті “Використання Flash IDE + Flash Develop“. В майбутньому ми будемо завжди користуватися подібною структурою, тому раджу вивчити та звикнути до неї. З часом ви зрозумієте, наскільки це просто та зручно.

Скажу лишень, що для потреб демонстрації роботи display object зовсім не обов’язково створювати багато вкладених папок і файлів. Я розмістив fla-файл та єдиний as-файл Main.as у одній папці. Нагадаю, що для підключення as-файла до вашого флеш-проекту потрібно прописати його у полі Class. Ось як це виглядає:

У файлі Main.as пишемо наступний код:

package //не потрібно вказувати пакет, бо as-файл та fla-файл знаходяться в одній папці
{
	import flash.display.Sprite;
	import flash.display.MovieClip;
	import flash.display.TriangleCulling;

	public class Main extends Sprite
	{

		/*вказуємо три змінні: чотирикутник, коло та трикутник
		 *і зразу присвоюємо їм візуальне відображення із бібліотеки
		 */
		private var square:MovieClip = new Square_mc();
		private var circle:MovieClip = new Circle_mc();
		private var triangle:MovieClip = new Triangle_mc();

		public function Main ():void
		{
			//вказуємо координати об'єктам, щоб красиво розмістити їх на сцені
			square.x = 100;
			square.y = 100;
			circle.x = 150;
			circle.y = 60;
			triangle.x = 140;
			triangle.y = 120;

			//додаємо об'єкти до списку відображення
			addChild(square);
			addChild(circle);
			addChild(triangle);
		}
	}
}

Якщо все було зроблено правильно, то при тестуванні файлу отримаємо такий результат:

Зверніть увагу, що порядок об’єктів відображення у списку відповідає порядку їх додавання. Першим був доданий чотирикутник – тож візуально він знаходиться під колом та трикутником. Останнім був доданий трикутник – він знаходиться над обома іншими об’єктами.

Власне, метод addChild() і є основною директивою, яка додає об’єкт до списку відображення. Якщо ви хочете “вставити” новий об’єкт в конкретну позицію списку, потрібно використовувати метод addChildAt().

Нумерація об’єктів у списку починається з нуля. Тому метод addChildAt(0) вставить об’єкт на найнижчу позицію у переліку.

Спробуйте змінити частину коду, в якій об’єкти додаються у список на:

addChild(square);
addChild(circle);
addChildAt(triangle, 0);

і ви побачите, що хоча чотирикутник та коло були додані першими, та все ж трикутник опинився найнижче, оскільки ми чітко вказали йому позицію на самому початку списку відображення. Таким чином індекси у списку відображення трикутника, чотирикутника та кола стали відповідно 0, 1 та 2.

Варто також пам’ятати, що у списку відображення існують тільки ті індекси, які присвоєні вже доданим до нього об’єктам. Спроба додати об’єкт на позицію, якої ще не існує, викличе помилку. Таким чином, наприклад, код:

addChildAt(square, 2);
addChild(circle);
addChild(triangle);

буде неправильним і програма не запуститься, тому що в момент додавання першого об’єкта (чотирикутника) індекса 2 у списку відображення ще не існує.

Зміна глибини (depth) об’єкта у списку відображення (display list)

Існує кілька способів змінити індекс об’єкта у списку відображення. З одним із них ми вже познайомилися вище – це метод addChildAt(), який дозволяє вказати точний індекс об’єкта. При цьому якщо об’єкт з таким індексом існує, то він автоматично переміщується вище.
Розберемо повторно код:

addChild(square);
addChild(circle);
addChildAt(triangle, 0);

Спершу до списку відображення додається чотирикутник і йому присвоюється індекс 0. Другим додається коло, і йому, відповідно, присвоюється індекс 1. Потім додається трикутник і йому примусово встановлюється індекс 0. Таким чином трикутник опиняється на “дні” списку відображення, а чотирикутнику та колу присвоюються індекси 1 і 2 відповідно.

Для об’єктів, які вже знаходяться у списку відображення, можна використовувати метод setChildIndex(), який діє по аналогії з addChildAt(). Якщо ж ви просто хочете поміняти місцями два об’єкти у списку відображення – використовується метод swapChildren() (якщо у вас є посилання на обидва об’єкти) або swapChildrenAt() (якщо вам відомі індекси цих об’єктів).

Якщо ж ви знаєте індекс об’єкта і хочете звернутися до нього – використовуйте метод getChildAt().

Щоб закріпити матеріал на практиці давайте спробуємо модифікувати попередній приклад з чотирикутником, колом та трикутником таким чином, щоб при кліку по будь-якому із об’єктів, він переміщувався на вершину списку відображення.

Значна частина коду залишилася без змін. З’явилося тільки кілька нових імпортів, слухачі подій мишки та функція, яка змінює розташування об’єктів у списку відображення. Ось оновлений код:

package //не потрібно вказувати пакет, бо as-файл та fla-файл знаходяться в одній папці
{
	import flash.display.DisplayObject;
	import flash.display.Sprite;
	import flash.display.MovieClip;
	import flash.events.MouseEvent;

	public class Main extends Sprite
	{

		/*вказуємо три змінні: чотирикутник, коло та трикутник
		 *і зразу присвоюємо їм візуальне відображення із бібліотеки
		 */
		private var square:MovieClip = new Square_mc();
		private var circle:MovieClip = new Circle_mc();
		private var triangle:MovieClip = new Triangle_mc();

		public function Main ():void
		{
			//вказуємо координати об'єктам, щоб красиво розмістити їх на сцені
			square.x = 100;
			square.y = 100;
			circle.x = 150;
			circle.y = 60;
			triangle.x = 140;
			triangle.y = 120;

			//додаємо об'єкти до списку відображення
			addChild(square);
			addChild(circle);
			addChild(triangle);

			//додаємо слухачі подій до кожного об'єкта
			square.addEventListener(MouseEvent.CLICK, onClickHandler);
			circle.addEventListener(MouseEvent.CLICK, onClickHandler);
			triangle.addEventListener(MouseEvent.CLICK, onClickHandler);
		}

		private function onClickHandler(e:MouseEvent): void
		{
			//присвоюємо змінній clickedObject об'єкт, на який ми клікнули
			var clickedObject:DisplayObject = e.target as DisplayObject;

			/*Змінюємо індекс у списку відображення нашого об'єкта.
			 *Зверніть увагу, на змінну numChildren, яка завжди повертає
			 *загальну кількість об'єктів відображення. Таким чином,
			 *щоб розмістити об'єкт останнім у списку відображення,
			 *потрібно присвоїти йому індекс numChildren - 1
			 */
			setChildIndex(clickedObject, numChildren - 1);
		}
	}
}

Особливу увагу потрібно звернути на нову змінну numChildren, яка повертає загальну кількість дітей у списку відображення. В нашому випадку їх 3. Таким чином, оскільки нумерація в списку починається з нуля, щоб отримати індекс найвищого об’єкта, потрібно від змінної numChildren відняти одиницю.

А ось і результат виконання нового коду. Клікайте по об’єктах і вони будуть переміщуватися на вершину списку відображення:

Видалення об’єктів (display object) зі списку відображення (display list)

Останнє, що потрібно навчитися для повноцінної роботи зі списком відображення – це видалення об’єктів зі списку. Для цього використовується метод removeChild(), який передає посилання на об’єкт як параметр. Спробуйте модифікувати код першого прикладу, додавши одну стрічку:

addChild(square);
addChild(circle);
addChild(triangle);
removeChild(circle);

І ви побачите, що при тестуванні флеш-файлу коло на екрані не з’явиться. Воно буде спершу додане у список відображення, але потім відразу ж видалене з нього.

Для видалення об’єкта з конкретним індексом у списку використовується метод removeChildAt().

Було б логічно, якби існував метод, який видаляє всі об’єкти зі списку відображення. Та з незрозумілих причин розробники AS3 не створили такого методу. Тому, щоб видалити всі об’єкти зі списку відображення, програмісти використовують наступну конструкцію-цикл:

while (numChildren > 0) {
     removeChildAt(0);
}

Саме цей метод я використовував для того, щоб очистити сцену від зірок у статті про динамічне додавання Movie Clip на сцену.

Сподіваюся, тут все зрозуміло. Цикл перевіряє, чи є в контейнері хоча б один об’єкті відображення (numChildren > 0). Якщо хоча б один об’єкт присутній – виконується наступна стрічка коду: removeChildAt(0); – яка видаляє найнижчий об’єкт. Цикл повторюється до тих пір, поки в списку відображення не залишиться жодного об’єкту.

На цьому розповідь про роботу з об’єктами відображення та списком відображення можна закінчити. Сподіваюся, стаття не виявилася занадто складною. Зате такі базові знання допоможуть вам краще орієнтуватися у керуванні візуальними елементами. Задавайте запитання у коментарях.

Якщо стаття вам сподобалася, підпишіться на RSS блога про Flash та ActionScript, щоб не пропустити нічого важливого.

Інші записи на цю тему:

• Умовні вирази (conditionals) та оператори в ActionScript 3. Використання конструкцій if … else та switch … case
• Чому мене навчила розробка флеш-гри, або Практика – найкращий вчитель!
• Уроки польотів для черепахи та кілька слів про концепцію другої гри
• Динамічне додавання MovieClip на сцену. Робота з символами MovieClip методами ActionScript 3
• Урок 8. Навчаємо м’ячик стрибати, використовуючи ефект motion (classic) tween у Flash

А працюю я, як ви могли здогадатися із заголовку, над новою грою з робочою назвою Symbiosis. Поки що готовий тільки прототип, а це не більше 5% від загального об’єму роботи.

За задумкою це повинна вийти гра на перехресті жанрів Tower Defense та стратегії. Як і в Tower Defense гравець буде будувати та керувати вежами. Але на відміну від класичних ігор у цьому жанрі ніяких “хвиль” ворогів не буде. Натомість, гравцеві доведеться зіткнутися зі штучним інтелектом, який теж зможе будувати вежі.

Втім, я не буду заглиблюватися у деталі гри, тому що за час розробки все ще може тисячу разів змінитися. Натомість, сьогодні я вирішив викласти коротке відео роботи над малюнком кристалу (ворожий юніт).

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

Взагалі, у мене немає жодної художньої освіти і тому малюю я відверто по-дилетанськи. Але дуже хочеться навчитися! Конкретно в цьому відео використовувався тільки один інструмент – line tool. Втім, зазвичай я дуже активно малюю пензлем (brush tool). Планую використовувати у новій грі тільки графіку, намальовану власноручно.

Інші записи на цю тему:

• Чому мене навчила розробка флеш-гри, або Практика – найкращий вчитель!
• Уроки польотів для черепахи та кілька слів про концепцію другої гри
• Match Insanity – перша flash-гра мого власного виробництва!
• Drawing objects (об’єкти-малюнки) у флеші. Нововведення у Flash Professional CS5
• Хто готовий віддати гроші за вашу гру? або Кілька слів про спонсорів та типи ліцензій

Сьогодні я вирішив трішки розповісти про найбільш розповсюджені способи монетизації flash-ігор та показати, яким чином інді-розробники мають змогу отримати компенсацію (іноді – дуже суттєву) за свій час, зусилля та креативність.

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

Хто зацікавлений в купівлі гри?

В інтернеті існують сотні тисяч, якщо не мільйони ігрових порталів. Звісна річ, багато з них закинуті або мають мінімальний трафік. Втім, трапляються і справжні гіганти з мільйонними показниками щоденних відвідувань та переглядів. Такі портали приносять значні прибутки своїм власникам. Але для їх підтримки потрібно постійно оновлювати ігровий контент, публікувати ексклюзивні новинки і знаходити все нові та нові джерела трафіку. І тут в нагоді стає ліцензіювання ігор!

Спонсором в даному випадку стає флеш-портал. Саме його власники готові заплатити за гру від $100 і до $50 000 доларів (це, відповідно, мінімальна і максимальна суми спонсорства, про які мені доводилося чути).

Що отримує спонсор?

Що ж отримує спонсор (ігровий портал) купуючи флеш-гру? Адже, здавалося б, безкоштовних ігор в інтернеті “хоч греблю гати”. При чому безкоштовні вони як для гравців (що само собою зрозуміло), так і для порталів. Тобто володіючи порталом ви можете цілком законно і абсолютно безкоштовно розміщувати на ньому практично будь-які ігри. Наприклад, мій портал існує менше двох місяців, але на ньому вже розміщено близько сотні флеш ігор, які коштували мені $0.

Тоді який же сенс іншим порталам платити за ігри гроші (і іноді – дуже немалі)?

Щоб зрозуміти суть цього явища, потрібно усвідомити, що спонсор купує не право розміщувати гру на своєму порталі (таке право всім дістається безкоштовно), а можливість вбудувати власний брендинг у гру. Відчуваєте, в чому хитрість?

Якщо ви хоча б зрідка граєте у флеш-ігри, то безперечно, стикалися із анімованими заставками (splash screen) перед початком гри. Ви, мабуть, думали, що це заставки розробників, та насправді у більшості випадків це і є найяскравіший приклад брендінгу спонсора. Чи варто говорити, що заставка клікабельна, і клікнувши на ній, ви потрапите на сайт спонсора.

Водночас, брендінг – це не лише заставка. Тільки від спонсора залежить, скільки логотипів та посилань на свій сайт він вирішить вбудувати у гру. Найбільш агресивні різновиди брендінгу можуть включати логотипи безпосередньо в процесі гри, які до того ж, “маскуються” під елементи інтерфейсу. Все це робиться, звісно ж, тільки з однією метою, щоб гравець клікнув і потрапив на сайт спонсора.

Якщо додати до цього той факт, що успішна гра “розходиться” по тисячах порталів і отримує мільйони переглядів, стає очевидно, в чому полягає вигода спонсора. Якщо говорити зрозумілою мовою: за допомогою флеш-гри він просто рекламує свій сайт.

При CTR брендінгу середньостатистичної гри >10% (а по факту буває і набагато більше) до спонсора з інших порталів приходить 100 тисяч відвідувачів з кожного мільйона людей, які зіграли в гру. Це велетенський трафік, за який спонсори готові платити!

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

Типи ліцензій

Продаючи гру спонсору, ви в кожного разу будете підписувати договір, в якому обгворюються конкретні умови ліцензії. Але в загальному їм можна привести до трьох основних типів: ексклюзивні (exclusive), основні (primary) та неексклюзивні (non-exclusive).

1. Ексклюзивна ліцензія (Exclusive license). Один з найдорожчих видів ліцензій і найбільш вигідних для розробника в короткостроковій перспективі. Продаючи спонсорові таку ліцензію, розробник одноразово отримує значну суму грошей, при цьому втрачаючи право розповсюджувати будь-яку іншу версію гри, окрім версії з брендінгом ексклюзивного спонсора. Інакше кажучи, в інтернеті на всіх порталах повинна бути тільки одна версія – та, в яку ексклюзивний спонсор вбудував свій брендінг.

Іноді люди запитують, чи означає це втрату прав автором на користь спонсора? Відповідь однозначна – ні в якому разі! Якщо мене не зраджує пам’ять, авторське право у всьому світі вважається невідчужуваним.

Продавши ексклюзивну ліцензію, розробник може зітхнути з полегшенням – більше перейматися продажею йому не потрібно. Можна взагалі забути про гру. Або з інтересом спостерігати за її статистикою (скільки людей в неї зіграли, на скількох порталах вона була розміщена, скільки часу в середньому проводить гравець у грі тощо).

Потрібно пам’ятати, що продавши ексклюзивну ліцензію, розробник втрачає право продавати неексклюзивні ліцензії або так звані “сайтлоки” (про них далі).

Втім, зазвичай ексклюзивна ліцензія не забороняє автору портувати гру на інші платформи (Android або iOS) та випускати продовження. Взагалі, продовження гри вважається окремою грою, а отже може продаватися окремо.

2. Основна ліцензія (Primary license). Взагалі цю ліцензію ніхто не називає основною. Всі користуються транслітерацією “праймарі”. Тому, щоб не виникало плутатини в термінах, ми також будемо називати її саме так.

Праймарі ліцензія відрізняється від ексклюзивної тільки тим, що за розробником збергіається право продавати неексклюзивні ліцензії (non-exclusive license або сайтлоки).

Простіше кажучи, ви можете продати одному спонсору праймарі ліцензію, в яку він вбудує свій брендінг і буде розповсюджувати по інтернету. Але якщо інший спонсор також захоче придбати цю гру – ви зможете продати йому сайтлок.

Кількість сайтлоків може обмежуватися тільки охочими їх купити! Тому теоретично, хоч праймарі ліцензія зазвичай дешевша за ексклюзивну, та за рахунок продажу сайтлоків розробник може заробити набагато (іноді – в рази) більше.

3. Неексклюзивна ліцензія (Non-exclusive license або сайтлок). Сайтлок (від англ. site – сайт та lock – замок) – це версія вашої гри, яка працює тільки на конкретному порталі і не буде працювати, якщо ви спробуєте перенести її на інший. Для цього в коді прописується спеціальна функція, яка перевіряє домен, з якого запускається гра.

Продаж сайтлоків зазвичай починається після того, як праймарі ліцензія вже продана (як пам’ятаєте, при ексклюзивній ліцензії продаж сайтлоків неможливий). Втім, деякі портали не хочуть розміщувати у себе гру з брендінгом конкурента і при цьому дуже хочуть отримати саму гру. Для таких порталів розробник створює окрему версію з їхнім власним брендінгом. А щоб така версія не розповсюджувалася по інтернету – вбудовує сайтлок.

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

Один із сайтлоків своєї гри “Turtle Dreams to Fly” я продав за $200, тоді як primary ліцензія була продана всього за $400.

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

P.S.: У коментарях доречно зауважили про перформанс (performance), тому додам кілька слів про нього. Performance – це не тип ліцензії, а швидше додатковий пункт угоди між розробником і спонсором, який може бути включений в договір при ексклюзивних та праймарі ліцензіях. За правилами перформансу спонсор платить вам не за факт купівлі гри, а конкретно за трафік, який гра приведе на його сайт. В залежності від домовленості спонсор може платити як за перегляди самої гри, так і за кліки по брендінгу (тобто людей, які перейшли з гри на його сайт).

Класикою наразі вважається $1000 за мільйон переглядів або $0,03 за одного користувача, який прийшов на сайт спонсора. Це середні ціни. Хороші спонсори пропонують більше, погані – менше. Іноді доходить до смішного: наприклад, $10 за мільйон переглядів. З такими спонсорами краще не мати справи взагалі!

Зазвичай при ліцензіюванні гри з включенням перформансу спонсор платить завдаток – гроші, які гарантовано заробив розробник. Але якщо гра покаже себе з кращого боку і сподобається користувачам, у розробника є всі шанси заробити набагато більше. Мені відомо чимало ігор, як набирали більше 10 мільйонів переглядів – тобто більше $10 000 для розробника.

Чи вигідний перформанс для людей, які роблять ігри? Насправді, це доволі неординарне питання. Якщо ви впевнені, що ваша гра буде популярною, тоді перформанс справді вигідний. Але якщо гра виявиться провальною, тоді звичайна ексклюзивна або праймарі ліцензія виявиться кращою за перформанс.

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

Щоб не пропустити нічого цікавого, підпишіться на оновлення блога.

Інші записи на цю тему:

• Редизайн першої гри: Графіка має значення!
• Використання Flash IDE + FlashDevelop. Базова структура флеш-проекту.
• Уроки польотів для черепахи та кілька слів про концепцію другої гри
• Wacom Intuos 4 та Samsung XL2370 – подарунки на День Народження
• Match Insanity – перша flash-гра мого власного виробництва!

За рік мені вдалося багато чому навчитися, продати свою другу гру “Turtle Dreams to Fly” (пограти в неї можна тут), створити власний ігровий портал Jar of Games і повністю переосмислити підходи до ігрової розробки.

З цим хоч і невеликим, та все ж доволі важливим вантажем знань я знову повернувся до своєї першої гри, яка досі бездіяльно “лежала” на аукціоні FGL. І хоча “Match Insanity” створювалася в першу чергу заради розвитку навичок флеш-розробки, було б марнотратством не спробувати заробити на ній хоча б якусь копійчину. Адже за наявності ігрового порталу перед розробником відкривається чудова опція самоспонсорування.

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

В першу чергу зміни торкнулися графіки. Створюючи Match Insanity я повністю проігнорував цей аспект розробки, тому що був свято переконаний – візуальна складова не має ніякого значення… І, вочевидь, це було однією із найбільших помилок. Як виявилося, будь-який спонсор чи власник порталу приймає рішення про купівлю/розміщення гри в першу чергу сприймаючи її візуально. У більшості випадків він не має часу на те, щоб заглиблюватися у ігровий процес. Звучить безглуздо, але нерідко саме іконка (логотип гри розміром 100 на 100 пікселів) виявляється вирішальним фактором успішності продажу/дистрибуції.

Можливо, ви вже бачили цей скріншот, але я хочу ще раз нагадати, як виглядала Match Insanity до редизайну:

Повна відсутність будь-якої графіки “дбайливо” поєднана з абсолютно байдужим ставленням до інтерфейсу.

Для порівняння, нове візуальне оформлення ігрового екрану виглядає так (як і у грі Turtle Dreams to Fly, з графікою мені частково допомагала дружина, за що я їй дуже вдячний):

Як бачите, окрім, власне, графіки, зміни торкнулися деяких елементів ігрового дизайну та логіки інтерфейсу. Передусім, я додав більш “реального” суперника. Якщо у старій Match Insanity це був абстрактний “комп’ютерний інтелект”, то в новій версії гравцеві доведеться зіткнутися з цілою родиною “демонів”.

До речі, ідея ввести в гру більш “предметного” опонента вилилася у ще одне цікаве рішення, яке стосувалося рівнів складності. У попередній версії гравець міг сам вибирати інтелект суперника із трьох варіантів “простий”, “середній” та “складний”. В оновленій грі рівень складності буде зростати автоматично. Спершу вашим суперником виступатиме мале чортеня Боббі, перемогти яке досить легко. Потім в гру вступить його батько Білл (дружина сказала, що схоже на Біла Гейтса). Подолавши його, гравець зіткнеться з наймогутнішим демоном Бальтазаром (найвищий рівень складності).

Не обійшлося у новій грі і без часточки іронії. Хоча опонентами в ній виступають злі сили, нічого поганого вони не роблять, а просто дуже люблять ягоди. До речі, оскільки тепер замість сірників гравцеві пропонується збирати ягоди, назва гри змінилася відповідно – тепер це Don’t Eat Last Berry. Як ви вже здогадалися, основна мета гравця, зробити так, щоб останню ягоду з’їв демон.

Дистрибуція

Оскільки гру було закінчено лише сьогодні пізно вночі, вона ще не встигла розійтися по порталах. Поки що я додав її у Mochi Distribution і чекаю узгодження. Найближчим часом також завантажу гру на два основних ігрових портали Kongregate та Newgrounds.

Вже зараз пограти у Don’t Eat Last Berry можна на моєму порталі. Також буду вдячний за лайки та ретвіти, які посприяють просуванню гри.

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

Бонус: Match Insanity як вона є!

Ну і насамкінець – невеликий бонус. Гра Match Insanity, якою вона була до редизайну. Попри всю її недосконалість, це доволі значна віха історії мого розвитку, як флеш-розробника. Окрім того, оскільки цей варіант гри не буде запускатися у жодну дистрибуцію – її можна назвати своєрідним ексклюзивом. Щоправда, я про всяк випадок таки вбудував туди брендінг порталу – а раптом хтось захоче “вкрасти” для себе.

Пограти у Match Insanity можна за цим посиланням.

Інші записи на цю тему:

• Редизайн першої гри: Графіка має значення!
• Настав час показати мій новий проект – портал флеш-ігор Jar of Games!
• Turtle Dreams to Fly: Статистика та висновки після релізу
• Turtle Dreams to Fly: Реліз!
• Turtle Dreams to Fly нарешті на FGL

Можливо, хтось із читачів пам’ятає статтю про мою першу флеш-гру Match Insanity. Вона була зроблена за кілька тижнів практично без досвіду програмування і мала на меті тільки практику. Звісно, ніхто зі спонсорів навіть не звернув увагу на гру, не дивлячись на те, що я виклав її на FGL. Цілком закономірний і очікуваний результат.

Втім, зважаючи на те, що не так давно я запустив свій ігровий портал Jar of Games, про що більшість, мабуть, також читала у цьому блозі, я вирішив отримати від першої гри хоча б якусь користь і спробувати самоспонсоруватися.

Але зрозуміла річ, що в тому вигляді, в якому гра існує на даний момент, марно навіть думати, що вона зможе принести хоча б якусь віддачу. За рік спроб та помилок я отримав деякий досвід як в плані розробки, так і в плані того, що потрібно гравцям. Тому було вирішено малою кров’ю зробити редизайн гри – змінити графіку, інтерфейс та внутрішню структуру. Я не маю наміру витрачати на це багато часу, тому якихось глобальних змін не буде. Максимум, на що я готовий – виділити кілька днів на “переродження” Match Insanity (до речі, назву також буде змінено, але новий варіант поки що не вигадано).

Щоб трішки відволіктися від роботи, я вирішив поділитися поточним результатом роботи. Можливо, комусь буде цікаво.

Старий варіант Match Insanity виглядав так:

Зараз же гра поступово набуває ось такого вигляду (зміни неостаточні – просто робочий скріншот):

Якщо все буде гаразд – то за тиждень-два (а може й раніше) в гру вже можна буде погратися!

Інші записи на цю тему:

• Редизайн першої гри завершено: Реліз “Don’t Eat Last Berry”
• Match Insanity – перша flash-гра мого власного виробництва!
• Хто готовий віддати гроші за вашу гру? або Кілька слів про спонсорів та типи ліцензій
• Настав час показати мій новий проект – портал флеш-ігор Jar of Games!
• Уроки польотів для черепахи та кілька слів про концепцію другої гри

Jar of Games – це портал найкращих флеш-ігор, орієнтований в першу чергу на європейську та американську аудиторію. Поки-що готовий тільки каркас (для його створення було використано спеціалізовану CMS AV Arcade), але вже зараз портал повністю робочий, працює реєстрація і діють основні функції (як то накопичення балів за оцінку та коментування ігор).

На даному етапі наповнення ведеться повністю вручну, але в майбутньому, коли буде помітно першу віддачу – я обов’язково додам можливість сабмітити ігри учасникам спільноти (з жорсткою премодерацією, звісно). Взагалі, мені дуже хотілося б по-максимуму розвинути соціальну складову порталу і згуртувати навколо нього лояльну спільноту активних гравців. Але все це стане можливим тільки коли я побачу першу віддачу від порталу.

Хотілося б також написати кілька слів про концепцію Jar of Games. Якщо ви хоча б трішечки цікавитесь ігровими порталами, то без сумніву знаєте, що їх кількість надзвичайно велика і вимірюється десятками (якщо не сотнями) тисяч. Втім, по-справжньому якісних порталів з унікальним функціоналом та можливостями для гравців набереться заледве кілька десятків. Як же потрапити до їх переліку?

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

Я ж вирішив поставити на високу якість (навіть якщо доведеться пожертвувати кількістю) і додавати ігри виключно вручну, ретельно відбираючи найкращі. Так, це вимагає чимало часу. Але супершвидкісне наповнення критичне тільки на перших етапах існування порталу – поки збирається основна бібліотека ігор. Коли колекція буде досить “багатою”, можна перейти в режим щотижневого додавання 5-10 найкращих ігор, які були випущені за цей період.

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

Чому я вирішив створити ігровий портал?

Я не хочу перевтомлювати читачів блога про флеш деталями концепції та розробки порталу Jar of Games, оскільки не знаю, наскільки ця інформація буде цікавою для них. Втім, скажу кілька слів про причини, які спонукали мене до створення цього ресурсу.

1. Власний ігровий портал – найкращий спосіб приміряти на себе роль спонсора. Люди, які стежать за цим блогом знають, що останнім часом я захопився розробкою флеш-ігор. Одна з найбільш розповсюджених моделей монетизації такого захоплення – пошук спонсора, який захоче купити вашу гру. Втім, у більшості випадків розробник має дуже “одностороннє” бачення своїх стосунків зі спонсором. На свій власний продукт він дивиться тільки як творець, і не може абстрагуватися від нього. Та це й не дивно, адже розробник ніколи не був у “шкірі” спонсора.

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

Маючи всі ці знання, ви почуватиметесь набагато впевненіше, беручись за розробку власної гри і зможете оцінювати її об’єктивно під час торгівлі зі спонсором.

2. Самоспонсорування. В житті кожного розробника бувають моменти, коли він відчуває себе недооціненим. Припустимо, ви створили гру за яку розраховували отримумати X доларів, а максимальна ставка від спонсорів склала всього X/2. Не біда! Якщо ви впевнені у власних силах і у вас є ігровий портал – можна ризикнути і спробувати самоспонсорування.

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

Окрім того, самоспонсорування – це спосіб отримати хоча б щось за гру, яка взагалі не зацікавила спонсорів. У мене є одна така. Пам’ятаєте – Match Insanity. За вісім місяців на FGL гра так і не отримала жодної ставки від спонсорів (чесно кажучи, зважаючи на її якість, я й не сподівався). Втім, тепер з’явиться можливість отримати з неї хоч щось! Найближчим часом зроблю рескін (тобто зміню графіку у грі) і спробую самоспонсоруватися.

3. Прибуток. Я не даремно розмістив цю причину останньою в переліку. Адже досягнути серйозних фінансових результатів, ведучи портал, ох як не просто! Втім, якщо ви візьметеся до справи зі всією серйозністю, присвячуватимете достатньо часу відбору контенту, працюватимете над створенням власної спільноти і не забудете про SEO – то можливо через деякий час портал не тільки поверне вкладені в нього інвестиції, але й стане основним джерелом прибутків. Принаймні, такі приклади мені також відомі.

А головне, як і завжди – по-справжньому любити справу, якою займаєшся і пам’ятати – сам по собі ігровий портал ніколи не стане прибутковим. Для того, щоб отримати віддачу, потрібно працювати, працювати і ще раз працювати!

А тим часом запрошую всіх читачів блога про флеш завітати на ігровий портал Jar of Games і трішечки відволіктися від шаленого робочого ритму, зігравши в класну флеш-гру. Поки-що колекція не дуже велика (36 ігор на даний момент), але вже зараз вибирати є з чого. Повірте, ви знайдете, на чому зупинити свою увагу! А в майбутньому бібліотека ігор буде тільки поповнюватися.

Ви також можете зареєструватися, щоб отримати можливість накопичувати бали, коментувати ігри, виставляти рейтинг та комунікувати з іншими зареєстрованими користувачами. Але пам’ятайте, для власне гри реєстрація необов’язкова. Тому самі вирішуйте, чи варто реєструватися.

Буду вдячний за коментарі щодо порталу та щодо портальної тематики на блозі про флеш? Наскільки це цікаво для вас і чи хотіли б ви дізнатися деталі щодо створення/розвитку/монетизації флеш-ігор та флеш-порталів.

Інші записи на цю тему:

• Редизайн першої гри завершено: Реліз “Don’t Eat Last Berry”
• Редизайн першої гри: Графіка має значення!
• Хто готовий віддати гроші за вашу гру? або Кілька слів про спонсорів та типи ліцензій