За время существования индустрии разработки игр формул разных механик, способных развлечь нас, придумали не одну сотню. Что-то умерло засветившись в паре игр, что-то ушло со временем, какие-то существуют до сих пор. Есть и такие, которые не просто выжили, но стали мейнстримом, хотя только портят нервы игрокам. Игровой дизайн большинства старых игр, от второго фолыча до первого FarCry и пятью активными перками, пусть и не был вершиной искусства - затягивал не хуже современных песочниц с миллионом активностей. Редкую игру захочется пройти второй раз, а как вспомню, что на прохождение можно потратить под сотню и больше часов - думаю, а оно мне действительно было надо? Можно же было заняться чем-то более интересным. Я знаю, чем закончился второй фолыч, знаю это уже четвертый раз, но каждый раз игра удивляет меня чем-то новым. А вот нового "Аватара" бросил на половине, слишком много всего и все недоделанное, и прозрачные стены... просто бич игры. И тут вопрос, чего-то не хватает в этой раздутой, перекачанной сотней механик игре? Только задумайтесь - в аватаре больше сотни основных механик, которые влияют на окружение. Может в играх что-то потерялось? Хотя "потерялось" - звучит странно - за столько лет индустрия только создала просто море всего нового. Статья ориентирована на "побурчать", так что не ждите каких-то великих секретов и тонкостей мастерства.

Теория вероятностей – одна из важных частей не только игрового дизайна, строго заскриптованые события без вариантов быстро вызовут скуку у игроков. У меня за спиной был всего один год этой дисциплины в универе, и не сказать, чтобы нужно было применять это каждый день, но когда надо объяснить базовые знания дизайнерам, то приходится сталкиваться с тем, что каждый дизайнер понимает теорию вероятности по-своему. Эти мои размышления появились после обсуждения с одним из коллег замечательной статьи Яна Шрайбера о неслучайных случайностях и сломанных ГСЧ в играх. Игры - это огромные недетерминированные системы, независимо от того, закладывали это в проект или нет. И понимание природы случайности для контролирование таких систем, которые влияют на опыт игрока, помогает создавать их так, чтобы они не казались прибитыми сбоку гвоздями. Если в системе есть случайность, нужно понимать как её изменить, приблизив её к бытовому пониманию игроков. И даже если все механики игры строго детерминированные - их взаимодействие дает случайный результат, в чём вы можете убедиться, посмотрев многочисленные видео по различным взломам игровых систем.

Фараон, вышедший в далеком 1999 году был одной из первых игр, которые предлагали поэтапное строительство зданий. Да которые еще и требовали наличие разных ресурсов. Навскидку могу припомнить серию Settlers, Majesty и может еще парочку. После Цезарь III, исхоженного вдоль и поперек, где основным ресурсом при постройке зданий были монеты, это было действительно удивительно и ново. Особым удовольствием было наблюдать, как город живет своей жизнью в процессе постройки монументов, помню просто построил минимальную необходимую инфраструктуру для монумента и просто наблюдал как архитекторы жаловались на недостаток материалов, рабы бегали то на фермы, то на строительную площадку, торговцы периодически продавали кирпичи. Ну и остальной город, конечно, жил своей жизнью, можно даже забыть на какое время про отдельные части города, игра все равно не остановится, и тут понимаешь почему игра до сих пор остается одним из лучших градостроев: отличительная особенность серии — «баланс», баланс отточенный в мелочах. Восстанавливая эту часть игры, я не перестаю удивляться как это все было реализовано на тех аппаратных средствах, замечу, очень и очень небольших, 64Мб оперативки было далеко не у всех. Одним из нововведений монументов было то, что они были составными зданиями, отдельные части могли быть заменены на другие, что в общем давало возможность из одного набора текстур создавать разные по виду здания. Это сейчас кажется, что такой подход есть в любой игре, но в 99 такой механикой могли похвастаться немногие. Сначала я пытался восстановить оригинальный алгоритм отрисовки, но быстро понял, что столько if не осиливаю не только я, но и компилятор, пришлось велосипедить.

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

В разработке игр тоже есть похожая проблема, но уже в отношении существующих вещей, и называется она "red barrel", этот термин я несколько раз слышал от своих англоязычных коллег game-дизайнеров. Страхи те же: критика, негативное отношение к изменениям, отсутствие четкого плана действий.

