Открыть меню

Тим Кейн о себе, игровой разработке, Fallout и Arcanum (страница 4)

  • Страница 4 из 4
  • «
  • 1
  • 2
  • 3
  • 4
Форум » Общеролевой раздел » Обсуждение статей » Тим Кейн о себе, игровой разработке, Fallout и Arcanum (Подборка информации с YouTube-канала Тимоти Кейна.)
Тим Кейн о себе, игровой разработке, Fallout и Arcanum
# 151 | | | 0

Оптимизация

  • Зачастую оптимизация — это поиск компромисса между скоростью и компактностью кода. Скорость определяется количеством затраченного на выполнение задачи процессорного времени, а компактность — количеством занимаемой памяти. «Быстрый» код нередко занимает больше памяти, а компактный — исполняется медленнее, однако в редких случаях удаётся и «ускорить» код, и сделать его компактнее.
  • Кейну часто приходится объяснять не особо разбирающемуся в программировании начальству, что не стоит начинать оптимизировать проект сразу после его начала — необходимо выждать время и посмотреть, на что уйдут основные ресурсы компьютера. Тим снова припомнил первую демоверсию Fallout и то, как медленно она работала — это абсолютно нормально, потому что любые внесённые на ранних стадиях разработки оптимизации могут впоследствии оказаться бесполезны, потому что появился новый код, новые функции, а часть старого убрали или переписали.
  • Хороший пример рассказанного выше — механизм прототипов в Arcanum, позволивший заметно сэкономить память, но немного сильнее загрузивший процессор. «Колоссальная экономия памяти» стоила дополнительных трат процессорного времени на извлечение необходимых данных.
  • 15–20 лет назад была в ходу оптимизация переписыванием с языка C++ на обычный C, который лучше оптимизировался компилятором. Иногда начинался настоящий хардкор: часто используемые участки кода на C частично переписывали на ассемблер.
  • Многие современные молодые неопытные программисты не умеют даже толком работать с компилятором. Если на выходе из компилятора появляются какие-то проблемы, они начинают наугад отключать флаги оптимизации, пока всё не заработает снова. Тим не любит, когда что-то делается без понимания происходящего. С другой стороны, Кейн признаёт, что зачастую так получается быстрее заставить работать код, нежели копаться вручную в ассемблере.
  • Когда только появились первые видеокарты, приходилось отдельно оптимизировать игру под каждую, ведь все они сильно отличались друг от друга. Зачастую дело касалось даже не оптимизации — сложно было написать код так, чтобы игра запускалась на любой видеокарте. Но и сейчас есть определённые нюансы с оптимизацией игр под консоли с разным аппаратным обеспечением.
  • Среди современных программистов бытует мнение, что оптимизация не важна, и хотя Тим понимает, откуда растут ноги этого убеждения, он с ним не совсем согласен. В современных играх он постоянно видит нерациональное использование процессора и памяти. Например, нередко значение переменной пересчитывается при каждом обращении к ней, даже если ничего не изменилось. Или создаётся огромный массив данных, из которого потом извлекается единственный элемент. Например, в одном из проектов Тима программист запросил перечень всех существ в игровой области, чтобы определить ближайшее к игроку, но всё ещё сложнее: вызывалась функция, которая собирала перечень всех объектов в игровой области, вычленяла из них существ и формировала массив, который сортировался, затем выбирался первый элемент, а все остальные отбрасывались. Тим заменил всё это технопорно на функцию, которая при перемещении существ вычисляла расстояние до персонажа игрока — так и определялось ближайшее к нему существо (при гибели которого функция перезапускалась).
  • Одна из самых распространённых операций — сортировка, но нет одного подходящего на все случаи жизни алгоритма. И хотя на небольших объёмах данных они действительно справляются с задачей примерно одинаково, на больших лучше подбирать подходящий под конкретные параметры.
  • Таким образом, оптимизацию откладывают на самый конец разработки, и предсказать необходимое на неё время довольно трудно («не уверен, что встречал хоть одного программиста, который мог бы предсказать время, необходимое для оптимизации кода — а о всяких продюсерах и говорить нечего»). Кроме того, трудно найти программиста, который умеет оптимизировать код. Нередко программисты просто наугад перебирают различные методы и алгоритмы, и наблюдают за изменением в потреблении ресурсов и скоростью выполнения кода.
  • Оптимизация — это задача не только программистов, но и художников с дизайнерами. Например, стоит поразмыслить, нужно ли в вашем проекте динамическое освещение, если в нём нет подвижных источников света. Если таковые всё же есть, стоит определиться с их максимумом.
