Adventure Jam 2016

image

Хочеться розповісти про досвід участі в Adventure Jam 2016. Деякий час тому я вирішив спробувати взяти участь в якому-небудь геймджеме і вивісив пост про пошук команди в одному з спільнот вконтакте. Пройшло більше місяця, ніхто не писав, і я вже забув про цю затію, але раптово на зв'язок вийшов художник Сергій. Досить швидко ми знайшли великий конкурс довжиною в два тижні, темою якого були ігри-адвенчуры. Вирішено було робити класичний point'n'click-квест. Команду поповнили аніматор Борис і композитор Василь, за кілька скайп-сесій ми обговорили сеттінг і сюжет, після чого взялися за роботу. Під катом ви знайдете невелику постмортем у чотирьох частинах від імені кожного учасника команди, з описом техпроцесу, проблемами та рішеннями, враженнями і висновками, які кожен виніс з участі.

Частина Віктора (код)

I. Движок
Після того як ми визначилися з жанром і механікою, настав час вибирати зброю. Щоб у вашу гру пограло найбільша кількість людей, вона повинна бути максимально доступною. Мало кому хочеться качати і ставити білди по кілька сотень мегабайт, тим не менш, багато учасників вибрали саме цей шлях. Запусків у ігор, що підтримують браузер, більше на порядок, тому ідеальним варіантом було зробити щось під веб. У мене досить багато досвіду з С++ версією Cocos2d-x, але вона орієнтований на десктопи і телефони/планшети, а ось JS-версія дозволяє запускати гру в тому числі і в браузері. На JavaScript я до цього жодного разу нічого не писав, тривалість джему — всього два тижні, тож цей варіант викликав певні побоювання, але наявність досвіду з самим фреймворком і З-подібність JS виглядали непоганою компенсацією.

II. Хронологія
Розробка почалася з імпорту тестовій сцени і ефект паралакса (коли різні шари рухаються з різними швидкостями, створюючи ілюзію глибини). Тут дуже допоміг Python, в якому є чудовий модуль psd-tools, він дозволяє читати PSD-файлів і експортувати як окремі шари зображення. Скрипт парсил отриману від художника сцену і генерував папку з картинками і json з координатами.

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

image

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

III. JavaScript
JavaScript наче створений для режиму code like hell. Швидкість розробки порівняно з С++ більше в 3-4 рази, без жартів. Мені вистачило одного поста (https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript) і прикладів з движка, щоб за пару днів почати більш або менш висловлюватися. Звичайно, поспішність позначилася на якості коду, але, з іншого боку, на те це і джем.

Як IDE я використовував WebStorm, автокомплит працює відмінно, помилки підсвічуються. Для налагодження замість веб-версії запускав нативний білд, в якому забиндил кнопку R для перезавантаження всіх скриптів з диска. Довелося пожертвувати можливістю покрокового дебага, але він виявився не дуже й потрібне. У підсумку workflow був наступним: пишемо код, альт-таб в додаток, R, все за секунду підвантажується, дивимося на зміни, альт-таб в IDE, пишемо код. Швидкість ітерацій неймовірна.

Ще один позитивний момент в JavaScript — можливість перевизначити метод у існуючого класу або розширити його без успадкування, наприклад ось так:

cc.Node.prototype.runActionWithDelay = function(delay, action) {
this.runAction(cc.sequence(cc.delayTime(delay), action));
}

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

Механізм заливки виявився досить простим, cocos compile -p web -m release, архівуємо, заливаємо на gamejolt.com або itch.io, там же можна вказати розміри вікна з грою, що дозволяє уникнути мук з дозволами. Ігор, що використовують Cocos2d-x, незважаючи на простоту і зручність розробки, на GameJolt досить мало, я думаю наша була першим проектом на JS версії.

IV. Проблеми
Анімації пресонажей і дій робилися під Flash, для імпорту використовували покадрову нарізку. На жаль, нормальної підтримки SWF для HTML5 версії движка я не виявив, хоча раніше успішно використовував для цих цілей SuperAnim в С++ і Lua версіях. Покадровые анімації не самим позитивним чином позначилися на розмірі білду, буквально за кілька днів він разъелся до 130 мб. І хоча на великий розмір у веб-версії ніхто не скаржився, користувачі мобільної версії такої гри відразу помітять недобре. В якості можливого рішення для анімацій можна використовувати Spine, він добре підтримується движком і дозволяє уникнути гігансткіх атласів з покадровыми анімаціями.

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

