Масштабный итеративный дизайн

8

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

Как сократить итерации дизайна для крупномасштабных проектов?

design-patterns development-speed

— newton1212
источник

1

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

— JPtheK9

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

— Fuhrmanator

это тема обмена стеками программистов.

— v.oddou

4

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

Кроме того, имеется хороший конвейер искусства / ресурсов, который прост в использовании и легко вводит ресурсы в игру.

В основном, устраните препятствия для людей, выполняющих свою работу, и оптимизируйте их рабочие процессы.

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

— Алан Вульф
источник

+1. Так что в разработке игр нет острых углов, но с опытом их становится проще. :)

— newton1212

2

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

— Алан Вулф

3

Timeboxing означает, что итерации не становятся длиннее

Вы спрашиваете, как сократить итерации. Но это означает, что они занимают больше времени, а значит, вы не применяете бокс времени. В любой итерации, когда сложность начинает весить больше (или у вас есть другие непредвиденные неудачи), вы не меняете длину итерации. Вместо этого вы отказываетесь от добавления, которое вы запланировали в начале итерации. Некоторые итерационные методы предлагают выполнять эту оценку в середине итерации (пока не стало слишком поздно). Узнайте больше о том, что предлагает OpenUP :

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

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

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

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

Языки сценариев и автоматизированные процессы помогают снизить риск сложности, который можно назвать «случайной» сложностью (и обсуждается в другом ответе). Высоко итеративные, но сложные проекты (хороший пример - Chromium, даже если это не игра) имеют много инфраструктуры для управления сложностью. Посмотрите на https://www.chromium.org/developers множество примеров таких вещей, как советы по кодированию для BuildBot .

Риск уменьшается со временем На этом рисунке не показана стабильность проекта, которая выглядит примерно так:

Проект становится более стабильным со временем

Пока технические риски не будут хорошо поняты, вы имеете дело с простыми прототипами

— Fuhrmanator
источник