Игровой движок и дизайн, управляемый данными

Я слышал о дизайне, управляемом данными, и некоторое время изучал его. Итак, я прочитал несколько статей, чтобы получить концепции.

Одна из статей - Data Driven Design, написанная Кайлом Уилсоном, Как он описал, мне кажется, что код приложения (т.е. код для управления ресурсами, такими как память, сеть ...) и код игровой логики должны быть разделены, а код игровой логики должен управляться внешними источниками данных. В этот момент я могу представить, что разработчик написал бы своего рода редактор игры, который принимает внешние данные об игровых объектах (такие как информация о персонажах, информация об оружии, информация о карте ...). Дизайн сценария будет написан на языке / инструменте, написанном программистом, чтобы позволить игровому дизайнеру создавать взаимодействие между игровыми объектами. Дизайнер игры будет использовать существующий / пользовательский язык сценариев для написания сценария для игры или инструмент перетаскивания для создания игрового мира. Примером инструментального подхода, который я могу вспомнить, является World Editor, который обычно упаковывается вместе с играми Bliizard.

Тем не менее, другая статья против использования Data Driven Design, «Дело против Data Driven Design» . Автор предлагает не позволять игровому дизайну руководствоваться данными, потому что на разработку игры потребуется больше времени, так как игровой дизайнер несет бремя программирования. Вместо этого будет программист игры, который будет свободно программировать игру из эскиза и будет проверен разработчиком игры после завершения программирования игры. Он называет это программистом. То, что я думаю об этом методе, похоже на то, что я делал раньше: игровая логика - это само приложение, в отличие от приведенной выше идеи, приложение - редактор игр, а настоящая игра разработана на основе этого инструмента.

На мой взгляд, первый способ представляется более разумным, поскольку компоненты игры можно использовать во многих проектах. Со вторым методом, который противостоит дизайну, основанному на данных, код игры принадлежит только этой игре. Вот почему я думаю, что в Warcraft так много игровых жанров, как, например, оригинальный Warcraft и различные пользовательские карты, и одна из самых известных: DOTA, которая фактически определяет новый жанр. По этой причине я слышал, что люди называют World Editor игровым движком. Это правда, каким должен быть игровой движок?

Итак, после всего этого, я просто хочу проверить, есть ли какой-либо недостаток в моем понимании этих идей (управляемых данными, программистских накопителей, сценариев и т. Д ...)?

Создание вашей игры (или любого программного продукта) на основе данных почти всегда является преимуществом. Единственный реальный минус в том, что вы можете потратить немного больше времени на создание соответствующих систем заранее; тем не менее, это окупится за всю оставшуюся карьеру программиста (даже если вы не будете использовать те же самые системы в течение всего этого времени, вы будете использовать методы, использованные для их создания).

Сложность, и где вступает в игру разъединение в этих двух статьях, которые вы связали, заключается в том , что вы выбираете для ввода данных и кого вы выбираете для предоставления доступа к этим данным. По сути, проектирование и разработка на основе данных просто означает, что вы помещаете информацию во внешнее хранилище, загружаете эту информацию во время выполнения и воздействуете на нее. Код вашего приложения выполняет то, что ему говорят внешние данные, а не вы пишете код приложения, который напрямую выполняет то, что, по вашему мнению, должно быть конечным результатом. Это не сложная идея.

Вам не нужно создавать сложные «компонентно-управляемые архитектуры» (как это принято сейчас). Помещение констант для настройки физики (сила тяжести, коэффициенты восстановления) в текстовом файле зависит от данных. Скрипты (в Lua или что-то еще) управляются данными. Описание вашего уровня данных в XML. Что-нибудь в этом роде.

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

Кроме того, вы подвергаетесь огромному риску, пытаясь сделать «дизайн дизайнеров», а программисты «делают эти проекты реальностью», заставляя программиста существовать в цикле итерации для работы дизайнера: вы рискуете заставить программиста почувствовать он просто обезьяна кода, постоянно вносящая мелкие изменения в дизайн. Это может значительно деморализовать большинство программистов, которые хотят работать над интересными техническими задачами, а не быть доверенным лицом дизайнера.

По вашим конкретным вопросам:

Это правда, каким должен быть игровой движок?

«Движок игры» на самом деле не имеет фиксированного определения. Как правило, это унифицированный набор базовых технологий, используемых для создания игры, обычно поддерживаемый набором связанных инструментов (и, следовательно, в значительной степени управляемых данными). Но это варьируется довольно широко от контекста к контексту.

Итак, после всего этого, я просто хочу проверить, есть ли какой-либо недостаток в моем понимании этих идей (управляемых данными, программистских накопителей, сценариев и т. Д ...)?

Похоже, вы более или менее на правильном пути, хотя, возможно, вы слишком усложняете, что такое проектирование и разработка на основе данных, сопоставляя их с компонентными системами.

Как автор второго поста, я хотел бы уточнить несколько моментов.

