Я знаю, что большинство игр хранят текст диалога в файлах, но я также видел несколько текстовых игр, которые фактически программируют контент (карту, варианты, возможные команды игрока, текст истории) в коде игры.
Я могу придумать несколько причин, но какова основная причина, почему даже текстовые игры хранят все в файлах вне программы?
Детали реализации мало отличаются между хранением контента в чем-то вроде популярного формата XML, его анализом, затем рендерингом карт / отображением текста на основе переменных, созданных из файла XML, и простым отказом от файла XML полностью. Они оба заканчиваются строками, которые выводятся на экран. Разве это не просто запись?
Некоторые игры даже содержат графику (ASCII art?) Внутри кода. Я знаю, что это неправильно, и я могу догадаться о нескольких причинах, почему это плохо, но также не знаю, почему это так.
Очень популярно иметь большую часть контента вне программы. Даже Dwarf Fortress не использует реальные символы ASCII, но изображения символов ASCII загружаются в память.
Я в первую очередь спрашиваю, потому что это немного PITA для создания, анализа и работы с файлами XML. Вы знаете ... по сравнению с ленивой альтернативой простого превращения каждого уникального подземелья (контента) в свой класс.
just making every unique dungeon (content) its own class.Это только заставило меня дрожать. Отделение данных от логики является для меня настолько фундаментальным принципом, что я удивлен, что разработчики все еще нарушают его.Ответы:
Для этого есть несколько причин. Я просто коснусь нескольких:
ifс,switchэс и так далее. В результате получается код, который подвержен ошибкам, труден для чтения и отладки.источник
constмассивы , мы надеемся, со статической продолжительностью хранения). Это экономит весь код и затраты оперативной памяти на загрузку / преобразование внешнего представления данных во время выполнения. Конечно, все другие ваши причины для сохранения данных по-прежнему применимы.Don't Starveследует этому подходу, и это одна из самых написанных игр, которые я когда-либо видел. Это делают и многие другие игры прошлого и настоящего, а также приложения (и редко утилиты). Я бы сказал, что в целом, за исключением небольших проектов и крошечных утилит, тяжелые слои и разделение всегда являются вашими друзьями.Помещение данных игрового контента в код означает, что для того, чтобы увидеть любое возможное изменение или итерацию данных игрового контента, вам необходимо перекомпилировать саму игру. Это плохо по двум причинам:
Многие языки, на которых написаны игры, имеют длительное время компиляции. В частности, C ++ может быть очень плохим в этом отношении, а C ++ - очень распространенный язык для больших коммерческих игр. Это менее важно для таких языков, как C # и Java, но все же не так быстро, как возможность хранить игровые данные во внешних файлах, которые могут быть загружены в горячем режиме, пока игра фактически запущена, чтобы увидеть изменения.
Многие игры разрабатываются командами, которые часто состоят из нетехнических разработчиков (дизайнеров и художников), производящих контент. Мало того, что нетехнические люди не хотят перекомпилировать игру или иметь дело с «громоздкими инструментами программиста» для итерации своего контента, может быть желательно минимизировать воздействие исходного кода только на программистов (потому что меньше людей, которые иметь доступ к исходному коду, меньше людей, которые могут его утекать - случайно или нет).
Я думаю, вы переоцениваете сложность загрузки данных из текстовых или XML-файлов. Большую часть времени вы должны использовать для этого библиотеку, что значительно упрощает процесс анализа XML / JSON / любого другого. Да, написание системы загрузки уровней, основанной на данных, сопряжено с некоторыми затратами, но в конечном итоге это сэкономит вам много времени в долгосрочной перспективе по сравнению с тоннами уникальных классов для представления каждого уровня.
Меньшие или более простые игры могут не принести такой выгоды от долгосрочных инвестиций в подход, основанный на данных, поэтому, если разработчики не используют существующие платформы / механизмы, поддерживающие его, для них может быть более эффективным просто кодировать данные в код игры.
Конечно, существует множество причин, по которым любая игра может поместить свои данные во внешние файлы (или нет); не представляется возможным перечислить их всех. На каком-то уровне они обычно сводятся к дополнительной скорости и гибкости итерации, которую может обеспечить отсутствие необходимости «перестраивать игру».
источник
Как всегда, как всегда, это зависит. Но сначала я бы хотел сказать, что жесткое кодирование само по себе неплохо.
У меня есть жестко закодированный контент, в частности текст диалога, в некоторых простых играх, и мир не кончился. Мы, программисты, любим абстрагироваться, но помните, что каждый слой абстракции, который вы создаете, сделает вашу программу более сложной и трудной для понимания.
Если ваша игра достаточно проста, чтобы вы могли жестко закодировать в ней какой-то контент, я бы, конечно, рассмотрел ее ради простоты.
Это, однако, на самом деле не слишком масштабируется. Конечно, наиболее распространенная причина размещения контента во внешних ресурсах - это упрощение командной работы, поскольку один человек или команда могут сосредоточиться на написании игры, а другой - на создании и совершенствовании контента.
Однако провести грань между программой и контентом не всегда тривиально. Можно сказать, что текстуры на 100%; а как быть с процедурно генерируемыми текстурами? Текст диалога можно считать 100% содержанием; но как насчет того, когда диалог меняется в зависимости от ваших предыдущих действий? Другие элементы, которые можно считать 100% частью программы, такие как скрипты или шейдеры, также могут рассматриваться как часть содержимого игры. Должны ли они быть жестко закодированы? они должны быть загружены как внешний ресурс?
Помните, однако, что каждый тип контента, который вы поддерживаете в своей игре, должен иметь код загрузки и интерпретации, связанный с ним, поэтому, как правило, если вы сомневаетесь, я бы рекомендовал жестко кодировать контент, и вынимать его только на внешний ресурс, когда вы действительно нужна эта гибкость (не тогда, когда вы думаете, что она может вам понадобиться, а когда вы действительно нуждаетесь)
Наконец, одно из преимуществ хранения данных в файлах ресурсов состоит в том, что вы можете загружать их только тогда, когда они вам нужны (следовательно, возможно, ускоряют время загрузки игры), и выгружать их, когда они вам больше не нужны (что позволяет вам иметь больше контента). чем может уместиться в памяти). (Уголок Nitpickers: библиотеки DLL ресурсов можно считать внешними ресурсами)
источник
Основной причиной хранения в текстовых файлах является возможность повторного использования. Создание текстовой игровой среды, которая считывает ваши карты, диалоги и другие ресурсы из текстового файла, позволяет повторно использовать вашу среду для других игр. Выходя за рамки текстовых игр, вот как бюджетные игры вроде Call of Duty выпускают новую игру каждый год.
Другая причина - мобильность. Вы можете использовать одни и те же файлы для Интернета, ПК, Mac, Android и т. Д. Все, что вам нужно сделать, - это макет вашей платформы для этих различных платформ, и большая часть игровых данных остается нетронутой.
При выходе за рамки текстовых игр наличие сценария и данных, хранящихся в файлах, уменьшит время перекомпиляции и позволит вам создать интерфейс для более удобного управления данными.
источник
Чтобы ускорить внесение изменений, это ускоряет разработку больших объемов производства.
Вам не нужно учить всех учиться входить и редактировать исходные тексты для внесения простых изменений. Вытаскивая его из реального кода, больше людей получают возможность дурачиться, легче узнать, с какими вариантами вы можете поиграть, и весь процесс тонкой настройки различных частей вашей игры занимает гораздо меньше времени. Даже вопросы и ответы могут помочь с этим.
источник
Я не могу поверить, что никто еще не упомянул об этом, но главная причина заключается в том, чтобы сделать локализацию ОЧЕНЬ проще. Если вам требуется поддержка английского, французского, немецкого, испанского, португальского, итальянского, русского, китайского и любого другого языка, на который вы нацелены, жестко запрограммированный код требует наличия отдельного кода для каждого языка. Это также означает, что если вам нужно удалить определенный контент (читай: цензура), вам нужно изменить сам код, чтобы избежать его, вместо того, чтобы сказать «просто замените эту анальную пробную мини-игру на этот пассивно-агрессивный баннер, который графически объясняет, что происходит». ». Это также довольно недружелюбно для потребителей, поскольку, скорее всего, им потребуется перезапустить игру, чтобы изменить язык, поскольку вам нужно загружать другие библиотеки. В заключение,
С другой стороны, если вы используете внешние ресурсы, поддержка разных языков означает просто загрузку другого файла ресурсов. Это легко сделать во время игры. это означает, что вы можете иметь единую кодовую базу, что значительно упрощает разработку. И это также означает, что вы можете легко добавить поддержку после выпуска для других языков. Наконец, это означает, что вы можете позволить пользователю отказаться от установки определенных языков (функция, которая не часто встречается в играх, но все еще возможна), чтобы сэкономить дисковое пространство и пропускную способность.
источник
Я думаю, что ключевая фраза - это разделение интересов .
Если ваш код не включает в себя текст, код становится менее сложным. Программист, пишущий код, не должен думать о конкретном тексте и может сосредоточиться на коде.
Ему не нужно думать о локализации. Человек, занимающийся локализацией, не должен беспокоиться о коде.
источник
Я думаю, что слишком легко быть парнем «иссохшего чем белый» и рекомендовать горячо, используя внешний текстовый файл ресурса.
Зачем? Потому что здесь есть выбор балансировки затрат / проблем / преимуществ каждого решения.
При использовании внешнего файла ... Ну, я думаю, другие ответы достаточно хорошо объясняют преимущества. Но как насчет затрат? Вы должны определить действительный формализм, создать интерпретатор, согласовать формат файла и, что еще хуже ... создать другое приложение - редактор -. Что является проблемой на 0,00%, если вы являетесь членом команды программистов из 50 человек, строящей большой проект. Но если ты один: ты застрял.
Опять же, я не недооцениваю огромную гибкость внешнего ресурса: программирование на основе данных кажется мне подходящим для видеоигр. Но давайте не будем забывать стоимость.
С другой стороны, наличие текста внутри кода позволяет быстро создавать прототипы, поэтому его следует использовать с первого раза. Тогда мой совет будет, по мере развития проекта, анализировать данные, необходимые для моделирования диалогов (настроение / история-состояние / ...). Затем в какой-то момент вы выбираете некоторые классы / правила / формат файла и переходите к реальной ситуации, позволяя другим людям редактировать / отделять код от содержимого и так далее. ИЛИ для игры с простыми диалогами (Марио ...) вы просто считаете стоимость слишком высокой и сохраняете жестко закодированные несколько строк / поведения.
Ваш звонок.
(Замечание о локализации: это всего лишь хеш-таблица, поэтому это независимая и легко решаемая проблема.)
источник
Я думаю, что лицензирование также может быть причиной не включать контент в код.
Например,
источник