Dmitry Yanovsky

Именно :) Переименовать entity/component/system в record/table/query и готово.

Да все как ты сам говорил - сильно зависит от конкретной ситуации :) В моей команде обалденная атмосфера и условия, людей очень ценят и всячески помогают становится еще лучше (как профессионально так и личностно). Но разумеется я тоже слышал кучу страшилок про потогонки и кранчи в Rockstar, сам за пять лет пока не сталкивался. По деньгам все отлично, бонусы как и много где ежегодные. После релиза обычно на несколько лет все становится прям очень хорошо :) Из-за этого базовые ЗП могут быть чуть ниже средне-рыночных, но это больше зависит от твоего таланта торговаться и пользы, которую приносишь :)

Рекомендовать однозначно могу, даже за те пять лет, что я тут, очень много поменялось внутри компании в лучшую сторону. И пока не видно никаких причин этому вектору меняться.

Благодарю, взаимно! :)

Работаю в Rockstar North, пилю движок потихоньку.

В целом после брексита для имигрантов "на визе" почти ничего не поменялось, а вот у европейцев куча головной боли появилось. В Шотландии конечно сразу начались разговоры "а давайте мы тоже станем независимыми", возможно будет очередной референдум, но хочется верить, что опыт брексита показал насколько это не классная идея и сколько несет проблем. :) 

Более долгосрочные последствия станут понятны позднее мне кажется.

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

Я пять лет живу в Эдинбурге, это Шотландия. То, о чем ты пишешь скорее относится именно к Англичанам. Те действительно могут смотреть на окружающих сквозь призму своего величия :) Но как и везде наверное это сильно зависит от круга общения. Бюрократия (по слухам) есть, но я лично с ней сильно не сталкивался. Социалка для иммигранта никакая, ведь "ты даже не гражданин", зато медицина "бесплатная". Правда, как и много где в Европе, нужно пробиваться через терапевтов, чтобы попасть к "настоящему" врачу и чтобы тебя нормально осмотрели. В 90% случае терапевт уделит тебе 10 минут, посоветует пить витаминки и не нервничать. Частная медицина есть, но сильно дорогая. Очень помогает страховка, если компания ее предоставляет, особенно на зубы. Поставить коронку за 600 фунтов - обычная история.

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

Из минусов - безумные цены на жилье, "скучный" (спокойный и размеренный) образ жизни (если речь не про Лондон) и налоги, налоги, налоги :)

Если кому-то интересно, как обстоят дела в Великобритании, тоже готов ответить на вопросы :) 

Никаких проблем! :)

Подозреваю, мы знакомы? :) Нет, стараюсь так больше не кранчить.

Вы меня явно с кем-то спутали :)

По статистике 93% чисел в статистике взяты с потолка. Можете называть это принципом Парето (80/20), как угодно. Вся тема о том, что игры стали весить непростительно много. Вы сейчас рассуждаете так, будто эта проблема только может появится, если разработчики начнут использовать подобный подход. По-моему причинно-следственная связь слегка нарушилась. Да, игрокам это не нравится, об этом и речь в этой статье. Но я позволю себе сказать (о чем возможно пожалею), что быстрая и плавная игра важнее, чем занятое место на жестком диске. Это просто еще один компромисс и каждый разработчик сам решает, как ему поступать.

Вся разработка игр - это по сути бесконечный поиск компромиссов. Оптимизация, не имеющая минусов, это невероятно редкий зверь в нашем деле. Если какое-то решение работает в 90% случаев хорошо, а в 10% случаев не очень (но работает), то это замечательно.

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

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

Да, все так. Чуть выше я ответил человеку про фрагментацию, если интересно.

Здорово, что вы упомянули фрагментацию. Все действительно так, как вы говорите - если диск сильно фрагментирован, то при запросе на запись большого файла на диск могут произойти несколько вещей - если ОС не сможет выделить линейный блок достаточного размера для записи этого файла из-за сильной фрагментации, то она может (в зависимости от поддержки "рассеянных" (sparse) файлов): разбить файл на части и записать куда получится; провести on-the-fly дефрагментацию небольшого участка; отказать в записи вовсе. На современных ОС дефрагментация обычно выполняется в фоновом режиме, поэтому пользователь с такимим проблемами скорее всего не столкнется и файл запишется как и предполагалось в линейный буфер. Как видите даже такое маленькое отступление увеличило комментарий в несколько раз. Плюс мы начали говорить о платформо-зависимых вещах и здесь сразу всплывает миллион деталей. В сети есть тысячи статей на эту тему, необязательно верить какому-то парню в комментариях (мне), можно всегда пойти и самому поискать ответы на свои вопросы.

Вы возможно удивитесь, но ОС не имеет цели вставлять вам палки в колеса и специально раскидывать данные по всему диску.

