Итеративный контент
После пресловутого объединения и «возврата» из контрактной разработки игрового контента в реальное проектное производство первый серьезный вопрос, занявший все процессорные мощности мозга, встал в том, как совместить производство контента и итеративную модель разработки.
Все эти Agile’ы, Scrum’ы, XP и прочие подходы придумали программисты сами для себя, дабы структурировать слабо структурируемый процесс разработки ПО. Например, я себе слабо представляю итеративное строительство небоскреба, или итеративную съемку фильма. Продукт, получаемый в конце таких процессов, может быть довольно четко описан (например, в проектной документации или сценарии), а потому любые попытки итерационных декораций будут просто маскировкой «водопада».
С игровым контентом несколько сложнее. Игра, в конечном итоге, это программа, где можно отказаться от части функционала, что повлечет изменение требований к контенту. Да, контент можно зарезать, но это уже опять же не итеративность — это банальный фичекат, только для контента.
Вопрос возникает с планированием итеративности производственного процесса разработки ассетов. Как показывает практика, не всегда можно разделить по релизам отдельные модели. Содержание моделей, их настройка и т.п. может зависеть от текущих реализованных технологий, которые разрабатываются как раз итеративно. Исходя уже из этого, возникает необходимость определять итерации производства отдельных моделей. И в отличие от программирования, делать это приходится в явном виде, иначе можно потом запутаться какая модель или карта осталась в каком состоянии.
И выделяя эти явные итерации моделей, их, по идее, можно разделять по проектным итерациям, релизам и т.п. и ставить в производство.
Если кто-то что-нибудь понял, что я хотел сказать — дайте знать.
Саша, вроде бы все понятно
Насчет программирования. Здесь есть одна хорошая штука, которая помогает разобраться что в каком состоянии осталось. Если взять в пример XP и подход TDD (Test Drive Development), то там тесты выступают в качестве описания того, в каком состоянии у тебя модуль/класс и т.п.
При этом тебе не обязательно реализовывать все сразу и запоминать, что ты уже реализовал. Если что-то забыл: смотри в тест, в код.
Тесты позволяют в любой момент убедится: не сломана ли система, выполняются ли все требования (функциональные или интеграционные тесты). Этим обеспечивается возможность итерационности и непрерывности разработки: выяснили требование, добавил фичу, протестили, починили - вот тебе новый релиз, итерация.
Документация здесь лишняя. Т.к. поддерживать её в актуальном (по настоящему) состоянии, как ты знаешь, очень тяжело. XP и гибкие методики говорят: путешествуй на легке.
Знаешь, можем это как-нибудь обсудить при встрече. А то кажется, что я не совсем в тему