Вверх Вниз
Группа: Factol
Регистрация: 2026-02-27
Репутация: 0
Сообщений: 60
# 152 | | | 0

Вопросы без однозначных ответов

  • Изометрия или вид от первого лица. Раньше у разработчиков не было особого выбора, и Fallout была изометрической не потому, что это был лучший вариант для этой игры — разработчики перепробовали несколько движков, и именно изометрический вариант выглядел лучше всех (хотя выбора, опять же, особо и не было). Игры от первого лица того времени были низкополигональными, да и разрешением текстур похвастаться не могли. Изометрия отлично подходит для тактической боёвки: игрок видит местность, врагов, может оценить различные факторы, управлять отрядом. С другой стороны, при игре единственным персонажем отлично раскрывается вид от первого лица. Он обеспечивает лучшее погружение: игрок видит происходящее словно своими глазами, может бродить по миру, заглядывать в различные закоулки, а разработчикам не приходится думать, что делать с мешающими обзору в изометрии крышами и стенами.
  • Сложные или простые игровые механики. Простые механики привлекают больше игроков: чем проще механики игры — тем она популярнее. Однако всегда можно воспользоваться правилом «легко освоить — трудно стать мастером», то есть на первых порах предложить простые механики, которые будут усложняться по мере прохождения. Это отчасти повторяет современный подход Тима к подаче информации об игровом мире: в прошлом разработчики любили навалить «лора», теперь же Тим старается не перегружать игрока сведениями, давая лишь самое необходимое, а дополнительное вынося в книги и второстепенных персонажей. Если при создании персонажа игрока завалить тоннами информации, он не поймёт, что важно, а что нет, ведь он ещё не играл. Один из способов избежать этой проблемы — дать пройти обучение и определиться с предпочтениями или для начала выбрать пол, внешность и имя, а остальное оставить на потом.
  • Определённость и неопределённость. Кейн предпочитает элемент случайности не только в боевых системах, но и в проверках навыков (взлом замков, обезвреживание ловушек, убеждение). Он прекрасно понимает, что современные игроки при таком подходе будут просто сохранять игру на каждом шагу и загружаться до победного. Поэтому для борьбы с этим применяются жёсткие проверки — например, когда убедить персонажа можно лишь с навыком 50 или выше, и никак иначе.
  • Работа в небольших или крупных студиях. «В маленькой команде ты знаешь всех, кто над чем работает, достоинства и недостатки каждого, и исходя из этого можно распределить работу». Разработка идёт быстрее, обратная связь появляется чаще, меньше бюрократии. Однако в небольших командах требуется доверять друг другу и полагаться на остальных. Тем не менее, большую современную игру с открытым миром, видом от первого лица и крутой графикой не сделать малыми силами, а там уже нужны различные продюсеры, координаторы отделов и так далее, что приводит к засилью политики и бюрократии, а значит и некоторым явлениям, не идущим на пользу проекту. Тим не умеет в политику, поэтому с опаской относится к крупным командам.
  • Балансировка универсальных и специализированных персонажей. В играх можно реализовать оба пути со своими достоинствами и недостатками. В своих первых играх Тим делал акцент на специализацию, но впоследствии осознал, что неплохо бы поддержать и персонажей-универсалов, что видно ещё на примере Arcanum. Универсальные персонажи дают игроку больше возможностей, но в среднем их навыки слабее, чем у специализированных. Поскольку по задумке разработчиков игра должна проходиться любым персонажем, проверки навыков на заданиях основного сюжета занижены. Напротив, специалист получает определённые преимущества, но некоторые сюжетные задания становятся существенно сложнее, ведь ему доступен лишь один вариант их выполнения, и он может быть не самым простым. Зато некоторые побочные задания могут оказаться проще, поскольку правило «Сила, скрытность, слово» (или «Убей, укради, уговори) на них не распространяется, и никто не ориентируется на персонажей с минимальными уровнями навыков. В The Outer Worlds самые крутые уровни навыков — это первый и последний. Таким образом, игра поощряет как универсалов, так и специалистов в своём деле.
Вверх Вниз
Группа: Factol
Регистрация: 2026-02-27
Репутация: 0
Сообщений: 60
# 153 | | | 139
Цитата zk2qX0S18z3ReibUszwh ()
С другой стороны, при игре единственным персонажем отлично раскрывается вид от первого лица.

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

Цитата zk2qX0S18z3ReibUszwh ()
разработчикам не приходится думать, что делать с мешающими обзору в изометрии крышами и стенами

