Почему плохо программировать контент?

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

Я могу придумать несколько причин, но какова основная причина, почему даже текстовые игры хранят все в файлах вне программы?

Детали реализации мало отличаются между хранением контента в чем-то вроде популярного формата XML, его анализом, затем рендерингом карт / отображением текста на основе переменных, созданных из файла XML, и простым отказом от файла XML полностью. Они оба заканчиваются строками, которые выводятся на экран. Разве это не просто запись?

Некоторые игры даже содержат графику (ASCII art?) Внутри кода. Я знаю, что это неправильно, и я могу догадаться о нескольких причинах, почему это плохо, но также не знаю, почему это так.

Очень популярно иметь большую часть контента вне программы. Даже Dwarf Fortress не использует реальные символы ASCII, но изображения символов ASCII загружаются в память.

Я в первую очередь спрашиваю, потому что это немного PITA для создания, анализа и работы с файлами XML. Вы знаете ... по сравнению с ленивой альтернативой простого превращения каждого уникального подземелья (контента) в свой класс.

Для этого есть несколько причин. Я просто коснусь нескольких:

1. Это делает ваш исходный код беспорядком. Если у вас много диалогов (деревьев), огромная часть вашей кодовой базы - это просто текст, который не имеет ничего общего с вашим настоящим игровым кодом.
2. Вам нужно будет перекомпилировать каждый раз, когда вы меняете столько, сколько один символ.
3. Сам диалог трудно ориентироваться. Я полагаю , пытаясь реализовать весь диалог дерева, не говоря уже о нескольких, полностью внутри ваш источник приведет к вложенной беспорядок спагетти и вложенных друг в друга ifс, switchэс и так далее. В результате получается код, который подвержен ошибкам, труден для чтения и отладки.
4. Если вы хотите, чтобы люди могли модифицировать или расширять вашу игру, гораздо проще, если им не нужно иметь дело с исходным кодом, чтобы что-то изменить.
5. Вышеуказанное еще более важно, если вы работаете в команде. Вы не хотите, чтобы ваш писатель возился с кодом, просто чтобы ввести часть диалога.
6. Синтаксический анализ XML или других стандартных форматов файлов довольно прост, если вы используете существующие библиотеки, поэтому затраты на его реализацию очень низки, при этом вы получаете много преимуществ, избегаете проблем, упомянутых выше, и многое другое.
7. Как отметил @MiloPrice ниже, локализовать игру гораздо проще, если ваш текст находится во внешних файлах. Вы можете добавить язык, добавив файл, ваша команда может позаботиться о переводе, не касаясь источника (что особенно важно, если вы разрешите переводчикам, которые не должны видеть весь ваш код, - считают фрилансеры, люди из сообщество, которое не принадлежит вашей команде и т. д.).

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

• Многие языки, на которых написаны игры, имеют длительное время компиляции. В частности, C ++ может быть очень плохим в этом отношении, а C ++ - очень распространенный язык для больших коммерческих игр. Это менее важно для таких языков, как C # и Java, но все же не так быстро, как возможность хранить игровые данные во внешних файлах, которые могут быть загружены в горячем режиме, пока игра фактически запущена, чтобы увидеть изменения.

• Многие игры разрабатываются командами, которые часто состоят из нетехнических разработчиков (дизайнеров и художников), производящих контент. Мало того, что нетехнические люди не хотят перекомпилировать игру или иметь дело с «громоздкими инструментами программиста» для итерации своего контента, может быть желательно минимизировать воздействие исходного кода только на программистов (потому что меньше людей, которые иметь доступ к исходному коду, меньше людей, которые могут его утекать - случайно или нет).

Я думаю, вы переоцениваете сложность загрузки данных из текстовых или XML-файлов. Большую часть времени вы должны использовать для этого библиотеку, что значительно упрощает процесс анализа XML / JSON / любого другого. Да, написание системы загрузки уровней, основанной на данных, сопряжено с некоторыми затратами, но в конечном итоге это сэкономит вам много времени в долгосрочной перспективе по сравнению с тоннами уникальных классов для представления каждого уровня.

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

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

Как всегда, как всегда, это зависит. Но сначала я бы хотел сказать, что жесткое кодирование само по себе неплохо.

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

Если ваша игра достаточно проста, чтобы вы могли жестко закодировать в ней какой-то контент, я бы, конечно, рассмотрел ее ради простоты.

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

Однако провести грань между программой и контентом не всегда тривиально. Можно сказать, что текстуры на 100%; а как быть с процедурно генерируемыми текстурами? Текст диалога можно считать 100% содержанием; но как насчет того, когда диалог меняется в зависимости от ваших предыдущих действий? Другие элементы, которые можно считать 100% частью программы, такие как скрипты или шейдеры, также могут рассматриваться как часть содержимого игры. Должны ли они быть жестко закодированы? они должны быть загружены как внешний ресурс?

