Як прототипувати, як я можу легше вивчити поведінку гри?

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

^{(фото з блогу Інтерком )}

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

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

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

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

Багато великих сучасних двигунів (Unity, Unreal тощо), як правило, роблять це, вводячи свого редактора всередину ігрового двигуна, так що ви можете робити більшість модифікацій в прямому ефірі, ніколи не перезапускаючи гру. Менші двигуни / ігри, як правило, фокусують роботу в іншому напрямку; змушуйте компілювати гру та запускати її так швидко, що не має значення, чи доведеться перезавантажувати гру для кожної зміни; Ви все ще будете проходити тестування до того, як закінчиться п'ять секунд.

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

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

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

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

Щоб добре скласти прототип, зменшіть витрати на тестування ідей.

Мій робочий процес налаштований на невеликі ігри, але я вважаю ці речі корисними:

• Прототип-технологія  Мені здається корисним використовувати динамічну мову програмування та рамки, такі як Lua ( LÖVE приємно для 2D), JavaScript або Lisp / Scheme, де для отримання програми щось потрібно вимагає мінімальних натискань клавіш, навіть ціною всього іншого. Коли ви знаєте, що вам потрібно, і хочете вдосконалити його, оптимізуйте або перенесіть його на якийсь інший движок.
• Контроль версій  Зберігайте прототипи в сховищі, керованому версією . Гілка рано, гілка часто. Це дозволяє вам зручно пробувати речі, не переживаючи, що щось втратите чи забудете. (У Git є найдешевша модель розгалуження.)
• Автоматизація побудови  Переконайтеся, що вам потрібно зробити якнайменше, щоб реально розпочати роботу. На мій погляд, навіть НЕ потрібно натискати кнопку надто багато: я зазвичай є Makefileз make watchмішенню , яка працює inotifywaitв циклі, реагуючи на зміни файлів шляхом автоматичного складання / запуску гри. У інтерпретованій або JIT-компільованій мові це моментально.

Оскільки розробник зосереджується в основному на прототипуванні, ось дещо поради з мого досвіду.

