 |
| ru |
 |
17-10-07 @ 02:24
GameDev  : Kassandra  
О планировании работ.
|
В приведенном ниже материальчике указан один из примеров работы над проектом. Не берусь утверждать, что это единственно верный вариант построения работ, а равно не стану говорить, что тут описаны полностью все нюансы и возможное развитие событиый.
Основная мысль сабжа: "Планирование следует вести по этапам таким образом, чтобы в конце каждого из них был виден какой-то результат, придерживаясь определенной основной системы". Кроме того, она рекомендуется при конвеерном проектировании, так как можно более четко распределить ресурсы, чтобы конечный результат оправдывал затраты.
Да, и предупрежу сразу: букафф очень много :)
(оригинал)
"Формализация производственного цикла является эффективным методом управления средними и крупными (от 10 человек) коллективами разработчиков" © Архитектура и проектирование игр
[Под формализацией подразумевается ведение документации и четкое планирование. - прим.ред]
Своевременность выхода проекта напрямую влияет на его успешность. Проект, вышедший в "мертвый сезон" или одновременно с конкурирующими продуктами, принесет заказчику куда меньшую прибыль, чем этот же проект, выпущенный в верный срок. Это аксиома.
Второй момент, который влияет на успешность проекта - это возможность прогнозировать завершение того или иного этапа разработки - соответственно, в дальнейшем это возможность вовремя начать PR-кампанию. Кроме того - это является требованием, если Вы хотите рассчитать бюджет и вообще сдать проект. Нельзя строить железную дорогу из пункта А в пункт Б, не обладая информацией о направлении и пути следования.
Прогнозируемость процесса разработки зависит от того, насколько Вам удалось распределить ресурсы и расставить приоритеты.
Распределение ресурсов возможно только при наличии перечня работ (концепт-документация), оценки трудозатрат и объемов. Исходя из этого уже строится полноценный график работ. О нем чуть ниже.
Расставить приоритеты можно при наличии features list (список особенностей, которыми обладает игра вообще, отличается от схожих продуктов) и USP (unique selling points - уникальные позиции, обеспечивающие продажи, в отличие от Features List более конкретизированы, и этот список крайне нежелательно сокращать, так как он является базовым документом для организации PR кампании).
Как только у Вас расставлены приоритеты, и Вы определились с особенностями проекта, можно начинать планировать работу над продуктом. Обычно этот процесс занимает от полугода до нескольких лет, в зависимости от сложности - AddOn с вероятностью в 99% процентов будет выпущен раньше, чем полноценная версия.
Но в любом случае, даже пол года - это достаточно большой срок. Особенно, для нашего менталитета -все мы хотим иметь возможность видеть то, что мы делаем, какие-то результаты. Если этих результатов нет, то мораль в коллективе падает, падает работоспособность и эффективность, теряется мотивация. Это ведет к задержке сроков, снижению качества, уходам сотрудников, дополнительным затратам, и как следствие - срыву конечного срока разработки и бюджетирования. Повезло, если издатель игрового продукта относится к разработчику лояльно и может себе позволить расширить бюджет, и все же выпустить игру. А если нет? Думаю, результат понятен, и таких случаев в практике разработки игр масса.
Происходит это, прежде всего, из-за отсутствия приоритетов задач, из-за отсутствия так называемых milestones (ключевых точек разработки, этапов), то есть, из-за неверного планирования. В данном случае подразумевается стратегическое планирование по этапам. Сразу оговорюсь, что не считаю разумным планирование только "по задачам отдела" без назначения этапа сборки - milestone, так как рано или поздно Вы запутаетесь, что происходит в проекте, и что на самом деле готово, не сможете прогнозировать дату конечной сборки, отделы не смогут нормально координироваться между собой, и большая часть работы будет сделана в пустую, но зато в "награду" Вы сможете получить "бонус" - потерянность в цели. Нельзя ставить один ориентир на период, более, чем месяц, так как глобальные цели слишком эфемерны для их достижения.
Пример с некорректным планированием (по аналогии):
Вам нужно построить дом. Вы знаете, что дом должен быть высотным (самый высокий в городе!), квартиры просторными (примерно в таком-то метраже и соответствующие таким-то требованиям), строиться он должен 2 года, и потратить на постройку можно сумму n. Для постройки дома Вам нужны несколько отделов - строительство (по сменам с главным по смене), архитекторы, закупщики оборудования и материалов (известно, что материалов определенное количество), бухгалтерия... ну, допустим, остальное вам предоставляет заказчик. А теперь представим развитие событий, если Вы просто выдадите задание всем - делать свою часть работы. К чему это приведет? Кто-то работает быстрее, кто-то представляет себе работу под другим углом, кто-то привозит материалы тогда, когда сочтет нужным (но предупреждает об этом), каждая смена при этом воспринимает требования по-своему - для кого-то высокий потолок - это 3 метра, для кого-то -4... кто-то цемент мешает в одной консистенции, кто-то в другой. И так далее. Что Вы получите в результате? Получите здание, которое может быть даже будет функционировать. А может, развалится. А может, Вам не хватит денег на строительство. А может, оно случайно получится качественным, и даже почти в срок. По стечению обстоятельств и взаимоподдержке всех участников строительства. Но стоит ли при затевании такого предприятия полагаться на случай? Решать Вам..
Планировать разработку лучше всего по этапам, по достижению которых происходит "контрольная сборка", благодаря которой Вы можете посмотреть, что же у вас получилось, и в каком курсе дальше действовать. Кроме того, это Вам позволит вовремя найти и ликвидировать возможные ошибки. Речь не только об ошибках кода, но и об ошибке архитектуры, концепции и баланса.
При планировании не забывайте, что детально можно запланировать только ближайший этап. Дальнейшая работа может быть намечена "пунктиром" или тезисно целями. Только в таком случае это будет эффективно.
Примерные этапы разработки
Pre-Production
Этот этап предназначен для того, чтобы определиться с основным курсом, попробовать разные варианты, определиться со списком всех необходимых работ и элементов (предполагается, что на этом этапе фичелист уже есть в наличии), разработать основную архитектуру взаимодействий процессов, детально проработать концепцию проекта, и создать базовый эскизный проект, который в дальнейшем должен вырасти в полноценную проектную документацию (в том числе, дизайн документация). На этом этапе не стоит тратить силы на все мелочи. Нужна общая картина и канва, по которой Вы будете работать. Так же, этот этап можно спокойно тратить на поиск "недостающих звеньев" и дополнительный, более полный анализ рынка и аудитории, ну и естественно, обеспечение материальной и технической базой. Закладывать на этот этап лучше не менее месяца.
Demo version (Прототип)
Основными задачами этого этапа являются: создание прототипа проекта, наметка основных модулей, проработка нюансов игры. Здесь опять же не стоит углубляться слишком сильно в детали, а нужно проверить играбельность и возможность реализации тех или иных вещей. Этот этап сопровождается постоянным ведением дизайн документации, поправками и ликвидированием критических ошибок геймплея. После завершения этого этапа дальнейший процесс должен быть полностью утвержден. Не должно оставаться вопросов "как?" и "что?" по основным параметрам. С этой версией Вы уже можете спокойно отправляться к издателю, если на начало работ у Вас его не оказалось, но его присутствие необходимо.
Technical Demo (n) - количество этапов зависит от сложности проекта и количества модулей, необходимых для разработки
С каждым последующим этапом (n) у Вас должны появляться новые модули, новые возможности и новый арт, все изменения должны быть задокументированы. При этом вопрос цифрового вида баланса (статы, величины урона и прочее) не ставится за критическое требование, но его прототип так же должен постепенно обретать черты. Базовый баланс должен быть уже в последней технической демке. Не стоит разбивать работу над этапами более, чем 2 месяца.
Alpha Version
На этом этапе у Вас уже должны быть готовы все основные модули, написан весь код, который Вы хотели внести в проект. В эту игру уже можно играть, и теперь пришло время поработать с балансом и отладкой механизмов. Так же на этом этапе можно рассмотреть возможность внесения дополнительных фич или же наоборот сделать фиче-кат (если не успеваете проработать какую-то часть или же увидели, что она не так хорошо выглядит в композиции с остальными элементами). По завершению этапа у Вас должны быть устранены все базовые ошибки, и игра должна быть "практически готовой к выпуску/запуску". Кроме того, это этап, когда полноценная PR кампания должна начинать набирать обороты. До этого возможны предварительные анонсы, но без особой детализации.
Beta Version
Здесь у Вас на руках фактически, готовый продукт. Самое время проводить фокус-тестирование, тестирование на устойчивость системы, соответствие требованиям, да и вообще, полностью проверить проект с привлечением хотя бы группы тестеров. Или же выпуском "урезанной" версии игры на просторы открытого тестирования. Для разработчиков и издателей онлайн игр дело обстоит проще - время начинать открытое бета-тестирование, которое можно разбить еще на 2 этапа - для ограниченного числа людей (проверка на основные баги и недокументированные возможности), и полноценное открытое тестирование (проверка на устойчивость системы, баланс и прочее).
Gold Version / Release
Это запуск проекта в массу. Здесь от Вас, как разработчика, потребуется только внимательность к требованиям аудитории, написание постмортемов (для себя, на будущее), анализ проведенных работ, и возможно, выпуск патчей и подготовка AddOn. Если речь идет о single-player.
Если речь идет об MMO, то тут уже проектом занимается support. От которого потребуется своевременное реагирование на настроение целевой аудитории, анализ ситуации, отлов багов, решение о написании новых модулей.. и прочее, и прочее.
На последок замечу, что все выше сказанное является моим мнением. У кого-то могут быть другие способы работы, но имхо, так удобнее.
Кроме того, "наворачивая" новые витки проекта не забывайте оценивать в конце каждого этапа, насколько это удачные решения, првоодите фокус-тесты на близких и знакомых, обращайте особое внимание на интерфейс и соответствие требованиям целевой аудитории. В общем, не забывайте за деревьями леса ;)
Mood: сонное Music: Nightwish |
Post reply | Post reply with quote
|
 |