Помните, однако, что каждый тип контента, который вы поддерживаете в своей игре, должен иметь код загрузки и интерпретации, связанный с ним, поэтому, как правило, если вы сомневаетесь, я бы рекомендовал жестко кодировать контент, и вынимать его только на внешний ресурс, когда вы действительно нужна эта гибкость (не тогда, когда вы думаете, что она может вам понадобиться, а когда вы действительно нуждаетесь)

Наконец, одно из преимуществ хранения данных в файлах ресурсов состоит в том, что вы можете загружать их только тогда, когда они вам нужны (следовательно, возможно, ускоряют время загрузки игры), и выгружать их, когда они вам больше не нужны (что позволяет вам иметь больше контента). чем может уместиться в памяти). (Уголок Nitpickers: библиотеки DLL ресурсов можно считать внешними ресурсами)

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

Другая причина - мобильность. Вы можете использовать одни и те же файлы для Интернета, ПК, Mac, Android и т. Д. Все, что вам нужно сделать, - это макет вашей платформы для этих различных платформ, и большая часть игровых данных остается нетронутой.

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

Чтобы ускорить внесение изменений, это ускоряет разработку больших объемов производства.

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

Я не могу поверить, что никто еще не упомянул об этом, но главная причина заключается в том, чтобы сделать локализацию ОЧЕНЬ проще. Если вам требуется поддержка английского, французского, немецкого, испанского, португальского, итальянского, русского, китайского и любого другого языка, на который вы нацелены, жестко запрограммированный код требует наличия отдельного кода для каждого языка. Это также означает, что если вам нужно удалить определенный контент (читай: цензура), вам нужно изменить сам код, чтобы избежать его, вместо того, чтобы сказать «просто замените эту анальную пробную мини-игру на этот пассивно-агрессивный баннер, который графически объясняет, что происходит». ». Это также довольно недружелюбно для потребителей, поскольку, скорее всего, им потребуется перезапустить игру, чтобы изменить язык, поскольку вам нужно загружать другие библиотеки. В заключение,

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

Я думаю, что ключевая фраза - это разделение интересов .

Если ваш код не включает в себя текст, код становится менее сложным. Программист, пишущий код, не должен думать о конкретном тексте и может сосредоточиться на коде.

Ему не нужно думать о локализации. Человек, занимающийся локализацией, не должен беспокоиться о коде.

Я думаю, что слишком легко быть парнем «иссохшего чем белый» и рекомендовать горячо, используя внешний текстовый файл ресурса.

Зачем? Потому что здесь есть выбор балансировки затрат / проблем / преимуществ каждого решения.

При использовании внешнего файла ... Ну, я думаю, другие ответы достаточно хорошо объясняют преимущества. Но как насчет затрат? Вы должны определить действительный формализм, создать интерпретатор, согласовать формат файла и, что еще хуже ... создать другое приложение - редактор -. Что является проблемой на 0,00%, если вы являетесь членом команды программистов из 50 человек, строящей большой проект. Но если ты один: ты застрял.

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

С другой стороны, наличие текста внутри кода позволяет быстро создавать прототипы, поэтому его следует использовать с первого раза. Тогда мой совет будет, по мере развития проекта, анализировать данные, необходимые для моделирования диалогов (настроение / история-состояние / ...). Затем в какой-то момент вы выбираете некоторые классы / правила / формат файла и переходите к реальной ситуации, позволяя другим людям редактировать / отделять код от содержимого и так далее. ИЛИ для игры с простыми диалогами (Марио ...) вы просто считаете стоимость слишком высокой и сохраняете жестко закодированные несколько строк / поведения.
Ваш звонок.

(Замечание о локализации: это всего лишь хеш-таблица, поэтому это независимая и легко решаемая проблема.)

Я думаю, что лицензирование также может быть причиной не включать контент в код.

Например,

• ваш код может быть FLOSS , но вы вообще не хотите лицензировать свой контент (может быть, вы хотите опубликовать свой игровой код, чтобы другие могли использовать его для создания похожих игр с разным контентом)
• ваш код может быть FLOSS, но вы хотите использовать лицензию Creative Commons для вашего контента (так как лицензии на программное обеспечение не очень хорошо работают с контентом и наоборот)
• Ваш код может быть закрытым , но вы повторно используете бесплатный контент
• Ваш код может быть закрытым, но вы хотите опубликовать свой собственный контент под свободной лицензией