1. Використовуйте двигун, який дозволяє швидко вносити зміни. Це включає в себе такі речі , як «Не чекаючи компіляції», але і «змінити становище речей під час виконання», «простота налагодження», «доступність тестових активів» і т.д. Я особисто люблю Unity3D, але це не найкращий інструмент там. Найкращий інструмент залежить від гри: наприклад, Unreal Engine компілює шлях коду повільніше, ніж Unity3D, але він може швидко запускати декілька підключених клієнтів. Для мережевої гри це часто компенсує витрати на компіляцію. Врахуйте також знайомство. Якщо ви чудернацький з C ++, навіть найкращий механізм Javascript не принесе багато користі, і навпаки. Не витрачайте час на боротьбу з незнайомими технологіями (я маю на увазі, вивчайте інші мови / рамки, але не одночасно з створенням важливих прототипів).
2. Навчіться нещадно бракувати наявні функції. Причеплення до речей, які ви вже реалізували, є анафемою для успішного складання прототипів, але відпускати свою роботу важко.
3. Якщо ви не працюєте з ігровим дизайнером, поставте чітку межу між "носінням шапки програміста" та "носінням шапки дизайнера". Додавання нової класної геймплейної функції здається дуже спокусливою, але не робіть цього, коли ви на посаді дизайнера. Скоріше спробуйте створити веселий ігровий процес (бажано, кілька варіантів) з тим, що у вас є; складіть список функцій, які допоможуть, а потім реалізуйте (деякі) їх.
4. Швидке прототипування передбачає балансування між двома протилежностями. Ви хочете зробити речі якомога швидше, тому ви пишете неправильний код. Але ви хочете якомога більше змінити речі, тому вам доведеться написати хороший код! Навчіться балансувати ці два. Вибачте, я не можу придумати жодних конкретних порад щодо того, як насправді це зробити, але принаймні пам’ятайте про цю проблему (-8

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

Можна розділити розвиток гри між цими чотирма фазами:

• прототипування
• вдосконалення ігрового процесу
• розвиток
• удосконалення виконання

Дослідження геймплея, я вважаю, трапляється в основному на етапі прототипування, і я радимо дотримуватися деяких порад:

• Почніть проектування з паперового прототипу. Отримавши чітке уявлення про те, якою може бути гра, починайте кодувати її, щоб реально відчути взаємодії. Можливо, це непотрібно для 3D-ігор, але особисто мені це дуже допомогло в минулому.

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

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

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

• Не витрачайте час на полірування чи пошук активів. Напишіть щось на папері, сфотографуйте його, виріжте в Photoshop, можливо, пофарбуйте його і використовуйте як спрайт. Увімкніть мікрофон і скажіть "pew pew". Покладіть два кубики і кулю разом, і у вас є робот. Завжди майте на увазі, вивчення можливостей ігрового процесу - ваш перший і єдиний пріоритет.

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

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

Зрештою, візьміть те, що у вас є, і налаштуйте його на використання менших ресурсів.

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

Я погоджуюся з відповіддю Тревора Пауелла, що швидкість ітерації є критичною для вас, щоб ви залишалися в творчому настрої, а не просто полірували. Великим джерелом натхнення для мене є розмова Брета Віктора "Винахід на принцип" . На жаль, на цьому рівні важко знайти справжні інструменти. Я спробував створити один для розробки Python, який дозволяє мені запускати свій код Python, коли я його набираю. Це називається Live Coding на Python .

Я створив інструмент для складання прототипів під назвою Trabant, який:

• немає 3D і ігрова механіка ТІЛЬКИ (без інтерфейсу, без тексту, нічого);
• для складання прототипу потрібно вкрай мало коду та відсутність активів;
• 3D-моделі створюються в коді за допомогою мистецтва ASCII ;
• дозволяє здійснювати піддруге ітерації;
• має підтримку симуляції твердого тіла;
• працює на Windows, Mac, Linux та iOS;
• використовує відому мову загального призначення, Python;
• має IDE для Windows та iOS.

Я побудував в ньому 30 тестових прототипів, щоб перевірити вищесказане.

Як підкреслив Тревор Пауелл, ітерації повинні бути <5 секунд, і я вважаю, що ітерації <1s майже в п’ять разів більші.:)

Анко зазначив, що використання динамічної мови є хорошою ідеєю, я вибрав Python, оскільки це одна з найбільш широко використовуваних . Що стосується автоматизації збірки, тестування в Trabant настільки ж швидко, як натискання F5 в IDE (або F6 для тестування його на вашому iPad), і оскільки немає жодного кроку збирання, він не отримує більше миттєвого, ніж цей.

Одноразовий код був один з фіги в виносі . Я повністю згоден, і Трабант це виконує.

Окрім швидкості ітерації Тревора Пауелла, яка справді важлива, ось деякі інші корисні міркування:

Це як хороший код ...

Багато ІФ там.

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

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

У будь-якому випадку прихильність до технології не має значення, якщо те, що ви шукаєте, можна імітувати без особливої ​​глибини - прототипуйте її на тому, що ви хочете / можете.

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

Це як ви будуєте масштабну модель. Хоча приємно мати мініатюрну репліку життя того, що ви хочете. Іноді його достатньо, щоб вирізати його з журналів, ручної роботи та склеїти шматки разом. Усі з роздумом уяви не збираються припускати, що ви дійсно будете будувати хмарочос із того самого картону, з яким показали модель масштабу. А в креативних галузях - її різновид переважніше працювати з людьми з деякою уявою. Якщо вони не зможуть оглянути минулі проблеми, щоб побачити потенціал за цілою концепцією, вони рідко, якщо коли-небудь оцінять продукт. Ніяка вдячність означає, що вони менш готові до виконання зобов'язань, і це низхідна спіраль. Його різниця полягає в налаштуванні ставлення вашого малюка до підкорення світу і замість того, щоб сказати: "Ви навіть не можете правильно пов’язати взуття, маленька дурня"

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

Я колись прототипував гру, використовуючи виключно gif-зображення і надаючи їм трохи спільного з javascript. Це не сліпуче, але воно служило меті показати те, що я хотів показати. Не має значення, чи згодом ви розробляєте його виключно для Xbox.

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