Як ви готуєтесь до повзучості?

Як я можу підготуватися до повзучості під час попередньої постановки?

Можливість повзання - це коли ти перебуваєш у фазі виробництва та вирішуєш "Було б здорово, якби це була особливість!" Це додає n годин на час розробки, які не враховувались, і якщо ви не Blizzard, не маєте на це часу. Ви не можете передбачити, що вона є цікавою особливістю під час попередньої постановки, оскільки ця функція виявляється лише під час виробництва.

Що я можу зробити під час попередньої постановки для обліку або запобігання або підготовки до повзучості фільму?

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

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

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

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

Це випливає з методу MoSCoW , за яким ви класифікуєте такі функції:

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

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

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

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

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