V. Підсумки
Перед початком джему необхідно мати якийсь базовий код для типу гри. Завжди приємно писати свої велосипеди, але краще робити це заздалегідь, щоб залишити максимум часу для написання безпосередньо геймлпея. У правилах деяких джемів прямо забороняється використовувати будь-які власні надбудови над движками, але з одним винятком: якщо код викладений в публічний доступ і доступний іншим учасникам джему, його дозволено використовувати — ось і привід викласти свої поделия на GitHub. Я писав все з нуля, і частина моїх тимчасових оцінок виявилася надто оптимістичною, що, на жаль, позначилося на інтенсивності останніх 2-3 днів розробки перед дедлайном.

Відсотків 10-20 від усього часу потрібно залишити на полишинг і плейтест — це дуже важливий пункт, який легко забути в бойовому запалі. Пропустити якусь прикру помилку крайньої легко, і вона найсумнішим чином позначиться на оцінках. У цьому джемі одну з ключових механік я почав писати вночі, за три години до дедлайну, як результат у версії 1.0 була певна кількість неприємних шорсткостей. На щастя правила джему дозволяли вносити косметичні патчі, після воссатновления хп і мани всі огріхи були виправлені.

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

Частина Сергія (арт)

I. Розробка сеттінга/стилістики
На ранньому етапі має сенс визначитися з сеттінгом і стилістикою проекту. Тут я зроблю невеликий відступ. Справа в тому, що в ігровій індустрії існує мейнстрім, широко поширені сеттинги (фентезі, sci-fi і т. д.) та стилістики (візуальні мови, в рамках яких ці сеттинги втілюються), які полюбилися гравцям. При цьому поширена копіювання і компіляція, часто важко відрізнити один фентезійний проект від іншого, т. к. форми і прийоми кочують з одного проекту в інший. Я переконаний в тому, що робити те ж, що і всі, має сенс лише в тому випадку, якщо у вас є достатньо ресурсів і навичок, щоб зробити це краще за інших. В умовах обмеженості ресурсів ефективніше просто відрізнятися, мати впізнаване обличчя. Якщо ви змогли підібрати унікальний візуальний мову, то гравець простить вам можливі огріхи у виконанні, він запам'ятає вашу гру. Якщо ви робили те ж, що й інші, але не дотягли до того, щоб підняти планку вище, то всі забудуть про вашу грі, ледве зачинивши вікно програми.

Звідси виникає логічне запитання: а як взагалі зробити щось нове? Відповідь проста і логічна: потрібно брати матеріал поза середовища відеоігор. Це можуть бути суміжні професійні середовища, наприклад, ілюстрація та інші форми образотворчого мистецтва — у них можна знайти вже готові, опрацьовані образотворчі мови, які ще не втілювалися в іграх (так, наприклад, зробили творці Year Walk — порівняйте те, що вони зробили, з роботами ілюстратора Jon Klassen). Можна також шукати матеріал в інших сферах життя, але тоді переробляти і уніфікувати його в стилістику вам доведеться самим.

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

1) Збір матеріалу та відбір
Ще до початку джему я грунтовно покопався в надрах рунета і зібрав безліч референсов. Проаналізувавши їх, я зробив висновок, що об'єкти з дитячих майданчиків дуже сильно різняться естетично, і малювати їх без попереднього відбору й уніфікації було б помилкою. Найсильніше об'єкти відрізнялися за матеріалом — були дерев'яні, як правило витесані з колод, металеві зроблені з грубо пофарбованих цементних брил. Кожен з видів являє собою дуже багатий матеріал, але для простоти я вирішив обрати один вид — дерев'яні статуї.

image

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

image

image

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

