Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт. Можно уволить программиста и на его место придет другой и через условные месяц-два-полгода начнет закрывать таски не хуже. Если увольняется дизайнер, его монстр, пушка или контент повисает без хозяина и без "видения". Если её не перехватил сосед (а у соседа свой монстр), то в большинстве случаев его работа просто уходит в стол и монстра пишут заново на тех же ассетах и принципах, но заново.
Если увольняется арт-директор, который несет "видение" проекта, то проекту становится очень плохо, в большинстве случаев визуально он изменится до неузнаваемости, хотя ассеты могут быть те же самые. Программисты делают всё, кроме самой игры: рендер, звук, физику, сеть, AI, инверсную кинематику, поиск пути и т.д. Можем подискутировать в комментариях.
Что вообще тут делают програмеры?
Когда я получил свою работу мечты в Ea Spb тоже думал, что "вот щас" буду делать игры - нести светлое, доброе и вечное через уникальные механики. Но увяз в куче кода на с/с++, поиске ботлнеков на лоуенд девайсах и получил в саппорт кривой индусский (его действительно в Индии разрабатывали) фреймворк для показа рекламы на 5 дюймах экрана.
Так для примера, код из парсера значений, которые вычитывались из json'a рекламного блока. Пару раз даже менял код, но с обновлениями все возвращалось как было. А лид получил гневное письмо, с просьбой не менять ничего, потому что это будет сложно поддерживать.
if(value1 == "-0")
value1 = "+0";
if(value2 == "-0")
value2 = "+0";
if(value1 == "-0.0")
value1 = "+0.0";
if(value2 == "-0.0")
value2 = "+0.0";
if(value1 == "-0.00")
value1 = "+0.00";
if(value2 == "-0.00")
value2 = "+0.00"; оттуда же в другой функции, и так было везде - что не открой.
switch (*p) {
case '0': id += 0; break;
case '1': id += 1; break;
case '2': id += 2; break;
case '3': id += 3; break;
case '4': id += 4; break;
case '5': id += 5; break;
case '6': id += 6; break;
case '7': id += 7; break;
case '8': id += 8; break;
case '9': id += 9; break;
case 'a': case 'A': id += 10; break;
case 'b': case 'B': id += 11; break;
case 'c': case 'C': id += 12; break;
case 'd': case 'D': id += 13; break;
case 'e': case 'E': id += 14; break;
case 'f': case 'F': id += 15; break;
case 'g': case 'G': id += 16; break;
И на чём?
С++ уже десятки лет без альтернатив является основным языком игростроя. Как он занял свою нишу где-то в начале нулевых, так и остается главным инструментом для создания игр. Выкладывал недавно статью, где описал с какими движками сталкивался для разработки (Не Unity единым…), все что более-менее используется сообществом и развивается написано на плюсах. Весь "кровавый ентрепрайз пота, слёз и пикселей" и подавно.
Еще много кода написано на С, он используется в основном в зависимостях и внешних либах, постепенно и там уступает свои позиции плюсам, но очень медленно. Никто не горит желанием переписывать тонны кода работающих библиотек только ради рефакторинга. Но на плюсах пишут в основном движки и окружающий инструментарий, золотой век использования плюсов для реализации логики в играх закончился лет пятнадцать назад с выходом мощных комбайнов вроде Unity/Unreal, и это хорошо - плюсы точно не для написания логики в играх, хотя Unreal и пытается доказать обратное. Но у анриала это не совсем честные плюсы, это диалект языка щедро пересыпанный синтаксическим сахаром и намертво прибитый гвоздями к функционалу движка. И без прекомпиляции он не заведется вообще.
UCLASS()
class UTeaOptions : public UObject
{
GENERATED_BODY()
public:
UPROPERTY()
int32 MaximumNumberOfCupsPerDay = 10;
UPROPERTY()
float CupWidth = 11.5f;
UPROPERTY()
FString TeaType = TEXT("Earl Grey");
UPROPERTY()
EDrinkingStyle DrinkingStyle = EDrinkingStyle::PinkyExtended;
};Еще камней покидаю в Unreal
TMap<FString, int32> MyMap;
for (auto It = MyMap.CreateIterator(); It; ++It)
{
UE_LOG(LogCategory, Log, TEXT("Key: %s, Value: %d"), It.Key(), *It.Value());
}
for (TFieldIterator<UProperty> PropertyIt(InStruct, EFieldIteratorFlags::IncludeSuper); PropertyIt; ++PropertyIt)
{
UProperty* Property = *PropertyIt;
UE_LOG(LogCategory, Log, TEXT("Property name: %s"), *Property->GetName());
}// Find first Thing whose name contains the word "Hello"
Thing* HelloThing = ArrayOfThings.FindByPredicate([](const Thing& Th){
return Th.GetName().Contains(TEXT("Hello"));
});
// Sort array in reverse order of name
Algo::Sort(ArrayOfThings, [](const Thing& Lhs, const Thing& Rhs){
return Lhs.GetName() > Rhs.GetName();
});Но если вы хорошо знаете С, то вас с удовольствием возьмут для перекапывания legacy кода. А еще есть Git, JVM, MySQL, Nginx, PostgreSQL, tarantool, tensorflow и море другого c-кода, которое используется и встроено зачастую в сами игровые движки, функционал этих компонентов тоже надо менять и подстраивать под запросы команды разработки.
Справедливости ради стоит упомянуть, что С все еще используется в движке Unity (наравне с С++), как для написания модулей движка, так и для основной логики. Весь рендер юньки был написан на чистом C. Мои данные могли устареть, с движком я работал в 2014-16, но обычно коркомпоненты движка переписывают в крайних случаях. Как вариант можно пойти работать туда.
В больших коммерчески успешных движках ещё больше бюрократии и секретности, чем в анонсах новых игр, вы никогда не узнаете больше чем за пару лет, какую новую фичу пилят для Rage или Frostbite. Если она появилась для широкой публики, значит прошла свои десять кругов ада и сто двадцать согласований на ревью. Причина простая: если ты заявишь об этом, то у конкурентов оно тоже появится, даже если её и не было в планах, а значит и переманить разработчиков будет сложнее и директорам нелегко будет обосновать свою зп.
Еще программистам в игрострое приходится обсчитывать, и зачастую придумывать новые алгоритмы, вычислять сложные 5-этажные формулы и писать много кода на бумаге. Да, вы не ослышались, почти все мои знакомые программеры таскают с собой толстую бумажную тетрадь, с кучей формул, вычислений и кусочков кода. Потому что кода под задачи, которые ставят перед тобой, зачастую просто нет в сети, она есть в голове у дата-аналитика или дизайнера.
Есть и другая сторона, часто игровому программисту даже ничего и не надо писать вообще. Больше важны навыки тестирования и анализа, улучшения существующего кода из движка, интеграция тулов, обработки данных телеметрии. Какие-то решения и подходы можно взять из других движков или ядра ОС (например linux), на удивление там есть много пересекающихся тем, особенно по управлению ресурсами и памятью. Так, например, если вы используете системный менеджер памяти, то теряете до трети (30%) перформанса, у Unity менеджер памяти вообще самописный по принципу memory arena, у Unreal форк от dlmalloc, Dagor тоже его использует.
Собеседования
Собеседования вообще больная тема из-за отсутствия людей, штаты пылесосят рынок уже третий год, в этом плане европейский игрострой оказался в очень уязвимом положении, потому что не может предложить 1.5-2x зп и вынужден терять разработчиков, и что еще хуже дизайнеров. Гугл конечно может уволить 10к ит-людей, но в игрострое как был дефицит около 70к людей на всех позициях от программеров до арта, так и остался. Проблему с дизами я описал в начале, остается молиться на старичков, лидов и кор команду, которых не так легко перехантить. Вопрос денег здесь уходит на второй план, потому что эти люди уже делают свою игру мечты.
Затравочный вопрос, который обычно задают всем претендентам звучит так:
— Есть ли доведенные до релиза проекты?
Если ответили нет, считайте что дальше количество кругов собеседования увеличится вдвое. Людей «с улицы» студии берут очень неохотно, есть большая вероятность, что человек сольется через полгода, не зная специфики области. На этом многие обжигались, что и привело к таким странностям.
Второй вопрос обычно:
— Готов работать с legacy кодом?
Это, напомню, на позицию, где основные задачи будут по написанию нового функционала.
Третий уже как‑то ближе к теме. Звучит обычно так:
— Готов ли разбираться со смежными задачами вне своей области экспертизы?
— Согласен заниматься анализом решений/reverse engineering?
Если ответов больше НЕТ чем ДА, то с лидом вы, скорее всего, не подружитесь.
Переработки
Про переработки вопрос всем уже набил оскомину, но скажу так: кранчей стараются избегать, чтобы не потерять команду, но программер, который выдает результат, в среднем тратит 9-10 часов рабочих в день. Эффективной работы над тасками там часов пять, максимум шесть, остальное это ревью, ресерч и общение с коллегами по задачам.
Как устроиться
Что забавно, на европейском рынке gamedev компаний есть одна любопытная особенность, чем более крупный и известный проект, тем проще туда попасть на практически любую открытую позицию. А на какой-нить стартап или инди разработку из пяти студентов будут гонять по всем темам игростроения, Computer Science, захватят немного звука и AI, а потом выясняется, что компания делает очередной три-в-ряд на Unity. В Arkane на тогда еще начинавшийся Deathloop вместо техревью получил разговор по душам с техлидом (engine team, лид наш соотечественник из Казахстана), а когда пытался договориться о сотрудничестве с Triskell Interactive не спросили разве что, какого цвета глаза у лошади Вронского. И все равно вышло, что моего опыта разработки не хватает для клона одного старого ситибилдера про египет на Unity, может и к лучшему, игру "слили" мобильными механиками и идеями.
Юниттесты
Так сложилось, что движки писали умные люди, легенды игростроя, которые компилировали код в уме, там же в уме отлаживали, а потом сразу комитили в репо. Тесты писали по остаточному принципу в ночь после релиза, чтобы оно не скатывалось в регрессию. Попытки внедрить интеграционное тестирование кода до его попадания в репо, частенько наталкивается даже сейчас на непонимание и посыланию к QA, которые должны это самое тестирование всеобьемно проводить, но они тоже люди, их тоже мало, у них тоже своих задач выше головы.
Ситуация лучше разве что у Larian/Dice и крупных студий. Они пишут движки, которые изначально исповедуют другой принцип разработки на основе (TDD) или чего-то похожего. Чинить все баги за месяц до майлстоуна и сейчас в порядке вещей, увы. Большие компании еще хоть как-то следят за этим, а средние и инди просто делают игры. Как умеют так и делают. Отчасти это вина многократно ускорившегося пайплайна разработки и мощных движков комбайнов, которые ограждают от возможности выстрелить в ногу, в худшем случае будет сообщение в лог, но игра продолжит работать, хоть и не всегда правильно.
Вот тут lead gameplay Ларианов рассказывает, как они такого добились. Это традиция студии, о традициях ниже.
Но, не все так плохо! Ситуация меняется и к нам пролезают общие механизмы безопасной разработки ПО. В gamedev программисту очень трудно убедить студию начать использовать новые инструменты. Что-то по мелочи - без проблем, новый моник, комп, клаву, смузи утром на кухне. Продавить инструменты статического анализа, если он не встроен в пайплайн, практически нереально, пишите таску на QA.
Отношения с инди-разработчиками
С одиночками еще хуже. Если взять инди разработчика и поместить его в общепринятую модель производства игры, с нашими ежедневными планерками по 5-7 минут, сборке на билдферме, qa-командами, ревью комитов, модульными тестами и прочее, то выяснится, что он (программист, дизайнер, художник) вообще не может решить ни одной задачи. Это не просто слова, в студиях пробовали неоднократно брать ребят с инди-разработки, их приходится переучивать работать в команде и по плану, не всегда это проходит успешно и приходится расставаться, потому что они не смогли в планирование и компромисы, пишут игру как пишется, как делали это во времена дикого игростроя 90-х.
Можете почитать, как делали Казаков.
Традиции
Зато в каждой студии сложился целый пласт традиций. Тут речь идет не о тех традициях, чтобы облить новичка Шато десятилетней выдержки (одна французская компания) или сходить всем отделом в баню и выпить пива (Remedy, эти своей гордятся). Традиции спускаются вплоть до кодстайла, которым пользовались отцы-основатели (отступ с табом в пустой строке после имени функции и кеширование значений в объектах, Unity) или CamelCase, использование префиксов для идентификации типа объекта: "A" для акторов, "U" для объектов, наследующих UObject (Unreal). Хуже, если в традициях узаконены не самые лучшие практики, вроде устных задач, которые могут быть не заведены тасками в jira, или передача таски другому исполнителю без ведома автора (питерская студия, которая делала xcom на мобилки).
Фреймворки и кодовая база.
Тут вообще полная анархия, кроме крупных открытых игровых движков и опенсорс проектов нет доверенной покрытой тестами кодовой базы. Есть EASTL, но не все готовы его использовать в силу нелюбви к EA, платформенные std не любят из-за привязки к вендорам и тормозам. Вроде бы и алгоритмы одинаковые, да вот реализация разная на боксе и плойке. Про злую memcpy на плойке я уже как-то писал, это системный вызов, который проверяет пересечение используемых адресов с защищенными областями памяти консоли. Не готовы что memcpy тормозит? Пишите свою.
Легенды игростроя вроде Кармака, Суини, Кейна так вообще увлекались повальным велосипедостроением. Нужен vector? Давайте напишем свой с преферансом и дамами, и пофиг, что в третий раз. Unity/Frostbite/Unreal/CryEngine/Dagor - везде написаны свои стандартные библиотеки алгоритмов. То есть нет тех самых кирпичей, из которых можно было бы гарантированно собирать работающее переносимое решение, добавьте сюда различия в реализациях под платформы. Нет никакой общей культуры разработки движков (разве что кроме god object, этот шаблон есть везде), нет преемственности, нет общей терминологии. Везде свой фольклор и богатый внутренний мир.
На моей памяти в Unreal уже четвёртая смена идеологии развития, Tim Sweeney - программер старой школы, если вы посмотрите на код образца 2007 года, когда были первые утечки, то движок представлял собой монолит с кучей велосипедов. Потом настал черёд Jim Brown и движок двинулся в сторону стандартных компонентов и унификации кода, но часть великов заботливо припаркована, а про другую вообще забыли. Потом пришёл Nick Penwarden, движок вывели в опенсорс, стали разворачивать анриал в сторону мобилок, что потребовало переделки внутренней архитектуры, наворотили кучу новых фичей и сломали не меньше старых. Сейчас у руля Mike Fricker и движок двигается в сторону плагинов и AI контейнеризации всего до чего дотянутся, посмотрим к чему это приведёт. Все еще верите, что Unreal хороший выбор? Посмотрите на архитектуру clang'a, а потом загляните под капот Unreal. Такое чувство иногда появляется, что его пишут студенты
Привет, сосед
До ковида в основном в офисе, сейчас с разрешения на удалёнке, обычно программист работает в небольших группах по интересам (4-5 человек). Интересы у всех разные, у кого AI, у кого движок и тулы, у кого редактор. Часто задачи перемежаются с соседними отделами и надо разбираться с багом рендера, который внезапно вылез из-за ошибок в загрузке ресурсов, но кадров так на пять десять позже, и колстек к рендеру вообще отношения не имеет. Случайных людей здесь мало, всё начальство программистов в четырёх случаях из пяти - это в прошлом коллеги-программеры из этой же области, о программировании они знают намного больше, но либо выгорели и ушли на админские должности, либо остаются на позициях играющего тренера и решают сложные таски, которые не осиливают другие.
Также они часто уходят в ресерч и реализацию новых технологий, выхлоп от которых будет видно хорошо если через год. Так что готовьтесь часто слышать: "Твой код - @#$%^&" и улетать на респ, т.е. на переделку комита. В силу большого опыта они предпочитают проверенные простые инструменты и скрипты, вместо солюшенов и IDE.
C git'ом, кстати, тоже есть проблема, он хорошо подходит для сорцов, а вот что делать с гигабайтными текстурами или файлами модели по 100мб, или луашником/json'ом уровня размером под 20-30 мб текста? Тут либо держишь 2 cvs - одну для сорцов, вторую для контента, либо пишешь своё решение.
Будьте готовы, что вас не раз ткнут носом в незнание алгоритмов, кодовой базы или традиций студий, слабое знание векторной математики или специфику области. Если ты попал к хорошему лиду, который знает свою область движка, будь готов плакать ночами над комитами, которые вернули в десятый раз. Если выживешь и останешься в отделе, будешь делать движок игры наравне с отцами-основателями. Среднее время работы программиста в студии год-полтора. На группу 40-50 человек, коркоманда составляет 10-15 человек, это люди, которые работают больше 4 лет и являются носителями знаний и технологий, ещё 2-3 техлида, которые определяют, куда движок развивается.
Дизайнеры
С дизайнерами разговор отдельный, дизайнеров надо любить, потому что, как я уже сказал выше, игру делает дизайнер. Разговаривать, учить, помогать, не давать делать @#$%&. Дизайнеры должны быть творческими людьми, иначе игра не получится, даже три-в-ряд. Для дизайнера умение писать стихи и рисовать гораздо важнее, чем умение писать код. Писать код можно научиться, умение писать стихи и делать игры даровано природой.
Дизайнеры придут к вам со своими идеями, вопросами и багами, если дизайнер пишет багу, это уже не его проблема, а программиста. Иногда последней защитой от дизайнера будет только лид, который сумеет объяснить, почему мы так сделать не можем, ну или волевым решением отправить таску в бэклог.
Хорошим дизайнерам вообще прощают очень много, их "код" (BT, скрипты, AI) не изучают, не анализируют, не тестируют. Вряд ли вы услышите от них такие слова как "архитектура", "тесты", "кодревью". Интерес представляет только готовое поведение в игре. Дело в том, что обычно дизайнер полностью отвечает за свою область на карте, логику, пропсы и если заставляют подгонять качество под стандарты, то оно в итоге только ухудшается. Поэтому дизайнеров в студиях ценят выше, чем программистов. Программистов можно заменить дешёво, дизайнера заменить дорого.
Как в итоге пишут код/бт/аи дизайнеры никого, в общем-то, не волнует. Главное - результат. Эта логика никого кроме одного-двух дизайнеров, которые сапортят фичу, не интересует. В одной питерской студии (та, которая xcom на мобилы делала) дизайнер называл функции в скриптах именами героев из "Атаки Титанов" и это никого вообще не волновало, так как кроме него с этим кодом никто не работал. При этом он был на хорошем счету в проекте, и на этот бзик закрывали глаза, равно как и на поздний приход на работу и желание разогреть рыбу в микроволновке в обед.
Школы разработки и их влияние на студии
Из-за соло-разработки движков и принципиальной закрытости и секретности разработки игр, сложились множество различных движкостроительных школ. Можно условно их назвать Unreal/Unity и Housemade/Solo. Причём Unreal/Unity больше распространены в Европе и Азии, а housemade в Штатах. БОльшая концентрация gamedev студий в штатах делала разработку собственного движка одним из знаков качества и статусности студии. Unreal школа больше ориентирована на мелкокомандную работу и модульные проекты, которые легко прототипировать, насобирать асетов и сделать на коленке mvp, а дальше уже разбираться, как придать проекту уникальности. Ответственность разделена между всеми участниками, минимум использования труда программиста в доработке движка, и больше упор в игровые механики.
Housemade школа — это крупные команды от 50 человек, известные проекты, наличие коркоманды и длительные сроки разработки, минимум внешних зависимостей. Ответственность лежит обычно на отцах-основателях, и провал движка-игры приводит к роспуску студии.
Довелось поработать в компаниях, где применяют оба этих подхода и могу сказать, что возникают серьёзные конфликты между представителями разных школ внутри одной группы, и тут надо искать компромиссы, причём последователи Unreal последнее время побеждают. Это как споры между приверженцами Windows и Linux.
Заметил ещё одну особенность: если студия переезжает на другой движок вместо своего, значит, развалилась коркоманда (https://gamerant.com/cd-projekt-red-explains-using-unreal-engine-5-the-witcher-4/) и в игре не будет оригинальных решений. Это не хорошо и не плохо, просто пришло другое поколение разработчиков, которые не умеют работать со сложными вещами, но умеют делать хорошие игры. И наоборот, если студия начала писать или форкнула один из движков, значит, там выросли спецы, которые умеют писать вещи сравнимые с Unity\Unreal, а зачастую и лучше.
Первая часть Cities Skylines написана на Unity, программисты взяли движок и переписали его под игру. Вторая часть игры написана на ядре Unity 2206 и судя по тому, что я увидел - его даже не пробовали дорабатывать под игру. Проблемы вы видели сами (Почему Cities: Skylines 2 так тормозит), хотя надо было всего лишь сохранить старую команду.
Мало общения на работе
Как правило, на одну фичу сажают одного человека, командная работа в рамках одной задачи затруднена их большим числом. Поэтому программистами в игрострое работают обычно интроверты, мизантропы и социопаты, да простят меня мои коллеги. Общаться с ними не всегда комфортно, порой сложно и приходится идти на компромиссы, а также помнить цвет и особенности тараканов. У большинства программистов напрочь отсутствуют Soft Skills, потому что больше ценятся технические качества и умение решать поставленную задачу, что еще больше культивируется руководством студий приемом в команду суперстаров. Написать в чат в пять утра и обсудить решение бага - в порядке вещей. У меня тоже есть свои тараканы, обычно ревью уходит с апрувом на 5-6 доработку.
Обыкновенная ситуация, когда программист в принципе ни с кем не обсуждает кроме лида свою фичу по несколько недель, а потом выкатывает в репо сотню-другую комитов, нанося добро всем подряд и блокируя работу студии, хорошо если на пару дней, пока все баги не выловят в аврале. На расстоянии вытянутой руки сидит другой такой же разработчик из отдела рендера, свои комиты он выкатит через неделю. Рендер вообще отдельная опасТность, их не устраивают общие алгоритмы. Каждый местный Кармак старается написать свою версию стека, swap, расчет контрольной суммы, временные буферы и строки. Аllocator на стеке так это вообще милое дело, за это уже даже не ругают, и прочее и прочее, хорошо если юнит-тестов добавят. А еще два Кармака могут подраться на почве неприятия технологий, а ночью проигравший ультимативно удаляет код из репо и трет историю комитов.
Промышленная разработка housemade движков в индустрии похожа на времена дикого запада. Каждый шериф строит своих индейцев по-разному и радуется, если они начинают петь в унисон. Каждый раз из проекта в проект шериф начинает героически решать одни и те же задачи. У программистов в gamedev нет менеджера пакетов, нет общих решений, как это повсеместно в ентерпрайзе, или в разработке на Python. Поэтому каждый раз в каждом новом проекте мы вынуждены проходить от первых шагов младенца до Майкла Джексона. Или тащить свое наследие из предыдущих проектов. Вам нужно вытащить данные из influxdb? Извольте написать это сами и желательно на плюсах.
Развитие поколениями
В gamedev, как в деревне, ничего не меняется десятилетиями. Не мы в этом виноваты, что-то действительно новое выходит примерно через поколение консолей, а это 7-10 лет. Что уж говорить, если на плойке до сих пор не полностью завезли 14 стандарт в соневском компиляторе, про свич и мобилки отдельная тема. Постоянный консерватизм в наборе технологий, в то же время взрывной рост стека в моменты смены поколений приводит вот к такому странному состоянию. Что в 2014 в Unity я боролся с ботлнеками на iPhone 4S на загрузке уровня, что сейчас нам не хватает шины ps5 на загрузке сейва. В то же время эта работа требует непрерывно доучиваться чему-либо, чтобы сделать наш массив еще более оптимальным и нереально быстрым.
Девочкам тут не место
Они есть среди дизайнеров, художников, но их практически нет среди разработчиков движков. Могут случайно заскочить на полгода, или появляются по ошибке и недоразумению, но надолго не задерживаются. Знаю профессионалов девушек-программисток в банках, CAD и embedded разработке, не знаю их в gamedev.
Знания и экспертиза
Вы вряд ли услышите такие слова как FrameWork, boost, std::map, std::thread. Более того, если вы попробуете протащить это через ревью, то коллеги строго на вас посмотрят и скажут "Вай-вай, убери это @$%^&, дорогой друг". Фреймворки не возбраняются, но если этого еще нет в движке, то его можно написать и незачем тянуть новую зависимость. Хотя список зависимостей от SDK у движков обычно под сотню разных либ, но это все проверенные временем библиотеки и технологии, которые достигли зрелости, вроде zlib, squish, lua. Главный принцип в разработке - это должно быть быстро и своё. Никаких бантиков и стразиков в движке не будет, ибо это снижает перформанс. У нас тут только один шаблон: это должно работать быстро и только одна абстрактная структура данных - это массив. Все остальное сделано с использованием этих двух компонентов.
Слишком мрачно?
Что-то я всё мрачно описал, на самом деле есть много положительных моментов, которые компенсируют сложности.
В игры играют люди
Игру видят и играют сотни и тысячи людей, её обсудят десятки журналистов. Здесь создается софт, который запомнится на десятилетия не просто как иконка на экране, а как картины, книги и музыка. Программисты игр создали целую индустрию, которая по деньгам сравнялась с кино. Кстати, косяки и ошибки тоже видно всем и сразу, и вам не преминут об этом сказать и коллеги и игроки.
Я тут хозяин
Главное достоинство - это возможность влиять на разработку практически с самых нижних позиций. Вряд ли где-то еще вам дадут поресерчить и переписать реализацию спинлока в готовом движке на котором уже выпущена игра(https://habr.com/ru/articles/689310/), все завязано на ваши знания и умение питчить свои решения. На консолях ближе вашего игрового кода только ОС, есть полный контроль за девкитом (пк пока оставим за скобками), и даже ОС пляшет под вашу дудку. Всё можно измерить, любые параметры снять через SDK и посмотреть, а девкоманда консолей всегда готова помочь с разработкой под свое железо.
Тебя слушают
Работа программистом в gamedev заставляет тебя показывать и доказывать свои решения. Решение, которое тащишь в движок придется защищать перед людьми намного умнее и опытнее. Как я уже писал выше, лиды - это вчерашние программисты, с хорошим бекграундом, которые хорошо понимают код и знают движок. В 8 случаях из 10 никто не будет говорить тебе под руку, что делать и стоять над душой. Поправят на ревью.
Маленький уютный мирок
С момента как я заскочил в большой gamedev в 2014 году, каждый год появляется один-два новых знакомых из разных студий, но и старые связи тоже сохраняются. Все, кто делал игры так и продолжают их делать, несколько людей переметнулись в финтех или совсем в другое, но потом вернулись. Если у вас получилось тут поработать, в других местах будет чего-то не хватать.
З.Ы.
Gamedev-мир отстает от "большого IT". У нас есть все, от систем контроля версий сорцов до сборки из скриптов, есть подобие командной работы, планёрок, авто тестов, но это все свое, домостройное. Зарплаты программистов в gamedev средние по рынку, но ниже чем в WEB(е)/FinTech или enterprise. Если сравнивать создание игр с web/fintech, это как водитель болида формулы-1 и водитель комфортабельного седана S-class. Жесткий кузов, минимум удобств, зато быстро и Шумахера знают все. Но попробуйте уместить всю вашу логику в 15мс, с обработкой четырехсот NPC на уровне, физики, музыки, рендером на экран без просадок фпс.
Все это ради совместного фото команды на релизе игры и твоего имени в титрах. Приходите в gamedev, тут делают игры.
З.З.Ы.
Много в личку спрашивают как устроиться. Пишите письма напрямую в студии, даже если там нет приглянувшейся позиции. Людей всегда не хватает, а задач всегда много, впрочем как и везде в IT. ЗП, говорить могу только за себя. Если нет опыта, шипнутых проектов и горят глаза соглашайтесь на то, что дают (спорно конечно). Отработаете полгода-год и поймете что к чему, как правильно сказал @Eltayв коментах.
Зарплаты - да средние по рынку, но найти компанию с достойной оплатой в целом реально. Хотя золотых гор вы тут не получите в найме.
Комментарии (192)
s_e_k_a_i
19.11.2023 21:44+10Статья довольно полезная и интересная. Геймдев - жестокая штука...
NickDoom
19.11.2023 21:44+7…но классная :) Когда-то и меня вела дорога приключений… были же времена, когда двушки с EGA/CGA/«Геркулесом» на вторичном рынке были на развес, а Doom уже существовал :) И я даже что-то почти написал в те древние годы :)
А сейчас стрела в колене, клапанная недостаточность в венах, башка кровь не получает, тупой как пень, еле-еле свой эмбед/физмат вывожу :( прямо хоть бери подработку электронные книги начитывать (читаю хорошо, но переигрываю люто — «реквизит грызу»).
А жаль. Интересные задачи в геймдеве, перманентная мечта — какая-то халтурка на выходные из этой области. Сделать так, чтобы не тормозила физика уровня Нойты/Мимокрафта/Факторио — прямо вот «моё-родное», в приборостроении часто нужно сделать так, чтобы виртуальная физика не отставала от реальной :-D
Тут одна статья была, которая меня прямо до потолка заставила подпрыгнуть, я в ней увидел возможность мимокрафтовскую физику на шейдеры перевести. Попробую найти. Я вообще к кубическим движкам неравнодушен :-D пытался даже на шейдерах написать софтовый рендерер, оптимизированный под взгляд а-ля Вольф3Д, то есть строго горизонтально. И за счёт этого поднять на порядок скорость по сравнению с обычным разбиением кубов на полигоны и скармливанием оных видеокарте. А вертикальный прицел реализовать просто смещением «крестика» до достижения края экрана (а потом тупо поменять оси координат и точно так же рендерить строго вниз или строго вверх, только потом пост-процессингом придётся весь кадр повернуть, как в «Дюке», когда он голову наклонял, это быстро).
NickDoom
19.11.2023 21:44+7Нашёл! Правда, редактирование уже всё :( Добавлю самоответом.
https://habr.com/ru/articles/721314/
Главное — удобный (для дизайнеров) редактор таких правил сделать. Потому что для движка это просто супер — правила спокойно конвертируются в GLSL, он при старте компилируется и дальше простые шейдеры, без всяких этих ваших питорчей, на любом видеокарто-подобном девайсе (идеально — встроенном, пока дискретный перемалывает графоний) фигачит физику со скоростью, достойной не Мимокрафта, но Нойты.
s_e_k_a_i
19.11.2023 21:44Увы нет возможности поставить голос на ваш ответ, потому отвечу комментарием.
Довольно интересно получилось, а расписали так, словно я статью прочёл)
igor_suhorukov
19.11.2023 21:44Не жестче работы на заводе. Как раз тут недавно "Приходите к нам на завод, у нас тяжело". Там еще турникеты, непрерывность производства и особая дружеская атмосфера.
Вообще популярная нынче тема зазывать в кочегарку! К чему бы это?
Etlay
19.11.2023 21:44+18Любопытная статья. Не могу согласиться с автором во всем. Сам уже больше 10 лет в геймдеве.
Зарплаты - да средние по рынку, но найти компанию с достойной оплатой в целом реально. Хотя золотых гор вы тут не получите в найме.
Да и если попробуете найти инвесторов и организовать свой проект/студию - статистика не на вашей стороне. Очень много проектов закрывается не окупив себя. Особенно последний год. Хотя редко - но может выстрелить очень громко (тот же Minecraft)
Кранчи тоже ситуативно - в некоторых компаниях их прям любят, в некоторых нет.
По поводу влияния на дизайн - у меня прям противоположный опыт, программисты всегда участвуют в процессе разработки самой игры, помогают геймдизам, вносят свои решения. Да, финальное слово обычно за продюсером. Но на моем опыте, очень часто хорошие идеи по гейм.дизайну приносили именно программисты.
Gamedev-мир отстает от "большого IT" - вот тут я бы вообще поспорил. Много гейм.девных решений было бы неплохо затащить в "большой IT". Тот же Data oriented design. А то что тащат сейчас в гейм.дев из энтерпрайса - лучше бы не тащили. За те же модные DI в Unity нужно по рукам бить.
Маленький уютный мирок - вот тут полностью согласен. Компаний не так много, а геймдев в России, по понятным причинам, умер. Так что нужно быть готовым к релокации.
Обыкновенная ситуация, когда программист в принципе ни с кем не обсуждает кроме лида свою фичу по несколько недель, а потом выкатывает в репо сотню-другую комитов, нанося добро всем подряд и блокируя работу студии, хорошо если на пару дней, пока все баги не выловят в аврале.
Вот тут - зависит от культуры в компании. На свои проектах в текущей компании вводил практики дизайн-ревью (https://youtu.be/4Y0XJXRZv6k https://youtu.be/IDj3x__YZgE)
и обсуждений задач в Slack/на созвонах. И есть культура и инструменты шаринга знаний между разными проектами...
mayorovp
19.11.2023 21:44+3За те же модные DI в Unity нужно по рукам бить.
По рукам нужно бить тех, кто заставляет мододелов использовать Harmony.
domix32
19.11.2023 21:44+4тот же Minecraft
Так он же инди изначально. Это потом уже майки их скупили и допиливают.
Data oriented design
Его-то не весь геймдев/движкостроители используют, а там где он хорошо вписывается он уже и так есть.
геймдев в России, по понятным причинам, умер
В который раз, конечно, хоронят. Он скорее затаился, нежели умер совсем. Тут и внутренняя кухня немножко подрастёт, и платформы подтянутся и игры глядишь к мирным временам появятся неплохого качества. Я бы назвал это "затаился".
Wallhead
19.11.2023 21:44Что они там допиливают? Одного моба в год выпускают, моддерское комьюнити делает куда больше для майна, чем майки
domix32
19.11.2023 21:44Ну тот же RTX сделали, какие-то там штуки для AR, пилили, и прочего по мелочи. Вопрос-то был в том, что майн был не сказать чтобы большим геймдевом, несмотря на миллиард скачиваний игры.
Weilard
19.11.2023 21:44(смеется). На моей памяти игровую индустрию хоронили так часто, что сначала это было предсказанием, затем инфо-поводом, теперь это всего лишь повод улыбнуться. Нельзя убить деятельных и интересующихся, нельзя задушить молодежь, которая в данный момент активно обучается этим дисциплинам. Геймдев, в очередной раз, поставили на колени. Но, справедливости ради, он давно уже стоит на них. Периодически приподнимаясь в человекоподобное состояние со времён "американского ипотечного кризиса", который в нашу историю вошел как кризис 2008 года. Периодически игры делают. К сожалению не так активно, как хотелось бы. Довольно бюджетно, а хотелось бы большего. Но похоронные процессии... уже кажутся смешными.
MountainGoat
19.11.2023 21:44+9Вопрос о жизни российского геймдева накрепко завязан на вопрос "Когда компания, принадлежащая гражданам Израиля но зарегистрированная на Кипре нанимает на удалёнку молодёжь из Тамбова - это российский геймдев или нет?"
dalerank Автор
19.11.2023 21:44Мисс вселенная из Тамбова не станет менее русской из-за получения титула в штатах. Имена в титрах тоже не поменяются
MountainGoat
19.11.2023 21:44+2Ну тогда он никогда и не помирал. Имён с окончаниями на -ов и -ко в титрах всегда полно было.
Правда, тогда Гугл - тоже российская компания получается...
Kanut
19.11.2023 21:44+2А если так: "Когда компания, принадлежащая гражданам Израиля но зарегистрированная на Кипре нанимает на удалёнку молодёжь из Тамбова, Исламабада и Бангалора - это российский геймдев или нет?" :)
BTRchik
19.11.2023 21:44Конечно российский. Россия там, где говорят по русски:))
Хотя конечно грустно все это.
Год назад прицеливался устроится на работу в какую-нибудь русскоговорящую команду на Кипре, но не хватало скиллов. Сейчас полез смотреть, а поезд ушел, теперь везде англ от B2 требуют. Видать набрали интернациональные команды. Теперь надо подтягивать разговорный англ.
ProcessorThreadReaper
19.11.2023 21:44+2Я как раз из тех кто ненавидит все эти лишние митинги и "дизайн ревью". Мы просто общались с тим-лидом и это прямо ну то что я люблю. Зачем блин это выносить на всеобщее обозрение.
- мимо социопат программист, ненавижу вас :)Etlay
19.11.2023 21:44Ну тут нет серебряной пули, процессы подбираются под команду а не наоборот :)
Я не сторонник процессов ради процессов. Если у вас слаженная команда и для выполнения задач хватает лишь общений программист-тимлид, то пускай так и работает :) Главное в конечном итоге готовый рабочий продукт, а не способ которым вы его сделали.
arTk_ev
19.11.2023 21:44-6Доверять писать код дизайнерам, тем более бизнесс-логику - это безумие. Cкрипты давно устарели.
Дизайнеры даже теперь диздоки не пишут - ибо бесполезно, результат все равно непредсказуем.
Обычно сначала разрабатывается технология, делается прототип, вычисляются сроки. Показываем множество вариантов, они уже по ним разрабатывают оптимальное решение. Поэтапно изменяя прототип по фидбеку по каждой детали.
Потом дается прототип с множеством параметров, чтобы провести точную настройку. У всех дизайнеров супер-способность крутить "крутилки", не понимая их функцию, получая красоту.
А от том как работает вся игра никто не знает, кроме QA.
Но это все касается исключительно разработки. На производстве и поддержке никто вам не даст время на ресерч. Там свои особенности и инструменты.
dalerank Автор
19.11.2023 21:44+5Ну что же Вы так дизайнеров обидели, они то и делают игру. Несколько дизайнеров, с кем я работал, знают сопромат и вышку лучше меня. Задача команды направить полет мысли и помочь сделать правильно.
arTk_ev
19.11.2023 21:44-12Делают галоши на заводе. Игры разрабатывает команда разработчиков, включая офис-менеджеров.
Сопромат никак не поможет программированию. От дизайнера требуется формальная логика, которую только программист сможет перевести в строгую логику, учитывая все варианты и тех. ограничения.
Технические ограничения первичны дизайна.
GrigorGri
19.11.2023 21:44Я как раз начинаю работать в одном проекте где DI используется в Unity, хотелось бы послушать критику.
Есть Modules которые зависят от других Module (настраивается с помощью атрибута). Module это субсистема, например, отвечающая за Input.
У Module есть Init метод до вызова которого все запрошенные Dependency будут переданы через специальный объект.
Работает через Reflection, ищя все Modules на сцене. Если что то не удаётся инициализировать - посылает Exception. Круговые зависимости запрещены (тоже Exception).
Прицнипальная идея: заставить делать так, чтобы модули низкого уровня зависли от модулей высокого уровня без круговых зависимостей (в, инспектор можно добавить A->B, B->A, что может запутать код). Гарантирует порядок инициации (сперва инициирует модули верхнего уровня, которые не зависят от никого) +:бонусом Unit тесты проще: легко мокировать Dependency.
Был бы благодарен если подскажите за что тут нужно по рукам бить.
Etlay
19.11.2023 21:44+4Все в целом сводится к фразе автора:
Но попробуйте уместить всю вашу логику в 15мс, с обработкой четырехсот NPC на уровне, физики, музыки, рендером на экран без просадок фпс.
Во первых рефлексия это всегда оверхеад как по памяти (аллокации) так и по лишним операциям на цпу.
Современные DI под юнити, например Zenject https://github.com/modesttree/Zenject широко используют помимо рефлексии еще LINQ. Что тоже добавляет лишних аллокаций. Тут стоит заметить что garbage collector для игр - это в большинстве случаев плохо, а не хорошо. На одном из проектов где мы широко использовали Zenject - у нас доходило до 100 mb аллокаций на старте сцены, что бы построить дерево объектов.
Но допустим вы решили написать свои DI и заморочились и оптимизировали эти вещи. Остается на мой взгляд основная концептуальная проблема: когда я как программист хочу создать некий IObject - я никогда не знаю, насколько больше поддерево объектов породит мне DI. И какие именно реализации забинденны к интерфейсам.
Особенно если инъекция происходит не в конструкторе класса а в какие-то его поля.
В итоге создание с первого взгляда безобидного объекта в памяти могло породить очень большее количество аллокаций.
Но тут я наверное не совсем корректно выразился, DI как концепция ок. Проблема в контейнерах которые скрывают зависимости. Сейчас я стараюсь использовать концепцию Poor Man's DI в проектах - когда зависимости классов явно определены в конструкторах, а дерево объектов объявлено явно и собирается руками в контекстах.
Ну и опять же даже такие вещи делаются в основном не для highload кода. Так как в highload коде бывает приходится порой избавляться даже виртуальных вызовов (прощай классическое ООП), заниматься оптимизацией данных под кэш цпу (привет ECS), SIMD и т.п....
dalerank Автор
19.11.2023 21:44+1Выделение памяти отдельный разговор, от этого тоже стараются избавляться всеми доступными способами. Особенно от кратковременных которые больше всего фрагментируют память, есть наброски на статью с бенчами, надо собраться и дописать
mayorovp
19.11.2023 21:44Во первых рефлексия это всегда оверхеад как по памяти (аллокации) так и по лишним операциям на цпу.
Так при загрузке же. Нет, понятное дело что загрузки тоже нужно оптимизировать, но они всё же не настолько критичны как метод Update.
Но допустим вы решили написать свои DI и заморочились и оптимизировали эти вещи. Остается на мой взгляд основная концептуальная проблема: когда я как программист хочу создать некий IObject - я никогда не знаю, насколько больше поддерево объектов породит мне DI. И какие именно реализации забинденны к интерфейсам.
И не должны знать.
В итоге создание с первого взгляда безобидного объекта в памяти могло породить очень большее количество аллокаций.
Во-первых, нет смысла считать аллокации для сервисов. Их просто не должно быть так же много, как и игровых объектов.
Во-вторых, вы точно читали тот комментарий на который отвечали? Там же все объекты уже на сцене, дополнительных аллокаций нет.
ImagineTables
19.11.2023 21:44+19Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт.
С первой строки видно адекватного и честного человека. А то начитаются вот такого: https://ericlippert.com/2015/04/27/wizards-and-warriors-part-one/ (всемирно знаменитый разработчик, между прочим) и думают потом, что программист действительно программирует поведение магов и воинов. Нет, блин. Он парсит джейсончик со свойствами, сделанный в редакторе настоящими креаторами.
Newbilius
19.11.2023 21:44+6Но ведь программисты реально делают игры. В том смысле, что они делают кубики, из которых потом дизайнер сделает игру :)
PrinceKorwin
19.11.2023 21:44+7Так можно сказать, что те, кто делает C++ тоже пишут игры в том смысле, что они делают кубики из которых потом делают игры :)
wellusion
19.11.2023 21:44+3Эта тропинка может далеко завести) Например, что игры делают шахтёры. Которые добывают уголь, который сжигают на теплоэлектростанции, которая вырабатывает электричество, на котором работает компьютер, за которым сидит программист, который пишет на С++, на котором делают кубики, из которых...
mayorovp
19.11.2023 21:44+9От дизайна игры зависит. Если в игре маги и воины настолько разные классы что у них даже наборы свойств разные - то программисту придётся их программировать.
ImagineTables
19.11.2023 21:44Если в игре маги и воины настолько разные классы
В статье Липперта эта разница чётко сформулирована:
A warrior can only use a sword.
A wizard can only use a staff.Последний раз я видел, чтобы подобную разницу прописывали в коде, а не в дата-файле, в досовских играх, в виде таблиц на #define'ах, и тогда это делали не от хорошей жизни.
mayorovp
19.11.2023 21:44А что именно вы будете прописывать в дата-файле, если у вас в игре у мага свои механики, завязанные на характеристики посоха, а у воина - свои, завязанные на характеристики меча?
ImagineTables
19.11.2023 21:44+4Ещё раз цитата:
A warrior can only use a sword.
A wizard can only use a staff.В дата-файле это прописывается в виде списка id в поле AllowedCharacterClass в таблице оружия или, наоборот, AllowedWeapon в таблице персонажей. (На практике, в играх типа HoMM или DMoMM, условия сложнее и привязаны к скиллам, т.е. их правильно было бы записывать не в виде id, а в виде evaluated expression predicate, но какова задача — таково и решение). Если программист прописывает эти зависимости в виде кода, в разговоре со мной ему бы лучше иметь для этого очень хорошее объяснение (например, повышение fps).
(Объяснение Эрика Липперта, что это лишь учебный пример, а в учебных целях можно обсуждать ООП на заведомо неправильно спроектированном движке — это очень плохое объяснение, как по мне).
mayorovp
19.11.2023 21:44Ещё раз: добавляем сюда уникальные механики классов - и списков AllowedCharacterClass/AllowedWeapon начинает резко не хватать.
ImagineTables
19.11.2023 21:44В самом общем виде мой посыл таков: хороший программист (необязательно игровой) всё, что только можно, выносит из кода в дата-файлы/ресурсы/конфиги, чтобы затем можно было вносить изменения в конкретные сценарии 1) без пересборки, 2) не имея квалификации разбираться в исходниках. Естественным следствием будет то, о чём пишет автор:
Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт.
В оригинальном примере Липперта совершенно очевидно, что на уровне кода не должно быть никаких магов и мечей. С гипотетическим примером с «уникальными механиками классов» надо разбираться конкретно (что это за механики, как их описать декларативно и т.п.), но ответ всё равно скорее всего будет в области DSL (типа Lua), а не в проектировании иерархии классов на том же уровне, что и движок.
PrinceKorwin
19.11.2023 21:44+2В самом общем виде мой посыл таков: хороший программист (необязательно игровой) всё, что только можно, выносит из кода в дата-файлы/ресурсы/конфиги
Зачем? Это типичный оверинжениринг.
Если это специально не оговорено, то такие финты у нас не проходят ревью и откатываются. Почему? Потому что это приводит к усложнению кодовой базы там, где это не требуется.
ImagineTables
19.11.2023 21:44+3Если каждый раз, когда дизайнер захочет проверить, не изменится ли игровой баланс к лучшему, если разрешить Некроманту Сандро владеть Посохом Тьмы, надо будет писать тикет в Джиру программисту, чтобы он внёс соответствующее изменение, а затем ждать перевыкатки, далеко с таким процессом вы не уедете.
Это не только игр касается, вообще-то. Например, я работал в компании, писавшей управляющую программу для промышленного оборудования. Для управления отдельными компонентами этого оборудования программисты быстренько накидали DSL, чтобы на площадках конечных юзеров можно было что-то оперативно подправить (тайминги, хотя бы), и это могли сделать внедренцы. А потом у них случился переворот, типа как сейчас в OpenAI, все поувольнялись, и продукт попал в руки карьеристов и жителей солнечной Индии, которые тут же начали хардкодить поддержку всего и вся в C++. А потом туда устроился я (как всегда, к шапочному разбору). Ну вот, глядя в код, я прямо без гита, одним только мысленным взором, видел границу геологических слоёв, когда всё пошло по звезде, и стало нельзя ни у юзеров что-то поотлаживать, ни срочный патч выслать, заведомо не ломающий другие части программы.
И кстати, код при таком подходе становится проще для понимания, а не наоборот. Я читал сначала скрипты для старых железяк вида
Move(150); Sleep(100); Rotate(pi);, а потом — то же самое, но на C++ для новых железяк, и имел возможность сравнить.PrinceKorwin
19.11.2023 21:44Ну вот в вашем случае это должно быть специально оговорено. Не было? Тогда какие претензии к южным программистам?
ImagineTables
19.11.2023 21:44+3А почему тогда это не надо было обговаривать с теми, первыми программистами, которые сочинили DSL, а потом уволились в ходе корпоративного переворота? Почему они сами догадались, что задействовать DSL — хорошее решение? Потому что у программистов есть класс. Не тот, который тип данных, а тот, который позволяет подумать пять минут и представить, каково будет поддерживать кодом зоопарк ситуаций (в данном случае — зоопарк железа, но и к зоопарку магов и воинов с их мечами и посохами это тоже относится).
PrinceKorwin
19.11.2023 21:44+3Потому что вы рассматриваете только положительные аспекты.
Но ситуация может быть и такой: программисты придумали свой DSL и теперь мы имеем усложнение там, где его никто не просил. Код работает медленнее, изменения нужно вносить в разные подсистемы, нужно учить людей этому dsl.
KanuTaH
19.11.2023 21:44Это да. Когда игровая логика максимально вынесена в абы как написанные абы кем скрипты, это например сразу бьёт по тем местам, где надо просчитать множество вариантов для принятия оптимального решения (например, игровой AI). В шутерах это, может быть и не столь важно, не знаю, но в пошаговых стратегиях, где AI должен просчитывать, какие объекты на карте и в каком порядке он должен посетить, или какое заклинание в данный момент выгоднее применить во время боя, должен ли юнит атаковать (и как именно), или отступить, или прикрыть другого дружественного юнита, или, может быть, блокировать вражеского, чем быстрее все это просчитывается, тем более продвинутую/изощренную логику ты можешь себе позволить.
Hungryee
19.11.2023 21:44+1Преимущества конфигурабельности кода во много раз превышают оверхед от использования одной дополнительной папки / репозитория
PrinceKorwin
19.11.2023 21:44С этим никто не спорит. Речь про то, что это нельзя отдавать на откуп разаработчикам. В надежде, что все будет зашибись.
Это должно быть прописано в требованиях к коду, к функционалу. Покрыто тестами и т.д.
Если не прописали. То опять мой вопрос - какие претензии к новым разработчикам которые пришли на проект и сделали решение по другому?
Kanut
19.11.2023 21:44А механики нельзя прописать как отдельные "сущности"? И потом точно так же связать с классами и/или оружием через AllowedCharacterClass/AllowedWeapon?
Ну то есть берём механику "Fireball" и разрешаем её только магам или только при наличии посоха? Заодно получаем возможность просто добавить эту механику условному новому классу "'Witcher" или новому оружию "Magic book".
mayorovp
19.11.2023 21:44"Fireball" - это заклинание, а не механика. А вот если урон этого Fireball зависит от характеристик мага и посоха в его руках, причём ни те, ни другие даже не существуют у воина и его меча - это и есть уникальная механика магов.
Kanut
19.11.2023 21:44"Fireball" - это заклинание, а не механика.
А какая принципиальная разница? Это только пример.
вот если урон этого Fireball зависит от характеристик мага и посоха в его руках, причём ни те, ни другие даже не существуют у воина и его меча - это и есть уникальная механика магов.
Делаем стандартные "SDCIWC" атрибуты общие для всех. Или "конвертируем" разные атрибуты разных классов в какой-то общий для подсчёта таких вещей.
То есть вполне себе решаемые детали. Можете посмотреть как это например сделано во всяких D&Dшных "конструкторах" с их мешаниной классов, субклассов и допклассов. Или других подобных настолок.
Причём там это хорошо работает даже на бумаге и без всякого программирования.
mayorovp
19.11.2023 21:44Если брать готовую ролевую систему, то да, надо делать атрибуты общими и всё. Но если делать свою систему - может просто не хватить времени на то, чтобы свести всё к одному набору атрибутов.
Kanut
19.11.2023 21:44Ну во первых если у вас не хватает времени или умения нормально продумать такую "базу", то на мой взгляд у вас вряд ли получится годная игра.
А во вторых такое решается банальной конвертацией в "общий атрибут". Ну то есть у воина "strength", у мага "intellect", у вора "dexterity". Но для расчёта урона и прочего все они могут конвертироваться в какой-нибудь power. Как самый простой вариант 1 к 1.
Можно сложнее с какими-то коэффициентами для разных заклинаний/механик. Например для того самого "Fireball" можно сделать так что "strength" конвертируется 2 к 1, а "intellect" 1 к 1.
И мы всё ещё можем прописать такие вещи куда-то в табличку и нам не надо их хардкодить.
mayorovp
19.11.2023 21:44Иногда лучше захардкодить, чем конвертировать в общий атрибут.
Если в игре вдруг появится третий, смешанный, класс - лучше сразу увидеть все проблемы с механиками, чем двадцать патчей вылавливать всякую ерунду вроде влияния остроты меча на урон огненного шара.
Kanut
19.11.2023 21:44Иногда лучше захардкодить, чем конвертировать в общий атрибут.
Ну да. Когда не планируется ничего менять или добавлять :)
Если в игре вдруг появится третий, смешанный, класс
То он элементарно добавляется через таблички без всяких изменений в коде. И "играть" с этим классом проверяя как его лучше сделать дизайнеры могут элементарно без того чтобы что-то менять в коде и возможно ещё и ломать другие классы.
mayorovp
19.11.2023 21:44Когда не планируется ничего
менятьили добавлять :)Именно так! Когда в текущей версии не планируется добавлять смешанный класс.
Статическая типизация - она вообще, по сути, вся про то чего код не делает.
Kanut
19.11.2023 21:44Именно так! Когда в текущей версии не планируется добавлять смешанный класс.
Ага. А когда в новой версии его всё-таки решат добавят, то мы всё перепишем заново? Или ещё лучше скопипастим куски от двух разных классов и сделаем смешанный? :)
mayorovp
19.11.2023 21:44Новая версия будет новой версией.
Разумеется, надо думать хотя бы на шаг вперёд, и если в будущем планируется смешанный класс - неплохо было бы заранее подумать как вообще представлять его механики.
Но если геймдизайнер заверяет, что смешанного класса не будет никогда, а следующий на очереди - вообще лучник с луком, то почему программисту вообще нужно думать об этом самом смешанном классе мага-мечника?
Kanut
19.11.2023 21:44Новая версия будет новой версией.
Не ну конечно бывают игры, которые сразу делаются так как изначально задумывались и потом никак не развиваются. Но не сказал бы что есть много примеров хороших игр такого типа. Особенно если мы говорим о играх с механиками вроде тех что мы обсуждаем.
Но если геймдизайнер заверяет, что смешанного класса не будет никогда,
То не надо ему верить :)
то почему программисту вообще нужно думать об этом самом смешанном классе мага-мечника?
Банально потому что есть вариант, который позволяет избежать таких проблем в будущем и переложить кучу вещей с программиста на самих дизайнеров. И есть вариант, который этого всего не позволяет.
И нет особого смысла использовать второй вариант. Ну за исключением ситуаций когда игру действительно не планируется как-то особо развивать и менять.
dalerank Автор
19.11.2023 21:44ждите тогда лучей добра, и багу в jira от дизов, которым придется костылить такой хардкод. Бага на программера, уже не проблема дизайнера
deema35
19.11.2023 21:44+8Вы вряд ли услышите такие слова как FrameWork, boost, std::map, std::thread.
А вот это интересно. Если говорить про фреймворки то ладно. Но стандартные библиотеки языка C++ их ведь утверждает целый комитет по стандартизации. И при всем при этом к ним нет доверия у разработчиков игр.
voldemar_d
19.11.2023 21:44+3Возможно, это к данному случаю отношения не имеет, но как-то читал в каментах, как один человек рассказывал, что они в своей компании берут исходники контейнеров из STL, выкидывают всю универсальную обвеску, "причесывают" под свои особенности, и в результате то, что получается, и компилируется, и работает быстрее. В статье упомянута EASTL - вроде как, в ней есть более быстрые контейнеры, заточенные под gamedev. В конце статьи сказано, для чего это всё:
попробуйте уместить всю вашу логику в 15мс, с обработкой четырехсот NPC на уровне, физики, музыки, рендером на экран без просадок фпс.
domix32
19.11.2023 21:44Ну, кстати, упомянутые штуки редко являются частью нестандартных stl. Там обычно кучка контейнеров и рутин для работы с ними. Ну и кастомные аллокаторы. Всякие NavMesh, BehaviorTree/GOAP и прочее геймдизайновое это уже штуки сбоку, сделанные поверх этих контейнеров.
PrinceKorwin
19.11.2023 21:44+8Но стандартные библиотеки языка C++ их ведь утверждает целый комитет по стандартизации.
Функционал который входит а стандартные библиотеки (любого языка) - это результат компромисса между:
Скоростью
Универсиализацией
И потреблению памяти
Поэтому ничего удивительного нет в том, что существуют более быстрые сторонние решения или те, что используют меньше памяти.
yatanai
19.11.2023 21:44+2Ещё тянется Легаси от прошлых решений, который признаёт и сам комитет, но избавится от них не может. Я всё ещё помню тот трепет от введения концептов в язык и "легализации" библиотеки range.
Складывается ощущения что все эти решения рождались в муках, ибо те же контейнеры недостаточно структурированы, а сделать свой собственный linked list уже не кажется велосипедостроениеи.
beeruser
19.11.2023 21:44+1>> И при всем при этом к ним нет доверия у разработчиков игр.
Причём тут доверие? Имея несколько платформ, важно однообразное поведение среди всего этого зоопарка. Сейчас остался один Clang на x86/ARM на всех платформах и можно даже использовать обычный stl, но ещё недавно было нельзя. Было месиво mscv/gcc/clang/snc/intel на x86/arm/xenos/cell.
Поэтому использовали eastl как единую реализацию для всех платформ.
shiru8bit
19.11.2023 21:44+6Я программист и делаю игры. Геймдев - он разный. Большой корпоративный коммерческий - да, конечно, роли сильно другие, но дело же не в геймдеве как таковом. В любой корпоративной разработке любой отдельно взятый рядовой работник, включая разработку и менеджмент, не делает продукт, а делает какую-то мельчайшую часть, которая не факт, что вообще попадёт в проект.
Другое дело, что можно переформулировать это так: в играх не важен код. Да, это факт, игра - это не код. Можно полностью заменить код, его могут сделать другие люди, а конкретная игра останется конкретной игрой.
freeExec
19.11.2023 21:44"Фу игра не оптимизирована" это хейтеры про что и к кому обращаются?
shiru8bit
19.11.2023 21:44Я с подобными вопросами не сталкивался, а опыту близких людей, имеющих дело с подобной публикой - нет никакого резона искать здравый смысл в словах хейтеров. Они и до идеального столба докопаются.
yatanai
19.11.2023 21:44"попиксельная симуляция мира алгоритмически довольно сложна и требует большой вычислительной мощности, мы не можем вам дать игру которая бы работала на atom z3735f в 60фпс с размером карты 16К*16К, пожалуйста поймите нас"
ЗЫ, большая часть игр будет выдавать млрд ФПС даже на самопальной виртуальной машине, проблема больше в системе рендера. Любую игру можно ускорить в 2 раза если просто добавить LODы (2D игры умеют тормозить?)
s1im
19.11.2023 21:44+1Млрд ФПС? Не помню, чтобы видел хотя бы четырехзначное число ФПС даже на программках тупо отрисовывающих один треугольник. Не поделитесь ссылкой на такой бенчмарк, мне правда интересно?
Про тормозящее 2д, тут на самом деле все очень просто. Недавно игрался с юнити, делал простенькую сцену, типа 3в-ряд или пятнашек, Первое решение в лоб - каждая клетка была цветным пикселем PNG-файла, и представляла собой префаб с одним коллайдером2д, спрайтом и дочерним объектом, выводящим текст (просто циферку). Когда поле было маленькое, 16х16 - никаких проблем, значение фпс прыгало от 300 до 500 в 1080p, но стоило для теста изменить на картинку 100х100 - как фпс упал до неиграбельных 10-15. Хотя казалось бы, на экране не происходит вообще ничего, просто выводится сетка из 10к префабов с цифрами.
yatanai
19.11.2023 21:44Чтоб было понятно мою точку зрения... Я помешанный кресто-бог. Твою 3 в ряд я написал бы на голом С++ OpenGL и радовался стабильным 1000фпс. В моём понимании, 2D может лагать только если на экране огромное колличество объектов, там даже никакие батчи тебе не помогут. В остальном всё упирается в логику. Тот же факторио считает перемещение тысяч объектов на карте, что уже накладно по процессору.
А с 3D проще, ибо туда можно накрутить текстур по хуже, модели по уже, рендер на 0.75 со сглаживанием, всяких "генераторов травы" и вот мыльная мега детальная картинка в 200фпс готова. Всякие potatomod оптимизации Dark Souls3 которые на встройке HD4000 запускаются, как бы намекают что это работает.
arTk_ev
19.11.2023 21:44-2У вас просто не было ни разу опыта разработки и нет ни одного пет-проекта. Вы бы так не рассуждали.
voldemar_d
19.11.2023 21:44+4плюсы точно не для написания логики в играх
А можно пару слов, почему? Какая разница, на чем писать логику?
rutenis
19.11.2023 21:44+12Логику пишет дизайнер, для него разница принципиальная: попробовал, поправил, щёлкнул пальцами, и логика должна поменяться. И никаких этих ваших часовых компиляций.
DaneSoul
19.11.2023 21:44+3Присоединяюсь. Кроме быстроты применения для дизайнера еще и понятность кода критична - это должен быть простой язык, а не такой где только описание стандарта такого объема что им убить можно.
voldemar_d
19.11.2023 21:44+1Какие языки для логики используют? Таблица параметров в json?
DaneSoul
19.11.2023 21:44+5Насколько слышал, Lua популярна в таких задачах.
Кроме таблицы параметров нужно еще кучу всяких условий задавать и проверять: есть ли нужный предмет, достаточен ли уровень навыка и т.п. - все это и описывает логику игры и по разному может реализовываться в разных квестах, так что вынести это все в один конфиг не всегда оправдано.
MountainGoat
19.11.2023 21:44Lua, Python. Раньше Java иногда вкручивали, сейчас вряд ли.
Но главное - максимальная формализация правил и описание их в формате данных, так что да: JSON, YAML.
voldemar_d
19.11.2023 21:44+2Логику можно вынести в отдельный модуль, который быстро компилируется. Ну, впрочем, мысль понятна, спасибо.
dalerank Автор
19.11.2023 21:44+2Используют "быстрые интерпретаторы" lua, js или пишут свои языки quirrel, tjs, dascript
voldemar_d
19.11.2023 21:44+2Как же раньше всякие Doom 1/2 писали? Тоже вся логика в скриптах была?
MiraclePtr
19.11.2023 21:44+3Там логики практически не было. Только совсем базовое поведение стандартных юнитов (стой на месте и реагируй стрельбой на игрока если он появится рядом) и набор простых правил (типа если тут нажали переключатель, то там надо открыть дверь). В современных играх логики гораздо больше, там могут быть всевозможные квесты, довольно сложное поведение игровых персонажей и объектов, и т.д. Соответственно, писать эту логику и отлаживать приходится гораздо сложнее и дольше.
dalerank Автор
19.11.2023 21:44+2игры проще были, но вообще да, писали свои vm и языки сценариев, скриптов. Просто это не было массово, как сейчас
yatanai
19.11.2023 21:44+1Какая логика? Если подобрал предмет то открыть дверь? Так вроде это просто конфигом к уровню задавалось. Большая часть фич была вшита в движок а ты только описывал карту уровня.
Какой-нибудь Майнкрафт первых версий тоже был везде прибит гвоздями, то потом научились нормально скрипты с ресурсами тащить.
axe_chita
19.11.2023 21:44+2Приемлемую "расширяемую" не вшитую в код логику Кармак сделал только в "великом и ужасном" QuakeC из одноименного первого Quake.
mynameco
19.11.2023 21:44+2Есть разные программисты, и есть разные дизайнеры и артисты. И там и там, есть те, условно, кого можно легко уволить и взять любого из толпы. Не в плане их качества а в в плане их роли. И если проект сложный, то и код сложный. Настолько, что уволив программиста который за него отвечает, новый, придет со своим монстром, и по сути будет писать нового моснтра. И это превратится в неподдерживаемый код. Еще в сложных проектах, все может быть настолько сложно, что дизайнерам приходится консультировать с программистами, что можно, а что нельзя сделать. И, коственно, программисты влияют на дизайн игры, а значит ее делают )
jaha33
19.11.2023 21:44+1Я вообще не знаю мест, где можно без проблем протащить инструменты для статического анализа, возможно это обронка, может места где такие решения принимает кто то из бывших разрабов.
ReadOnlySadUser
19.11.2023 21:44+5В любой ИБ конторе. Есть требования регулятора по статическому анализу, так что он там точно будет. И скорее всего даже не один, а штуки 3.
aabzel
19.11.2023 21:44+3В обороне никакого статического анализа кода не делают. Личный опыт 3 года.
dalerank Автор
19.11.2023 21:44+3И зря, это ведь не игрушки. Так было и 15 лет назад когда там работал. Стабильность блин
domix32
19.11.2023 21:44+1Если у тебя ultimate garbage collection, то на многое можно забить. Это как админские скрипты - делают ровно то что надо сделать без заморочек и надежды на то, что кто-то станет это читать.
dalerank Автор
19.11.2023 21:44+1смотря где, в моем железе аптайм спокойно выходил за 5-6 месяцев, а оперативки меньше 16метров было обычно
panzerfaust
19.11.2023 21:44+1А в чем именно проблемы? Ну да, поначалу выдача SASTа разрабов не порадует. Но его несложно настроить. Как и несложно составить план по фиксу ишью.
Paradox179
19.11.2023 21:44+13Если честно, не увидел причин не идти в геймдев, если смотреть на него без розовых очков.
Во-первых, это всё-таки работа, а на работе нужно работать, а не чилить. И также для дизайнера, продюсера, арта и т. д. - для них это такая же работа, как и для программиста.
И если вдруг программист шёл делать игру: код писать, музыку писать, рисовать, продумывать сюжет, логику и т. д. - это же всё-таки инди-геймдев, но тоже геймдев.
Если программисты - мизантропы, социофобы, асоциальные личности без софт скиллов - они на своём месте и они никогда не справятся с тем, чтобы написать музыку, что-то нарисовать, придумать хайповую игру. Также и люди искусства никогда не напишут мега-оптимизированный код, который сэкономит памяти, и они не смогут написать свой движок.
Тоже самое про лида - это программист без социофобии и с прокачанными софт скиллами, поэтому они и стали лидами, потому что это им в кайф, и они снова же на своём месте.
В общем, лид и нужен для того, чтобы направлять творческую энергию художников и техническую энергию программистов в то, что будет выглядеть, как годная, оптимизированая и окупаемая игра.
Без одного типа человека - всё развалится: без лида - никто их не организует, без художника - никто не сделает яркую и привлекательную игру, без программиста - никто не напишет качественный оптимизированный код.
Вопрос, скорее в том, чтобы каждый человек понимал, что ему больше всего подходит в геймдеве и выбрал то, что ему по силам и будет его драйвить.
Спасибо за статью)
Myz17
19.11.2023 21:44+11Если честно, не увидел причин не идти в геймдев, если смотреть на него без розовых очков.
для меня решающей стала зарплата. Ушёл из геймдева в энтерпрайз.
PsihXMak
19.11.2023 21:44+2В целом, ничем не отличается от обычной работы программиста.
Мне больше интересно, как попасть в геймдев? Сколько лет рассылаю резюме по игровым студиям, но всегда получаю тишину, либо типовой отказ.
ReadOnlySadUser
19.11.2023 21:44+3По опыту, есть два пути: сложный и простой.
Сложный - написать любую законченную игру в которую хоть кто-то играет, даже 5 человек.
Простой - по рекомендации. Причём попасть можно прям сразу на высокую позицию. Я в жизни ни строчки кода не написал для игр, но по рекомендации прошёл собес в довольно крупную геймдев компанию, получил оффер на senior позицию, но и по деньгам не сошлись, да и передумал я там работать после более детального изучения игры, на которую меня брали.
AnimeSlave
19.11.2023 21:44Мне больше интересно, как попасть в геймдев?
Я попал через стандартное собеседование. То есть можно это сделать через стандартные пути. Но есть нюансы, которые зависят от конкретной компании. Я статью писал об этом (на правах наглости). В ней я описываю несколько собеседований. Если есть вопросы, тегай здесь, могу помочь, подсказать
Bayfong
19.11.2023 21:44+2Сори за дилетантский вопрос: я правильно понял, "дизайнеры" - это не про художников? Они код пишут и еще чего-то делают.... Можете объяснить плиз
dalerank Автор
19.11.2023 21:44+7Да, level designer, ai designer, sound designer, env designer и ещё немного других, в общем называют gamedsigner или Диз/des
CBET_TbMbI
19.11.2023 21:44+2Тут автор сократил.
Обычно их зовут гейм-дизайнерами. Это те, кто отвечает за суть игры, за геймплей, за баланс. Они в свою очередь могут подразделяться далее (на тех, кто отвечает за уровни, за баланс, за сценарий, за монетизацию, и за кучу других вещей). Вообще, их правильно переводить "проектировщики игр". Но почему-то их так никто не называет. Они не пишут код, зато каждая цифра в характеристиках, каждое умение, каждый враг, каждый квест на их совести.А есть ещё просто дизайнеры (по буржуйски "артисты"). Это те, кто создаёт визуал: рисует, делает 3д-модели и т.п.
Кстати, и дизайнеры, и гейм-дизайнеры получают зп намного ниже. Ибо конкуренция намного выше. Туда идут все, кто хочет делать игры, но не умеет программировать.
dalerank Автор
19.11.2023 21:44у них тоже свой рынок, который сильно разбавлен gamekiddis - людьми, которые набрали ассетов со стора, кинули туда пару блупринтов и пробуют это продать игрокам, а себя назвать дизайнерами. Не скажу, что сильно меньше. Kiddis да, пятачок за пучок (извините), но этот джуны, которые вырастут, если вырастут, и станут потом будущим индустрии
Hlad
19.11.2023 21:44+2По поводу "если увольняется арт-директор..." вспоминается история с третьей "Готикой": её показывали на куче выставок, вот-вот должен был быть релиз... А потом у разработчиков как-то резко всё стухло, релиз перенесли то ли на год, то ли на два, выкатили малоиграбельное забагованное нечто... А титры после прохождения игры начинались со слов соболезнования по поводу смерти как раз арт-директора...
azTotMD
19.11.2023 21:44+1тем не менее, она на порядки лучше 4ой....
XAHOK
19.11.2023 21:44Будем честными, 3-ка от 4-ки отличается только отсутствием коридорности и невнятным сюжетом. В остальном они близнецы-братья, особенно на фоне контраста с 1-2 Risen. Причем 3-й Risen от 3-ей готики далеко не ушел, одинаковое отвращение вызывает, что забавно.
Bozaro
19.11.2023 21:44+6C git'ом кстати тоже есть проблема, он хорошо подходит для сорцов, а вот что делать с гигабайтными текстурами или файлами модели по 100мб, или луашником/json'ом уровня размером под 20-30 мб текста? Тут либо держишь 2 cvs - одну для сорцов, вторую для контента, либо пишешь своё решение.
Большие файлы стало можно использовать после появления Git LFS.
А проблему взаимодействия Git с не-программистами мы решали реализацией Subversion API поверх Git-репозитория: https://habr.com/ru/companies/vk/articles/241095/
domix32
19.11.2023 21:44-1Когда ассеты начинают становиться гигантскими, когда все вот эти 4к текстуры с десятками слоёв для PBR и финальными паками по дцать гигов как у того же Bioshock или каких-нибудь современных MW, то хранить их в той же репе с кодом крайне неудобно. Обычно их суют параллельно в альтернативные системы контроля для ресурсов - какой-нибудь Preforce и его альтернативы или даже SVN, вместо git.
o_f
19.11.2023 21:44+2"Если у вас получилось тут поработать, в других местах будет чего-то не хватать."
Чего, например?
dalerank Автор
19.11.2023 21:44+15Фидбека от игроков, рокстара за соседним столом, который пилил Ил2-штурмовик в 2007, дизов с их безумными идеями, игровых движков bleeding edge tech, пьянки в ночь релиза, первых патчей, оптимизаций на асме... еще что-то забыл?
BattleAngelAlita
19.11.2023 21:44-1Если так не хватает юнит-тестов, фрэймворков, совещаний и посиделок с коллегами то что вы делаете в геймдеве? В геймдев и идут как раз те, кому надо чтоб интровертно аутировать и чтоб быстро работало.
Не надо очернять нишу просто потому-что она вам не подходит. Многим другим не подходит корпо-среда, и для них геймдев отличное место.
Myz17
19.11.2023 21:44+3у меня наоборот работа в геймдев студии была гораздо более социальной, чем в большом софте. Если почитать "Повелители Doom" - вот примерно такая же атмосфера. Могли пол дня просто играть во что-то, а вторую половину разбирали механики и смотрели арт.
Weilard
19.11.2023 21:44Студия студии рознь. Мне удавалось побывать и в коллективах увлечённых делом людей без лозунгов, и в конторах где главенствовал лозунг "мы дружная семья профессионалов", но на деле это место оказывалось джунглями с двуногими акулами, где был дресс-код, где приходилось говорить то, что было надо говорить, а не то что было бы хорошо для проекта, и где приходилось соблюдать крайне странные правила.
Этим я хочу сказать, что конторы, как и люди все очень, и очень... разные. Есть и корпоративно-ориентированные, а есть очень милые и уютные кораблики, в теле которых очень приятно плыть. Одной из таких контор, вероятно, была Troika Games, о которой её создатели вспомнитают исключительно тепло. Правда творческий гений и добрая атмосфера плохо укладываются в концепцию продуктивного и успешного бизнеса, на мой взгляд.
MountainGoat
19.11.2023 21:44Правда творческий гений и добрая атмосфера плохо укладываются в концепцию продуктивного и успешного бизнеса
Нормально укладываются, если не пытаться заработать всё и сразу, и если не обещать инвесторам ежегодный рост прибыли на 30% минимум.
data_analyst
19.11.2023 21:44+2Можно ли благополучно работать программистом в gamedev, если не играешь в компьютерные игры?
dalerank Автор
19.11.2023 21:44+5думаю что нет, вы как минимум будете треть времени тратить на проверку фичей, если это не доставляет удовольствия, будут только мучения. Ну и смотря какие игры конечно, мне не нравятся сегодняшние игры на мобилках, в них я почти не играю, за исключением игр от Kairosoft (но эти скорее исключение)
Myz17
19.11.2023 21:44да. Например toolset развивать. Или просто узкоспециализированным специалистом - программировать физический движок, базовые библиотеки пилить или спецэффектами заниматься.
bfDeveloper
19.11.2023 21:44+2Можно. Я почти 10 лет геймдеве (пусть и не ААА) и примерно столько же ни во что почти не играю. На мне это сработало как с колбасой - когда знаешь как делают, сам есть уже не можешь. Очень на многих работает наоборот - так что предугадать сложно.
Aquahawk
19.11.2023 21:44можно, играть перестал как пришёл в геймдев. Почти 12 лет, полёт нормальный. Тут и вырос, и интересы поменялись на более жизненные, но и играть уже не интересно когда понимаешь как игра монетизируется, как удерживается внимание, как вешается крючок чтобы ты завтра зашёл и т.п.
Keeper10
19.11.2023 21:44+4играть уже не интересно когда понимаешь как игра монетизируется, как удерживается внимание, как вешается крючок чтобы ты завтра зашёл и т.п.
Зачем вообще играть в плохие игры? Играйте в хорошие, без всего этого дерьма.
aabzel
19.11.2023 21:44+3Спасибо Вам за ваш текст про будни в GameDev. Как по мне это похоже на настоящее программирование.
Вот бы еще почитать тексты на темы оставшихся областей программирования
1--"Вы точно хотите пойти программистом в Web Back-End?"
2--"Вы мечтаете пойти программистом в Web Front-End?"
3--"Вы хотите стать программистом приложений под Android/iOS?"
4--"Что? Вы хотите стать прикладным программистом под DeskTop?"
5--"Неужели Вы хотите быть системным программистом ядра Linux?"
6--"Мечтаете стать системным программистом для видеокарт GPU?"
7--"И Вы тоже хотите быть DataSience инженером?"
8--"Точно хотите разрабатывать компиляторы и IDE?"
9--"Я так понял, Вы хотите стать программистом под FPGA?"
и что там еще осталось?...
Brrastak
19.11.2023 21:44+2Эмбед ещё. Обидно, однако!
aabzel
19.11.2023 21:44-1Эмбед ещё. Обидно, однако!
А про Embedded программирование как раз таки есть аналогичный текст.Называется
Вы в Самом Деле Хотите Стать Программистом Микроконтроллеров?
https://habr.com/ru/articles/668368/
aabzel
19.11.2023 21:44Когда я поздно вечером после 23:00 прихожу домой с работы программистом микроконтроллеров я обнаруживаю дома как мой брат играет в видеоигры на DeskTop PC. Что-то типа GTA-5, Crisis, и поговаривает:
Вот этих программистов я уважаю! Отличную компьютерную программу написали... Сразу видно, отлично поработали парни!
Потом он поворачивает голову в мою сторону и говорит
А то, что ты там программируешь в своей северной промзоне 10й год по 3й форме допуска, я не знаю?...
Вот программисты игр и являются True Программистами, а ты (программист MCU) вообще не пойми кто!
dalerank Автор
19.11.2023 21:44+3какая то обида в коменте, ну так не ходите туда, вокруг достаточно других позиций, не обязательно gamedev. Ну и насчет северной промзоны, поверьте я знаю что такое и третья и вторая и первая формы (https://habr.com/ru/articles/751706/), и в embeded разработке поварился достаточно. Да только на седьмой год понял, что на 300баксов зп либо семья либо ипотека и ушел.
aabzel
19.11.2023 21:44Разработку авиасимуляторов для Миг(ов) с Су(шек) и танковых тренажеров для военных НИИ можно причислить к GameDev разработке?
aabzel
19.11.2023 21:44+1Как по мне GameDev это яркий пример как люди буквально на пустом месте создают компании и продукт.
aabzel
19.11.2023 21:44Напишите что-н про метрики из разработки GameDev.
Сколько строк кода в игре?
Сколько времени собирается *.exe файл с релизом игры из готовых исходников?dalerank Автор
19.11.2023 21:44+5Зависит от проекта, на текущем 1.5млн+/30к файлов движок + редактор, сам бинарь из готовых либ пересобирается 5+ минут, все что не меняется вынесено в либы. Их меняют редко, весь билд с ресурсами собирается 2+ часа, с прогоном тестов под 4+ часа, с деплоем и прогоном релиза 6+
seepeeyou
19.11.2023 21:44+4Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт
Действительно огорчили. Раньше игры делали именно программисты, и они были интересными. А теперь мудовая зачистка двухста двадцати восьми аванпостов в НУ ОЧЕНЬ КРАСИВОМ мире.
dalerank Автор
19.11.2023 21:44+4Если покупают зачистку в красивом мире эти игры будут делать, но ведь можно покупать вот такие, и тогда их тоже будут делать чаще. Игра к сожалению не окупилась.
agray
19.11.2023 21:44Это ошибка выжившего. То что покупают зачистку карты совсем не значит что покупать красивые, интересные и сложные игры не будут или что такие игры не будут иметь огромный успех превышающий аванпосты.
Мне кажется это просто сложно, сложно делать нормальные игры, сложно искать людей кто будет делать нормально, сложно вообще понять что это такое, это ваше "интересное" и "нормальное". Вроде бы очевидно что у этого декаданса что у этого декаданса скудно с интерфейсами и графикой, но как это выразить в вещественной форме? Сложно. И на эту сложность никто не хочет тратить деньги. Аванпосты-то покупают, зачем делать лучше и заморачиваться, поскачем же вместе в продакшн!
DarkEld3r
19.11.2023 21:44Точно не окупилась? А на что тогда Colony Ship сделали?.. Да, разработчик говорит, что от продаж последней зависит их дальнейшая судьба и это может стать их последней игрой, но думал, что Age of Decadence продалась не так плохо. Конечно, по меркам такого инди проекта. Вообще читал множество интервью с Винсом и у меня сложилось впечатление, что он как раз не разработчик. Но могу и ошибаться: на их форум всего пару раз заглядывал и особо не вникал сколько у них человек сейчас и кто чем занимается.
Если что, Age of Decadence покупал до релиза, после - нескольким знакомым в подарок. И Colony Ship три раза купил. И даже Dungeon Rats куплена.
dalerank Автор
19.11.2023 21:44+2steamdb говорит (https://steamdb.info/app/230070/charts/) 33к фоловеров - это кто купил + вишлисты (Винс пишет, что разработку продажи окупили), 15 на старте, 10 средняя цена - 30% коммиссия ~ 10 * 30k = 300k - 100k стиму = 200к на 4года разработки ~ 4k в месяц, Винс денег не брал, получается 1.5к в месяц каждому из участников. С натяжкой получается, что вытянули, да.
да, я сам их поддержал себе взял, и друзьям раздарил штук десять
Kanut
19.11.2023 21:44+3Истории и игровые механики придумывают тоже не программисты. И раньше в общем-то не они этим занимались. Просто раньше эти вещи лучше удавалось совмещать и одновременно быть и программистом и дизайнером.
Weilard
19.11.2023 21:44+1Раньше у программистов просто не было выбора. Они учились всему, методом проб и ошибок. Это если углубляться в далекие дали и посетить на машине времени зарю игростроения, то можно увидеть множество любопытных свершений. Улететь в эпоху "игр в шароварах" (shareware games) и даже ранее. Тогда и и толковый программист, и толковый художник были чем-то особенным. Ведь даже один человек мог сделать коммерчески успешную игру, чьё визуальное сопровождение могло не выходит за четыре цвета. Художник, к несчастью, этого сделать - не мог. Это мог сделать - только программист.
И ещё долгое время программисту приходилось соединять в себе одном - кучи специальностей. Но когда игры стали расти, стали расти и конторы, и началось последующее разделение на специализации. Технологии позволяли использовать сканированный и обработанный затем арт, появились и другие пути создания графики. И постепенно это направление унаследовали те кому и положено этим заниматься.
Поэтому я бы сказал, что не "удавалось совмещать и одновременно быть и программистом и дизайнером", НО... приходилось совмещать и одновременно быть.
Kanut
19.11.2023 21:44+2Раньше у программистов просто не было выбора.
Или у дизайнеров игр :)
Художник, к несчастью, этого сделать - не мог.
Художник и дизайнер игр это даже близко не одно и тоже.
Это мог сделать - только программист.
Написать тот же тетрис(то есть именно сам код игры) и тогда и сейчас могла куча людей. Это вообще не сложно с точки зрения программирования.
А вот придумать тетрис как игру...
seepeeyou
19.11.2023 21:44-2Разработчик - Алексей Пажитнов
Алексе́й Леони́дович Па́житнов - советский и американский программист и геймдизайнер
ась?
shiru8bit
19.11.2023 21:44+4Во взгляде из сегодняшнего дня всё слегка перевернулось с ног на голову. Это сейчас кто-то как-то может сначала стать программистом, а потом захотеть делать игры. В прошлом порядок был обратным - захотел делать игры, стал и программистом, и художником, и дизайнером, и всеми остальными. И тебе 14 лет.
KanuTaH
19.11.2023 21:44А вот поддержу. Если хочу поиграть, играю в HoMM3, MOO2, такие штуки. В качестве хобби пилю свободный движок для HoMM2. Автор статьи к слову пилит свободный движок для Фараона. А современный геймдев производит одноразовые игры, еле ворочающиеся на современном железе. Может, они и красивые, но играть в них больше одного раза не хочется.
Devakant
19.11.2023 21:44+1Ещё бы кто-нибудь написал как в тестирование игр попасть... :)
Везде нужен человек с уже опытом, а стартовых вакансий просто нет, либо они в духе - работы за опыт, и грамоту в рамке (которую к тому же самому купить надо)dalerank Автор
19.11.2023 21:44+5хм похоже вы не там ищите, с грамотами точно. «I have nothing to offer but blood, toil, tears and sweat.», первый год действительно придется просить ниже рынка, если глаза горят и очень хочется в gamedev и именно на qa. Потом освоитесь обучитесь и выйдете на среднюю зп. Но вроде так везде, gamedev - it, здесь не показатель вообще. А Вы не ищите по вакансиям, пишите туда куда хотите устроиться, на почту HR или info, на форуме разработчиков
mishkin79
19.11.2023 21:44-3В Рик и Морти передана вся парадигма юнити) (буэээ ассетами и модулями - и ты программист с дизайнером).
aabzel
19.11.2023 21:44Сейчас делают что на движке HGE?
AnimeSlave
19.11.2023 21:44+1Да. Но я рекомендую смотреть в другие движки, просто потому, что HGE не мультиплатформенный. Со временем, если такое понадобится, будет огромная проблема переходить на его форки, где были добавлены другие платформы
l_Tungus_l
19.11.2023 21:44Спасибо автору за статью. Сам читаю хабр и это та статья которую не стыдно кинуть в Закладки и позже перечитать еще раз.
На данный момент я ещё студент, учусь на разработчика, и в свое время, как и любой маленький мальчик(девочка) переигравший в Ведьмака или ГТА 5 мечтал по ночам о том, как я буду делать в будущем такие эпохальные игры.
Время шло, я становился старше, и с каждый годом приходило понимание, что АйТишечка не такая уж радужная в целом - не у всех получается научиться программировать и не всех потом берут на работу по итогу. Что уж говорить про геймдев.
В какой-то степени даже профессионально завидую иногда таким как вы, дай мне выбор - пытаться дальше попасть на смузи-галеру или в геймдев со всеми его минусами, я как зелёный студентик без опыта выбрал бы геймдев, и уже потом, спустя годик если было совсем тяжело, уже только тогда начал бы искать работу в "большом" АйТи. Но, видимо это то что и отличает меня ещё зелёного от таких как вы - возможность выбирать куда двигать свою карьеру являясь уже хорошим специалистом.
Извиняйте за словесный понос.
tommyangelo27
19.11.2023 21:44+2Если реально хотите попасть в айти, вам нужно срочно перестать читать Двач.
dalerank Автор
19.11.2023 21:44+1Скорее думать, что игрострой это розовые поля с зелёными единорогами, как и везде это тонны кода и ночи отладки. Тогда и ожидания меньше разойдутся с реальностью
l_Tungus_l
19.11.2023 21:44+1А вы мой комментарий читали? Где там я говорил что автор не прав, а геймдев это миллионы в наносекунду и смузихлебство? Была описана ситуация детства, когда ты играл в игру и проникался ей настолько, что мечтал о том как в будущем сделаешь нечто подобное.
Хотя, смысл объяснять, вон, на мой комментарий уже -1 влепили, даже не написав что не так с ним, а я ведь просто написал свою мысль об этом)
Хабр нынче стал каким-то пассивно агрессивным - очень часто пишешь комментарий и на него сразу прилетает -1, неважно какой тематики комментарий - ругаешь автора или хвалишь, или вообще высказываешь свое видение данной ситуации - будь готов к инстант минусу "просто потому что"
dalerank Автор
19.11.2023 21:44+1конечно читал, не имел ввиду конкретно Вас, извините если как-то обидел словами. Но через одного вижу это на собесах, и именно так как вы описали - про смузи и быстрый бакс. А через полгода ребята сдуваются, когда приходит реальная нагрузка. А минусы, ну минусы - люди разные, у них есть свое мнение, не хуже, не лучше, просто другое. Оно будет ответом на ваш комент, иногда минусом
l_Tungus_l
19.11.2023 21:44+1Тогда извиняюсь, думал это ко мне адресовано было. Касаемо минусов, у меня нет с этим проблем, просто как я понимаю некоторые так самоутверждаются наверное, но да ладно...
Algrinn
19.11.2023 21:44+3Ладно код некачественный, графика некачественная, анимация некачественная, саунд дизайн некачественный, но хотя бы сюжет можно не самим писать, а попросить профессионального писателя? Ну невыносимо просто всё унылое, кажется, что игры под Android просто пишут люди, которые искренне их ненавидят. От всего веет дешевизной, экономией, ориентацией на казуалов и детей.
s1im
19.11.2023 21:44+2Если программист именно хочет заниматься программированием, то идти работать в гейм-дев компанию, мне кажется, было бы неплохим решением. Плохим решением было бы идти на вольные хлеба в соло-инди-дев. У меня есть небольшой опыт подобного, по факту получилось что именно программирования (создания С# скриптов для юнити) оказалось дай бог если 5% от всей работы. Остальное время заняло: проектирование, создание сцен в редакторе, рисование графики и арта, поиск всевозможных звуков и музыки (поиск бесплтаного, покупка недорогого или создание с нуля в редакторах музыки), локализация, тестирование и отладка. На закуску: издательство и маркетинг. В момент когда к тебе приходит идея и ты тестируешь какую-то интересную геймплейную фичу, ты в этот момент даже не задумываешься, сколько времени может уйти просто на то чтобы настроить и оформить свою страницу на каком-нибудь маркетплейсе, типа стима и внедрить их оверлей в свою игру с ачивками и прочими плюшками (программирования там опять же по минимуму, все уже написано для вас, в основном это конфигурирование сборок).
AnimeSlave
19.11.2023 21:44+1Простой вывод из ситуации - «Хочешь программировать в gamedev — не иди в компанию, где используют готовые игровые движки». Суть готовых игровых движков именно в том, чтобы не тратить время и ресурсы на программирование. А наличие инструментов визуального программирования в ряде современных игровых движков ещё больше сокращает необходимость в программировании
s1im
19.11.2023 21:44Мой комментарий не столько про готовые или собственные движки, сколько про разделение задач и ответственности. В соло или маленькой команде скорее всего придется заниматься многими вещами далекими от разработки как таковой, в большой компании (даже использующей готовый движок) могут просто посадить за узкую задачу, типа отдельный редактор квестов или игровой карты, при этом ни байта твоего кода по сути в самой игре и не будет. Будешь ли ты при этом счастлив или нет - вопрос который каждый должен задать себе сам, прежде чем идти в геймдев.
esisl
19.11.2023 21:44Открываю свой код:
scene.transferOfItems = true scene.transferDescUserId = teamListArr[player].id selectedPlayerForTransfer = player transferItemTransparent.p0=0 transferItemTransparent.p1=0 transferItemTransparent.p2=0 transferItemTransparent.p3=0 transferItemTransparent.p4=0 switch (player){ case 0: transferItemTransparent.p0 = 1;break; case 1: transferItemTransparent.p1 = 1;break; case 2: transferItemTransparent.p2 = 1;break; case 3: transferItemTransparent.p3 = 1;break; case 4: transferItemTransparent.p4 = 1;break; } transferItemMessage = 'Transfer ' + teamListArr[player].name } function clickTransfer(itemName: string) { if (itemName && teamListArr.length > 0) { selectedPlayerForTransfer = -1 transferItemTransparent.p0=0 transferItemTransparent.p1=0 transferItemTransparent.p2=0 transferItemTransparent.p3=0 transferItemTransparent.p4=0 scene.transferItemName = itemName scene.transferDescUserId = '' transferItemVisible = trueКак здесь сделать смайлик "ёкарный стыд"? :)
aabzel
19.11.2023 21:44Я умею чертить 3d детали в программе moi 3d есть ли шанс пристроиться в gamedev?
dalerank Автор
19.11.2023 21:44+1Люди всегда нужны, не уверен правда что вы будете чертить детали конечно ;)
aabzel
19.11.2023 21:44-3На 7м-10м году санкций и Эмбарго, российским программистам микроконтроллеров по любому придётся переучиватся в чертёжники. Западные микроконтроллеры закончатся на российских неотапливаемых складах.
Вычислительные машины будут снова проектироваться шестерёночно- кулачковыми.
Нас тут снова ждёт паровой век! Аж дух захватывает.
aabzel
19.11.2023 21:44Я хочу разработать на Windows программу симулятор графического монохромного дисплея. Разрешение 64x128. Fps 5Hz.
Код писать на Си. Какой мне выбрать игровой движок?
dalerank Автор
19.11.2023 21:44+1а вам точно нужен Игровой движок для этого?
aabzel
19.11.2023 21:44Я пробовал в python на канве отрисовать. Получился Fps 0.1 hz. В 50раз медленнее чем требуется.
mayorovp
19.11.2023 21:44+3Значит, либо что-то сильно не так делали, либо проблема в Питоне.
О какой канве речь? Надеюсь, вы не путались отрисовать по точкам картинку на Canvas из tkinter? Там векторная графика, а вам явно нужна растровая.
aabzel
19.11.2023 21:44Вот код
import socket import tkinter as tk import threading import sys import time #Приветственное окно #=================================================================================================== def draw_numbers(canvas, num1, num2, num3, num4, pixel_size, canvas_width, canvas_height): # Устанавливаем размеры холста #canvas.config(width=canvas_width, height=canvas_height) # Очищаем холст canvas.delete("all") coord_net() # Если ширина холста меньше 78, рисуем числа в одной колонке if pixel_matrix_width < 78: x = pixel_size * 2 y = pixel_size * 2 draw_number(canvas, num1, x, y, pixel_size) y += pixel_size * 7 # Увеличиваем расстояние между числами на 5 пустых пикселей draw_number(canvas, num2, x, y, pixel_size) y += pixel_size * 7 # Увеличиваем расстояние между числами на 5 пустых пикселей draw_number(canvas, num3, x, y, pixel_size) y += pixel_size * 7 # Увеличиваем расстояние между числами на 5 пустых пикселей draw_number(canvas, num4, x, y, pixel_size) else: # Остаемся с текущей логикой отрисовки spacing_between_numbers = pixel_size * 1 x = spacing_between_numbers y = pixel_size for num in [num1, num2, num3, num4]: digits_list = list(map(int, str(num))) for digit in digits_list: draw_digit(canvas, digit, x, y, pixel_size) x += (pixel_size + pixel_size // 2) * 4 x += spacing_between_numbers * 4 y = pixel_size def draw_number(canvas, number, x, y, pixel_size): digits_list = list(map(int, str(number))) for digit in digits_list: draw_digit(canvas, digit, x, y, pixel_size) x += (pixel_size + pixel_size // 2) * 4 y += pixel_size * 7 # Увеличиваем расстояние между числами на 5 пустых пикселей def draw_digit(canvas, digit, x, y, pixel_size): # Карта пикселей для отображения цифр (0-9) digits = [ [ "111", "101", "101", "101", "111", ], [ "010", "010", "010", "010", "010", ], [ "111", "001", "111", "100", "111", ], [ "111", "001", "111", "001", "111", ], [ "101", "101", "111", "001", "001", ], [ "111", "100", "111", "001", "111", ], [ "111", "100", "111", "101", "111", ], [ "111", "001", "001", "001", "001", ], [ "111", "101", "111", "101", "111", ], [ "111", "101", "111", "001", "111", ], ] global Hello for row, pixel_row in enumerate(digits[digit]): for col, pixel in enumerate(pixel_row): if pixel == '1': Hello = canvas.create_rectangle( x + col * pixel_size, y + row * pixel_size, x + (col + 1) * pixel_size, y + (row + 1) * pixel_size, fill="white" ) #=================================================================================================== #Аргументы командной строки pixel_matrix_width = int(sys.argv[1]) # 1 аргумент cmd - ширина матрицы pixel_matrix_height = int(sys.argv[2]) number_of_port = int(sys.argv[3]) pixel_size = int(sys.argv[4]) # Глобальные переменные для размеров холста и пикселя PIXEL_SIZE = pixel_size CANVAS_WIDTH = pixel_matrix_width*PIXEL_SIZE CANVAS_HEIGHT = pixel_matrix_height*PIXEL_SIZE # Для приветственного холста canvas_width = pixel_matrix_width * pixel_size canvas_height = pixel_matrix_height * pixel_size def start_window(): # Приветственное окно с числами global canvas draw_numbers(canvas, pixel_matrix_width, pixel_matrix_height, number_of_port, pixel_size, pixel_size, canvas_width, canvas_height) root.update() def remove_hello(): # Удаление приветственного окна global canvas canvas.delete('all') canvas.update() def coord_net(): # Создание координатной сетки #global canvas for x in range(0, canvas_width, pixel_size): canvas.create_line(x, 0, x, canvas_height, fill="white") for y in range(0, canvas_height, pixel_size): canvas.create_line(0, y, canvas_width, y, fill="white") root.update() def server_thread(): global canvas global client_socket try: client_socket, client_address = server_socket.accept() print(f"Connected by client with address: {client_address}") #remove_hello()# Удалить окно "Hello!" при подключении клиента #coord_net() if int(sys.argv[1]) > 85: for i in range(0, 6): # for j in range(1, 85): # x = j # y = i # c = 1 x1 = j * PIXEL_SIZE y1 = i * PIXEL_SIZE x2 = x1 + PIXEL_SIZE y2 = y1 + PIXEL_SIZE canvas.create_rectangle(x1, y1, x2, y2, fill="black", outline="white") root.update() elif int(sys.argv[1]) < 85: for i in range(0, 28): # for j in range(1, int(sys.argv[1])): # x = j # y = i # c = 1 x1 = j * PIXEL_SIZE y1 = i * PIXEL_SIZE x2 = x1 + PIXEL_SIZE y2 = y1 + PIXEL_SIZE canvas.create_rectangle(x1, y1, x2, y2, fill="black", outline="white") root.update() while True: data = client_socket.recv(1024) if not data: continue # Получаем координаты a и b из приходящей посылки received_data = data.decode('utf-8') a, b, c = map(int, received_data.strip('<>').split(', ')) if c == 1: # Рисуем белый квадратный пиксель на холсте x1 = a * PIXEL_SIZE y1 = b * PIXEL_SIZE x2 = x1 + PIXEL_SIZE y2 = y1 + PIXEL_SIZE canvas.create_rectangle(x1, y1, x2, y2, fill="white") elif c == 0: x1 = a * PIXEL_SIZE y1 = b * PIXEL_SIZE x2 = x1 + PIXEL_SIZE y2 = y1 + PIXEL_SIZE canvas.create_rectangle(x1, y1, x2, y2, fill="black", outline="white") # Обновляем холст root.update() except Exception as e: print(f"Error: {e}") finally: client_socket.close() # Создаем окно Tkinter root = tk.Tk() root.title("Monochrome display") # Создаем холст с черным фоном canvas = tk.Canvas(root, width=CANVAS_WIDTH, height=CANVAS_HEIGHT, bg="black") root.geometry('1280x640+100+75') canvas.pack() # Рисуем вертикальные и горизонтальные осевые линии с белым цветом HOST = '127.0.0.1' # localhost PORT = number_of_port # Произвольный порт (вы можете выбрать любой доступный порт) server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.bind((HOST, PORT)) server_socket.listen(1) print(f"Server is listening on {HOST}:{PORT}") # Запускаем основной поток для отображения окна "Hello!" start_window_thread = threading.Thread(target=start_window) start_window_thread.start() # Запускаем дополнительный поток для ожидания подключения клиента и удаления "Hello!" server_thread = threading.Thread(target=server_thread) server_thread.start() # Запускаем главное окно Tkinter root.mainloop()mayorovp
19.11.2023 21:44+2Ну да, симуляция растровой графики через векторную. Вы рисуете символы прямоугольниками, а потом Tk рисует ваши прямоугольники пикселями. Чтобы это заработало с нормальным FPS, надо одно из двух.
Либо вы остаётесь в векторном мире, тогда вместо рисования прямоугольниками надо сделать растровый шрифт в виде картинки, и рисовать на канве куски этой картинки.
Либо же надо положить на канву BitmapImage, и рисовать свои пиксели строго на нём.
aabzel
19.11.2023 21:44Я пробовал синтезировать экраны на Graphviz, однако FPS получился 0,3 Hz
Симулятор Графического Монохромного Дисплея на Graphviz
https://habr.com/ru/articles/753890/
Alesh
Спасибо, интересная статья.