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

Потенційно може бути сотні різних станцій / кораблів / тощо, які грі потрібно буде використовувати - ось ось що мені було цікаво. Чи варто витрачати час на створення завантажувача даних "softcoded", який би зберігав усю цю інформацію у (наприклад) XML-файлах, і тому було б дещо простіше змінити пізніше, або мені просто піти з тим, що я робив зараз - жорстке кодування всіх об'єктів в основний двигун гри.

Я єдина людина в проекті, і, як я вже сказав, я займаюся лише захопленням у вільний час поза університетом. Але чи рекомендує громада інвестувати у створення цілої додаткової системи зберігання даних у додаткових файлах?

Які переваги даних програмного кодування таким чином, а не просто жорстке кодування все це через конструктори? Чи є довгострокова вигода від наявності зовнішніх файлів, які можна змінити - якщо я не шукаю, щоб гра мала «модники», чи потрібно мати зовнішні файли? Якщо я просто захоплююся справою, від якої я можу відмовитись через кілька тижнів чи місяців, чи варто витрачати час на це?

Так. Вам слід запровадити систему для завантаження вмісту поза вашим основним двигуном.

Заголовки стислих відповідей.

Ні. Це не забирає занадто багато часу.

Я думаю, що питання про те, чи є правильним розподіл вашого обмеженого часу, суперечить; навіть якщо тільки на те, що це буде невелика частина загального часу проекту.

Ви витратите сотні (тисячі) годин на ігровий проект, який ви приймаєте до завершення. Можливо, не на клоні Pong, але, безумовно, так для вашої складної космічної гри. Порівняйте це з програмою зчитування конфігураційних файлів. Впровадження системи для передачі XML у ваш основний конструктор та згодом перезапуск до ігрового процесу займе, можливо, 10 чи 20 годин. Навіть якщо це займе у вас 50 або 100, це буде невелика частка загального часу проекту.

Це заощадить час

Це не витрата часу; це вкладення часу. І це окупиться.

Важливий робочий процес, а наявність конфігураційного завантажувача покращить ваш робочий процес. Створивши систему, яка дозволяє вам відредагувати конфігурації на ходу, ви заощадите незліченну кількість перебудов. Ви можете переглянути гру, поки вона працює, налаштувати XML і повторно перевірити за лічені секунди. Або ви можете переглянути код, знайти рядок коду (серед тисяч), надзвичайно ретельно відредагувати його значення (ви в своєму головному двигуні, після закінчення), відновити, виконати, повернути гру до стану тестування, постарайтеся важко пам’ятайте, як це виглядало до зміни, і подивіться, чи зміна мала ефект, який ви планували. Якщо припустити, що у вашому двигуні нічого не відбувається, ваш потяг, безумовно, порушений.

З точки зору більш фундаментальної науки, спробуйте пам’ятати, що найбільш трудомісткою частиною написання програмного забезпечення є не кілька додаткових натискань клавіш або пробілів. Це полювання на помилок. І якщо ви витратите трохи додаткового часу, щоб зробити речі зрозумілішими, написавши більше детального коду, ви заощадите набагато більше часу пізніше. У вашому випадку написання імпортера вмісту призводить до отримання більш чистого коду, який буде легше читати. Замість миль і миль твердо кодованих значень у вашому джерелі з'явиться проста завантаження файлів. Так само ви можете читати конфігураційний файл, не перебираючи код ігрового двигуна. Обидві частини стають більш ремонтованими та простішими у налагодженні.

Однокласні команди виграють найбільше

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

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

Не робіть цього собі. Зробіть інструменти, і у вас буде більше часу, щоб зробити гру.

Це гарне запитання, і найкраща відповідь, яку я можу дати, - це те, що лише досвід дійсно може вам сказати, коли це гарна ідея пройти шлях, який є більш складним / трудомістким. Якщо хтось скаже вам, що ЗАВЖДИ це робити «належним чином», то вони просто помиляються.

Ви вже розумієте, що це торгівля. З одного боку, жорстке кодування настільки спокусливо, тому що його швидко та легко розпочати, але з часом додавання функцій та налагодження стануть кошмарним. З іншого боку, створення чудової, гнучкої, розширюваної системи вимагає великих початкових інвестицій, але робить життя в пеклі набагато простішим.

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

• Ви можете подумати, що ваш проект невеликий, але можливо, що він зростає, коли ви вирішите додати більше функцій. Якщо ви почнете жорстке кодування, настане час, коли енергія, необхідна для його підтримання (оновлення його новими речами та виправлення безлічі неминучих помилок), почне серйозно переважувати початкові вигоди.

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

• На даний момент ви можете працювати самотніми, але може настати час, коли ви захочете залучити когось іншого до проекту. Ви збираєтесь витратити час, щоб пояснити свою огидну парафіяльну систему та написати документацію на неї?

• Жорстке кодування часто передбачає необхідність знати, що означають певні магічні числа чи складні залежності класу. Ви, можливо, зможете все це пам’ятати зараз, але просто зачекайте, поки ви деякий час не підете з коду. Навіть з обширними коментарями, погано розроблена структура - це пекло.

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

З іншого боку, я прототип, як божевільний і жорсткий кодування певних речей, швидко і легко, і залишає вас вільним зосередитись на експерименті. Це залежить від вашого стилю роботи.

Те, про що ви говорите, - це програмоване керування даними .

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

Однак програмування, кероване даними, може бути ДУЖЕ легким у виконанні. Якщо ви серйозно ставитесь до цього, ви, ймовірно, повинні використовувати XML, JSON або YAML, але ви також можете використовувати текстові файли із звичайним текстом.

Програмування на основі даних

Плюси

1. Дозволяє дизайнерам отримувати доступ та змінювати дані гри без знань про програмування
2. Ви можете вносити зміни в гру, не потребуючи перекомпіляції . Це не варто недооцінювати, оскільки таким чином ви можете розвивати гру набагато швидше. Хороші ігри приходять після багатьох ітерацій.

Мінуси

1. Для її здійснення потрібен час і сили.
2. Це може збільшити складність програми.