3) Начерки композиції
На цьому етапі я продумував сюжет гри одночасно з роздумами над композицією окремих фонів. Спочатку ми планували зробити кілька сцен і навіть миниигру. Джем, як водиться, вніс свої корективи — ми встигли тільки одну сцену, і сюжет не вийшов завершеним. Проте в рамках джемів більш вигідно виглядають проекти, які виглядають не як зав'язка, а як повноцінні твори. Тут ми допустили промах — потрібно точніше розуміти свої сили і розподіляти їх так, щоб встигнути виконати мінімальний обсяг задуманого. Часто варто робити контент менш продуманою, щоб встигнути більше. На жаль, я маю звичку закопуватися в деталях, це моя хронічна помилка. Можливо, десяток джемів відучити від цього. Було б непогано.

image

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

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

image

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

2) Фон
Що стосується фону, то напрошувалося таке рішення — використовувати для прототипу ще не промальований фон, але вже з нарізаними і належним чином проименованными шарами.

image

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

3) Розробка фону:

image

-попередній начерк (thumbnail sketch) композиції
-пророблений лінійний малюнок (lineart). Я рідко роблю детальні лайнарты, оскільки не хочу робити зайву роботу — лайнарты сильно змінюються при фарбуванні об'єкта і частково навіть не використовуються. Тому цей етап у мене не так сильно відрізняється від попереднього.
-заливання форм, кожному об'єкту — окрема заливка по силуету. Як раз на цьому етапі я віддав хлопцям чорновий варіант графіки (див. п. 2).
-прописування кожного об'єкта одного за іншим всередині заливки, починаючи з найбільш великих мас. Ось це небезпечний номер. Справа в тому, що роблячи так, ми порушуємо принцип «від загального до часткового» і ризикуємо отримати картинку з абсолютно дробової колірною схемою, де об'єкти не поєднуються один з одним ні за кольором, ні за тону. Тому робити так має сенс тільки якщо у вас багато досвіду і ви себе добре уявляєте, який колір де має бути, або якщо композиція дуже проста. Я робив так, тому що інакше я б взагалі не встиг, довелося покластися на свій досвід. Класичне рішення даної проблеми — це як роблять академічні художники: перед початком картини вони роблять етюди, в яких визначають загальне кольорове і тонове рішення. Але у них немає іншого вибору, оскільки якщо вони зіпсують картину, то все, нічого не поробиш. В цифрі є й інші способи вирішення даного питання, в цілому кожен робить як йому зручно.

image

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

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

Частина Бориса (анімації)

I. Flash
Говорити про роботу аніматора в цьому проекті – суще покарання. Практично все, що я робив, було зроблено не зовсім або зовсім не так, як це робиться зазвичай. Ми не обговорювали з художником-постановником характер анімації персонажа, практично не обговорювали графіком (тут обійшлося, оскільки Сергій зробив персонажа максимально умовним, що істотно розв'язало руки аніматор, тобто мені), анімації взаємодії персонажа та об'єктів фону ми «запікали», що призвело до невеликих стрибків у чіткості об'єктів, ми використовували Flash виключно як графічний інструмент, так як в гру анімація імпортувалася в формі растрових сиквенсов. Зроблено це було, зрозуміло, не з-за недбалості, а через катастрофічний брак часу.
Тому описати роботу над анімаціями персонажа можна дуже коротко: я робив це дуже швидко і дуже неправильно.

II. Підготовка руху
А от розповісти про анімації об'єктів фону – дерев'яних статуй, буде корисно. Тут у аніматора взагалі мінімальна свобода: об'єкти практично не мають рухомих частин і заздалегідь намальованих фаз руху (стану об'єкта, які не можуть бути зроблені простим переміщенням його частин, наприклад градації «розколотості» зберігача ключа). Для боротьби з цим використовується прийом «підготовка руху». Прийом формулюється так: підготовка руху важливіше самого руху. Очей, вірніше, мозок, часто одурюється і «домальовує» відсутні частини руху, гріх цим не скористатися. Розглянемо приклад.

image