Если в пылу сражения, например в шутере, вы увидите красную бочку, то точно по ней пальнете, потому что 9 игр из 10 предлагают именно такое поведение - красные бочки взрываются. Бочка взорвется и нанесёт урон врагам, которые (совсем вот глупые) мало того, что бочки с ГСМ расставили по уровню, так еще и курят рядом(все знают что курение убивает). Почему бочки стали проблемой расскажу ниже.

В 98 году в школе, где я учился, компьютер был только у директора. Наш учитель биологии, замечательный мужик, который по ночам подрабатывал админом в компьютерном клубе через дорогу, был единственным человеком, который шарил как этот ящик вообще работал. Я там тоже периодически зависал, поэтому в какой-то момент получил доступ к директорскому компу, под видом чистки и настройки. Все попытки заинтересовать меня программированием заканчивались включением SimCity, Caesar или Settlers и парой часов упорных тренировок в мобами. Позже, уже закончив универ, я работал в различных конторах, писал код для проектов не связанных с игростроем, но постоянно мечтал о создании игр. Пробовал заниматься маленькими играми для себя, да только в 2006 году бесплатные движки, такие как Unity и Unreal, ещё не существовали. В итоге получалось в основном писать свои движки с нуля и делать разные демки, которые благополучно забыты.

Свою карьеру в игровой индустрии мне довелось начать в компании EA в качестве программиста игрового движка, того самого Unity, но заниматься приходилось в основном низкоуровневыми оптимизациями. Так я быстро понял, что мне нравится игровой дизайн больше, чем программирование (мне по-прежнему нравятся оба направления, поэтому в какой-то момент я и перешел в AI). И хотя программистам особо не доверяли ни создание уровней ни дизайн игр, зато в рабочее время можно было спокойно изучать как функционирует и то и другое, да еще и денег за это платили. Причем изучать не только со стороны редактора, но и изнутри. Стать профессиональным игровым дизайнером у меня не вышло, но разбирать как этот самый дизайн в играх был сделан нравится и сейчас.

Над открытыми мирами не довелось работать, ну кроме, разве что, Cuisine Royale, которая, как бы, не совсем честный открытый мир, но задачи анализа технических решений в других играх и движках, чтение соответствующих лекций и статей помогают понимать какие решения были приняты дизайнерами при разработке, и главное зачем это было сделано. При погружении в новую игру, эти решения еще не так очевидны, но когда набегаешь под сотню часов в Witcher 3 или Zelda, эти паттерны становятся видны и легко ловятся взглядом. Хочу заметить, что ни та ни другая игра не ставят исследование в качестве основной цели. Квесты в Witcher рассказывают уникальные истории, а Зельда, как бы это не показалось странным, акцентируется на боевке и системе крафта. И что еще заметно, в этих играх не обязательно сильно исследовать окружающий мир. Дизайн уровней и компоновка golden path построены так, что игры ведут игрока за ручку, и он все равно оказывается возле важных областей или сюжетных квестов. А когда появилась возможность покопаться в движке и уровнях Metro: Exodus, то конечнo, с интересом начал разбираться с доступными материалами.

Опять будет много текста и картинок

Эта история навеяна недавним интервью в одну контору, которая считает, что желтые и красные конторы, не такие синие. Все случайные совпадения неслучайны, имена скрыты. Ни один случайный бобёр за время интервью не пострадал.

Бобер-HRобер: я увидела как грызете дерево в соседнем лесу, не хотите перебраться к нам? У нас деревья синие и потолще ваших, зеленые деревья нынче не в моде.
Бобер-погромист: хм, наверное нет, толщина текущих деревьeв меня устраивает.

Бобер-HRобер: ну вы всё-таки приходите, мы заложили пару делянок, где самые опытные бобры будут распиливать очень старую монолитную сосну с ветками длиной 98 см, на доски очень модной нынче длины 23 см, а еще у вас также будет возможность повлиять на толщину досок длиной 26 см.
Бобер-погромист: а вот это интересно, отправляйте соловья.

Через неделю, на комфортабельной полянке где-то в синем лесу.

Senior-Бобер: Итак, вы считаете себя хорошим бобром?
Бобер-погромист: Всё верно. Грызу деревья разной толщины уже лет двадцать.

Lead-Бобер: А ветки какой длины предпочитаете?
Бобер-погромист: Ветки 17см самые вкусные

