Как се правят игри Подкаст програмисти за Unreal Engine
Старши програмист на Epic и изпълнителен директор на Luden.io за настоящето и бъдещето на двигателя.
— Ник Атамас — старши програмист на двигателя, Epic;
— Олег Чумаков — главен изпълнителен директор на Luden.io.
DTF публикува избрани моменти от разговора.
За историята на двигателя
Ник Атамас:За мен той е разделен на периоди преди и след Unreal Engine 3 (UE3).
Започнах работа в Epic през 2008 г. - тогава се разработваше Gears of War 2. След това направихме браузъра за съдържание (content browser) - първата част на бъдещия UE4.
Андрю Шайдекер работи върху идеята за изобразяване в стил Pixar. Това е, когато вземете мрежа (меш), разделите я на микротриъгълници, всеки с размер на пиксел. След това се прилага аналитично антиалиасинг и независима от реда прозрачност.
Щях да направя UI система, която да работи на всички платформи. Моята част беше оставена в UE4, останалите бяха прекалено умни и някак си не вървяха.
Олег Чумаков:Сега програмистите често пишат контролери за модел на изглед. Всеки сам си е написал такива рамки, защото индустрията, поне в България, работи по Unity през последните години. А в Unreal вие веднага получавате играч, контролер на пешка и вие трябва сами да разделите всичко между тях. В развитието на компанията тя някак си е разбита на подсистеми или се придържате само към основната рамка?
Ник Атамас:В развойна компания разработката започва с това как да направиш играта интересна, така че хората да искат да играят и да не спират. Това обикновено се прави от дизайнери на игри или художници, а не от програмисти. Понякога е необходимо да добавим напълно нови системи, например, така че анимацията да взаимодейства с физиката. Тогава - да, програмистът ще го направида помогна.
Създаването на потребителския интерфейс е по-структурирано, защото има модел: бутони, плъзгачи, менюта, тоест очевиден дизайнерски речник, можете да използвате MVC, MVVM с него. А като правиш една игра - как разбираш кое трябва и кое не.
Олег Чумаков:В концепция, при която дизайнерите започват да правят игра и ние я завършваме, всичко е наред. Но да кажем, че ни донесоха проект, много забавен. Сега трябва да го направим удобен за потребителя, да го накараме да работи бързо със сървъра и така че да не се налага добавянето на нова функция за една седмица.
Как постъпвате обикновено – оставате в рамката, която ЕС предоставя, или не?
Ник Атамас:Инженерите, разбира се, искат да правят нещата по структуриран начин. Но обикновено има график, който казва, че всичко трябва да е приключило преди месец и е време да започнем да хрускаме. Няма време за пренаписване - просто го накарайте да работи.
В този момент са необходими талант и опит, за да се реши дали да се пренапише всичко или да се оставят и да се коригират отделни грешки.
Ако MVC, MVVM са подходящи, те се използват. Мисля, че основното в тях не е гениалният дизайн (който не винаги е подходящ), а в контекста. Получавате „речник“, който можете веднага да използвате, за да стигнете до точката как да приложите нещо.
Всеки разбира, че да се правят отделни "M", "V" и "C" не винаги е умно, те обикновено го разделят така: "M" и "VC". Използва се дори набор от концепции, произлезли от Next и Apple.
И MVVM като цяло е ново нещо, което не винаги е подходящо. Защо да правите три класа, когато много често можете да направите един, да го напишете бързо и той ще работи?
Олег Чумаков:Недоумението при първото стартиране на Unreal идва от факта, че мнозина в българската индустрия седяха на Unity. Има чист елемент-компонент: всичко, което двигателят ви дава, ебазов клас и се отнасят до базовия API, относително казано, статичния API на самия двигател. Като „въведете, кажете ми колко време сте прекарали на последния кадър“ и всичко това. Около това всеки изкриви системата, от която се нуждаеше - естествено, най-често MVC.
Нека да разгледаме други двигатели, дори рамки на Javascript. Там почти винаги, когато създавате ново приложение, автоматично се генерира рамка, за да не носи програмистът архитектурен ад и кошмар. В UE4 случаят е точно такъв. Двигателят създава основната рамка. Ако играта започне с идея за дизайн, дизайнерите са по-малко склонни да пропуснат и след това, когато кажат, че вече е бил месец на „криза“, се сблъскват с факта, че всичко е изложено случайно и го няма.
Ник Атамас:Когато написах първия си двигател, направих всичко погрешно. Но беше необходимо да разберем как да ги напишем.
Не винаги е лесно да се разбере защо ЕС прави това, което прави. Дори бих казал, че всичко се промени отново, време е да помислим как трябва да се приложи за VR. Имаме понятието „контролер за игри“ – това е физически контролер: геймпад или мишка. И има "пешка" - това е като пешка в света, която играчът контролира чрез контролера. Но ако се замислите сега – във VR този контролер е „пионката“ в света на игрите. Човек може да попита отново - MVC вече е на повече от 30 години, може би вече не е подходящ?
Олег Чумаков:Цял живот сме се занимавали със стратегия или CCG и в крайна сметка разбрахме как да разберем архитектурата на Unreal. Трябва сами да напишете как се картографират контролерът на пешката, състоянието на играта, състоянието на играча и т.н., като използвате примера на шутър за мултиплейър. След това записваме параметрите на нашата игра, например - Hearthstone. И ние се опитваме да направим паралели - какво би се случило, ако беше стрелец и как да "разпръснем" компонентите правилно.
Ник Атамас:Мисля, че това е правилното нещо.
Олег Чумаков:С болка стигнахме дотук. Някъде във форума на ЕС има тема, която започнахме. Потребителите рисуваха там къде държат кода за логика и къде - за променливи, синхронизирани със сървъра и т.н. Публикувахме екранна снимка на Hearthstone, на която стрелките показват: по аналогия със стрелеца, тази карта е пешка, а това е само независим актьор, съществува само на клиента (четири бази по краищата на масата).
Олег Чумаков:UE официално поддържа Blueprint (синтетичен език, който може да се превърне в C++) и самия C++. Защо не добавихте някакъв скриптов език, който има текстово представяне?
Ник Атамас:Мисля, че в бъдеще може да има C#, Python или нещо подобно. Вече казахме - MVC, MVVM, защо на въпроса "как трябва да е подредена архитектурата?" добавете "трябва ли да използвам Python, C# или Blueprint, или C++?".
Може би е по-удобно да напиша логиката на C#, визуализацията на Python, а мрежовата част на Blueprint? Сега опитайте да отстраните грешки през всичко това. Защо такова главоболие?
Всеки добавен език е много работа за нас. Колкото повече от тях, толкова по-трудно е да се направи добра опора. Но мисля, че всеки иска да има поне един скриптов език, достъпен за всички, но текстов, а не направен от тел и кутии. Само не е ясно коя.
Да вземем VR. Все още не е ясно за повечето, но във VR има приблизително 10 милисекунди на кадър, а не 16 или 30. Това е много малко. Ако събирането на боклук причини забавяне и играта прескочи 2-3 кадъра, на човек може да му се гади. Може би C# е грешният избор, може да бъде много трудно да се контролира събирането на боклук в него. Или започвате да пишете на C# без да използвате оператора New исе превръща в нещо напълно неразбираемо.
Това са сериозни въпроси - отговорите на тях не са очевидни и дискусията все още продължава.
Сергей Гальонкин:Доколкото разбирам, проблемът е, че програмистите биха искали да позволят на дизайнерите на игри да пишат на скриптов език, който разбират. Има добавки за почти всеки скриптов език в Unreal Engine. Ако някой наистина иска, може да ги сложи.
Олег Чумаков:Нека обясня от гледна точка на разработчика. Има плъгини, те дори бяха подкрепени от грантове. Но когато вляза в тях, списъкът с платформи винаги е непълен. Дай Боже, играта ми иска да работи на Mac OS, Windows, Linux - това е, няма нито един plug-in. Или ако излезе нова версия на API на двигателя, трябва или сам да я „препратя“ в Javascript, или да изчакам, докато този, който поддържа плъгина, има почивен ден, за да го направи.
Ник Атамас:Какво ще кажете за iOS, Android, PS4, Switch? Единственият език, който работи на всички платформи, е C++. Ако изберем един език, трябва да сме сигурни, че той работи перфектно навсякъде. Мисля, че нито една компания в света няма да осигури добра поддръжка за два езика - твърде много работа. Сега Python, C# и JS може да са правилният избор - мисля, че един от тях.
Относно Blueprint
Ник Атамас:Направихме плана след Кисмет. Имаше три използвани системи в UE3 - C++, Unreal Script и Kismet. C++ е използван от разработчиците на двигателя. САЩ, използвани от програмисти, които правят геймплей. И дизайнерите на нива работиха с Kismet, например, ако вратата трябва да се отвори след убиване на врагове.
Някои дизайнери на нива използваха трикове. Един човек, Лий Пери, използва Kismet, за да направи статив робот от War of the Worlds за UT3. Тогава програмистите го взеха, прехвърлиха го в US и C ++ и тази машина можеше да бъдекарам в UT3.
Погледнахме го и казахме: „Добре, нека получим повече възможности от САЩ за Кисмет, САЩ трябва да изчезнат.“ Програмистите ще се погрижат за двигателя, а останалите разработчици ще започнат работа в Kismet 2. След това той беше преименуван на Blueprint.
Сега, използвайки Blueprint, можете почти напълно да направите игра и да не напишете нито един ред C ++ код. Мисля, че основната му сила е скоростта на итерация. От момента, в който промените нещо и натиснете бутона "play", минава половин секунда-секунда и проверявате какво сте променили. Благодарение на добрата интеграция с двигателя, скоростта на развитие се увеличава. Ако трябва да намерите нещо, просто отивате в браузъра за съдържание, плъзгате и пускате и всичко работи.
Мисля, че има и слабости - отстраняването на грешки не е толкова добре развито, колкото C ++. Търсенето работи доста добре, но не толкова добре, колкото в C. И ако имате голям екип, е невъзможно да се влеете в него. Единият работи върху плана, другият не може да направи нищо, докато другият не свърши.
Михаил Кузмин: Има ли някакви ограничения, например за клиент-сървър игрите, или може да прави нещо?
Ник Атамас: Blueprint може да направи всичко. Не бих правил тежка математика върху него, моя алгоритъм за сортиране. Например на Robo Recall превеждаме Blueprint на C++ и става доста бързо - с един бутон.
За библиотеките
Олег Чумаков:Имало едно време Oculus пусна своя много, много първи проект за VR, беше на UE и с отворен код. Бяхме изненадани, че целият код, онези функции, които са написани на C ++, логиката на играта и така нататък - всичко е разложено на C ++ .dll файлове, отделни библиотеки. Кодът на играта беше свързан с двигателя като плъгини. Имахме хипотези защо това е така - библиотеката се компилира по-бързо, художниците не компилират нищо, но могатпросто дайте библиотеки и т.н. "Разбивате" C++ ли, или е в проекта?
Ник Атамас:Наистина зависи от състава на отбора. Например Robo Recall има 4-5 дизайнера в него, някои могат да пишат на C ++, но най-вече правят всичко в Blueprint поради скоростта на итерация. Мисля, че запалените инженери на C ++ работят върху Oculus и те са много по-приятни да работят в него: те разбиват логиката на плъгини и когато плъгинът е малък, можете да получите итерация за две или три секунди.
Също така обичам да правя всичко на C++. Натискате бутона „компилиране“ или „презареждане на модула“ (това е по-„скрита“ функция в Unreal) и стартирате отново .dll, без да спирате двигателя. Бонусите са очевидни - дебъгерът, търсенето и рефакторингът работят страхотно, има достатъчно разделяне (сливане) между хората.
Но обикновено дизайнерите казват на програмистите как трябва да работят нещата и те точно като робот казват „добре, ще го направя“.
Относно мобилното развитие
Ник Атамас:Цялото съдържание никога не е било включено в компилацията. Имаме процес на "готвене" - "изпичане" на проекта. Това е като "събиране на боклук". Започваме с root - това е списък със специални пакети, които винаги се използват в играта, например - снимките за потребителския интерфейс винаги се съхраняват в паметта. Разглеждаме корена и правим „пропуск за събиране на боклука“: намираме всичко от този корен, което показват стрелките, всички препратки. Останалото изхвърляме.
Имаме концепцията за DDC - "Derived Data Cache". Например компресираме текстура във формат, който най-добре отговаря на платформата. Това е частта "изпичане". По време на изпълнение Unreal записва всички версии на текстури, мрежи и анимации в DDC, подготвени за платформата. След това „изпичането“ или взема извлечени данни, или при пренасяне ги адаптира към желаната платформа.
Разбира се, често хората добавят препратка към този листнещо, което всъщност не използваме и то случайно попада в най-новата версия. Но ние се опитваме да го избегнем.
Работа със звук
Композиторът, който в момента работи с нас, е Арън Макларън. Той е гений, много обича музиката, сам я пише през уикендите. Той напълно пренаписа миксера, който смесва звуците в играта, и ние го използваме в Robo Recall. Той също така добави синтез към системата и направи API за нея. Живеейки в Сиатъл, често говорим как да подредим потребителския интерфейс, така че да е по-достъпен за работещите в музикални програми.
В Robo Recall имаме втори човек, млад инженер, който се занимава много сериозно с музика – той написа част от саундтрака и звуците за проекта. Мисля, че това е най-добрият звук, който сме правили в Epic. Нови опции от тази област ще се появят в UE, мисля, че ще бъдат показани на GDC.
Относно Вулкан
Ник Атамас:Мисля, че нашите момчета вече работят с него. Vulkan и DirectX 12 дават на програмиста повече възможности, но с тях е много по-лесно да се направи грешка, която влошава производителността.
Програмистите, които правят графики само ден и нощ, най-вероятно няма да направят тези грешки. Или ако ги направим, те ще ги намерят. Това ще даде много на двигателя. Но за човек, който иска да напише мобилна игра или нещо подобно, Vulkan е по-лош. Добрият стар Open GL е по-добър за прости игри.