Від Могилянки до розробки S.T.A.L.K.E.R. 2 за три роки: інтерв’ю з Lead Platform Programmer GSC Game World
У тринадцять років Кирило Сидоров відкрив для себе C++ завдяки олімпіаді, на яку потрапив майже випадково. Тоді програмування здалося йому магією: можна написати кілька рядків коду й змусити комп’ютер робити те, що потрібно. Згодом це захоплення привело його до інтернатури в Dragon’s Lake та роботи в GSC Game World, де Кирило зараз відповідає одразу за два напрями.
Ми поговорили з Кирилом про керівництво командою досвідченіших за нього спеціалістів, розробку інструментарію для модингу S.T.A.L.K.E.R. 2 та поради тим, хто хоче увірватися в геймдев
«Це реально здавалося магією, особливо в мої 13 років». Про зацікавленість геймдевом та вибір університету
Ледь не з першого класу я був впевнений, що піду в економіку. Але так склалося, що я жив у провінційному містечку (Ніжин, Чернігівська область) і був тією дитиною, яку тягали на половину олімпіад: українська мова, математика, економіка... В якийсь момент мене запросили на олімпіаду з програмування, хоча я тоді абсолютно нічого в цьому не тямив.
У нас був молодий вчитель інформатики, який після університету прийшов викладати до школи. У процесі підготовки (це було вивчення C++) я зрозумів, наскільки це прикольно: коли ти можеш просто власноруч щось написати й змусити комп’ютер робити те, що тобі потрібно. Це реально здавалося магією, особливо в мої 13 років. Десь так я й зачепився за програмування. Тому хочу подякувати Роману Олексійовичу за допомогу з першими кроками в «плюсах».
У мене є сестра, на 9 років молодша, і ми з нею постійно вигадували різні ігри. Коли всі інші гралися в машинки чи стрілялки, у нас була митниця, документи, чеки, банки — отака двіжуха. Програмування мені дуже допомагало розвивати ці наші ігри, бо можна було друкувати різні речі, вигадувати цікаві механіки. В якийсь момент я навіть купив на AliExpress чековий принтер, написав програму, яка імітує банк, і друкував справжні чеки. Тож моя сестра була таким собі мимовільним драйвером, який допомагав мені розвиватися в програмуванні поза школою та олімпіадами.
Для мене в геймдеві надзвичайно важливо відчувати безпосередній результат своєї роботи. Умовно, коли ти робиш якийсь банківський застосунок — це круто. Я розумію, чому люди задоволені, чому хвалять той самий Монобанк. Там чудові технічні рішення. Але мені набагато цікавіше створювати те, що змушує людей десь сміятися, а десь, можливо, злитися на гру. Коли ти бачиш, що результатом твоєї роботи користуються мільйони людей, вони грають, їм весело, вони класно проводять час — це неймовірно мотивує. І хоч я тоді ще до кінця не розумів усіх процесів, бо розробка ігор — це складно, та точно знав, що хочу пов’язати своє життя з цією індустрією.
Далі постало питання вибору університету. Вступити до Києво-Могилянської академії я хотів ще з дев’ятого чи десятого класу. Чому саме туди?
- чув багато хороших відгуків про те, що там немає корупції;
- там можна самостійно вибирати предмети;
- там викладають найкращі фахівці країни.
Я був переконаний, що треба йти тільки туди. Хоча був і один курйозний момент. Я з україномовної родини, але моє рідне місто Ніжин у ті часи (це десь
«Давно думаю, щоб прийти туди й провести курс із геймдеву». Про плюси та мінуси навчання в Могилянці
Якщо говорити про актуальність загальної програми, то я оцінив би її як 50 на 50 або навіть трохи менше. На жаль, чимало речей у програмі (особливо нормативні предмети) були складені ще
Перше — індивідуальний вибір предметів. Ти обираєш дисципліни самостійно, а не всією групою, як у багатьох інших університетах. Раз на рік відкривається запис на курси: перед тобою список із майже сотні дисциплін, з яких потрібно сформувати власний навчальний план. Наприклад, обрати десять вибіркових курсів професійного спрямування.
Друге — міжфакультетний вибір. Якщо хочеш додатково вивчати англійську, психологію чи економіку — просто записуєшся на ці курси, і вони зараховуються як повноцінні дисципліни.
Втім, із матеріальною базою є проблеми. Університет намагається забезпечити студентів всім необхідним. Ліцензіями, внутрішніми сервісами... хоча нормальних комп’ютерів у Могилянці майже не було, тож усі працювали з власних ноутбуків. На той момент у мене ще не було роботи й грошей, тому мій ноутбук був дуже старим — як у тих мемах, коли вмикаєш його, а він гуде й заводиться, наче газонокосарка.
Фінансування — мабуть, найбільший біль НаУКМА. Через це університету дуже важко втримувати сильних викладачів. Мій приятель, який там викладає, отримує близько 20 тисяч гривень на місяць. Це смішна оплата за таку важку працю.
Через це в університети (і це проблема не лише Могилянки) йдуть працювати дві категорії людей:
- Ідейні, натхненні фахівці. Вони реально цікаво розповідають, хочуть навчити й мають практичний досвід у бізнесі. Для них викладання в університеті — це фактично волонтерство.
- Ті, хто не зміг знайти достойну роботу в приватних компаніях. Вони йдуть викладати в ЗВО, бо конкуренція за посади через низьку оплату там невисока.
Саме завдяки ідейним викладачам і варто йти в Могилянку. Вони чудово пояснюють низькорівневі аспекти програмування. Не в сенсі «примітивні», а максимально наближені до роботи самого комп’ютера. І дуже добре дають алгоритми та структури даних. Мені це надзвичайно допомогло на співбесідах. Інтерв’юери навіть дивувалися: «О, класно, ти ж інтерн і не зобов’язаний був цього знати, але знаєш!» Це було дуже приємно.
Це, зокрема, заслуга і Бублика Володимира Васильовича. Він вже літній пан, але саме він навчив мене дивитися «під капот» C++ і розглядати програмування не з позиції кодера, а з позиції інженера. Це кардинально змінило мою перспективу.
До речі, щодо Могилянки. Я давно думаю про те, щоб колись прийти туди на рік чи два й провести курс із геймдеву. Наразі таких курсів там немає. Це було проблемою і під час мого навчання, і залишається нею зараз. В українському IT більшість іде у веброзробку, AI, Machine Learning, Data Science чи Embedded (особливо тепер, коли цей напрямок критично важливий для MilTech). Геймдев-напрям у більшості університетів практично не представлений.
Я ще ні з ким в університеті про це не говорив, але знаю, що наш декан дуже підтримує такі ініціативи. Він любить, коли приходять практики й привносять щось нове. Там немає радянської бюрократії із затвердженням програми через сім кіл пекла й гори паперів. Просто приходиш, пояснюєш концепцію курсу, і це цілком реально організувати.
«Пів року досвіду — і вже штука баксів». Про інтернатуру в Dragon’s Lake, академвідпустку та особисту старосту
В певний момент часу я розумів, що для мене робота має вищий пріоритет. Бачив багато прикладів, коли люди закінчували університет (в Україні ж часто вступають до вишу просто за інерцією після школи), але потім не могли знайти роботу. І усвідомлював: що раніше почну працювати, то швидше здобуду цінний практичний досвід. Фахівець із досвідом завжди має більше перспектив, ніж новачок без нього. Під час повномасштабної війни це стало особливо помітно, адже увійти в індустрію джунам стало набагато складніше.
Я хотів працювати ще до повноліття, але неповнолітніх тоді майже нікуди не брали. Щойно мені виповнилося 18 років, я активно почав готуватися. Моніторив вакансії й знайшов інтернатуру в Dragon’s Lake. На співбесіду я прийшов добре підготованим із C++. Мені одразу сказали, що знання Unreal Engine на старті не потрібні — усього навчать. Але сама співбесіда була надзвичайно жорсткою. Мабуть, настільки глибокого технічного інтерв’ю я більше ніколи не проходив — мене дуже серйозно ганяли по всій теорії.
Тоді я взагалі не уявляв ринкових зарплат джуніорів. Думав, що великі гроші — це десь далеко в майбутньому. На співбесіді озвучили умови: під час інтернатури платять 250 доларів, а після її успішного завершення — вже тисячу. Я був просто шокований: пів року досвіду — і вже штука баксів! На той момент це здавалося чимось космічним.
Хоч я і думав, що співбесіду провалив, технічний директор Володимир Іванов вирішив інакше. Він взяв мене на інтернатуру й став моїм ментором. Я неймовірно вдячний цій людині. Володимир навчив мене майже всього, що було потрібно для роботи з Unreal Engine, а головне — дивитися вглиб проблеми, а не лише ковзати по поверхні.
Наша інтернатура була повністю присвячена навчанню — без комерційних завдань. Упродовж шести місяців ми слухали лекції та виконували практичні завдання. Нас поділили на групи, і кожна мала створити власний великий проєкт. Вимоги були максимально простими: зробити будь-яку гру, але з мультиплеєром, анімаціями, штучним інтелектом та інтерфейсом. Три місяці ми працювали над цим проєктом. Фактично це була повноцінна фултайм-робота, але без комерційного тиску. Після завершення інтернатури нас розподілили на різні, вже комерційні проєкти. Це був безцінний досвід.
Я розумів, що поєднувати фултайм-роботу з навчанням у Могилянці буде непросто. Але мені допомогла дисципліна, до якої звик ще зі школи. Тоді я прокидався о п’ятій ранку, щоб до уроків встигнути виконати замовлення на фрилансі. Мені дуже подобалося заробляти власні гроші й купувати собі круті речі — новий монітор чи то відеокарту для компа. Тож я звик мало спати й не байдикувати.
До того ж інтернатура почалася саме під час пандемії COVID-19. Усі думали, що це ненадовго, тому університет у моїй системі пріоритетів трохи відійшов на другий план. Я сфокусувався на роботі й тих університетських дисциплінах, які справді вважав корисними, а деякі менш цікаві інколи доводилося пропускати.
Через онлайн-формат я міг дивитися лекції асинхронно: викладачі записували заняття й загалом дуже адекватно ставилися до студентів, які працюють. За це їм величезний респект.
«Від друзів з інших університетів я часто чув зовсім інше: „Ваша єдина робота — це навчання, а все інше другорядне“. У нас же казали: „Працюєш? Круто. Але не забувай також виконувати завдання“»
Тож лекції я дивився вночі, лабораторні робив вечорами — крутився як міг. Під час сесії, яка в Могилянці триває два дуже насичені тижні, завжди брав відпустку на роботі. Коли вона закінчувалася, проджект-менеджер щоразу запитував: «Ну що, відпочив?» А я ледь не зі сльозами відповідав: «Так, неймовірно відпочив. Усім бажаю так відпочивати». Насправді складати сесію було значно важче, ніж просто працювати у звичному темпі.
На останньому курсі я зрозумів, що всі організаційні деталі навчання губляться в нескінченних чатах і каналах. Тому за символічну плату найняв собі персональну старосту. Жодного порушення академічної доброчесності — лише допомога з відслідковуванням дедлайнів. Ми навіть створили окремий проєкт у Jira: замість робочих задач додали туди лабораторні, розставили пріоритети й планували спринти. Це було одне з найкращих рішень.
Усім, хто хоче поєднувати роботу з навчанням, можу дати одну пораду: змиріться з тим, що встигнути все неможливо. В добі лише 24 години, і хоча б сім із них треба спати. Доведеться жорстко визначати пріоритети: що справді важливо для майбутнього, що менш важливо, а що треба просто здати, щоб не вилетіти. До того ж викладачі дуже цінують студентів, які виконують завдання вчасно — це нерідко допомагає отримати автомат на іспиті.
І ще одна порада: не намагайтеся бути відмінниками в усьому. Я сам довго страждав через синдром відмінника й хотів бути найкращим усюди. Це забирало величезну кількість часу й сил. Оцінки в університеті далеко не завжди корелюють із реальними технічними навичками, а заради зайвого бала часто доводиться виконувати багато надлишкової роботи. Обирайте свій напрямок і фокусуйтеся на ньому.
Під час повномасштабної війни я взяв академічну відпустку на два роки, тому закінчив бакалаврат лише торік. Ніхто не знав, скільки триватиме війна, а моя родина залишилася без роботи. Я став єдиним годувальником. Тому вирішив повністю зосередитися на роботі, а до університету повернутися вже після стабілізації ситуації. Так і сталося: згодом я захистив диплом і нарешті отримав ступінь бакалавра.
Можливо, цього року вступатиму до магістратури — теж однозначно в Могилянку. Я дуже вдячний цьому університету за ставлення до студентів. Не знаю, як на інших спеціальностях, але в IT більшість навичок здобуваються через самоосвіту. Університет не може навчити всього, зате вчить шукати інформацію й швидко вчитися. Саме за це я йому найбільше вдячний. Звісно, були й конфлікти чи дрібні непорозуміння, але це нормальна частина процесу.
«Я вже звик, що можу бути молодшим за своїх підлеглих». Про роботу в оточені досвідченіших спеціалістів та перехід в GSC
Формально я тоді ще був студентом, але фактично — ні, бо переходив у GSC саме під час дворічної академвідпустки. Увесь мій час належав компанії, тож це нікого не бентежило. Про оцінки чи диплом мене ніхто не запитував, хоча навчання було зазначене в резюме.
На момент переходу в GSC у мене вже було три роки досвіду. У Dragon’s Lake я багато займався портуванням і платформною розробкою. Саме цей досвід став моїм золотим квитком. Перед релізом S.T.A.L.K.E.R. 2 компанії критично бракувало спеціалістів, які добре знаються на платформах. Я опинився в досить вузькій ніші, тож став майже ідеальним кандидатом і доволі легко потрапив до компанії.
У GSC дуже дружня атмосфера — такий собі вайб великого стартапу. Звісно, компанія росте, з’являються нові корпоративні процеси, адже неможливо керувати командою з пів тисячі людей за правилами маленької сімейної студії. Але з ейджизмом чи упередженим ставленням через вік я ніколи не стикався. Це велика заслуга менеджменту та HR.
Якщо говорити про синдром самозванця в технічному плані — ні, я його не відчуваю. До компанії я прийшов уже сильним спеціалістом із досвідом у своїй досить вузькій ніші, якого не було в інших.
Але що вища твоя позиція, то «сеньйорнішим» стає коло спілкування. Ти починаєш працювати з людьми, які мають по
«Я вже звик до того, що можу бути молодшим за своїх підлеглих, але водночас бути їхнім лідом. Вік чи навіть кількість років у професії — не головний показник»
Буває, людина роками працює над одним проєктом і розвиває одну систему — такий собі «програміст одного класу». А буває, що за менший проміжок часу фахівець проходить кілька абсолютно різних проєктів, працює з різними архітектурами й у результаті стає значно сильнішим інженером.
Найважливіше в менеджменті — спілкуватися дружньо й етично, але водночас чітко тримати професійну дистанцію. Коли стаєш лідом, уже не можеш бути «своїм у дошку братюнею», з яким можна попліткувати про рішення топменеджменту чи внутрішні проблеми компанії. Доводиться уважно стежити за тим, що говориш. Будь-які твої слова (навіть сказані без злого наміру) можуть передати далі як офіційну позицію ліда, а це створює зайві проблеми.
Найважче для мене було навчитися делегувати. Це перший серйозний виклик, з яким стикається майже кожен новоспечений лід. У моїй голові це виглядало так: «Мене призначили лідом, бо я найсильніший спеціаліст у команді. Отже, тепер маю працювати ще більше й ще краще, щоб довести, що цього заслуговую». Це створювало величезний внутрішній тиск.
Насправді все працює інакше. І часом найсильніший спеціаліст не стає лідом. Завдання очільника команди — не самому виконувати всі операційні задачі, а навчати людей, допомагати їм розвиватися. Потрібно зробити так, щоб у майбутньому в команді були не один лід і три мідли, а один лід і три сеньйори. Або щоб у разі твого переходу в інший відділ хтось із колег мав достатньо експертизи, щоб перебрати твою роль. Уміння не тягнути все на собі й делегувати — одна з ключових навичок ліда.
Якщо говорити про архітектуру проєкту, то треба прийняти просту річ: ідеальних технічних рішень майже не існує. А навіть якщо вони існують у вакуумі, то рідко збігаються з інтересами бізнесу. Тому завжди потрібно шукати баланс між якістю та швидкістю релізу.
«Якщо намагатися довести до ідеалу абсолютно все, гру можна не випустити ні за сім, ні за десять, ні навіть за тринадцять років — завжди знайдеться щось, що можна покращити»
Треба навчитися відчувати момент, коли подальше шліфування вже не робить продукт кращим, а лише спалює дорогоцінний час, який можна було б інвестувати в інші системи. У мене є чітке правило: коли я висловлююся від свого імені — це виключно моя особиста професійна позиція, а не офіційна позиція компанії.
«Так склалося, що в GSC я керую одразу двома напрямами». Про роботу Lead Platform Tools Programmer
Тож хто такий Lead Platform Tools Programmer і чим займається його команда? Це напрям, який люди без досвіду в індустрії часто взагалі не розуміють. Ми займаємося низькорівневою розробкою для ігрових консолей — PlayStation та Xbox.
Ця робота потребує глибокого розуміння архітектури консолей і принципів роботи кожної платформи. Вона також передбачає щоденне вивчення спеціалізованої документації, яку неможливо знайти ні в Google, ні в ChatGPT. Уся ця інформація перебуває під жорстким NDA й доступна лише на закритих партнерських порталах виробників консолей. Розібратися в ній — окремий великий виклик.
У багатьох аутсорс-компаніях цей напрям називають портуванням. Зазвичай все виглядає так. Клієнт приходить із готовим або майже готовим ПК-проєктом і каже: «Тепер нам потрібно запустити його на PlayStation». Завдання команди — у максимально стислі терміни розібратися в абсолютно чужому коді й адаптувати його до суворих вимог платформи. І Sony, і Microsoft мають величезні чеклісти технічних стандартів, без виконання яких гру просто не допустять до релізу у своїх магазинах.
Окрім цього, потрібно виконати величезний обсяг оптимізації. Під час активної фази розробки мало хто думає про продуктивність — усі зосереджені на створенні механік і контенту. Оптимізацією серйозно займаються вже ближче до релізу. І тоді доводиться занурюватися в написаний іншими код, аналізувати його й переписувати так, щоб він працював у рази швидше, не погіршуючи візуальну якість гри.
Так склалося, що в GSC я керую одразу двома напрямами. Через досить глибоку структуру команди, окрім платформної розробки, я відповідаю ще й за модинг. Наша команда розробляє офіційний інструментарій для модингу — Zone Kit, також відомий як S.T.A.L.K.E.R. 2 SDK або Mod Editor. По суті, це спеціально модифікована версія Unreal Engine, у яку ми інтегрували власні системи, створені спеціально для S.T.A.L.K.E.R. 2.
Наша мета — дати спільноті інструмент, за допомогою якого модери зможуть:
- замінювати 3D-моделі та текстури;
- змінювати баланс і конфігурацію гри;
- створювати повноцінні власні модифікації.
Ми активно розвиваємо цей інструментарій і плануємо регулярно випускати великі оновлення. Для мене це один із найцікавіших напрямів роботи, адже ти буквально переписуєш внутрішні механізми Unreal Engine, щоб інші люди могли створювати моди, пакувати їх, а кінцеві гравці — легко встановлювати. При цьому потрібно виконати величезну кількість вимог до безпеки, продуктивності й стабільності роботи гри з модифікаціями, що мають паралельно відповідати вимогам платформ.
Чому я так багато говорю саме про ці два напрями? Тому що новачки, які приходять у геймдев, зазвичай бачать лише те, що лежить на поверхні — геймплей. Вони бачать стрільбу, інтерфейс, ігрові механіки й часто запитують: «Навіщо мені вивчати складні алгоритми, структури даних чи оптимізацію? Їх усе одно ніхто не помітить».
Насправді ж наша Platform Tools-команда занурюється на самісіньке дно рушія, переписує його під наші потреби та змушує гру працювати стабільно. Як на мене, це найкрутіша й найцікавіша частина розробки. Мені це справді подобається. Хоча треба бути реалістом. Якщо для розробника критично важливо підійти до друга, який грає в гру, показати пальцем на екран і сказати: «Оце зробив я», тоді краще обирати геймплей-програмування.
«Наша робота — це невидимий фронт. Гравці помічають її лише тоді, коли ми з нею не впоралися»
Якщо гра виходить у реліз і підвисає, люди пишуть: «Розробники полінувалися й не зробили оптимізацію». Потім команда місяцями працює над виправленнями, виходять патчі, продуктивність нормалізується — і для більшості гравців це просто стає новою нормою. Ніхто не пише хвалебних відгуків про те, як круто ми переписали систему керування пам’яттю.
Через це низькорівневі програмісти нерідко вигорають. Результат їхньої роботи майже непомітний широкому загалу. Не будеш же пояснювати друзям: «Пам’ятаєш, раніше після пострілу з дробовика гра фризила на 20 мілісекунд через спавн проджектайлів? А тепер я переписав його на пул об’єктів з асинхронним стримінгом — і цього фризу вже немає». Більшість гравців навіть не здогадується, що за цим стоїть.
А от хлопцям, які працюють над SDK для модингу, у цьому сенсі трохи простіше. Модмейкери безпосередньо взаємодіють із нашим інструментарієм, бачать наші рішення і щиро радіють, коли нам вдалося щось оптимізувати. Тому я дякую команді за натхненну працю та невтомне бажання зробити Zone Kit на найвищому рівні. Щоправда, наш SDK вийшов настільки масштабним, що його, мабуть, варто продавати одразу в комплекті з окремим SSD-диском. Актуальна версія інструментарію займає приблизно від 600 до 700 ГБ. (Сміється)
Тож, щоб комфортно займатися модингом, знадобиться близько 700 ГБ під інструменти й ще приблизно 150 ГБ під саму гру. Майже терабайт чистого, добірного S.T.A.L.K.E.R. на SSD.
Вимоги до заліза справді серйозні. Але це не наша забаганка — такими є технічні вимоги Unreal Engine. На пересічному комп’ютері розгорнути настільки великий проєкт із безшовним відкритим світом, сотнями тисяч текстур, моделей, звуків і складними матеріалами дуже важко: він або завантажуватиметься годинами, або аварійно завершуватиме роботу через нестачу оперативної пам’яті.
«Це не та робота, де можна тихенько сидіти в кутку». Поради студентам, які мріють про великий геймдев
По-перше, йдіть у програмування й геймдев лише тоді, коли вам це справді подобається. За час навчання я бачив багато талановитих людей із високими балами ЗНО та сильними математичними здібностями, які йшли в IT лише тому, що там добре платять або так порадили батьки. Це шлях у нікуди. Якщо займатися тим, що не приносить задоволення, дуже швидко вигориш, перестанеш розвиватися й у підсумку навряд чи станеш високооплачуваним спеціалістом.
Геймдев — одна з найскладніших спеціалізацій в IT. Тут бувають овертайми, складна кросфункціональна взаємодія між геймдизайнерами, художниками, тестувальниками, продюсерами й програмістами. Це не та робота, де можна тихенько сидіти в кутку й ні з ким не спілкуватися.
По-друге, вивчайте, як усе працює «під капотом». Якщо ви обрали Unreal Engine, читайте його вихідний код. Не поспішайте щоразу відкривати Google чи ставити запитання ChatGPT, щойно виникла проблема. Розвивайте навичку самостійного дебагінгу й пошуку рішень у незнайомих ситуаціях. Unreal Engine — це величезний рушій із мільйонами рядків коду. Рано чи пізно ви натрапите на баг, який ніде не задокументований і про який не знає жодна велика мовна модель. У такі моменти потрібно вміти розбиратися самостійно.
По-третє, не нехтуйте алгоритмами й структурами даних в університеті. Навіть якщо зрештою ви не підете в геймдев, ця база знадобиться будь-де. Саме вона відрізняє інженера від людини, яка просто пише код.
Я переконаний, що рутинне програмування з часом значною мірою автоматизує штучний інтелект. Людина описуватиме алгоритм, а ШІ генеруватиме код. Але спроєктувати архітектуру, зрозуміти бізнес-завдання й побудувати логіку системи — це те, що ще дуже довго залишатиметься відповідальністю інженера.
По-четверте, робіть власні pet-проєкти. Це банальна, але надзвичайно ефективна порада. Спробуйте створити власний масштабний проєкт. Найімовірніше, без досвіду ви не доведете його до релізу самотужки — і це абсолютно нормально. Натомість у процесі ви власноруч попрацюєте з великою кількістю різних систем.
На співбесіді, коли вас запитають про досвід, ви зможете детально розповісти про свій проєкт і пояснити кожне технічне рішення. Якщо зможете аргументовано захистити свою архітектуру перед інтерв’юером — автоматично станете значно сильнішим кандидатом. Якщо ж ні — усе одно отримаєте безцінний досвід.
У вільний від роботи час я теж працюю над інді-проєктом. Наразі наша команда складається з восьми людей, і лише невелика частина отримує зарплату. Решта — мої друзі — допомагають на ентузіазмі. Моє основне коло спілкування — програмісти, тому знайти ще одного розробника для мене не проблема. А от відшукати сильного левел-артиста, 3D-моделера чи саунд-дизайнера — уже справжній квест.
«В інді-розробці ціна помилки значно вища, ніж у AAA»
Якщо велика студія помилиться, вона втратить час і гроші, але завдяки масштабам і бюджету, найімовірніше, зможе це компенсувати. Для невеликої інді-команди невдале технічне рішення, яке коштуватиме пів року чи рік роботи, може виявитися фатальним. Особливо якщо потрібно щомісяця виплачувати зарплати команді.
1 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарівДуже цікава і надихаюча стаття, дякую Кирило 🤝