Первый игровой автомат Atari Pong, был выпущен в 1972 году. Это игра для двух игроков, основанная на настольном теннисе, где каждый игрок управляет ракеткой и должен отбить мяч на другую сторону. Если игрок промахивается, соперник набирает очки. Первый кто наберет 11 очков становится победителем. Kent Steven в своей книге "The Ultimate History of Video Games" (Вся история видеоигр) описывает, что проект был отдан инженеру Aлану Алькорну (Alan Alcorn), который до этого не занимался играми и игровыми автоматами. Учитывая, что в кармане основателя Atari было немногим больше 500$, и привлечь опытных разработчиков для работы над неизвестным проектом шансы были минимальные, то Нолан Бушелл представил это как выполнение контракта для General Electric.

Алькорн превзошел ожидания на этот проект, кроме функции подсчета очков и таймера раунда, он добавил в игру разделение каждой ракетки на восемь условных сегментов, попадая в которые мяч менял траекторию движения на разные углы. Также вместо проектирования нового аркадного автомата как единого устройства, он использовал дешевый черно-белый телевизор, деревянный шкаф и ручки от газовой плиты. Кроме этого Алан перепроектировал оригинальную схему, заменил компоненты на более дешевые аналоги. Впоследствии таймер раунда был поправлен на изменение скорости шарика, это изменение добавило игре динамики, но потребовало больше памяти, из-за чего игра получила особенность, что ракетки не могли дойти до верхнего края экрана. Алькорну, ограниченному по времени, уже некогда было исправлять такое поведение и баг стал фичей, которая позволяла опытному игроку так отразить мячик, что он улетал в "мертвую зону".

Но каким бы точным и выверенным не был игровой процесс, центром игры является человек, ему свойственно ошибаться. Ошибаться в оценках, в действиях, в движения мышкой или скорости нажатия на кнопки. Когда у игрока не получается выполнить действие, которое, как он думает, было сделано правильно, он начинает ругать игру и окружение, отвлекаться и еще больше ошибаться и бросает играть. Зная эти особенности опытные дизайнеры всегда дают возможность ошибиться, но делают это так чтобы вы этого не заметили. Если игра слишком явно поддается, это раздражает даже больше, чем завышенная сложность.

Давайте разберем к каким уловкам прибегают игры, чтобы играть было интересно.

Хотел написать продолжение к статье Что почитать игровому программисту? про использование С++ в игровых движках, но размышления свернули куда-то не туда.

Завороженно смотрю как и какими темпами идет развитие языка в последние годы, и понимаю, что получить и особенно применить возможности С++20/3 в разработке игр и движков получится хорошо, если с опозданием лет эдак в пять, как раз на следующее поколение консолей, если вообще получится. Сейчас плюсы в игрострое зависли где-то между 14 и 17 стандартом, Сони только-только выкатила свою версию компилятора с полной поддержкой 17 стандарта, а учитывая реактивность игровых студий в изменении кор пайплайнов, что-то новое начнут только в новых проектах. Менять коня, т.е. компилятор посреди разработки игры равносильно стрельбе не только по ногам себе, но и соседям программистам: работает - не чини.

Если смена компилятора и стандарта не даст гарантированного прироста скорости работы больше 5%, то бюджет и людей я не одобрю. (с)

Знакомство с кодовой базой больших движков дает понимание уровня и объёмов кода в продакшене и в тулзах, и ситуация вырисовывается такая, что эти объемы стали в индустрии, что называется "too big to fall", т.е. написать что-то новое, уровня движков вроде Unity/Unreal/Dagor на другом языке, будь он хоть в тысячу раз безопаснее и в десять раз быстрее не получится, но попытки конечно делаются. И чем дальше продолжается поддержка существующих проектов на плюсах, тем меньше возможности выбора остается.

Все попытки прикрутить сбоку скрипты, виртуальную машину второго языка, визуальные редакторы скриптов, блупринты и т.д. лишь показывает насколько громоздким стал основной механизм. А игры прекрасно продаются на текущем стеке технологий, и обосновать переезд на новый стек мифическим рефакторингом, техдолгом и новыми технологиями не удаётся, поэтому мышки продолжают плакать и потреблять кактус++.

Разбирая завалы файлов на своем старом HDD, Seagate Barracuda 7200.10, объемом аж 80 гигабайт(сейчас туда влезет не всякая игра со стима) наткнулся на интересный документ, который выдавали программистам при приеме в дружную питерскую студию электроников. Он достаточно полно описывал набор знаний, на которые надо было ориентироваться при сдаче ежегодной аттестации. Но помимо соответствия некоторым придуманным требованиям, при поднятии грейда, первую роль конечно играло наличие закрытого объема задач, желание руководства и наличие позиции в штатном расписании.