Чего. Это ж в палеолите решалось ещё либо прозрачностью этих самых стен или крыш или банальной подсветкой контура персонажа.

Цитата zk2qX0S18z3ReibUszwh ()
игроки при таком подходе будут просто сохранять игру на каждом шагу и загружаться до победного

И эту проблему тоже уже решили - для контры сэйвскаму сэйв должен быть одним либо ручные сэйвы должны быть возможны в определенных местах, а не посередь плетня у взламываемого сундука (как, например, в Kingdom Come том же).

Цитата zk2qX0S18z3ReibUszwh ()
В The Outer Worlds самые крутые уровни навыков — это первый и последний. Таким образом, игра поощряет как универсалов, так и специалистов в своём деле.

Да нет, таким образом игра поощряет добавление метовых навыков на единичку во все билды, вот и всё. Да и уж TOW - не самый лучший пример разнообразия билдостроя, большинство билдов там строятся вокруг боевых: стрелок, рукопашник да криса (рукопашная или снайперская). Из "мирных" билдов там только условный "офицер", качающий утилити типа взлома и ремонта да болтологию.
Вверх Вниз
Кладбищенская шакалогиена
Группа: Namer
Регистрация: 2025-11-10
Репутация: 139
Сообщений: 490
# 154 | | | 98
Цитата Cringe ()

Да и от третьего неплохо раскрывается: во-первых, показывает самого персонажа и его экипировку,

Показывает задницу героя :D Что позволяет игроку фантазировать...
хех
Цитата Cringe ()
и его экипировку,

Если персонаж носит ножи/склянки на перевязи на груди - то при виде со спины будет не видно.
ДА можно вводить условности как в Дед Спейсе в виде интерфейса на спине. Но такие штуки нужно в мир вписывать.

Цитата Cringe ()
Когда я вижу FP в ролёвках - первое, о чём я думаю, что здесь авторы схалтурили и решили не париться с анимациями. И последние примеры с Абобой и Граалем тому прямое подтверждение.

Вот кстати не факт - противников все еще анимировать нужно :D

Я лично вида от 3го лица не очень люблю. Лучше или вид сверху или от 1го лица. Вид от 1го лица способствует погружению.
Вид от 3го лица - подойдет когда речь идет скажем о корабле - морском или космическом.
Цитата Cringe ()

И эту проблему тоже уже решили - для контры сэйвскаму сэйв должен быть одним либо ручные сэйвы должны быть возможны в определенных местах, а не посередь плетня у взламываемого сундука (как, например, в Kingdom Come том же).

Или сейвы должны усложнять игру :D Как сделали в Мор Утопии 2-3 Айс Пик лодж - где каждая загрузка "портит" мир, может пропасть часть снаряжения, инвентаря и даже сюженые НПС в мире. Причем в какой то момент можно снять органичение - но тогда нормальной концовки не видать.

Главная проблема ограничения на сейвы - что если твоя игра не будет работать стабильно? Игрок просто не будет перепроходить 5 часовые забеги, если каждый час есть 50% шанс вылета.
Цитата Cringe ()

Да нет, таким образом игра поощряет добавление метовых навыков на единичку во все билды,

Настоящий билдострой в ТОВ заключается не в навыках - а в АТРИБУТАХ - если повысить силу за счет интелекта - то ты так и будешь до финала игры ходить тупым или наоборот. Это как по мне очень красивое решение. Именно создавая персонажа - мы и задаем его роль.
Потом максимум артефакт на +1 к параметру атрибута можно в прохождении найти. Нельзя прокачать интелект если начать игру "тупым" и это "хорошо". Почему все остальные так не делают?!
// Сейчас играю: ark fatalis | Планы на будущее: Создать свою RPG | Жду: Чудес
Вверх Вниз
Группа: Namer
Регистрация: 2025-05-17
Репутация: 98
Сообщений: 643
Любимые CRPG: Morrowind, Готика 1-2, Ведьмак 1-2,
# 155 | | | 0