1. Как предположил Джош Петри, структурирование вашего кода для использования данных вместо простого жесткого кодирования - всегда выигрыш. Я не предлагал иначе. Я указывал, что толкать все на дизайнера не очень хорошая идея. Термин «дизайн, управляемый данными» означает разные вещи для разных людей, поэтому я, вероятно, должен был быть более конкретным, когда писал оригинальную статью.
2. В каждом месте, где я работал, мы создаем структуры данных, которые можно настраивать в движке. Чтобы внести изменения, нам не нужно перекомпилировать игру. Мы можем изменить число динамически во время выполнения. Структуры данных часто хранятся в коде, но в зависимости от того, кто их изменяет, их можно легко загрузить из «файла данных».
3. Большинство сред разработки поддерживают некоторую форму редактирования и продолжения или перезагрузки модуля для C / C ++.
4. В большинстве студий по разработке игр есть геймплейные программисты. Их работа часто состоит в том, чтобы работать с дизайнером в создании забавного опыта. Их главная проблема не в технических проблемах, а в создании забавного кода. Я работал программистом геймплея на протяжении многих лет, и я считаю, что это интереснее, чем просто пытаться решить технические проблемы. Мои обязанности менялись, но я нашел свою работу наиболее полезной, когда я отвечаю за реализацию и работаю с дизайнерами над созданием чего-то классного. Проблема дизайнеров в написании кода или написании сценариев заключается в том, что программистам часто приходится разбирать ошибки, что является одной из наименее забавных вещей, которые вы можете сделать как программист.
5. То, что лучше всего подходит для студии, зависит от игры. Если у вас есть долгое время, чтобы создать игру, и вы хотите дать свои игровые ножки мод-сообществу и создать что-то огромное по объему, тогда создание игры, полностью ориентированной на данные, имеет смысл. Многие игры не имеют такой цели. Они должны выпускать новую игру в течение двух лет, и, если у них нет популярной франшизы, это, вероятно, другой тип игры, чем их предыдущая работа.
6. То, что делает «дизайнер», может варьироваться от студии к студии. Я слышал о студии разработки, которая нанимает программистов геймплея из других студий, называет их дизайнерами и дает им сценарий поведения игры. Это позволяет обойтись без людей, которые не обучены программированию / написанию сценариев.
7. Всегда должно быть различие между кодом игровой логики и кодом движка. Кроме того, вы обычно хотите иметь какой-то визуальный редактор для размещения объектов. Я никогда не работал в студии, где вражеские локации жестко запрограммированы. Они размещены в редакторе. Позвольте мне предложить пример того, о чем я говорю. Допустим, дизайнер придумывает врага. Есть ли у дизайнера сценарий поведения этого нового типа врага? Это то, что я считаю дизайном, управляемым данными (в терминах того, что написал об этом Тим Мосс). В соответствии с тем, что я предлагаю, программист работает с дизайнером, они вместе делают забавного врага, возможно, с настраиваемыми параметрами, и затем они размещаются на уровне.
8. Собственный код, написанный программистом, будет выполняться быстрее во время выполнения, чем сценарий, написанный программистом, который будет выполняться быстрее, чем сценарий, написанный кем-то с меньшей технической подготовкой. Эта производительность может или не может быть важной в зависимости от того, какую игру вы делаете и чем занимаетесь, но это то, что нужно учитывать.
9. Вы можете делиться игровым кодом между играми независимо от того, какой метод вы выберете. Я не совсем уверен, к чему вы клоните. Даже если вы не используете язык сценариев или визуальный инструмент для определения некоторых типов поведения, вам следует как можно больше разбивать свой код геймплея на повторно используемые компоненты. Всегда будут вещи, которые не применимы к вашей следующей игре, но в каждом месте, где я когда-либо работал, когда мы начинаем следующую игру, мы начинаем с кодовой базы из предыдущей - даже если это не продолжение. Затем мы сохраняем материал, который имеет смысл, и удаляем материал, специфичный для игры.

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

Кроме того, как примечание, моей записи в блоге 5 лет. Кажется, что в наши дни гораздо больше студий переходят на языки сценариев и еще много чего, но создают зрелые инструменты для их отладки, что было моей главной жалобой. Когда я написал это, я не думаю, что существовал Unreal Kismet, которым я не пользовался, но похоже, что они пытаются упростить сценарии, и у него, по-видимому, есть отладчик. (Понятия не имею, насколько хорошо это работает, хотя)

Что касается игр меньшего масштаба, я определенно не думаю, что вы захотите использовать язык сценариев или аналогичные функции в своей технологии, но если у вас огромная команда и много времени, чтобы посвятить технологии, это можно сделать Правильно и время может иметь смысл в зависимости от того, как ваша команда разработчиков любит работать. Лично я, вероятно, буду держаться за C ++ как можно дольше, потому что для меня это самый простой и быстрый способ, поскольку мне часто приходится пытаться обходить такие «функции», как сборка мусора.

Вы должны посмотреть BitSquid Tech Engine . Он построен с использованием концепций DOD. Блог Никласа Фрикхольма очень интересный. Есть много статей о том, как этот двигатель разработан.

На GDC 2011 Никлас провел презентацию о Data Driven Renderer .