Розробники S.T.A.L.K.E.R. 2, World of Tanks та інших ігор згадали свої перші завдання у геймдеві

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

Створити за тиждень мережеві хрестики-нулики

Олександр Піндик, World of Tanks Lead Engineer у Wargaming

До того, як потрапити в геймдев, я працював системним адміністратором і налаштовував мережі та сервери в «Укртелекомі», а у вільний час писав сайти на PHP.

Це були темні часи :) Мені хотілося робити ігри, але в моєму місті було лише дві ігрові студії. І коли одна з них почала активно набирати людей, я вирішив спробувати. Вони шукали Flash-програмістів на соціалки для Facebook. Я відправив резюме, і за кілька днів мені відповіли та дали тестове завдання. Потрібно було написати мережеві хрестики-нулики з дедлайном за тиждень. Чи знав я, як робити клієнт-серверні ігри? Ні. Чи знав я Flash та ActionScript 3? Ні. Чи виконав я зрештою тестове? Так!

На той момент я знав PHP та C++. Точніше, думав, що знав. Особливо C++. Особливо після кількох спроб написати на ньому сервер. Тому сервер я написав на PHP. З Flash теж виникли питання. Google підказав довгий шлях — прочитати книгу Essential ActionScript 3.0: ActionScript 3.0 Programming Fundamentals (948 сторінок!) і вивчити ActionScript 3. Я ще кілька хвилин пошукав швидше, а потім взяв на роботі відпустку на тиждень і почав читати книгу. Всю прочитати не вийшло, але я вивчив синтаксис та основні концепції за три доби. Я читав і розбирав приклади з книги майже 24/7, зрідка роблячи перерви на їду та сон.

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

Через три дні мені відповіли та запросили на співбесіду. Правду кажучи, це була одна із найбільш запам’ятовуваних співбесід у моєму житті. По-перше, її проводив CTO компанії, який на той час відповідав за найм та перевірку тестових завдань. По-друге, моє тестове у нього не запустилося. Після цього я не вірив, що мене візьмуть на роботу. Тому коли наступного дня мені зателефонували та запропонували позицію, я не повірив! Як виявилось, CTO подивився код і оцінив хід моїх думок. Ось так я і потрапив у GameDev. Після цього на ActionScript я писав код кілька днів і більше ніколи з ним не стикався. Потім перемкнувся на розробку мобільних ігор під iOS, що привело мене до Wargaming.

Реалізація систем розпорядку неігрових персонажів

Дмитро Шевченко, Lead Programmer в Ubisoft Kyiv

У 2006 році я прийшов працювати скриптером над грою в жанрі RPG. І одним із моїх перших завдань була реалізація системи розпорядку для неігрових персонажів (NPC). Вони мали виходити зі своїх будинків, ходити певним маршрутом, «розмовляти» один з одним, якщо їхні маршрути перетнулися, та у призначений час йти додому спати.

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

І ось, коли все було зібрано докупи й увесь код написано, персонажі вирушили в місто. Увечері ж вони йшли до своїх ліжок і лягали... — і тут же фізика вистрілювала ними метрів на 15. У польоті вони «розуміли», що лежать не в ліжку, поверталися до них, і процес повторювався. Все це тривало до ранку, коли вони знову йшли на прогулянку містом.

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

Дізнався, як миттєво викликати блювоту та чому стандартна фізика в Unity не годиться для онлайн-ігор

Євгеній Ратушний, Senior Unity Developer в APPSULOVE

Моєю першою компанією був невеликий київський аутсорс, який спеціалізувався на VR-застосунках і спортивних симуляторах. А я самоука з двома місяцями досвіду роботи над своїми пет-проєктами з моменту мого першого Hello world! Я також не був знайомий із процесами роботи в ІТ-індустрії, а системи контролю версії знав поверхово, на практиці практично не застосовував. І тому моє завдання спершу ввело мене у ступор, а тоді викликало подив, як це має вийти.

Завдання звучало так: «У нас є потенційний клієнт з Китаю, який хоче замовити програму під VR Google Daydream (це такий VR-хедсет, або точніше сказати комплект для використання свого телефону як обчислювального центру та екрану VR-гарнітури, з контролером із 3 ступенями свободи, досить якісний, і ПЗ у нього гарне, я навіть був здивований, як воно в результаті круто працює), в якій зможуть працювати та взаємодіяти одне з одним кілька користувачів в онлайн-кооперативі. У цьому застосунку користувачам належить вчитися збирати всілякі складні механізми на кшталт ДВС чи турбін».