Были конечно и свои рокстары, которые "спасли контору" или разработали какую-то уникальную технологию в рамках студии, перескочив несколько ступенек сразу, но таких были единицы. В массе же народ просто рос на своих задачах, поднимая грейд каждые 2-4 года. Так что, если кто искал "железные грейды" из кровавого "ентерпрайза" добро пожаловать под кат. Судя по тому, что раздавали этот документ всем желающим, думаю он не был особо секретным или под NDA, на всякий случай убрал оттуда упоминания некоторых продуктов и специфичных технологий. Ну и учтите, что документу скоро будет 10 лет в обед. Требования cгруппированы по областям знаний. Документ так и назывался EA Developer Competency Matrix, переводить на русский не стал, думаю и так все понятно написано. (Оригинал КДПВ тут)

Это продолжение статьи с интересными, как мне кажется материалами, которые были собраны за время работы в игровых компаниях, и которые тем или иным образом повлияли на меня. Программисту игр, впрочем как и любому другому программисту, приходится достаточно много читать разной литературы, игровых и околоигровых статей, смотреть записи конференций. Так что, со временем получился список разных по технической направленности статей и видео, что примечательно достаточно много из них были опубликованы в треде на хабре. Особо урожайным выдался 20 год, когда из квартиры то выйти можно было не всегда, тогда наверное коллекционирование разных статей переросло в небольшое хобби.

Но, как справедливо написали в комментариях к прошлой статье, не стоит забывать классическую литературу, поэтому на первое место в этот раз я поставлю "Мертвые души" Гоголя. Произведение рассказывает историю о молодом и амбициозном человеке, который приезжает в провинциальный город с необычным предложением: он собирается купить "мертвые души" - крестьян, умерших или уходящих, но ещё "не снятых с учёта", чтобы заново зарегистрироваться их владельцем и получить на них кредиты и привилегии.

Двести лет роман по праву считается достоянием мировой литературы. Произведение умное и гениальное, ведь изложенная идея не сложна в реализации. Думаю, с некоторыми коррективами, она будет актуальной и через 10, и через 20 лет, оставаясь как бы вне времени. Перечитывая роман, наверное в третий уже раз, к сожалению, понимаю, что вижу на собственном опыте, как идеи Чичикова живут до сих пор.

Объём специфичных знаний, которые требуются рядовому программисту игр, даже если он только начал свою карьеру, вызывает у меня «лёгкую» тоску. Это одна из причин, почему большая часть людей, которые «горят делать игры», отсеивается на этапе технических собеседований (обычно их больше одного). Это нормально и грустно. Добавьте сюда, что нефундаментальные знания, вроде инструментов, библиотек и движков, приходится обновлять где‑то раз в 5–7 лет. Не вижу тут, что игрострой сильно отличается от других областей разработки. Если бы лет 15 назад «добрый я» скинул на почту список книг, которые придется прочитать и осмыслить, армия собранных граблей не была бы столь большой и разнообразной, и без ручек половинной длины. Осторожно, в конце статьи будет супердлинная картинка (взята с github отсюда, с разрешения автора).

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

На этой лодке, корабле или дредноуте, под названием "игровая студия", "вместе гребут", живут и трудятся очень много людей. И от каждого из них игра получает частичку души, много времени и уникальное видение. У большинства разрабатываемых игр есть заказчик, а недоступное многим крупным и средним студиям право "делать что хочу, как хочу и когда хочу" есть лишь у небольшой прослойки инди (independent/независимых) студий, которых еще не купили крупные издатели, но и денег с предыдущей разработки хватает на текущую жизнь.

Конечно, чтобы сделать игру нужны начальные инвестиции. Это к вопросу, почему игры стоят 10-20-40-80 убитых енотов. Когда вам скажут, что игра разошлась миллионным тиражом и разработчики должны купаться в шампанском - вспомните этот пример: авторами достаточно известной action-RPG Nier: Automata были PlatinumGames, издателем и заказчиком были Square Enix, инвесторами и соинвесторами были Tencent Invests, JPMorgan Chase & Co и Sega Corporation. У игры были два главных продюсера, в общем в разработке игры участвовали более 300 человек из трех игровых студий в Японии и США. Затраты на разработку игры составили более 20М$, а продажи превысили 7.5млн копий. Почему студия заработала на игре "всего" 35М$ при средней цене 35 за копию 7.5M * 35 == 35M? Это я расскажу в конце статьи. Такая вот высшая игровая математика. Но сначала давайте посмотрим как устроена разработка игры.