image
Тривалість анімації розколювання зберігача ключа – двадцять кадрів, і половину з них ми використовуємо навіть не на рух, а на замах: десять кадрів статуя злегка збільшується у висоту, вуса і брови злегка опускаються зовнішніми кінцями вниз. За цей час око звертає увагу на те, що відбувається – рух почався. З десятого по дванадцяте кадр статуя починає різкий рух вниз (брови і вуса відіграють в протилежну сторону, імітуючи інерцію), у тринадцятому кадрі ми підміняємо зображення злегка розколотої статуї на зовсім розколоту. Ця фаза по висоті трохи нижче попередньої і ілюзія продовження руху зберігається. Єдина рухома частина в цій фазі ключ і з тринадцятого по двадцятий кадр він здійснює одне хитання, завершуючи рух. Таким чином, при програванні ми отримуємо зв'язне рух, хоча власне анімації розколювання в цій послідовності взагалі немає. Після цього можна тихенько сказати собі: «Ура!» – ми обдурили очей, використавши мінімальна кількість фаз.

Частина Василя (музика)

I. Вступна частина
Коли мені запропонували взяти участь у джемі, я погодився майже відразу ж, мені дуже сподобалося візуальне рішення гри, а також концептуальна частина — ігор, які повертали б тебе в дитинство, не так багато, як може здатися, тому спробувати відтворити таке відчуття — це цікава задача. Крім того, мені сподобався підхід автора ідеї Сергія, який полягав не в режисерському деспотизмі «зробити треба як мені видніше», а повної творчої свободи «ти краще знаєш, як це повинно бути». В такому випадку ти сам собі замовник, а хто буде приймати роботу суворіше внутрішнього критика? Так що це було цікаве пропозицію, і я погодився.

II. Музика
Музика в іграх такого жанру, як правило, відіграє важливу роль: вона не повинна сильно набридати, оскільки ми не знаємо, за який час гравець вирішить ту чи іншу задачу, перш ніж зазвучить інший трек. Тому важливо, щоб мелодія була ненав'язлива і не відтягувала на себе увагу. Під час розробки нашої сцени було вирішено зробити три мелодії — стартову, мелодію «щось пішло не так» і динамічну, нагнітати тему. Звучить досить просто, якщо говорити про класичні хоррорах, проте в нашому сучае — це все ж відчуття дитинства, деякою казковості всього, що відбувається. Музика повинна була підкреслювати настрій, а не лякати.

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

III. Звукове оформлення
Говорячи про звуковому оформленні я відштовхувався від матеріалів наших персонажів. Як правило все це дерев'яні ідоли, тому очевидним рішенням став тріск і скрип рассошегося дерева. Такий підхід виправдав себе в моменти стосуються «Зберігача ключа», створити звук «дерев'яного чхання», руху усов з коротких семплів самих різних скрипів виявилося досить цікавим завданням. Анімації озвучувалися окремо, так, щоб звуки були синхронізовані з рухами, а на кроки персонажа-дівчатка я створив додатковий набір хрускотів, які програвалися у випадковому порядку, визначеному інтервалі кроків. Фоновим шумом для всіх ігрових моментів став звук цвіркунів — теж стандартне рішення, яке чудово себе виправдало. Хоча іноді хочеться здивувати нетривіальним підходом до вирішення завдань звуку, потрібно також розуміти, в яких моментах велосипед вже винайдено. Було б здорово, звичайно, озвучити репліки персонажів, але в наших умовах це було вже перфекціонізмом. До речі, факт того що репліки не були озвучені дав прекрасну можливість нашим летсплеерам озвучити їх самостійно.

IV. Резюме
На завершення хочу сказати, що для мене це був перший досвід участі в яких би то не було джемах. І це був дуже цікавий досвід. Відчуття того як майже незнайомі люди працюють як одна команда посилювалося весь час, поки ми розробляли гру, і я хочу висловити вдячність моїм колегам за унікальну можливість не просто виконувати свою роботу, але і буквально відразу ж бачити і її реалізацію, можливість бачити помилки і відразу їх виправляти. Хоча обмеження по часу має передбачати напруга, для мене цей досвід був радше приємним, що дозволило краще розібратися в своїх можливостях і дізнатися нові аспекти розробки ігор. І хоча я вже досить давно залучений в цю індустрію — вона не перестає мене дивувати. Завжди знайдеться щось новеньке, і це неймовірно здорово.

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

http://www.indiegamejams.com
https://itch.io/jams
http://jams.gamejolt.com/browse/active
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.