Комментарии 36
Спасибо за статью!
Ура Гайдзинам!!!
когда объект (например стул) предоставлял подошедшему к нему симсу информацию, что на него можно сесть
зачем так делать? НПС является активным агентом, он должен анализировать, что можно делать с встретившимися предметами и нужно ли ему это. А уж как быстро получить список свойств объекта - это можно кучу реализаций придумать
Smart objects это стандартный подход при создании интерактивных сцен. Симсы тому пример, не везде он нужен и подходит, но это намного дешевле чем тащить отдельное поведение в нпс.
Хммм, на днях запилил похожее для своего велосипеда, каждый объект в состоянии взаимодействия с другим взаимодействующим объектом отсылает ему список доступных экшенов на выбор, ломать, юзать, экипировать или что там ещё... Даже не подозревал, что это может быть реализовано так, что тормоза будут не при взаимодействии с объектом (у меня там, признаться, дофига абстракций, которые, уверен, дают ощутимый оверхэд), а просто при заходе на уровень =\
При полном переборе, всех объектов и всех действий с ними, общее кол-во действий одинаково.
Стало быть оптимизация, может уменьшить нагрузку от самой обработки до нужной степени, но если нагрузка, даже гипотетически будет сопоставима с ограничениями, придется решать задачу ограничений.
Если не решать, то в такой ситуации стоит ждать проблем.
И ладно, если речь таки об игре, в эпоху раннего доступа, работает и ладно.
А если не игра, а скажем IoT, хотя-бы, вот вроде +- то же самое, куча объектов, некоторые из них и так приходится думать.
И то сколько и как им работать, определяется не только некой общей производительностью, но и рядом других параметров.
Какие-то суммарно окажутся тяжелы для "игрока", каким-то подавай энергосбережение, а может быть и так, что они канал могут занять(хоть радио, хоть сеть).
В таком случае, придется либо совмещать, поделив объекты на активные и пассивные, либо строить более сложную структуру их взаимодействия.
Впрочем, в играх, чаще можно обойтись строгой структурой и просто правилами, ограничивающими перебор.
del
Движок - это ход мыслей других людей и часто проще сделать самому для себя и для своего хода мыслей, чем изучать и привыкать к чьему-то. Как простой пример - я очень комфортно читаю синтаксис C# но просто не могу смотреть на python, тут нет объективности или разумности, просто вот так вот. Поэтому мне проще взять что-то из питона и переписать на C#, если конечно цель стоит таких усилий.
По личному опыту и опыту кучи знакомых людей - обычно всё разработкой движка в этом случае и заканчивается, а игры как не было, так и нет :-(
Оно так и есть. У меня та же история. В процессе написания своего движка я понимал некоторые вещи, которые я бы, как мне кажется, не понял, используя готовый движок. Так как в готовом движке уже написаны вещи, и переделывать их, или просто залезть в них, чтобы посмотреть как они работают нет смысла, или нет возможности, если движок закрытый. И игру я так и не создал, которую хотел реализовать на самописном движке
Именно так
Проблема в том, что тут обычно разработка игры и заканчивается.
Спасибо огромное, интересно,почитаю позже
выглядит как попытка затормозить конкурентов из числа новых прогеров которые вместо того чтоб взять готовый движок с известными граблями и способами из решения будут городить свой движок который будет хуже по всем параметрам и в процессе пиления команда развалится не успев собственно стать конкурентом автору. Обходится вниманием проблема онбординга новых спецов в команду когад есть свой движок
Из всей статья наиболее ценное это последний кусок с комментом ревьювера.
Почти все из топ лучших игр прошлых лет
Starfield
Не все согласятся)
Походу прочтения возник вопрос, офк прошу прощения за возможный оффтоп и затуп, связанный с отсутствием базы в мозгу, но разработка карточной игры(не ККИ, а скажем условный преферанс онлайн, лол) где станет проще и удобнее - юнити/анрил/годот/гейммейкер/etc или собственноручно написанный движок на условном шарпе или с++?
https://youtube.com/watch?v=7roOTdz5GyQ
В данном вопросе есть ещё один довольно важный аспект: найм новых сотрудников. Когда у вас своя сложная технология - движок целиком или какая-то крупная его часть (например, ИИ или физика) - вашим новым коллегам придётся потратить несколько месяцев только на то чтобы её изучить и войти в курс дела. И нужно будет приставить к новичку ментора-синьора, чтобы максимально ускорить этот процесс.
Кроме того, далеко не все кандидаты вообще захотят изучать in-house технологии, нужные только в одной конкретной компании. Большинство всё же предпочтёт распространённые Unity / UE, опыт на которых котируется больше. Чтобы компенсировать этот момент вам, возможно, придётся или предлагать более высокие зарплаты, или как-то иначе завлекать сотрудников.
А что если что ваш новый сотрудник уволится через полгода? Деньги на его обучение и время его ментора вы уже потратили, а ничего полезного для проекта он сделать не успел. Ещё и человека надо искать с нуля.
Ещё неприятный сайд эффект - джуны для вас становятся сильно дороже. Если инди-студия может взять студента с базовым знанием Юнити и он уже через месяц худо-бедно (зато недорого) будет приносить пользу, то порог вхождения в вашу технологию для него выше в разы, плюс время его ментора. И вот уже по стоимости джуны для вас приближаются к мидлам. Зато джуны хотя бы есть на рынке. Мидлов найти куда сложнее, а те что есть - не горят желанием к вам идти.
Это отчасти так, потому что u/u широко разрекламированы и там физически нужно больше спецов, но что в гайдзинах, что сейчас если претендентам давали выбор между unity/dagor/4aengine большинство, процентов 80, выбирало in-house движок. С джунами совсем раз наоборот, в силу известности игр многие на первом этапе готовы работать за идею, другой вопрос что отработав год и получив строчку в резюме они ждут нормальной зп (что не всегда оправдано по знаниям) или уходят в другие студии. С мидлами признаю - полный швах, но так везде, не только у нас. У соседней студии с анриалом под капотом, с мидлами ещё большая нехватка, тут не в движке проблема, а в сдвигах на рынке
Простите что влезу в диалог.
Когда у вас своя сложная технология - движок целиком или какая-то крупная его часть (например, ИИ или физика) - вашим новым коллегам придётся потратить несколько месяцев только на то чтобы её изучить и войти в курс дела. И нужно будет приставить к новичку ментора-синьора, чтобы максимально ускорить этот процесс.
Это должно быть включено в процесс. То есть обучение новых сотрудников внутренним технологиям должно быть частью онбординга. Это неизбежный этап при использовании внутренних технологий. И это, типа, норма.
Ещё неприятный сайд эффект - джуны для вас становятся сильно дороже.
Не всегда. Зависит от требований. Для Unity джун, как мне кажется (из опыта моих собеседований на вакансии Unity) - это такой человек-оркестр, который сам может замутить игру из готовых ассетов. А там знаний нужно очень много, и на получение этих знаний нужно много времени. Джун же для условного разработчика какого-то своего движка - это программист на том языке, на котором написан код движка, и знаток некоторых технологий, которые в движке используются (OpenGL к примеру). Область знаний несколько сужается. И в том и в другом случае онбординг будет не простым
Ещё у remedy крутой собственный движок. Хотя бы посмотреть на их последнюю игру - "Alan Wake 2". Моменты с переключением из игры в реальные сцены с актерами и обратно, неевклидовые пространства и ещё много прикольных моментов.
Мысль статьи идёт в рознь самому главному правилу разработки - бери готовое, если оно уже есть. А в чем же плох этот подход? Вы правда считаете, что используя готовые движки, вы НЕ можете НЕ залезать в ассетстор?
Более того, если автор разрабатывал движки, то понимает, что модельки, текстуры, эффекты, шейдеры - это все делается в независимости от движка. Пока движок позволяет писать шейдеры, залезать в рендер - ты можешь менять облик игры крайне сильно. Я не знаю как этот аргумент может прийти в голову.
Другой аргумент - это пример игр. Но извините, это исключительно игры ААА сегмента. Знаете в чем причины их популярности?) Как можно сравнивать компании с многомиллионными бюджетами, и, даже не инди, а просто компании среднего бюджета? Более того, оценивать игры по сомнительным топом - большая безвкусица. Самые оригинальные, игры с душой (а не для дохода) сделаны именно компаниями поменьше, в голову которых не придет идея делать свой движок, чтобы "не использовать ассетстор". Есть примеры, когда это необходимо, например - Factorio, Exanima, Frostpunk(хотя уверен, могли бы сделать почти тоже самое на Unreal). Но большинство игр можно сделать визуально оригинально в большинстве движков.
В статье есть вопрос на каком движке разрабатывается мобилка со скрина. Я даже когда-то работал с движком этой игры. И вся его суть - это независимость (то есть, опять, деньги) и оптимизация для мобилок. Оригинальностью тут и не пахнет, да и Господи, это же самая казуальная мобилка, а какой важности в истории игр можно говорить? Что вообще такого уникального можно сделать в 2д рендеринге? Можно поиграться со светом, да... Кто бы это делал... А, точно, делали наши ребята в игре Backbone... На Unreal!
Ну и самое главное, автором явно движет чувство "сделать свое, разобраться, сделать лучше". Я это чувство очень хорошо понимаю. Но, для всех начинающих разработчиков, если вами движет делать игры - делайте игры. Особенно, если вы начинаете, и вам кажется в движке не хватает функционала - это скорее всего не так. А если ваш проект слишком сложен - не стоит ли отточить свои навыки на других проектах, не требующих годы разработок движка? Готовые движки позволяют решать крайне много задач и есть на весь вкус и цвет, поэтому делать своё, на мой взгляд, должно быть крайне обдуманной идеей, и быть оправданной крайне редко.
Конкуренция в любом случае это хорошо, если человек делает новое в рамках любых технологий, а не просто берет готовое, смешивает и пытается срубить копеечку (извините если обижаю много инди-героев), это просто отлично. Но готовое, одинаковое и за "условный доллар" из ассетстора убивает хорошие игры кмк. Вообще повод написать эту заметку был вообще смешной, я играл в хогвардс и смотрю персонаж прыгает очень знакомо, также ногу подгибает, таже высота прыжка, теже стрейфы, полез смотреть туторы по анриалу - точно, стандартный контролер плеера. Блин думаю, не могли же разрабы игры за дцать лямов такое зашипать, обычно это первое что меняют в игре под свои нужды. Вообщем это меня расстроило, игра отличная если что, я не фанат Поттера, но играть было интересно. Похоже это просто профдеформация уже - выискивать стандартные элементы, прозрачные стены, нелогичное АИ и тд
Движок лочил старый вектор, выделял память для нового массива колбеков, копировал туда все + 1
Но ведь обычно вектор из стандатртной библиотеки выделяет текущий размер * 2 памяти
Вам [не] нужен свой игровой движок