Никогда не знал, как начинать рассказы о командировках, чтобы и оставить интересные моменты и не выдать секретные секреты, но даже если было это очень давно и не правда, то некоторые моменты придется опустить, имена поменять, а названия городов забыть. Возвращаясь из командировки в город К-ск, еще в поезде команда получила от директора смс, что через неделю едем в другую, что называется только заскочить домой повидаться с семьей. Сплоченной разными командировками группе ездовых котов не доводилось еще бывать восточнее Байкала, но этот раз в поисках восхода, запаха моря и подписей высокого начальства после приемо-сдаточных испытаний предлагалось отправиться на самый край земли - манящий своей загадочностью Сахалин.

Что мне больше всего нравится в gamedev, так это что большая часть игр и каждый первый кастомный игровой движок бросают вызов устоявшимися стереотипам разработки. Иначе зачем начинать разработку такого сложного и комплексного софта, когда десятки похожих софтин есть вокруг. Конечно такие монстры как Unreal и Unity и десяток монстриков калибром поменьше существенно упростили разработку во многих отношениях, привлекли тысячи разработчиков к созданию множества великолепных игр с использованием готовых технологий, освободив их от ямы отчаяния пустого уровня. Но также не оставляет мысль, что еще больше игр они похоронили. Невзирая на весь функционал и мощь U/U люди часто застревают в рамках, о которых они даже не подозревали. На протяжении многих лет наблюдаю как оригинальный контент в большинстве случаев убивается ассетсторами, если там есть что-то близкое или похожее к нужному объекту, функционалу и виду. Не поймите мои слова неправильно, я обеими руками за магазины ассетов и любых других ресурсов, скриптов и технологий, но беря что-то в магазине за доллар, вы уже с большой вероятностью не сделаете свое. Или сделаете конечно, но позже, но до этого "позже" еще надо дожить, а пока что у вас будет всё как у всех: одинаковые паттерны, одинаковые текстуры, одинаковое поведение, одинаковые модели... и одинаковые игры? Что тогда остается своего - уникальные механики и впечатления. В другом случае не было бы игры, вот только проблема, что сначала люди видят картинку. Хорошо если игрок через полчаса-час доберется до уникальных механик, одинаковая картинка вызывает в памяти игры в которые вы уже играли, а уникальная механика так никогда может быть и не увидена в игре.

Пару недель назад, на меня вышла HR "светлячков" и пригласила поговорить о позиции AI программера в их новую старую игру. Я был несколько удивлен, потому что знаком с парой ребят из студии и знаю, что найм у них сейчас остановлен. Но всегда интересно пообщаться с умными людьми, поэтому отказываться не стал. Первый созвон с HR вышел стандартный, где над чем работал, какие игры шипнул. Не очень понимаю зачем все это было спрашивать, если все это есть на линкедине подробно и с датами. Ну да ладно - видно такая их эйчарская доля по тридцать три раза переспрашивать. Или HR дальше второй страницы просто поленилась почитать.

Забукали время технического интервью. В полдень четверга на встречу приходит сотрудник студии и начинает просматривать резюмешку дальше второй страницы, где натыкается на скрин опенсорсного проекта StoneKingdoms, в который я некоторое время активно комитил. Проект, если что, получил благословение самого Simon Bradbury, так что проблем с правами на использование ресурсов из Stronghold нет. Посыпались вопросы, а что за проект? а как делаете? и что все на lua? а как же плюсы? Где-то на середине разговора к нам подключился другой разработчик "светлячков", с которым мое знакомство началось еще в 2010, когда он помогал восстанавливать исходники Caesar III и просто давал консультации как реализована игровая симуляция. Мы и сейчас иногда общаемся на форуме по ремейкам старых игр.