Михаил, в какие ваши игры можно поиграть? Особенно "оптимизированные под ПК" интересуют.

Михаил, почитайте, пожалуйста, про sequential и random access для жёстких дисков.

Я с этим и не спорил, Рамиль.

Как хорошо, что в вашем мире жесткие диски сделали такой большой шаг вперед со времен PS3. Жаль, нам так не повезло.

Ну если в ПК начали неожиданно ставить какие-то новые жесткие диски, то, наверное, не используются.

Недавно в Twitter'е был замечательный тред про "почему разработчики не хотят рассказывать игрокам и, в целом, людям со стороны о том, как делаются игры". Наша ситуация с вами отличный пример почему. Я вам сразу сказал, что подробный, предметный разговор на такую обширную тему в комментариях - пустое дело. Хотите обсудить мою некомпетентность - пишите лично, я с удовольствием поболтаю. Кидаться друг в друга видео и накатывать простыни в каждом комментарии я не хочу.

Вау. Окей, посыпаю голову пеплом, разоблачили.

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

Заботятся о нервах игроков, которые "обожают" минутные загрузки уровней и сохранений, а также периодические фризы и подгрузки пока они мчат на всех порах к очередному квесту на маунте. Смысл всего этого в том, чтобы увеличить производительность чтения данных с диска в память, а не в том, чтобы жесткий диск сберечь.

Если кому-то интересна техническая сторона вопроса, то во многом на размер игры влияет то, как происходит собственно сама упаковка ресурсов в подавляющем большинстве современных движков. В настоящее время почти все серьезные тайтлы в той или иной мере используют стриминг. Проще говоря игра никогда не загружает все файлы одновременно, только то, что необходимо на данном этапе. В качестве примера подойдет любая open-world игра - непосредственно в памяти сидит только то, что находится рядом с игроком в текущий момент. Очень маловероятно, что каждый участок такой игры неповторим и уникален, скорее всего так или иначе используется схожий набор исходных элементов. Опять же в качестве примера возьмем какого-нибудь базового персонажа-врага. Он использует какие-то текстуры, какой-то меш, звуки возможно. Эти враги присутствуют почти на каждом участке общей карты. Казалось бы, первое что приходит в голову - хранить текстуры отдельно, звук отдельно, меши отдельно и т.д. Всего нужно по одному экземпляру, все логично разделено по типу, класс! Только вот, к сожалению, мы все еще ограничены по скорости загрузки данных жесткими дисками, которые не сильно чтобы выросли в этом плане за последнее время (SSD не в счет, пока их не начнут использовать на консолях, скорее всего ситуация не изменится). Так вот если мы будем хранить данные как я описал выше, то чтобы загрузить очередной участок игры с этим врагом в худшем случае (если он не находится уже в памяти) нам нужно будет отдельно загрузить текстуру, отдельно загрузить меш, отдельно загрузить звук. Если это все хранится в разных местах, то это огромное количество перемещений головки жесткого диска, а это физический обьект и он подчиняется законам физики. Максимально быстрое чтение происходит когда головка движется и читает данные непрерывно, без смены направления. Если наши данные разбросаны по всему диску, то это невозможно. Соответсвенно чтобы удовлетворить запросы стриминга и обеспечить быструю загрузку-подгрузку ресурсов, их пакуют рядом, чтобы весь участок карты можно было загрузить за одну непрерывную операцию чтения (обычно в любой момент времени таких "участков" в памяти находится определенное количество). Это ведет к значительной дубликации данных - на каждом участке карты, где есть этот враг, будет копия ресурса содержащего все необходимые для него текстуры, меши, звуки и т.д. С SSD таких проблем нет, потому что никаких "головок чтения" в них не используется и читать данные можно с любого места без потери производительности. Разумеется, это все обьяснение "на пальцах" и в реальности все как обычно "немного" сложнее и детальнее, но в целом картина думаю ясна.

Хорошая статья, но чувствуется весьма сильный "перекос" в сторону гейм-дизайна, на мой взгляд. Знаю довольно много прекрасных программистов, которые давно уже "игры делают, а не играют", но при этом по-прежнему на гребне волны, так сказать, пишут потрясающий тек, на котором потом как раз и создают "те самые" игры. Да и художнику по большому счету необязательно проводить так уж много времени в игре, чтобы продолжать делать крутой арт. Да, это бесспорно полезно и желательно, но вычеркивать человека из индустрии за то, что он не играет по 18 часов в свою игру как-то через чур жестко на мой взгляд. К тому же многие просто предпочитают тратить это время на развитие своего непосредственного скилла - программирования, рисования и т.д. И надо признать, что да, для гейм-дизайнера игра в свой и сторонние проекты является неотъемлемой частью развития навыка.