Почему это плохо для содержимого жесткого кода?

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

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

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

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

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

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

41 голос | спросил user50286 1 +04002014-10-01T00:26:32+04:00312014bEurope/MoscowWed, 01 Oct 2014 00:26:32 +0400 2014, 00:26:32

9 ответов


85

Этому есть несколько причин. Я просто коснусь нескольких:

  1. Это делает ваш исходный код беспорядочным. Если у вас много диалогов (деревьев), огромная часть вашей кодовой базы - это просто текст, который не имеет никакого отношения к вашему фактическому игровому коду.
  2. Вам нужно перекомпилировать каждый раз, когда вы меняете столько, сколько один символ.
  3. Диалог сам по себе трудно ориентироваться. Я предполагаю, что попытка реализовать цельное дерево диалогов, не говоря уже о нескольких, полностью внутри вашего источника приведет к вложенному беспорядку спагетти и вложенному if s, switch es и т. Д. , Что затем приводит к коду, который подвержен ошибкам, трудно читаемым и сложнее отлаживать.
  4. Если вы хотите включить людей в моду или расширить свою игру, это намного проще, если им не придется иметь дело с исходным кодом, чтобы что-то изменить.
  5. Вышеупомянутая точка еще важнее, если вы работаете в команде. Вы не хотите, чтобы ваш писатель должен был возиться с кодом только для ввода фрагмента диалога.
  6. Разбор XML или других стандартных форматов файлов довольно прост в использовании, если вы используете существующие библиотеки, поэтому стоимость его реализации очень мала, давая вам много преимуществ и избегая проблем, упомянутых выше, и многое другое.
  7. Как указала @MiloPrice ниже, гораздо легче локализовать игру, если ваш текст находится во внешних файлах. Вы можете добавить язык, добавив файл, ваша команда может позаботиться о переводе, не касаясь источника (что особенно важно, если вы позволите людям переводить тех, кто не должен видеть весь ваш код, - считают фрилансеров, людей из сообщество, которое не принадлежит вашей команде и т. д.).
ответил Christian 1 +04002014-10-01T00:45:53+04:00312014bEurope/MoscowWed, 01 Oct 2014 00:45:53 +0400 2014, 00:45:53
30

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

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

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

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

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

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

ответил Josh Petrie 1 +04002014-10-01T00:34:10+04:00312014bEurope/MoscowWed, 01 Oct 2014 00:34:10 +0400 2014, 00:34:10
7

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

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

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

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

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

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

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

ответил Panda Pajama 1 +04002014-10-01T06:48:41+04:00312014bEurope/MoscowWed, 01 Oct 2014 06:48:41 +0400 2014, 06:48:41
3

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

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

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

ответил Ted Wagner 1 +04002014-10-01T02:04:24+04:00312014bEurope/MoscowWed, 01 Oct 2014 02:04:24 +0400 2014, 02:04:24
3

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

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

ответил John Cobalt 1 +04002014-10-01T07:17:22+04:00312014bEurope/MoscowWed, 01 Oct 2014 07:17:22 +0400 2014, 07:17:22
3

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

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

ответил Nzall 1 +04002014-10-01T12:17:29+04:00312014bEurope/MoscowWed, 01 Oct 2014 12:17:29 +0400 2014, 12:17:29
3

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

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

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

ответил Christian 2 +04002014-10-02T14:25:13+04:00312014bEurope/MoscowThu, 02 Oct 2014 14:25:13 +0400 2014, 14:25:13
3

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

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

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

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

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

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

ответил GameAlchemist 1 +04002014-10-01T01:34:00+04:00312014bEurope/MoscowWed, 01 Oct 2014 01:34:00 +0400 2014, 01:34:00
2

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

Например,

  • ваш код может быть FLOSS , но вы не хотите лицензировать свой (возможно, вы хотите опубликовать свой игровой код, чтобы другие могли использовать его для создания похожих игр с различным контентом).
  • ваш код может быть FLOSS, но вы хотите использовать лицензию Creative Commons для вашего контента (в качестве лицензий на программное обеспечение не работает отлично для контента и наоборот)
  • ваш код может быть проприетарным , но вы повторно используете бесплатный контент
  • ваш код может быть проприетарным, но вы хотите опубликовать свой собственный контент под лицензией free /libre.
ответил unor 2 +04002014-10-02T18:03:12+04:00312014bEurope/MoscowThu, 02 Oct 2014 18:03:12 +0400 2014, 18:03:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132