Я на тысячу строк кода создаю свою собственную 2D-космическую игру, которая создает сети случайно сгенерированных звездных систем и наполняет их случайным выбором планет, станций, кораблей и оружия.

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

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

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

Да. Вы должны внедрить систему для загрузки контента вне вашего основного движка.

Заголовки для кратких ответов.

Нет, это не занимает слишком много времени.

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

Вы потратите сотни (тысячи) часов на игровой проект, который вы доведите до конца. Возможно не на клоне Понг, но, конечно, так для вашей сложной космической игры. Сравните это с читателем файла конфигурации. Внедрение системы для передачи XML в ваш основной конструктор и последующего перезапуска к игровому процессу займет, возможно, 10 или 20 часов. Даже если это займет у вас 50 или 100, это будет крошечная доля общего времени проекта.

Это сэкономит время

Это не затраты времени; это время инвестиций. И это окупится.

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

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

Команды с одним участником приносят наибольшую пользу

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

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

Не делай этого с собой. Сделайте инструменты, и у вас будет больше времени, чтобы сделать игру.

Это хороший вопрос, и лучший ответ, который я могу дать, заключается в том, что только опыт действительно может сказать вам, когда стоит выбрать более сложный / трудоемкий путь. Если кто-то говорит вам, что вы должны ВСЕГДА делать это «правильно», тогда они просто ошибаются.

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

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

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

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

• Возможно, вы сейчас работаете в одиночку, но может прийти время, когда вы захотите привлечь кого-то еще в проект. Собираетесь ли вы найти время, чтобы объяснить свою отвратительную приходскую систему и написать для нее документацию?

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

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

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

Вы говорите о программировании на основе данных .

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

Однако программирование на основе данных может быть ОЧЕНЬ легко осуществимо. Если вы серьезно относитесь к этому, вам, вероятно, следует использовать XML, JSON или YAML, но вы также можете использовать простые текстовые файлы.

Программирование на основе данных

Pros

1. Позволяет дизайнерам получать доступ и изменять игровые данные без знания программирования
2. Вы можете вносить изменения в игру без перекомпиляции . Это не следует недооценивать, так как вы можете разработать игру намного быстрее. Хорошие игры приходят после многих итераций.

Cons

1. Это требует времени и усилий для реализации.
2. Это может увеличить сложность программы.