В шейдере мы можем написать vec3 v0 = v1.xxy * 2 и любую другую комбинацию x, y, z и w в зависимости от длины вектора. Я рассматриваю только размеры вектора до 4, как самые распространенные для использования. Полученный вектор может не иметь той же самой размерности, как в меньшую так и в большую сторону и его компоненты могут быть скопированы в произвольном порядке. Это операция называется "swizzle" и это чертовски удобно для различных операций с малоразмерными векторами, особенно если они представляют игровые сущности в виде позиций, размера или цветов. Вектора используются повсюду в игровых проектах (да и не только в игровых), и не только в шейдерах. В какой-то момент swizzle было решено затащить и в наш игровой движок в базовые классы vec2, vec3 и vec4. Возникли вопросы: как добиться такого же синтаксического и семантического поведения в C++ коде, при этом минимизируя потери производительности.

Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт. Можно уволить программиста и на его место придет другой и через условные месяц-два-полгода начнет закрывать таски не хуже. Если увольняется дизайнер, его монстр, пушка или контент повисает без хозяина и без "видения". Если её не перехватил сосед (а у соседа свой монстр), то в большинстве случаев его работа просто уходит в стол и монстра пишут заново на тех же ассетах и принципах, но заново.

Если увольняется арт-директор, который несет "видение" проекта, то проекту становится очень плохо, в большинстве случаев визуально он изменится до неузнаваемости, хотя ассеты могут быть те же самые. Программисты делают всё, кроме самой игры: рендер, звук, физику, сеть, AI, инверсную кинематику, поиск пути и т.д. Можем подискутировать в комментариях.

Почему с некоторыми монстрами интересно играть? Графика тут конечно играет определенную роль вначале, красивая картинка радует глаз, а музыка берет за душу. Но если враг тупит, если поведение читается на раз-два, то внимание игрока начинает подмечать ошибки в целом, быстро разрушая общее впечатление, даже графоний не поможет, так устроено внимание человека. Среднее время удержания внимания на элементе игровой механике или поведении составляет не больше пяти минут. Дизайнеры игр об этом знают и стараются в пределах этого времени переключать внимание игрока на что-то другое. Вернемся к AI монстров, это же правило действует и здесь, если в течение пяти минут, NPC не показывает новых приемов в бою или поведении, то игроки считают его "тупым", много тупых и однотипных в поведении монстров вызывают только раздражение. Можно много говорить о быстром развитие ИИ общего назначения, увидеть его применение в играх, выходящим за рамки общения и диалогов вряд-ли получится в этом десятилетии. Поэтому нам остается применять проверенные временем поведенческие деревья (BT, Behavior Tree, GOAP), но тем не менее очень мощные и нейронную сеть общего назначения на печеньках и кофе.

Среди множества задач, решаемых программистом, одной из самых частых является подумать и добавить новый функционал в приложение. И там уже может быть много похожего функционала, он может быть хорошо написан, хорошо документирован. Искушение заключается в том, поддаться своей лени и задействовав специфические мышцы левой руки поместить чужой код в "новый" функционал. Другими словами, очень хорошо спроектированный код (равно как и очень плохой) готовит к разработке методом копипасты последующие поколения разработчиков. То есть мы находим в нашем коде что-то похожее на то, что мы хотим добавить, копируем это и вставляем, меняя небольшие детали, специфичные для нашей новой функции. Или находим что-то похожее на stackoverflow. Я отнюдь не против поиска и даже отдельных моментов разработки через анализ чужих решений, в любом случае код придется понять, принести, адаптировать. Да чего греха таить, я тоже не пишу весь код из головы.

Игры бывают разные, большие и маленькие, триA и супер инди, в компаниях с сотнями разработчиков и что создаются самородками-одиночками. Редко их делают с нуля и пишут код только игры, чаще пишут игровые тулы, редактор и параллельно пишут саму игру. За всей этой многомиллиардной индустрией стоит код, много кода, очень много кода. Игровые движки и фреймворки – мощные инструменты, которые помогают разработчику творить его идеи и создавать увлекательные игровые миры. Это каркас, на котором строятся все игровые вселенные, они включают в себя сотни инструментов, библиотек и ресурсов, позволяя разработчикам превратить строчки кода в театр для одного зрителя.

Существует более сотни игровых движков, каждый из них содержит как минимум одну фичу которой нет ни в каком другом. Всех возможностей вместе нет ни в одном, и это прекрасно - иначе бы такой движок монополизировал рынок. Хм, Unreal5 ты ли это? Иногда полезно пробежать по release notes движка, чтобы оставаться в курсе последних новостей. Возможно вы разрабатываете свое решение и эта статья натолкнет вас на новые идеи. Готовы узнать что ваша любимая игры была сделана не на Unity, а на православном SDL?