Искусственный интеллект в Arcanum

  • Стоя в центре сектора (область 64×64 тайла, об этом говорилось в видео о генерации ландшафта в Arcanum) вы видели на экране лишь его. По мере приближения к краю сектора, в память подгружались соседние (взамен удалённых), а максимум видимых на экране секторов составлял четыре (это означало, что разработчикам не требовалось держать в памяти больше четырёх секторов одновременно). Загружалась не только графика, но и оживающие после загрузки существа.
  • В отличие от анимаций, искусственный интеллект работал по «тикам» продолжительностью в три секунды. По мере приближения игрока к существу промежуток между «тиками» сокращался. Очевидно, что это стало следствием оптимизации под вычислительные мощности процессоров того времени — разработчики попросту не могли себе позволить обрабатывать ИИ всех окружающих существ в максимальном «разрешении».
  • У существ было четыре основных состояния искусственного интеллекта: мирное, боевое, бегство и капитуляция. Существа убегали, когда их здоровье падало до определённого низкого уровня, но у некоторых этот уровень был установлен в ноль, и они никогда не сбегали. В состоянии капитуляции существо просто переставало сражаться.
  • Когда атакующий нападал на жертву, это замечали. Вокруг нападающего и жертвы формировались два круга, радиус которых зависел от заметности атаки, поэтому скрытные атаки всегда лучше. Все атаки делились на незаметные, обычные, заметные — и в зависимости от этого вокруг нападающего и жертвы появлялись области, в радиусе которых все узнавали об атаке. Тим не помнит точно, но ему кажется, что местоположение нападающего точно раскрывалось лишь если жертва видела его, в противном случае окружающие персонажи узнавали лишь примерное положение нападающего, и отправлялись в этом направлении. Зачем нужны эти области? Нападающий сообщал союзникам в радиусе области, что нападает на кого-то, «предлагая» присоединиться, жертва же делала примерно то же, но уже с позиции защиты.
  • К трупу любого персонажа привязывалась информация об убийце. Каждый раз при обнаружении трупа NPC пытался понять, какое ему до него дело. И NPC было не всё равно, если убитый принадлежал к его фракции (а страже — всегда). В таком случае NPC начинал искать убийцу, и занимался этим 15 игровых минут, при условии, что персонаж игрока не приблизится к трупу.
  • Через 24 часа труп исчезал, оставляя лишь пятно крови. Пятно крови исчезало через два дня. Так что через два дня следов преступления не оставалось.
Вверх Вниз
Группа: Factol
Регистрация: 2026-02-27
Репутация: 0
Сообщений: 60
# 156 | | | 0

Размер команды

  • В целом, для разработки игр с каждым годом требуется всё больше людей.
  • Тим работал как в маленьких (3–4 человека), так и в больших (около 200 человек) командах. В среднем в 90-е игры разрабатывались командами 15–30 человек, но в 2000-х они начали разрастаться, и в 2010 году типичная команда разработчиков включала 50–60, а иногда и 70–80 человек.
  • У больших команд есть свои достоинства и недостатки, которые можно инвертировать в случае с маленькими. Главное преимущество большой команды — возможность сделать большую игру. В случае маленькой команды крайне сложно сделать длинную и увлекательную ролевую игру с современной графикой. Люди ждут определённого уровня технического исполнения, продолжительности, количества персонажей и игровых областей, и эти ожидания трудно удовлетворить небольшой командой. Кроме того, лишь большим командам по зубам создать и поддерживать какую-нибудь MMO.
  • Большие команды тяготеют к специализации. 80-е и 90-е годы Тим был мастером на все руки: продюсером, дизайнером, программистом. В больших командах может быть отдельный программист освещения или пиксельных шейдеров, художник по освещению и ничему больше. В отдельную касту выделились и сценаристы. Раньше повествованием занимались другие специалисты в дополнение к основным обязанностям, теперь же в проектах есть так называемые «дизайнеры повествования», да и те могут делиться на описывающих мир, пишущих диалоги и так далее.
  • В больших командах обычно есть управляющий сообществом — человек, который занимается постами в соцсетях, форумами, отвечает на вопросы игроков по конкретному проекту. Он особенно полезен, если нужно поучаствовать в конференции или выставке. Управляющий сообществом может донести до разработчиков часто задаваемые игроками вопросы, а значит можно заранее заготовить ответы на некоторые из них.
  • «Чем больше рук — тем меньше работы», то есть если разделить работу на множество специалистов, её сделают быстрее эффективнее. Кроме того, в разработке много рутины, а значит если выдать её всем понемногу, то меньше вероятность, что кто-то выгорит.
  • Большие команды (теоретически) позволяют ускорить разработку за счёт конвейерного производства. Если в крупной команде освобождаются специалисты, их можно перебросить на подготовку следующего, и так далее. Кроме того, на разных этапах разработки необходимо разное количество специалистов определённого профиля, а значит можно перебрасывать людей между проектами. Например, в самом начале разработки требуется много концептуальных художников, в середине меньше, а в конце, когда начинается оптимизация и исправление ошибок — они и вовсе не нужны.
  • К сожалению, в больших командах требуется много усилий для отслеживания и синхронизации работы множества специалистов, поэтому чем масштабнее проект, тем больше различных совещаний, согласований и переписок, документации, баз данных и ошибок, и с расширением команды все эти проблемы усугубляются в геометрической прогрессии. «Распределять задачи и поддерживать слаженную работу двух человек гораздо проще, нежели сотни», поэтому у вас появляются продюсеры и прочий производственный персонал, который сам ничего не разрабатывает, но помогает разработке не встать колом.
  • Чем больше команда, тем меньше люди знакомы друг с другом. У вас может быть 2–3 друга, 20–30 приятелей, но если в команде уже больше 50 человек, то будет немало людей, которых вы вообще не знаете. Это нередко приводит к недоразумениям и взаимному недоверию. Люди начинают думать, что именно они вкалывают, а остальные только вату катают.
  • В больших командах крошечные проблемы превращаются в огромные. Пусть у вас появляется издатель, который требует добавить в игру новый язык. Если у вас скромный проект на 10–20 тысяч слов — это одно, когда слов полмиллиона или миллион — это другое. При этом большое значение имеет какой это язык. Тут и сложность перевода, и необходимость добавлять новые шрифты, и, возможно, менять текст в зависимости от рода, а ещё в некоторых языках учитывается социальный статус собеседников, и тогда локализаторы начнут задавать вопросы, кто и с кем говорит, и всё это потребует глубокой доработки игры. Или, скажем, вы немного ошиблись с оценкой времени разработки определённой механики. В случае небольшого проекта цена такой ошибки измеряется десятками тысяч долларов, что может показаться немалой суммой, если не учитывать, что в действительно масштабных проектах такая ошибка может стоить миллионы. А ещё команды могут состоять из нескольких сотен человек в самых разных часовых поясах, что накладывает дополнительные ограничения.