Сказали, що в ролі серверної технології краще використовувати Photon PUN (я не гадки мав, що це значить). Мені створили Git-репозиторій під цей проєкт, дали в руки мобільний телефон Samsung Galaxy останньої моделі та хедсет з контролером. Також порадили завантажити тестовий проєкт Daydream для Unity і спробувати попрацювати спершу з ним.

Сказати, що я очманів, нічого не сказати: VR, онлайн-кооператив у реальному часі, складні механізми, Photon, Daydream, Git-репозиторій... Для мене тоді це все звучало як мова іншопланетної цивілізації, яка на трильйони років обігнала людство. Я гадки не мав, вийде у мене чи ні, бо раніше нічого схожого не робив.

Конкретних термінів мені не поставили, сказали, що в разі чого звертатися до проджект-менеджера. Показали на розробника, який відповідатиме на мої запитання, якщо вони з’являться. І за два тижні CTO мав дивитися проміжний результат.

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

Я пішов за своє робоче місце, завантажив останню LTS-версію рушія, створив новий 3D-проєкт, знайшов у UnityAssetStore плагін Google Daydream і Photon PUN. І зробив перший коміт, до речі, на це пішло не менше однієї години, може, двох, тому що до цього не мав досвіду роботи з гітом. «По дорозі» дізнався від того програміста, якому мені сказали ставити запитання, про існування .gitignore і .gitattribute.

Репозиторій засетапив і проєкт закомітив — вирішив я. Став думати, з чого почати. Спочатку розбирався, що таке Daydream і VR, раніше VR в руках не тримав.

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

Далі я вирішив зібрати Example-сцену з плагіну Daydream на телефон, білди на Android я до цього теж не робив, а тоді Unity не вміла нормально встановлювати Android SDK, NDK, JDK. Тому на це пішло ще кілька годин. Врешті я це виконав, переконався, що щось виходить. І це, по суті, все, що я встиг за свій перший робочий день.

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

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

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

Ось таке у мене було перше завдання у геймдеві.

Розплутати спагеті-код майже готової гри

Віктор Антоненко, Lead Unity-розробник OBRIO

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

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

Моєю серйозною помилкою, яка призвела до зриву термінів, була спроба розплутати це «спагеті». Але це виявилося надто часовитратним, і довелося кинути рефакторинг, а його код ізолювати, помістити в папку легасі та закрити для посилань зовні, щоб не допустити повторного використання.

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

Створити катсцени для гри у жанрі НОРА

Іван Чернишов, Senior 3D Animator в GSC Game World

Нині я Senior 3D Animator в GSC Game World, і моя діяльність виглядає приблизно так:

Але мій шлях в ігровій індустрії розпочався з інших завдань. Це було взимку 2014-го в Донецьку, коли друг, який працював у компанії Boolat Games, запропонував мені робити катсцени для гри Dreampath: The Two Kingdoms у жанрі НОРА, що була в розробці.

Складали катсцени у програмі Adobe After Effects, і це загалом нічим не відрізнялося від виробництва рекламних відеороликів. Мені давали розкадрування ролика та арт, який малювали художники. Часто в катсценах поєднувалися мальовані та 3D-об’єкти, а моїм завданням було змусити це «ворушитися», приправити все ефектами, зімітувати поведінку камери в сцені тощо.

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

Замовник спілкувався, як персонаж рольової гри

Степан Суліменко, Lead 3D Artist, 24Play

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

Це замовлення зацікавило мене не тільки тим, що воно передбачало роботу для сфери, а й надзвичайно креативним підходом замовника. Він написав: «Вітаю, мандрівник! Король оголосив про нагороду сміливця, який (далі було технічне завдання на кілька ізометричних моделей для 4Х-стратегії, яка так і не побачила світ)». Всі обговорення, правки відбувалися у рольовому форматі, що мене дуже веселило, оскільки робота справді перетворилася на квест. Завдання було не дуже просте на той час, бо мені доводилося вперше вчитися, як правильно дотримуватися кривенького концепту, як витримувати стилізацію і як зробити так, щоб ці кілька об’єктів разом потім мали гармонійний вигляд.

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

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному2
LinkedIn


Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі