Comments 229
Спасибо, интересная статья.
Статья довольно полезная и интересная. Геймдев - жестокая штука...
…но классная :) Когда-то и меня вела дорога приключений… были же времена, когда двушки с EGA/CGA/«Геркулесом» на вторичном рынке были на развес, а Doom уже существовал :) И я даже что-то почти написал в те древние годы :)
А сейчас стрела в колене, клапанная недостаточность в венах, башка кровь не получает, тупой как пень, еле-еле свой эмбед/физмат вывожу :( прямо хоть бери подработку электронные книги начитывать (читаю хорошо, но переигрываю люто — «реквизит грызу»).
А жаль. Интересные задачи в геймдеве, перманентная мечта — какая-то халтурка на выходные из этой области. Сделать так, чтобы не тормозила физика уровня Нойты/Мимокрафта/Факторио — прямо вот «моё-родное», в приборостроении часто нужно сделать так, чтобы виртуальная физика не отставала от реальной :-D
Тут одна статья была, которая меня прямо до потолка заставила подпрыгнуть, я в ней увидел возможность мимокрафтовскую физику на шейдеры перевести. Попробую найти. Я вообще к кубическим движкам неравнодушен :-D пытался даже на шейдерах написать софтовый рендерер, оптимизированный под взгляд а-ля Вольф3Д, то есть строго горизонтально. И за счёт этого поднять на порядок скорость по сравнению с обычным разбиением кубов на полигоны и скармливанием оных видеокарте. А вертикальный прицел реализовать просто смещением «крестика» до достижения края экрана (а потом тупо поменять оси координат и точно так же рендерить строго вниз или строго вверх, только потом пост-процессингом придётся весь кадр повернуть, как в «Дюке», когда он голову наклонял, это быстро).
Нашёл! Правда, редактирование уже всё :( Добавлю самоответом.
https://habr.com/ru/articles/721314/
Главное — удобный (для дизайнеров) редактор таких правил сделать. Потому что для движка это просто супер — правила спокойно конвертируются в GLSL, он при старте компилируется и дальше простые шейдеры, без всяких этих ваших питорчей, на любом видеокарто-подобном девайсе (идеально — встроенном, пока дискретный перемалывает графоний) фигачит физику со скоростью, достойной не Мимокрафта, но Нойты.
Не жестче работы на заводе. Как раз тут недавно "Приходите к нам на завод, у нас тяжело". Там еще турникеты, непрерывность производства и особая дружеская атмосфера.
Вообще популярная нынче тема зазывать в кочегарку! К чему бы это?
Любопытная статья. Не могу согласиться с автором во всем. Сам уже больше 10 лет в геймдеве.
Зарплаты - да средние по рынку, но найти компанию с достойной оплатой в целом реально. Хотя золотых гор вы тут не получите в найме.
Да и если попробуете найти инвесторов и организовать свой проект/студию - статистика не на вашей стороне. Очень много проектов закрывается не окупив себя. Особенно последний год. Хотя редко - но может выстрелить очень громко (тот же Minecraft)
Кранчи тоже ситуативно - в некоторых компаниях их прям любят, в некоторых нет.
По поводу влияния на дизайн - у меня прям противоположный опыт, программисты всегда участвуют в процессе разработки самой игры, помогают геймдизам, вносят свои решения. Да, финальное слово обычно за продюсером. Но на моем опыте, очень часто хорошие идеи по гейм.дизайну приносили именно программисты.
Gamedev-мир отстает от "большого IT" - вот тут я бы вообще поспорил. Много гейм.девных решений было бы неплохо затащить в "большой IT". Тот же Data oriented design. А то что тащат сейчас в гейм.дев из энтерпрайса - лучше бы не тащили. За те же модные DI в Unity нужно по рукам бить.
Маленький уютный мирок - вот тут полностью согласен. Компаний не так много, а геймдев в России, по понятным причинам, умер. Так что нужно быть готовым к релокации.
Обыкновенная ситуация, когда программист в принципе ни с кем не обсуждает кроме лида свою фичу по несколько недель, а потом выкатывает в репо сотню-другую комитов, нанося добро всем подряд и блокируя работу студии, хорошо если на пару дней, пока все баги не выловят в аврале.
Вот тут - зависит от культуры в компании. На свои проектах в текущей компании вводил практики дизайн-ревью (https://youtu.be/4Y0XJXRZv6k https://youtu.be/IDj3x__YZgE)
и обсуждений задач в Slack/на созвонах. И есть культура и инструменты шаринга знаний между разными проектами...
За те же модные DI в Unity нужно по рукам бить.
По рукам нужно бить тех, кто заставляет мододелов использовать Harmony.
тот же Minecraft
Так он же инди изначально. Это потом уже майки их скупили и допиливают.
Data oriented design
Его-то не весь геймдев/движкостроители используют, а там где он хорошо вписывается он уже и так есть.
геймдев в России, по понятным причинам, умер
В который раз, конечно, хоронят. Он скорее затаился, нежели умер совсем. Тут и внутренняя кухня немножко подрастёт, и платформы подтянутся и игры глядишь к мирным временам появятся неплохого качества. Я бы назвал это "затаился".
Что они там допиливают? Одного моба в год выпускают, моддерское комьюнити делает куда больше для майна, чем майки
(смеется). На моей памяти игровую индустрию хоронили так часто, что сначала это было предсказанием, затем инфо-поводом, теперь это всего лишь повод улыбнуться. Нельзя убить деятельных и интересующихся, нельзя задушить молодежь, которая в данный момент активно обучается этим дисциплинам. Геймдев, в очередной раз, поставили на колени. Но, справедливости ради, он давно уже стоит на них. Периодически приподнимаясь в человекоподобное состояние со времён "американского ипотечного кризиса", который в нашу историю вошел как кризис 2008 года. Периодически игры делают. К сожалению не так активно, как хотелось бы. Довольно бюджетно, а хотелось бы большего. Но похоронные процессии... уже кажутся смешными.
Вопрос о жизни российского геймдева накрепко завязан на вопрос "Когда компания, принадлежащая гражданам Израиля но зарегистрированная на Кипре нанимает на удалёнку молодёжь из Тамбова - это российский геймдев или нет?"
Мисс вселенная из Тамбова не станет менее русской из-за получения титула в штатах. Имена в титрах тоже не поменяются
Ну тогда он никогда и не помирал. Имён с окончаниями на -ов и -ко в титрах всегда полно было.
Правда, тогда Гугл - тоже российская компания получается...
А если так: "Когда компания, принадлежащая гражданам Израиля но зарегистрированная на Кипре нанимает на удалёнку молодёжь из Тамбова, Исламабада и Бангалора - это российский геймдев или нет?" :)
Конечно российский. Россия там, где говорят по русски:))
Хотя конечно грустно все это.
Год назад прицеливался устроится на работу в какую-нибудь русскоговорящую команду на Кипре, но не хватало скиллов. Сейчас полез смотреть, а поезд ушел, теперь везде англ от B2 требуют. Видать набрали интернациональные команды. Теперь надо подтягивать разговорный англ.
Я как раз из тех кто ненавидит все эти лишние митинги и "дизайн ревью". Мы просто общались с тим-лидом и это прямо ну то что я люблю. Зачем блин это выносить на всеобщее обозрение.
- мимо социопат программист, ненавижу вас :)
Ну тут нет серебряной пули, процессы подбираются под команду а не наоборот :)
Я не сторонник процессов ради процессов. Если у вас слаженная команда и для выполнения задач хватает лишь общений программист-тимлид, то пускай так и работает :) Главное в конечном итоге готовый рабочий продукт, а не способ которым вы его сделали.
Доверять писать код дизайнерам, тем более бизнесс-логику - это безумие. Cкрипты давно устарели.
Дизайнеры даже теперь диздоки не пишут - ибо бесполезно, результат все равно непредсказуем.
Обычно сначала разрабатывается технология, делается прототип, вычисляются сроки. Показываем множество вариантов, они уже по ним разрабатывают оптимальное решение. Поэтапно изменяя прототип по фидбеку по каждой детали.
Потом дается прототип с множеством параметров, чтобы провести точную настройку. У всех дизайнеров супер-способность крутить "крутилки", не понимая их функцию, получая красоту.
А от том как работает вся игра никто не знает, кроме QA.
Но это все касается исключительно разработки. На производстве и поддержке никто вам не даст время на ресерч. Там свои особенности и инструменты.
В сейчас точно про геймдев отвечали?
Ну что же Вы так дизайнеров обидели, они то и делают игру. Несколько дизайнеров, с кем я работал, знают сопромат и вышку лучше меня. Задача команды направить полет мысли и помочь сделать правильно.
Делают галоши на заводе. Игры разрабатывает команда разработчиков, включая офис-менеджеров.
Сопромат никак не поможет программированию. От дизайнера требуется формальная логика, которую только программист сможет перевести в строгую логику, учитывая все варианты и тех. ограничения.
Технические ограничения первичны дизайна.
Я как раз начинаю работать в одном проекте где DI используется в Unity, хотелось бы послушать критику.
Есть Modules которые зависят от других Module (настраивается с помощью атрибута). Module это субсистема, например, отвечающая за Input.
У Module есть Init метод до вызова которого все запрошенные Dependency будут переданы через специальный объект.
Работает через Reflection, ищя все Modules на сцене. Если что то не удаётся инициализировать - посылает Exception. Круговые зависимости запрещены (тоже Exception).
Прицнипальная идея: заставить делать так, чтобы модули низкого уровня зависли от модулей высокого уровня без круговых зависимостей (в, инспектор можно добавить A->B, B->A, что может запутать код). Гарантирует порядок инициации (сперва инициирует модули верхнего уровня, которые не зависят от никого) +:бонусом Unit тесты проще: легко мокировать Dependency.
Был бы благодарен если подскажите за что тут нужно по рукам бить.
Все в целом сводится к фразе автора:
Но попробуйте уместить всю вашу логику в 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 и т.п....
Выделение памяти отдельный разговор, от этого тоже стараются избавляться всеми доступными способами. Особенно от кратковременных которые больше всего фрагментируют память, есть наброски на статью с бенчами, надо собраться и дописать
Во первых рефлексия это всегда оверхеад как по памяти (аллокации) так и по лишним операциям на цпу.
Так при загрузке же. Нет, понятное дело что загрузки тоже нужно оптимизировать, но они всё же не настолько критичны как метод Update.
Но допустим вы решили написать свои DI и заморочились и оптимизировали эти вещи. Остается на мой взгляд основная концептуальная проблема: когда я как программист хочу создать некий IObject - я никогда не знаю, насколько больше поддерево объектов породит мне DI. И какие именно реализации забинденны к интерфейсам.
И не должны знать.
В итоге создание с первого взгляда безобидного объекта в памяти могло породить очень большее количество аллокаций.
Во-первых, нет смысла считать аллокации для сервисов. Их просто не должно быть так же много, как и игровых объектов.
Во-вторых, вы точно читали тот комментарий на который отвечали? Там же все объекты уже на сцене, дополнительных аллокаций нет.
Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт.
С первой строки видно адекватного и честного человека. А то начитаются вот такого: https://ericlippert.com/2015/04/27/wizards-and-warriors-part-one/ (всемирно знаменитый разработчик, между прочим) и думают потом, что программист действительно программирует поведение магов и воинов. Нет, блин. Он парсит джейсончик со свойствами, сделанный в редакторе настоящими креаторами.
Но ведь программисты реально делают игры. В том смысле, что они делают кубики, из которых потом дизайнер сделает игру :)
Так можно сказать, что те, кто делает C++ тоже пишут игры в том смысле, что они делают кубики из которых потом делают игры :)
От дизайна игры зависит. Если в игре маги и воины настолько разные классы что у них даже наборы свойств разные - то программисту придётся их программировать.
Если в игре маги и воины настолько разные классы
В статье Липперта эта разница чётко сформулирована:
A warrior can only use a sword.
A wizard can only use a staff.
Последний раз я видел, чтобы подобную разницу прописывали в коде, а не в дата-файле, в досовских играх, в виде таблиц на #define'ах, и тогда это делали не от хорошей жизни.
А что именно вы будете прописывать в дата-файле, если у вас в игре у мага свои механики, завязанные на характеристики посоха, а у воина - свои, завязанные на характеристики меча?
Ещё раз цитата:
A warrior can only use a sword.
A wizard can only use a staff.
В дата-файле это прописывается в виде списка id в поле AllowedCharacterClass в таблице оружия или, наоборот, AllowedWeapon в таблице персонажей. (На практике, в играх типа HoMM или DMoMM, условия сложнее и привязаны к скиллам, т.е. их правильно было бы записывать не в виде id, а в виде evaluated expression predicate, но какова задача — таково и решение). Если программист прописывает эти зависимости в виде кода, в разговоре со мной ему бы лучше иметь для этого очень хорошее объяснение (например, повышение fps).
(Объяснение Эрика Липперта, что это лишь учебный пример, а в учебных целях можно обсуждать ООП на заведомо неправильно спроектированном движке — это очень плохое объяснение, как по мне).
Ещё раз: добавляем сюда уникальные механики классов - и списков AllowedCharacterClass/AllowedWeapon начинает резко не хватать.
В самом общем виде мой посыл таков: хороший программист (необязательно игровой) всё, что только можно, выносит из кода в дата-файлы/ресурсы/конфиги, чтобы затем можно было вносить изменения в конкретные сценарии 1) без пересборки, 2) не имея квалификации разбираться в исходниках. Естественным следствием будет то, о чём пишет автор:
Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт.
В оригинальном примере Липперта совершенно очевидно, что на уровне кода не должно быть никаких магов и мечей. С гипотетическим примером с «уникальными механиками классов» надо разбираться конкретно (что это за механики, как их описать декларативно и т.п.), но ответ всё равно скорее всего будет в области DSL (типа Lua), а не в проектировании иерархии классов на том же уровне, что и движок.
В самом общем виде мой посыл таков: хороший программист (необязательно игровой) всё, что только можно, выносит из кода в дата-файлы/ресурсы/конфиги
Зачем? Это типичный оверинжениринг.
Если это специально не оговорено, то такие финты у нас не проходят ревью и откатываются. Почему? Потому что это приводит к усложнению кодовой базы там, где это не требуется.
Если каждый раз, когда дизайнер захочет проверить, не изменится ли игровой баланс к лучшему, если разрешить Некроманту Сандро владеть Посохом Тьмы, надо будет писать тикет в Джиру программисту, чтобы он внёс соответствующее изменение, а затем ждать перевыкатки, далеко с таким процессом вы не уедете.
Это не только игр касается, вообще-то. Например, я работал в компании, писавшей управляющую программу для промышленного оборудования. Для управления отдельными компонентами этого оборудования программисты быстренько накидали DSL, чтобы на площадках конечных юзеров можно было что-то оперативно подправить (тайминги, хотя бы), и это могли сделать внедренцы. А потом у них случился переворот, типа как сейчас в OpenAI, все поувольнялись, и продукт попал в руки карьеристов и жителей солнечной Индии, которые тут же начали хардкодить поддержку всего и вся в C++. А потом туда устроился я (как всегда, к шапочному разбору). Ну вот, глядя в код, я прямо без гита, одним только мысленным взором, видел границу геологических слоёв, когда всё пошло по звезде, и стало нельзя ни у юзеров что-то поотлаживать, ни срочный патч выслать, заведомо не ломающий другие части программы.
И кстати, код при таком подходе становится проще для понимания, а не наоборот. Я читал сначала скрипты для старых железяк вида Move(150); Sleep(100); Rotate(pi);, а потом — то же самое, но на C++ для новых железяк, и имел возможность сравнить.
Ну вот в вашем случае это должно быть специально оговорено. Не было? Тогда какие претензии к южным программистам?
А почему тогда это не надо было обговаривать с теми, первыми программистами, которые сочинили DSL, а потом уволились в ходе корпоративного переворота? Почему они сами догадались, что задействовать DSL — хорошее решение? Потому что у программистов есть класс. Не тот, который тип данных, а тот, который позволяет подумать пять минут и представить, каково будет поддерживать кодом зоопарк ситуаций (в данном случае — зоопарк железа, но и к зоопарку магов и воинов с их мечами и посохами это тоже относится).
Потому что вы рассматриваете только положительные аспекты.
Но ситуация может быть и такой: программисты придумали свой DSL и теперь мы имеем усложнение там, где его никто не просил. Код работает медленнее, изменения нужно вносить в разные подсистемы, нужно учить людей этому dsl.
Это да. Когда игровая логика максимально вынесена в абы как написанные абы кем скрипты, это например сразу бьёт по тем местам, где надо просчитать множество вариантов для принятия оптимального решения (например, игровой AI). В шутерах это, может быть и не столь важно, не знаю, но в пошаговых стратегиях, где AI должен просчитывать, какие объекты на карте и в каком порядке он должен посетить, или какое заклинание в данный момент выгоднее применить во время боя, должен ли юнит атаковать (и как именно), или отступить, или прикрыть другого дружественного юнита, или, может быть, блокировать вражеского, чем быстрее все это просчитывается, тем более продвинутую/изощренную логику ты можешь себе позволить.
Преимущества конфигурабельности кода во много раз превышают оверхед от использования одной дополнительной папки / репозитория
С этим никто не спорит. Речь про то, что это нельзя отдавать на откуп разаработчикам. В надежде, что все будет зашибись.
Это должно быть прописано в требованиях к коду, к функционалу. Покрыто тестами и т.д.
Если не прописали. То опять мой вопрос - какие претензии к новым разработчикам которые пришли на проект и сделали решение по другому?
А механики нельзя прописать как отдельные "сущности"? И потом точно так же связать с классами и/или оружием через AllowedCharacterClass/AllowedWeapon?
Ну то есть берём механику "Fireball" и разрешаем её только магам или только при наличии посоха? Заодно получаем возможность просто добавить эту механику условному новому классу "'Witcher" или новому оружию "Magic book".
"Fireball" - это заклинание, а не механика. А вот если урон этого Fireball зависит от характеристик мага и посоха в его руках, причём ни те, ни другие даже не существуют у воина и его меча - это и есть уникальная механика магов.
"Fireball" - это заклинание, а не механика.
А какая принципиальная разница? Это только пример.
вот если урон этого Fireball зависит от характеристик мага и посоха в его руках, причём ни те, ни другие даже не существуют у воина и его меча - это и есть уникальная механика магов.
Делаем стандартные "SDCIWC" атрибуты общие для всех. Или "конвертируем" разные атрибуты разных классов в какой-то общий для подсчёта таких вещей.
То есть вполне себе решаемые детали. Можете посмотреть как это например сделано во всяких D&Dшных "конструкторах" с их мешаниной классов, субклассов и допклассов. Или других подобных настолок.
Причём там это хорошо работает даже на бумаге и без всякого программирования.
Если брать готовую ролевую систему, то да, надо делать атрибуты общими и всё. Но если делать свою систему - может просто не хватить времени на то, чтобы свести всё к одному набору атрибутов.
Ну во первых если у вас не хватает времени или умения нормально продумать такую "базу", то на мой взгляд у вас вряд ли получится годная игра.
А во вторых такое решается банальной конвертацией в "общий атрибут". Ну то есть у воина "strength", у мага "intellect", у вора "dexterity". Но для расчёта урона и прочего все они могут конвертироваться в какой-нибудь power. Как самый простой вариант 1 к 1.
Можно сложнее с какими-то коэффициентами для разных заклинаний/механик. Например для того самого "Fireball" можно сделать так что "strength" конвертируется 2 к 1, а "intellect" 1 к 1.
И мы всё ещё можем прописать такие вещи куда-то в табличку и нам не надо их хардкодить.
Иногда лучше захардкодить, чем конвертировать в общий атрибут.
Если в игре вдруг появится третий, смешанный, класс - лучше сразу увидеть все проблемы с механиками, чем двадцать патчей вылавливать всякую ерунду вроде влияния остроты меча на урон огненного шара.
Иногда лучше захардкодить, чем конвертировать в общий атрибут.
Ну да. Когда не планируется ничего менять или добавлять :)
Если в игре вдруг появится третий, смешанный, класс
То он элементарно добавляется через таблички без всяких изменений в коде. И "играть" с этим классом проверяя как его лучше сделать дизайнеры могут элементарно без того чтобы что-то менять в коде и возможно ещё и ломать другие классы.
Когда не планируется ничего
менятьили добавлять :)
Именно так! Когда в текущей версии не планируется добавлять смешанный класс.
Статическая типизация - она вообще, по сути, вся про то чего код не делает.
Именно так! Когда в текущей версии не планируется добавлять смешанный класс.
Ага. А когда в новой версии его всё-таки решат добавят, то мы всё перепишем заново? Или ещё лучше скопипастим куски от двух разных классов и сделаем смешанный? :)
Новая версия будет новой версией.
Разумеется, надо думать хотя бы на шаг вперёд, и если в будущем планируется смешанный класс - неплохо было бы заранее подумать как вообще представлять его механики.
Но если геймдизайнер заверяет, что смешанного класса не будет никогда, а следующий на очереди - вообще лучник с луком, то почему программисту вообще нужно думать об этом самом смешанном классе мага-мечника?
Новая версия будет новой версией.
Не ну конечно бывают игры, которые сразу делаются так как изначально задумывались и потом никак не развиваются. Но не сказал бы что есть много примеров хороших игр такого типа. Особенно если мы говорим о играх с механиками вроде тех что мы обсуждаем.
Но если геймдизайнер заверяет, что смешанного класса не будет никогда,
То не надо ему верить :)
то почему программисту вообще нужно думать об этом самом смешанном классе мага-мечника?
Банально потому что есть вариант, который позволяет избежать таких проблем в будущем и переложить кучу вещей с программиста на самих дизайнеров. И есть вариант, который этого всего не позволяет.
И нет особого смысла использовать второй вариант. Ну за исключением ситуаций когда игру действительно не планируется как-то особо развивать и менять.
ждите тогда лучей добра, и багу в jira от дизов, которым придется костылить такой хардкод. Бага на программера, уже не проблема дизайнера
Вы вряд ли услышите такие слова как FrameWork, boost, std::map, std::thread.
А вот это интересно. Если говорить про фреймворки то ладно. Но стандартные библиотеки языка C++ их ведь утверждает целый комитет по стандартизации. И при всем при этом к ним нет доверия у разработчиков игр.
Возможно, это к данному случаю отношения не имеет, но как-то читал в каментах, как один человек рассказывал, что они в своей компании берут исходники контейнеров из STL, выкидывают всю универсальную обвеску, "причесывают" под свои особенности, и в результате то, что получается, и компилируется, и работает быстрее. В статье упомянута EASTL - вроде как, в ней есть более быстрые контейнеры, заточенные под gamedev. В конце статьи сказано, для чего это всё:
попробуйте уместить всю вашу логику в 15мс, с обработкой четырехсот NPC на уровне, физики, музыки, рендером на экран без просадок фпс.
Но стандартные библиотеки языка C++ их ведь утверждает целый комитет по стандартизации.
Функционал который входит а стандартные библиотеки (любого языка) - это результат компромисса между:
Скоростью
Универсиализацией
И потреблению памяти
Поэтому ничего удивительного нет в том, что существуют более быстрые сторонние решения или те, что используют меньше памяти.
Ещё тянется Легаси от прошлых решений, который признаёт и сам комитет, но избавится от них не может. Я всё ещё помню тот трепет от введения концептов в язык и "легализации" библиотеки range.
Складывается ощущения что все эти решения рождались в муках, ибо те же контейнеры недостаточно структурированы, а сделать свой собственный linked list уже не кажется велосипедостроениеи.
А как же "Ты не платишь за то, что не используешь"?
>> И при всем при этом к ним нет доверия у разработчиков игр.
Причём тут доверие? Имея несколько платформ, важно однообразное поведение среди всего этого зоопарка. Сейчас остался один Clang на x86/ARM на всех платформах и можно даже использовать обычный stl, но ещё недавно было нельзя. Было месиво mscv/gcc/clang/snc/intel на x86/arm/xenos/cell.
Поэтому использовали eastl как единую реализацию для всех платформ.
Я программист и делаю игры. Геймдев - он разный. Большой корпоративный коммерческий - да, конечно, роли сильно другие, но дело же не в геймдеве как таковом. В любой корпоративной разработке любой отдельно взятый рядовой работник, включая разработку и менеджмент, не делает продукт, а делает какую-то мельчайшую часть, которая не факт, что вообще попадёт в проект.
Другое дело, что можно переформулировать это так: в играх не важен код. Да, это факт, игра - это не код. Можно полностью заменить код, его могут сделать другие люди, а конкретная игра останется конкретной игрой.
"Фу игра не оптимизирована" это хейтеры про что и к кому обращаются?
Я с подобными вопросами не сталкивался, а опыту близких людей, имеющих дело с подобной публикой - нет никакого резона искать здравый смысл в словах хейтеров. Они и до идеального столба докопаются.
"попиксельная симуляция мира алгоритмически довольно сложна и требует большой вычислительной мощности, мы не можем вам дать игру которая бы работала на atom z3735f в 60фпс с размером карты 16К*16К, пожалуйста поймите нас"
ЗЫ, большая часть игр будет выдавать млрд ФПС даже на самопальной виртуальной машине, проблема больше в системе рендера. Любую игру можно ускорить в 2 раза если просто добавить LODы (2D игры умеют тормозить?)
Ну-ну, добавьте-ка LODы в Factorio, чтобы сборка K2+SE не тормозила...
Разве что в шутере, на симуляцию игрового мира лоды не влияют.
Млрд ФПС? Не помню, чтобы видел хотя бы четырехзначное число ФПС даже на программках тупо отрисовывающих один треугольник. Не поделитесь ссылкой на такой бенчмарк, мне правда интересно?
Про тормозящее 2д, тут на самом деле все очень просто. Недавно игрался с юнити, делал простенькую сцену, типа 3в-ряд или пятнашек, Первое решение в лоб - каждая клетка была цветным пикселем PNG-файла, и представляла собой префаб с одним коллайдером2д, спрайтом и дочерним объектом, выводящим текст (просто циферку). Когда поле было маленькое, 16х16 - никаких проблем, значение фпс прыгало от 300 до 500 в 1080p, но стоило для теста изменить на картинку 100х100 - как фпс упал до неиграбельных 10-15. Хотя казалось бы, на экране не происходит вообще ничего, просто выводится сетка из 10к префабов с цифрами.
Чтоб было понятно мою точку зрения... Я помешанный кресто-бог. Твою 3 в ряд я написал бы на голом С++ OpenGL и радовался стабильным 1000фпс. В моём понимании, 2D может лагать только если на экране огромное колличество объектов, там даже никакие батчи тебе не помогут. В остальном всё упирается в логику. Тот же факторио считает перемещение тысяч объектов на карте, что уже накладно по процессору.
А с 3D проще, ибо туда можно накрутить текстур по хуже, модели по уже, рендер на 0.75 со сглаживанием, всяких "генераторов травы" и вот мыльная мега детальная картинка в 200фпс готова. Всякие potatomod оптимизации Dark Souls3 которые на встройке HD4000 запускаются, как бы намекают что это работает.
У вас просто не было ни разу опыта разработки и нет ни одного пет-проекта. Вы бы так не рассуждали.
плюсы точно не для написания логики в играх
А можно пару слов, почему? Какая разница, на чем писать логику?
Логику пишет дизайнер, для него разница принципиальная: попробовал, поправил, щёлкнул пальцами, и логика должна поменяться. И никаких этих ваших часовых компиляций.
Присоединяюсь. Кроме быстроты применения для дизайнера еще и понятность кода критична - это должен быть простой язык, а не такой где только описание стандарта такого объема что им убить можно.
Какие языки для логики используют? Таблица параметров в json?
Насколько слышал, Lua популярна в таких задачах.
Кроме таблицы параметров нужно еще кучу всяких условий задавать и проверять: есть ли нужный предмет, достаточен ли уровень навыка и т.п. - все это и описывает логику игры и по разному может реализовываться в разных квестах, так что вынести это все в один конфиг не всегда оправдано.
Вплоть до визуального программирования на блюпринтах.
Lua, Python. Раньше Java иногда вкручивали, сейчас вряд ли.
Но главное - максимальная формализация правил и описание их в формате данных, так что да: JSON, YAML.
Логику можно вынести в отдельный модуль, который быстро компилируется. Ну, впрочем, мысль понятна, спасибо.
Используют "быстрые интерпретаторы" lua, js или пишут свои языки quirrel, tjs, dascript
Как же раньше всякие Doom 1/2 писали? Тоже вся логика в скриптах была?
игры проще были, но вообще да, писали свои vm и языки сценариев, скриптов. Просто это не было массово, как сейчас
Какая логика? Если подобрал предмет то открыть дверь? Так вроде это просто конфигом к уровню задавалось. Большая часть фич была вшита в движок а ты только описывал карту уровня.
Какой-нибудь Майнкрафт первых версий тоже был везде прибит гвоздями, то потом научились нормально скрипты с ресурсами тащить.
Приемлемую "расширяемую" не вшитую в код логику Кармак сделал только в "великом и ужасном" QuakeC из одноименного первого Quake.
Часовые перекомпиляции — признак неверной организации проекта.
Есть разные программисты, и есть разные дизайнеры и артисты. И там и там, есть те, условно, кого можно легко уволить и взять любого из толпы. Не в плане их качества а в в плане их роли. И если проект сложный, то и код сложный. Настолько, что уволив программиста который за него отвечает, новый, придет со своим монстром, и по сути будет писать нового моснтра. И это превратится в неподдерживаемый код. Еще в сложных проектах, все может быть настолько сложно, что дизайнерам приходится консультировать с программистами, что можно, а что нельзя сделать. И, коственно, программисты влияют на дизайн игры, а значит ее делают )
Я вообще не знаю мест, где можно без проблем протащить инструменты для статического анализа, возможно это обронка, может места где такие решения принимает кто то из бывших разрабов.
В любой ИБ конторе. Есть требования регулятора по статическому анализу, так что он там точно будет. И скорее всего даже не один, а штуки 3.
В обороне никакого статического анализа кода не делают. Личный опыт 3 года.
И зря, это ведь не игрушки. Так было и 15 лет назад когда там работал. Стабильность блин
Если у тебя ultimate garbage collection, то на многое можно забить. Это как админские скрипты - делают ровно то что надо сделать без заморочек и надежды на то, что кто-то станет это читать.
любой взрослый энтерпрайз, код прост обязан быть обвешан стайлкопами, сонарами и линтерами.
А в чем именно проблемы? Ну да, поначалу выдача SASTа разрабов не порадует. Но его несложно настроить. Как и несложно составить план по фиксу ишью.
Ставьте splint из cygwin. Бесплатный статический анализатор.
Croteam тоже перешли на Unreal.
Если честно, не увидел причин не идти в геймдев, если смотреть на него без розовых очков.
Во-первых, это всё-таки работа, а на работе нужно работать, а не чилить. И также для дизайнера, продюсера, арта и т. д. - для них это такая же работа, как и для программиста.
И если вдруг программист шёл делать игру: код писать, музыку писать, рисовать, продумывать сюжет, логику и т. д. - это же всё-таки инди-геймдев, но тоже геймдев.
Если программисты - мизантропы, социофобы, асоциальные личности без софт скиллов - они на своём месте и они никогда не справятся с тем, чтобы написать музыку, что-то нарисовать, придумать хайповую игру. Также и люди искусства никогда не напишут мега-оптимизированный код, который сэкономит памяти, и они не смогут написать свой движок.
Тоже самое про лида - это программист без социофобии и с прокачанными софт скиллами, поэтому они и стали лидами, потому что это им в кайф, и они снова же на своём месте.
В общем, лид и нужен для того, чтобы направлять творческую энергию художников и техническую энергию программистов в то, что будет выглядеть, как годная, оптимизированая и окупаемая игра.
Без одного типа человека - всё развалится: без лида - никто их не организует, без художника - никто не сделает яркую и привлекательную игру, без программиста - никто не напишет качественный оптимизированный код.
Вопрос, скорее в том, чтобы каждый человек понимал, что ему больше всего подходит в геймдеве и выбрал то, что ему по силам и будет его драйвить.
Спасибо за статью)
В целом, ничем не отличается от обычной работы программиста.
Мне больше интересно, как попасть в геймдев? Сколько лет рассылаю резюме по игровым студиям, но всегда получаю тишину, либо типовой отказ.
Есть завершенные проекты? Напишите в пм плиз или в телегу
Я написал логическую игру" быки и Коровы" в виде консольного приложения на Windows.
Есть ли шанс устроиться в gamedev?
Если вы её "продадите" в кампанию, то может быть.
По опыту, есть два пути: сложный и простой.
Сложный - написать любую законченную игру в которую хоть кто-то играет, даже 5 человек.
Простой - по рекомендации. Причём попасть можно прям сразу на высокую позицию. Я в жизни ни строчки кода не написал для игр, но по рекомендации прошёл собес в довольно крупную геймдев компанию, получил оффер на senior позицию, но и по деньгам не сошлись, да и передумал я там работать после более детального изучения игры, на которую меня брали.
Мне больше интересно, как попасть в геймдев?
Я попал через стандартное собеседование. То есть можно это сделать через стандартные пути. Но есть нюансы, которые зависят от конкретной компании. Я статью писал об этом (на правах наглости). В ней я описываю несколько собеседований. Если есть вопросы, тегай здесь, могу помочь, подсказать
Сори за дилетантский вопрос: я правильно понял, "дизайнеры" - это не про художников? Они код пишут и еще чего-то делают.... Можете объяснить плиз
Да, level designer, ai designer, sound designer, env designer и ещё немного других, в общем называют gamedsigner или Диз/des
Тут автор сократил.
Обычно их зовут гейм-дизайнерами. Это те, кто отвечает за суть игры, за геймплей, за баланс. Они в свою очередь могут подразделяться далее (на тех, кто отвечает за уровни, за баланс, за сценарий, за монетизацию, и за кучу других вещей). Вообще, их правильно переводить "проектировщики игр". Но почему-то их так никто не называет. Они не пишут код, зато каждая цифра в характеристиках, каждое умение, каждый враг, каждый квест на их совести.
А есть ещё просто дизайнеры (по буржуйски "артисты"). Это те, кто создаёт визуал: рисует, делает 3д-модели и т.п.
Кстати, и дизайнеры, и гейм-дизайнеры получают зп намного ниже. Ибо конкуренция намного выше. Туда идут все, кто хочет делать игры, но не умеет программировать.
у них тоже свой рынок, который сильно разбавлен gamekiddis - людьми, которые набрали ассетов со стора, кинули туда пару блупринтов и пробуют это продать игрокам, а себя назвать дизайнерами. Не скажу, что сильно меньше. Kiddis да, пятачок за пучок (извините), но этот джуны, которые вырастут, если вырастут, и станут потом будущим индустрии
ааа, гейм-дизайнеры. все, теперь все понятно
По поводу "если увольняется арт-директор..." вспоминается история с третьей "Готикой": её показывали на куче выставок, вот-вот должен был быть релиз... А потом у разработчиков как-то резко всё стухло, релиз перенесли то ли на год, то ли на два, выкатили малоиграбельное забагованное нечто... А титры после прохождения игры начинались со слов соболезнования по поводу смерти как раз арт-директора...
Благодарю вас за прекрасную статью, полную интересной информации.
C git'ом кстати тоже есть проблема, он хорошо подходит для сорцов, а вот что делать с гигабайтными текстурами или файлами модели по 100мб, или луашником/json'ом уровня размером под 20-30 мб текста? Тут либо держишь 2 cvs - одну для сорцов, вторую для контента, либо пишешь своё решение.
Большие файлы стало можно использовать после появления Git LFS.
А проблему взаимодействия Git с не-программистами мы решали реализацией Subversion API поверх Git-репозитория: https://habr.com/ru/companies/vk/articles/241095/
Когда ассеты начинают становиться гигантскими, когда все вот эти 4к текстуры с десятками слоёв для PBR и финальными паками по дцать гигов как у того же Bioshock или каких-нибудь современных MW, то хранить их в той же репе с кодом крайне неудобно. Обычно их суют параллельно в альтернативные системы контроля для ресурсов - какой-нибудь Preforce и его альтернативы или даже SVN, вместо git.
"Если у вас получилось тут поработать, в других местах будет чего-то не хватать."
Чего, например?
Фидбека от игроков, рокстара за соседним столом, который пилил Ил2-штурмовик в 2007, дизов с их безумными идеями, игровых движков bleeding edge tech, пьянки в ночь релиза, первых патчей, оптимизаций на асме... еще что-то забыл?
игровых движков bleeding edge tech
Скорее bleeding memory и бесчисленное количество часов на отладку, возможно в нерабочее время. Это другая сторона медали.
О да, пришёл в игрострой примерно в 2015 - очень рад, что успел совместно поработать с людьми, которые пилили Корсаров (в том числе мою любимую вторую часть), и послушать всяких баек и инсайдов обо всех любимых игровых студиях. Да и со статьёй в целом согласен, правда знаю девушек, которые достаточно долго в геймдеве именно на позиции программистов.
Если так не хватает юнит-тестов, фрэймворков, совещаний и посиделок с коллегами то что вы делаете в геймдеве? В геймдев и идут как раз те, кому надо чтоб интровертно аутировать и чтоб быстро работало.
Не надо очернять нишу просто потому-что она вам не подходит. Многим другим не подходит корпо-среда, и для них геймдев отличное место.
у меня наоборот работа в геймдев студии была гораздо более социальной, чем в большом софте. Если почитать "Повелители Doom" - вот примерно такая же атмосфера. Могли пол дня просто играть во что-то, а вторую половину разбирали механики и смотрели арт.
Игру-то выпустили?
Студия студии рознь. Мне удавалось побывать и в коллективах увлечённых делом людей без лозунгов, и в конторах где главенствовал лозунг "мы дружная семья профессионалов", но на деле это место оказывалось джунглями с двуногими акулами, где был дресс-код, где приходилось говорить то, что было надо говорить, а не то что было бы хорошо для проекта, и где приходилось соблюдать крайне странные правила.
Этим я хочу сказать, что конторы, как и люди все очень, и очень... разные. Есть и корпоративно-ориентированные, а есть очень милые и уютные кораблики, в теле которых очень приятно плыть. Одной из таких контор, вероятно, была Troika Games, о которой её создатели вспомнитают исключительно тепло. Правда творческий гений и добрая атмосфера плохо укладываются в концепцию продуктивного и успешного бизнеса, на мой взгляд.
но ниже чем в WEB(е)
Ой, да ладно :)
Привет.
Можно ли благополучно работать программистом в gamedev, если не играешь в компьютерные игры?
думаю что нет, вы как минимум будете треть времени тратить на проверку фичей, если это не доставляет удовольствия, будут только мучения. Ну и смотря какие игры конечно, мне не нравятся сегодняшние игры на мобилках, в них я почти не играю, за исключением игр от Kairosoft (но эти скорее исключение)
думаю нужно было играть в них в прошлом и все еще любить игры, тогда да
да. Например toolset развивать. Или просто узкоспециализированным специалистом - программировать физический движок, базовые библиотеки пилить или спецэффектами заниматься.
Можно. Я почти 10 лет геймдеве (пусть и не ААА) и примерно столько же ни во что почти не играю. На мне это сработало как с колбасой - когда знаешь как делают, сам есть уже не можешь. Очень на многих работает наоборот - так что предугадать сложно.
можно, играть перестал как пришёл в геймдев. Почти 12 лет, полёт нормальный. Тут и вырос, и интересы поменялись на более жизненные, но и играть уже не интересно когда понимаешь как игра монетизируется, как удерживается внимание, как вешается крючок чтобы ты завтра зашёл и т.п.
Спасибо Вам за ваш текст про будни в GameDev. Как по мне это похоже на настоящее программирование.
Вот бы еще почитать тексты на темы оставшихся областей программирования
1--"Вы точно хотите пойти программистом в Web Back-End?"
2--"Вы мечтаете пойти программистом в Web Front-End?"
3--"Вы хотите стать программистом приложений под Android/iOS?"
4--"Что? Вы хотите стать прикладным программистом под DeskTop?"
5--"Неужели Вы хотите быть системным программистом ядра Linux?"
6--"Мечтаете стать системным программистом для видеокарт GPU?"
7--"И Вы тоже хотите быть DataSience инженером?"
8--"Точно хотите разрабатывать компиляторы и IDE?"
9--"Я так понял, Вы хотите стать программистом под FPGA?"
и что там еще осталось?...
Эмбед ещё. Обидно, однако!
@SparkLoneнапишешь про будни энтерпрайза?
Эмбед ещё. Обидно, однако!
А про Embedded программирование как раз таки есть аналогичный текст.
Называется
Вы в Самом Деле Хотите Стать Программистом Микроконтроллеров?
https://habr.com/ru/articles/668368/
Когда я поздно вечером после 23:00 прихожу домой с работы программистом микроконтроллеров я обнаруживаю дома как мой брат играет в видеоигры на DeskTop PC. Что-то типа GTA-5, Crisis, и поговаривает:
Вот этих программистов я уважаю! Отличную компьютерную программу написали... Сразу видно, отлично поработали парни!
Потом он поворачивает голову в мою сторону и говорит
А то, что ты там программируешь в своей северной промзоне 10й год по 3й форме допуска, я не знаю?...
Вот программисты игр и являются True Программистами, а ты (программист MCU) вообще не пойми кто!
какая то обида в коменте, ну так не ходите туда, вокруг достаточно других позиций, не обязательно gamedev. Ну и насчет северной промзоны, поверьте я знаю что такое и третья и вторая и первая формы (https://habr.com/ru/articles/751706/), и в embeded разработке поварился достаточно. Да только на седьмой год понял, что на 300баксов зп либо семья либо ипотека и ушел.
Кто мешает программистам микроконтроллеров программировать игры?
Разработку авиасимуляторов для Миг(ов) с Су(шек) и танковых тренажеров для военных НИИ можно причислить к GameDev разработке?
Как по мне GameDev это яркий пример как люди буквально на пустом месте создают компании и продукт.
Напишите что-н про метрики из разработки GameDev.
Сколько строк кода в игре?
Сколько времени собирается *.exe файл с релизом игры из готовых исходников?
Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт
Действительно огорчили. Раньше игры делали именно программисты, и они были интересными. А теперь мудовая зачистка двухста двадцати восьми аванпостов в НУ ОЧЕНЬ КРАСИВОМ мире.
Если покупают зачистку в красивом мире эти игры будут делать, но ведь можно покупать вот такие, и тогда их тоже будут делать чаще. Игра к сожалению не окупилась.
Это ошибка выжившего. То что покупают зачистку карты совсем не значит что покупать красивые, интересные и сложные игры не будут или что такие игры не будут иметь огромный успех превышающий аванпосты.
Мне кажется это просто сложно, сложно делать нормальные игры, сложно искать людей кто будет делать нормально, сложно вообще понять что это такое, это ваше "интересное" и "нормальное". Вроде бы очевидно что у этого декаданса что у этого декаданса скудно с интерфейсами и графикой, но как это выразить в вещественной форме? Сложно. И на эту сложность никто не хочет тратить деньги. Аванпосты-то покупают, зачем делать лучше и заморачиваться, поскачем же вместе в продакшн!
Точно не окупилась? А на что тогда Colony Ship сделали?.. Да, разработчик говорит, что от продаж последней зависит их дальнейшая судьба и это может стать их последней игрой, но думал, что Age of Decadence продалась не так плохо. Конечно, по меркам такого инди проекта. Вообще читал множество интервью с Винсом и у меня сложилось впечатление, что он как раз не разработчик. Но могу и ошибаться: на их форум всего пару раз заглядывал и особо не вникал сколько у них человек сейчас и кто чем занимается.
Если что, Age of Decadence покупал до релиза, после - нескольким знакомым в подарок. И Colony Ship три раза купил. И даже Dungeon Rats куплена.
steamdb говорит (https://steamdb.info/app/230070/charts/) 33к фоловеров - это кто купил + вишлисты (Винс пишет, что разработку продажи окупили), 15 на старте, 10 средняя цена - 30% коммиссия ~ 10 * 30k = 300k - 100k стиму = 200к на 4года разработки ~ 4k в месяц, Винс денег не брал, получается 1.5к в месяц каждому из участников. С натяжкой получается, что вытянули, да.
да, я сам их поддержал себе взял, и друзьям раздарил штук десять
Истории и игровые механики придумывают тоже не программисты. И раньше в общем-то не они этим занимались. Просто раньше эти вещи лучше удавалось совмещать и одновременно быть и программистом и дизайнером.
Раньше у программистов просто не было выбора. Они учились всему, методом проб и ошибок. Это если углубляться в далекие дали и посетить на машине времени зарю игростроения, то можно увидеть множество любопытных свершений. Улететь в эпоху "игр в шароварах" (shareware games) и даже ранее. Тогда и и толковый программист, и толковый художник были чем-то особенным. Ведь даже один человек мог сделать коммерчески успешную игру, чьё визуальное сопровождение могло не выходит за четыре цвета. Художник, к несчастью, этого сделать - не мог. Это мог сделать - только программист.
И ещё долгое время программисту приходилось соединять в себе одном - кучи специальностей. Но когда игры стали расти, стали расти и конторы, и началось последующее разделение на специализации. Технологии позволяли использовать сканированный и обработанный затем арт, появились и другие пути создания графики. И постепенно это направление унаследовали те кому и положено этим заниматься.
Поэтому я бы сказал, что не "удавалось совмещать и одновременно быть и программистом и дизайнером", НО... приходилось совмещать и одновременно быть.
Раньше у программистов просто не было выбора.
Или у дизайнеров игр :)
Художник, к несчастью, этого сделать - не мог.
Художник и дизайнер игр это даже близко не одно и тоже.
Это мог сделать - только программист.
Написать тот же тетрис(то есть именно сам код игры) и тогда и сейчас могла куча людей. Это вообще не сложно с точки зрения программирования.
А вот придумать тетрис как игру...
Во взгляде из сегодняшнего дня всё слегка перевернулось с ног на голову. Это сейчас кто-то как-то может сначала стать программистом, а потом захотеть делать игры. В прошлом порядок был обратным - захотел делать игры, стал и программистом, и художником, и дизайнером, и всеми остальными. И тебе 14 лет.
А вот поддержу. Если хочу поиграть, играю в HoMM3, MOO2, такие штуки. В качестве хобби пилю свободный движок для HoMM2. Автор статьи к слову пилит свободный движок для Фараона. А современный геймдев производит одноразовые игры, еле ворочающиеся на современном железе. Может, они и красивые, но играть в них больше одного раза не хочется.
Ничего, рисующие и музыкальные нейросети скоро снова дадут делать весь арт программисту. Уже есть примеры простеньких игр, полностью созданных с помощью нейросетей.
Ещё бы кто-нибудь написал как в тестирование игр попасть... :)
Везде нужен человек с уже опытом, а стартовых вакансий просто нет, либо они в духе - работы за опыт, и грамоту в рамке (которую к тому же самому купить надо)
хм похоже вы не там ищите, с грамотами точно. «I have nothing to offer but blood, toil, tears and sweat.», первый год действительно придется просить ниже рынка, если глаза горят и очень хочется в gamedev и именно на qa. Потом освоитесь обучитесь и выйдете на среднюю зп. Но вроде так везде, gamedev - it, здесь не показатель вообще. А Вы не ищите по вакансиям, пишите туда куда хотите устроиться, на почту HR или info, на форуме разработчиков
Спасибо, было интересно.
В Рик и Морти передана вся парадигма юнити) (буэээ ассетами и модулями - и ты программист с дизайнером).
Сейчас делают что на движке HGE?
Спасибо автору за статью. Сам читаю хабр и это та статья которую не стыдно кинуть в Закладки и позже перечитать еще раз.
На данный момент я ещё студент, учусь на разработчика, и в свое время, как и любой маленький мальчик(девочка) переигравший в Ведьмака или ГТА 5 мечтал по ночам о том, как я буду делать в будущем такие эпохальные игры.
Время шло, я становился старше, и с каждый годом приходило понимание, что АйТишечка не такая уж радужная в целом - не у всех получается научиться программировать и не всех потом берут на работу по итогу. Что уж говорить про геймдев.
В какой-то степени даже профессионально завидую иногда таким как вы, дай мне выбор - пытаться дальше попасть на смузи-галеру или в геймдев со всеми его минусами, я как зелёный студентик без опыта выбрал бы геймдев, и уже потом, спустя годик если было совсем тяжело, уже только тогда начал бы искать работу в "большом" АйТи. Но, видимо это то что и отличает меня ещё зелёного от таких как вы - возможность выбирать куда двигать свою карьеру являясь уже хорошим специалистом.
Извиняйте за словесный понос.
Если реально хотите попасть в айти, вам нужно срочно перестать читать Двач.
Скорее думать, что игрострой это розовые поля с зелёными единорогами, как и везде это тонны кода и ночи отладки. Тогда и ожидания меньше разойдутся с реальностью
А вы мой комментарий читали? Где там я говорил что автор не прав, а геймдев это миллионы в наносекунду и смузихлебство? Была описана ситуация детства, когда ты играл в игру и проникался ей настолько, что мечтал о том как в будущем сделаешь нечто подобное.
Хотя, смысл объяснять, вон, на мой комментарий уже -1 влепили, даже не написав что не так с ним, а я ведь просто написал свою мысль об этом)
Хабр нынче стал каким-то пассивно агрессивным - очень часто пишешь комментарий и на него сразу прилетает -1, неважно какой тематики комментарий - ругаешь автора или хвалишь, или вообще высказываешь свое видение данной ситуации - будь готов к инстант минусу "просто потому что"
конечно читал, не имел ввиду конкретно Вас, извините если как-то обидел словами. Но через одного вижу это на собесах, и именно так как вы описали - про смузи и быстрый бакс. А через полгода ребята сдуваются, когда приходит реальная нагрузка. А минусы, ну минусы - люди разные, у них есть свое мнение, не хуже, не лучше, просто другое. Оно будет ответом на ваш комент, иногда минусом
Что это?
Ладно код некачественный, графика некачественная, анимация некачественная, саунд дизайн некачественный, но хотя бы сюжет можно не самим писать, а попросить профессионального писателя? Ну невыносимо просто всё унылое, кажется, что игры под Android просто пишут люди, которые искренне их ненавидят. От всего веет дешевизной, экономией, ориентацией на казуалов и детей.
Если программист именно хочет заниматься программированием, то идти работать в гейм-дев компанию, мне кажется, было бы неплохим решением. Плохим решением было бы идти на вольные хлеба в соло-инди-дев. У меня есть небольшой опыт подобного, по факту получилось что именно программирования (создания С# скриптов для юнити) оказалось дай бог если 5% от всей работы. Остальное время заняло: проектирование, создание сцен в редакторе, рисование графики и арта, поиск всевозможных звуков и музыки (поиск бесплтаного, покупка недорогого или создание с нуля в редакторах музыки), локализация, тестирование и отладка. На закуску: издательство и маркетинг. В момент когда к тебе приходит идея и ты тестируешь какую-то интересную геймплейную фичу, ты в этот момент даже не задумываешься, сколько времени может уйти просто на то чтобы настроить и оформить свою страницу на каком-нибудь маркетплейсе, типа стима и внедрить их оверлей в свою игру с ачивками и прочими плюшками (программирования там опять же по минимуму, все уже написано для вас, в основном это конфигурирование сборок).
Простой вывод из ситуации - «Хочешь программировать в gamedev — не иди в компанию, где используют готовые игровые движки». Суть готовых игровых движков именно в том, чтобы не тратить время и ресурсы на программирование. А наличие инструментов визуального программирования в ряде современных игровых движков ещё больше сокращает необходимость в программировании
Мой комментарий не столько про готовые или собственные движки, сколько про разделение задач и ответственности. В соло или маленькой команде скорее всего придется заниматься многими вещами далекими от разработки как таковой, в большой компании (даже использующей готовый движок) могут просто посадить за узкую задачу, типа отдельный редактор квестов или игровой карты, при этом ни байта твоего кода по сути в самой игре и не будет. Будешь ли ты при этом счастлив или нет - вопрос который каждый должен задать себе сам, прежде чем идти в геймдев.
Прочитал с интересом. Спасибо за статью!
Спасибо автор =)
Только так сейчас везде, не только в gamedev
Открываю свой код:
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Как здесь сделать смайлик "ёкарный стыд"? :)
Я умею чертить 3d детали в программе moi 3d есть ли шанс пристроиться в gamedev?
Люди всегда нужны, не уверен правда что вы будете чертить детали конечно ;)
На 7м-10м году санкций и Эмбарго, российским программистам микроконтроллеров по любому придётся переучиватся в чертёжники. Западные микроконтроллеры закончатся на российских неотапливаемых складах.
Вычислительные машины будут снова проектироваться шестерёночно- кулачковыми.
Нас тут снова ждёт паровой век! Аж дух захватывает.
В GameDev в каких программах обычно чертят 3D персонажей, монстров, дома, машинки, самолеты, корабли, оружие и пр?
Я хочу разработать на Windows программу симулятор графического монохромного дисплея. Разрешение 64x128. Fps 5Hz.
Код писать на Си. Какой мне выбрать игровой движок?
а вам точно нужен Игровой движок для этого?
Я пробовал в python на канве отрисовать. Получился Fps 0.1 hz. В 50раз медленнее чем требуется.
Значит, либо что-то сильно не так делали, либо проблема в Питоне.
О какой канве речь? Надеюсь, вы не путались отрисовать по точкам картинку на Canvas из tkinter? Там векторная графика, а вам явно нужна растровая.
Вот код
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()
Ну да, симуляция растровой графики через векторную. Вы рисуете символы прямоугольниками, а потом Tk рисует ваши прямоугольники пикселями. Чтобы это заработало с нормальным FPS, надо одно из двух.
Либо вы остаётесь в векторном мире, тогда вместо рисования прямоугольниками надо сделать растровый шрифт в виде картинки, и рисовать на канве куски этой картинки.
Либо же надо положить на канву BitmapImage, и рисовать свои пиксели строго на нём.
Я пробовал синтезировать экраны на Graphviz, однако FPS получился 0,3 Hz
Симулятор Графического Монохромного Дисплея на Graphviz
https://habr.com/ru/articles/753890/
Удивительно емкая статья, которая собрала все проблемы геймдева и очень точно описала происходящее в нем.
Закрытость, отсутствие общих решений, деградация процессов разработки, отсталые системы контроля версий...а потом я удивляюсь, почему уже двадцатый год в Total War поиск пути отрядов никак не эволюционирует и живет с старыми багами.
За описание про разницу подходов между инди-разработчиками и крупными компаниями, которые с друг другом не могут найти общий язык - отдельный лайк :) Очень точное описание опыта взаимодействия..
Надеюсь, хотя бы со временем индустрия станет более открытой и перестанет бояться перекатываться на новые стандарты разработки.
Привет, я тоже выходец из геймедева
Про этот пункт не соглашусь
>C git'ом, кстати, тоже есть проблема, он хорошо подходит для сорцов, а вот что делать с гигабайтными текстурами или файлами модели по 100мб, или луашником/json'ом уровня размером под 20–30 мб текста? Тут либо держишь 2 cvs — одну для сорцов, вторую для контента, либо пишешь своё решение.
Давно придумали:
1) Git LFS
2) Perforce (он же p4) - используется в крупных студиях, мелкие инди про него как правило не слышали
3) Инструменты для монорепозиториев так же подходят
Какие компиляторы и системы сборки используются в GameDev(е)?
Какой путь проходит *.cpp файл с момента написания до того как он отработает на мониторе в видео игре?
ответ "весь зоопарк" Вас устроит?
есть такое понятие как матрица компиляции, у каждого проекта она своя
gcc, msvc, clang, nx-clang, sce-clang иногда intelовский компилятор, старые и новые версии компиляторов и тулчейнов, что называется compilable is reliable
у дагора например система сборки jam
https://github.com/GaijinEntertainment/DagorEngine
у Arkane - msvc/clang и система сборки plumb самописная
у ЕA - scons и тоже зоопарк тулчейнов, еще и версированый, т.е. каждый билд собирается под разными версиями тулченов, занимаются этим обычно build инженеры
Раньше хотел в геймдев, сейчас работаю в команде над CAD, в геймдев уже не хочу, все устраивает. Зп в геймдеве ниже. Да и для устройства там уже надо иметь 3-5 лет опыта в геймдеве.
Видно, что автор работает по большей части в энтерпрайз командах и над бэкендом/кор-функционалом (поправь, если не так). Всегда есть рынок инди (по сути все, что не трипл эй и энтерпрайз мобилки) и геймплей программисты, которые не лезут в легаси движков, а занимаются именно что геймплеем, несколько более интересными задачами с точки зрения дизайна игры, чем решением проблем производительности. Тем более, когда для этого уже существуют готовые анрил/юнити-решения, в дебри которых без особой нужды тебе лезть не придется. НО про сниженные зарплаты, некую общую отсталость технологий от финтеха - все правда, зато чувствуешь, что занимаешься творчеством и вносишь вклад в общее дело, а не прикручиваешь очередной микросервис для очередной банковской системы.
Что такое ассеты в контексте gamedev?
Что такое "плойка" в контексте gamedev?
Компьютерные игры это безусловно высокотехнологичный наукоемкий продукт, великолепная бизнес модель, большое сообщество увлеченных разработкой этого людей и не самые низкие по программистским меркам зарплаты (если сравнивать c embedded конечно же).
Однако люди тысячи и тысячи лет как-то жили без компьютерных игр (может в настолки играли).
А когда видеоигры появились, то много людей стали наркоманами компьютерных игр.
По эволюционным меркам иммунитет от чрезмерного Gaming(а) не выработался.
У меня был одноклассник, который не смог поступить в институт потому что слишком много играл в видео-игры.
Я и сам чуть по подсел на эту иглу, однако меня спасло то, что мой Desktop просто раньше перестал запускать новые игры из- за высоких системных требований к железу.
В ВУЗе был однокурсник, который не смог сдать сессию и был отчислен так как весь семестр проиграл в видеоигры. Говорили "загамился".
Слышал даже истории как браки распадались так как муж играл в видеоигры вместо работы.
В связи с этим, разрабатывать видеоигры это серьёзная этическая дилемма для тех кто их разрабатывает. Это как производство табака или психотропных веществ.
Как разработчики из GameDev разрешают это противоречие, чтобы найти силы этим заниматься?
Эммм... нет, игры это искусство, наряду с книгами, кино, музыкой. Они могут быть не только развлекательными, но и передавать истории, учить новым навыкам, вызывать эмоции и быть средой для самовыражения. Почему же вы умолчали о порно, игровых автоматах (гемблинге) и азартных играх, соцсетях, алкоголе, и даже работе (трудоголизм?), и все этого намного старше компьютерных игр. Темные стороны можно найти в любой вещи, игры здесь не причем. Никакой дилеммы тут нет, делать закладки и доставлять еду по сути одно и тоже, довези товар из пункта А в пункт Б и оставь у двери, первое карается даже просто для курьеров, второе лицензируется властями.
Играйте в HOI4, Crusaders4, Stellaris, AOE, Fallout, не играйте во всякий треш.
Если ты попал к хорошему лиду, который знает свою область движка, будь готов плакать ночами над комитами, которые вернули в десятый раз.
Как Вы в GameDev(е) делаете инспекцию программ (code review)?
Вы используете сервер Gerrit?
Упомянули линейную алгебру.
Какие ещё математические разделы используются при разработке ПО в GameDev?
Может численные методы и дифференциальные уравнения для расчета физики применяются? Тригонометрия, мат-статистика, DSP(ЦОС), конечные автоматы, кватернионы, нейронные сети?
но в игрострое как был дефицит около 70к людей на всех позициях от программеров до арта, так и остался.
70к вакансий это много.
Наверное развитие GameDev(а) стимулируют искусственно компании-разработчики компьютерного железа: материнские платы, видеокарты, процессоры, памяти, мониторы и прочее.
Кому еще нужны мощные компьютеры как не gamer(ам)?
Новые игры сподвигают людей покупать себе новые DeskTop(ы).
GameDev нужен для увеличения спроса на вычислительную технику.
да вроде нет, продажи игровых компов и ноутов составляют меньше 10% от всех продаж железа, даже у майнеров больше сегмент рынка, основную долю продаж железа обеспечивают копрорации, наука и военка. Если бы игроки стремились за новыми компами это было бы офигенно, потому что по факту разработчики ориентируются на текущие возможности консолей, это топовый пк +- 5летней давности.
Новые игры сподвигают людей покупать себе новые DeskTop(ы).
Уже давно не так. Бум майнеров очень сильно ужал рынок. С точки зрения денег может быть цифры выросли (за счёт того, что цены на комплектующие выросли), но с точки зрения количества единиц, увы, нет. То есть количество игроков, готовых обновлять ПК в погоне за играми, сильно сократилось. И игровые компании это понимают, повышая стоимость игр, деля игры на части, вводя лутбоксы, и прочее. А параллельно существуют рынок консолей, рынок мобилок, которые тоже забирают игроков из области ПК, так как тупо дешевле
Отчасти это вина многократно ускорившегося пайплайна разработки и мощных движков к
Что такое пайплайн (pipeline) в контексте разработки программ?
Никогда не встречал такого термина в программировании микроконтроллеров.
менеджер памяти вообще самописный по принципу memory arena, ...
Что значит memory arena?
Memory arena\Segregate storage - это один из широко известных принципов управления памятью, в этом случае выделяется один большой блок памяти фиксированного размера кратный размеру элемента помноженному на степень двойки, используется для выделения памяти для объектов. Такой подход позволяет эффективно управлять памятью, уменьшая фрагментацию и повышая производительность за счёт уменьшения накладных расходов на управление. Обычно количество юнитов\монстров\нпс не превышает 32\64\128\xxx, поэтому нет необходимости динамически выделять её в процессе игры, на старте уровня выделяется нужный объем в котором потом выполняются все операции
Вы точно хотите пойти программистом в gamedev?