Spiiin's blogВ геймдеве процесс производства контента часто разбит по этапам производственного конвейера. Это удобно, потому что отдельный арт или целые уровни могут интегрироваться в игру в промежуточном виде — сначала в виде кубиков, затем грубыми черновыми моделями, и далее всё ближе к финальному качеству контента.
- Паттерны организации разработки уровней игр — про организацию процесса. Хорошие гейм-дизайнеры понимают, что на каких стадиях в игре уже должно быть зафиксировано, чтобы на это могли опираться другие команды, а что предполагает изменения.
С кодом я чаще встречал подход, при котором ответственность разделяется на уровне фич. Кто-то делает систему анимаций, кто-то занимается gui, кто-то тулзами и т.п. У такого разделения много плюсов — накапливается экспертиза, и при грамотном разделении подсистем команды почти не зависят друг от друга.
Но бывает и разделение по стадиям конвейера и у программистов. Кажется, у этой схемы есть какое-нибудь красивое название, типа stage-based development pipeline, но я его не знаю.
Условно, отдел прототипирования фич набрасывает рождественский ивент, передаёт отделу интеграции фич в игру, который передаёт отделу полировки, затем отдел оперирования запускает её в прод и гоняет всякие а/б тесты и запуски по расписанию. Из плюсов — можно попробовать отдавать менее важные стадии и фичи более слабым командам или вообще на аутсорс.
Из минусов — нагрузка на разных стадиях конвейера никогда не будет равномерной. Если на начальных этапах может быть интересно, то ближе к концу начинается ад с тем, что туда сыпятся все баги, горят сроки и ругаются продюсеры. Причём подключить авторов багов к решению часто нельзя — они уже вовсю занимаются следующим обновлением.
И всё это, сделанное условно более слабыми или аутсорс командами, должно быть допилено на последних стадиях. Только, в отличие от арта, с кодом редко выходит так, что черновой набросок после нескольких итераций становится очень качественным, особенно в условиях цейтнота по времени. Зачастую наоборот, в процессе прохождения по конвейеру код становится менее отполированным, обрастая обработчиками особых случаев, доработками — происходит накопление технического долга.
Также программисты в такой схеме более отчуждены от продукта (а что именно в этой игре я вообще сделал?), новички дольше разбираются, как всё устроено (мимо тебя пролетают задачи из совершенно разных частей игры, часто которые ты вообще ещё не видел), а менеджеры стараются переключать какие-нибудь команды на последние стадии конвейера, потому что задачи там виднее бизнесу, или убрать этапы, которые бизнесу не видны.
Но, похоже, такое деление даёт плюсы в более предсказуемом Live-Ops, а также в ограничении бесконечного роста команд с ростом фич. И скорее всего проверено в других сферах условные 10-15 лет. Так что возможно такой подход станет мейнстримом и в геймдеве.