Как вы готовитесь к ползучести?

Как я могу подготовиться к ползучести во время подготовки производства?

Ползучесть функций - это когда вы находитесь в фазе производства и решаете: "Было бы круто, если бы это была функция!" Это добавляет n часов к времени разработки, которые не были учтены, и, если вы не Blizzard, у вас нет времени для. Вы не можете ожидать, что это будет отличная функция во время подготовки производства, потому что эта функция обнаруживается только в процессе производства.

Что я могу сделать во время подготовки производства, чтобы учесть, предотвратить или подготовиться к ползучести функции?

Должен ли я позволить ползучести функции и обрезать менее нужные функции? Или это создаст проблемы, так как архитектура не предназначена для новых функций? Должен ли я сказать, что нет функций, если они не вписываются в существующую архитектуру?

Я знаю, что это широкий вопрос, но я надеюсь, что он не будет закрыт как таковой. Это основная проблема в разработке игр, и ее следует учитывать.

Хотя, конечно, нет жестких правил, когда дело доходит до подготовки производства, существует множество эвристических методов, которые могут помочь. Некоторые особенности ползучести являются естественными и необходимыми - ни один план не выживет при первом контакте с реальностью, и вы можете не знать, что будет «круто», пока не увидите его.

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

Это следует из метода MoSCoW , посредством которого вы классифицируете функции следующим образом:

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

В идеале вы хотите, чтобы развитие было прогрессивным усовершенствованием, а не «все или ничего». Работая в конечный срок, наименее важные функции должны быть доведены до конца, так что все, что вы не получите, будет материалом, который можно вырезать. Обязательно оцените, сколько времени потребуется каждой функции для разработки и уточнения этих оценок по мере продвижения. Никогда не сжимайте расписание, чтобы освободить место для дополнительных функций. Не допускайте переноса сроков (итеративных или окончательных) в будущее - вместо этого перемещайте или сокращайте элементы, если это возможно. Если вы подходите к своему крайнему сроку, а игра по-прежнему остается беспорядочным, то вы знаете, что пришло время серьезно пересмотреть свои решения и подумать о каннибализации проекта, прежде чем он превратится в пропасть времени / денег.

• Планируйте использовать часть доступного времени подготовки к работе для базового набора функций.
• Базовый набор функций должен быть с низким уровнем риска, с высокими наградами, так что вы не будете ползти по этим
• Базовый набор функций минимален и не подлежит обсуждению - они должны присутствовать - в противном случае нет твердой основы для работы, и вы будете пронизаны неуверенностью в себе / синдром «должен ли я заменить это»
• Убедитесь, что самые ранние итерации вашей игры достаточно привлекательны, чтобы вы могли позволить себе ползучесть функций. Фундаментально не впечатляющая игра не собирается делать это далеко, не говоря уже о ползучести.
• Заранее знайте, какой предел ползучести вы можете себе позволить, чтобы использовать его с умом.
• Используйте готовые, высокообобщенные технологии, такие как Unity, и используйте их канонически, чтобы повысить гибкость, чтобы ползучесть функций не оказала слишком сильного влияния на существующую архитектуру.
• Не создавайте сложные подсистемы - здесь подходит подход eXtreme Programming
• Попросите других (дизайнеров и программистов), чьи мозги вы можете периодически нажимать, чтобы помочь вам расставить приоритеты, какие функции вы позволите ползти, кто-то должен был проверить ваш код в качестве основного пункта для этих вопросов.
• Вам все равно придется ограничивать ползучесть объектов, поэтому постоянно расставляйте приоритеты и знайте, где провести черту

В конечном счете, это не то, что я бы посоветовал новичкам, потому что вы должны уметь принимать правильные решения на каждом этапе, а это непросто даже для самых опытных. Если вы не уверены в правильности принимаемых решений, придерживайтесь строгой политики «не выходить за рамки этой точки».

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