Вверх Вниз
Группа: Factol
Регистрация: 2026-02-27
Репутация: 0
Сообщений: 60
# 157 | | | 393
Цитата zk2qX0S18z3ReibUszwh ()
Это отчасти повторяет современный подход Тима к подаче информации об игровом мире: в прошлом разработчики любили навалить «лора», теперь же Тим старается не перегружать игрока сведениями

Pillars of Eternity просит подержать пиво.
Цитата zk2qX0S18z3ReibUszwh ()
Он прекрасно понимает, что современные игроки при таком подходе будут просто сохранять игру на каждом шагу и загружаться до победного. Поэтому для борьбы с этим

Зачем?
Сойер в F:NV тоже решил поработать над вопросом случайных значений в проверках радикальным образом. Получил за это множество похвал. Другой рукой Сойер ввёл журналы на +10 к навыку вдобавок к уже имевшимся препаратам и повышающей статы одежде. В итоге все проверки очень красивые, фиксированные, можно больше не ругаться на злой кубик, но у тебя в кармане чуть ли не +20 к навыку для любой проверки. Справедливости ради, в своей ребалансной модификации для Вегаса Сойер режет опыт и левелкап, что компенсирует созданную ситуацию.

А казалось бы, если игрок хочет сейвскамить проверки - дай ему это делать. Это его проблемы. И это даже и не будет для игрока проблемой, т.к. он пошёл на это решение сам, и получит свою порцию удовольствия от успеха сейвскама. А если игрок всё же увидит проблему игры в собственном решении (см. "игра заставила" by Khael), то, в целом, можно ему и на ебало нассать.
Вверх Вниз
Группа: Factotum
Регистрация: 2015-12-25
Репутация: 393
Сообщений: 1259
Любимые CRPG: Pathfinder: Kingmaker, NWN2, VtM:B
# 158 | | | 0
Цитата Чума ()
А казалось бы, если игрок хочет сейвскамить проверки - дай ему это делать. Это его проблемы. И это даже и не будет для игрока проблемой, т.к. он пошёл на это решение сам, и получит свою порцию удовольствия от успеха сейвскама.

С. Винке гигачад, получается.
Вверх Вниз
Группа: Factol
Регистрация: 2026-02-27
Репутация: 0
Сообщений: 60
Форум » Общеролевой раздел » Обсуждение статей » Тим Кейн о себе, игровой разработке, Fallout и Arcanum (Подборка информации с YouTube-канала Тимоти Кейна.)
  • Страница 4 из 4
  • «
  • 1
  • 2
  • 3
  • 4
Поиск:

M’aiq carries two weapons, to be safe. What if one breaks? That would be most unlucky.

M’aiq the Liar, The Elder Scrolls V: Skyrim

Реклама и распространение информации
RSS и другие источники