Чому погано вміст жорсткого коду?

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

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

Деталі реалізації мало відрізняються між вмістом вмісту у чомусь схожим на популярний формат XML, його розбором, а потім рендерінгом карт / відображенням тексту на основі змінних, створених з XML-файлу, та просто вилученням файлу XML повністю. Вони обидва закінчуються рядками, які виводяться на екран. Чи не різниця лише позначення?

Деякі ігри навіть містять графіку (ASCII art?) Всередині коду. Я знаю, що це неправильно, і я можу здогадатися про декілька причин, чому це погано, але не знаю головної причини, чому також.

Дуже популярно мати більшу частину вмісту поза програмою. Навіть фортеця-карлик не використовує фактичних символів ASCII, а зображення символів ASCII, завантажених у пам'ять.

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

Для цього є кілька причин. Я просто торкнусь декількох:

1. Це робить ваш вихідний код безладом. Якщо у вас багато діалогів (дерев), величезна частина вашої кодової бази - це лише текст, який не має нічого спільного з вашим фактичним кодом гри.
2. Вам потрібно буде перекомпілювати кожного разу, коли ви зміните стільки, скільки одного символу.
3. У самому діалозі важко орієнтуватися. Я думаю, що намагання реалізувати ціле діалогове дерево, не кажучи вже про кілька, повністю всередині вашого джерела призведе до вкладеного безладу спагетті та вкладених ifs, switches тощо. Потім це призводить до коду, схильного до помилок, важкого для читання та складнішого налагодження.
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 великих кодерів. Але якщо ти один: ти затримався.

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

З іншого боку, наявність тексту всередині коду дозволяє швидко формувати прототипи, тому слід віддавати перевагу в перший раз. Тоді в міру дозрівання моєї поради було б проаналізувати вид даних, необхідних для моделювання діалогів (настрій / історія-стан / ...). Тоді в якийсь момент ви вирішуєте деякі класи / правила / формат файлу і переходите до справжньої речі, дозволяючи іншим людям редагувати / від’єднувати код від вмісту тощо. АБО для гри з простими діалогами (Mario ...) ви просто вважаєте вартість занадто високою, і ви зберігаєте кілька рядків / поведінки жорстко кодованими.
Твій дзвінок.

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

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

Наприклад,

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