Разделы портала

Онлайн-тренинги

.
Методологии творчества
29.09.2008 10:13

Автор: Андрей Грищенко

Источник публикации: DFT.RU

Менеджер внешних проектов отдела игровых и мультимедийных продуктов фирмы «1С», рассуждает о том как делаются игровые проекты.

  Статья рассказывает о разных подходах к созданию программных проектов («каскад», RUP, MSF, экстремальное программирование), а также сравнивает разработку игр с созданием «обычного» ПО и кинофильмов.

Итак, больной вопрос: что же мы делаем — хорошо продаваемый продукт, товар, или мы делаем игру своей мечты?

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

Итак, делаем хорошие игры!

Но как сделать хорошую игру? Почему некоторые игры получаются хуже, чем виделось в начале самим разработчикам, их издателям и будущим игрокам?

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

Теорема: разработать хорошую игру сложно.

Доказательство: Разработка игры — это проектная разработка. Что значит «проект»? Проект — это деятельность по достижению поставленных задач (создание уникального продукта) при ограниченных временных, человеческих и финансовых ресурсах.

В игровой разработке даже сама цель не всегда четко и однозначно определена. Не всегда в начале разработки четко понятно, что же получится в конце. Почему так?

Разработка просто программных продуктов — достаточно сложный процесс. Разработка игр — еще более сложный процесс по следующим причинам:

  • Планка качества все время растет, технологии растут еще быстрее
  • Игра — это во многом продукт творческий, результат духовных усилий творческих людей, а потому в ней будут плохо формализуемые элементы
  • Игра — это продукт с очень трудоемкой составляющей, контентом: графикой, звуком, текстом
  • Игровая индустрия молода, мы часто ходим непротоптанными дорогами, риски всегда есть и они часто высоки (правда, бывают высоки и вознаграждения за эти риски)

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

Даже из Blizzard вице-президенты уходят с формулировкой «из-за многолетней рутинной работы по доводке игровых продуктов» (Аллен Эдхем). Надо быть готовым к тому, что момент ощущения рутины когда-нибудь наступит — тогда это не будет для вас сюрпризом.

Вы еще не передумали делать игры, причем хорошие? Если не передумали — замечательно!

Так «кто виноват?» Виновато то, что ресурсы (деньги, люди, время) всегда ограничены, а работы всегда больше, чем кажется. И «что делать» сразу становится понятно — эффективно использовать имеющиеся ресурсы. Но для этого надо понять, как это — эффективно? Про это говорил еще один классик: «Учиться, учиться и еще раз учиться».

Учиться эффективно работать можно по-разному: самостоятельно по книгам, в образовательных учреждениях, на своем и на чужом опыте.

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

Попробуем учиться у «смежных» индустрий. Что у нас с вами за смежные индустрии — понятно: это разработка делового ПО и кинематограф. Давайте попробуем посмотреть, как работают они.

Производство игр похоже на кинопроизводство, потому что игры:

  • Развлекательный аудиовизуальный продукт
  • Содержат значительный объем работ по производству контента

Производство игр НЕ похоже на кинопроизводство, потому что:

  • Игры интерактивны и нелинейны
  • Производство обходится не так дорого, как съемки
  • Видеоигры — относительно молодой тип развлечений
  • Есть геймплей (игровой процесс)

Производство игр похоже на разработку делового ПО, потому что это:

  • Программный продукт (немного пунктов, да?)

Производство игр НЕ похоже на разработку делового ПО, потому что:

  • В играх есть значительное количество содержимого помимо программного кода (контент);
  • Предназначение — развлекательное, «одноразовость» продукта;
  • Есть геймплей — игровой процесс (опять!)

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

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

Итак, все тот же автор может перечислить следующие методологии разработки ПО, с которыми он сталкивался лично. Вот они:

 

Давайте рассмотрим, что нам предлагают это методики и что мы можем из этого почерпнуть.

Каскад (водопад)

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

Обычная игровая разработка идет примерно так же — концепция, дизайн-документ, собственно производство и пост-продакшен; потом — тестирование всего, что получилось. А получается не всегда то, что хотелось бы — об этом мы уже говорили выше.

А что, бывает как-то по-другому? Да, бывает.

Все другие методики предполагают не одноразовую последовательность этапов, а итеративную последовательность. Это уже интересно. Поэтому давайте посмотрим, что же еще имеется в нашем меню.

RUP (Rational Unified Process)

Что это такое и что нам это даст? Ключевое слово здесь — Unified Process, то есть унифицированный процесс (подразумевается создание ПО, но не только).

Чем это нам интересно? Думаю, этим:

  • RUP — это обобщенный многолетний опыт ведущих разработчиков программного обеспечения, его не стоит недооценивать
  • Это наиболее полный набор концепций, которые, так или иначе, присутствуют в других методиках. Даже работа разработчика-индивидуала, делающего игру полностью самостоятельно, может быть описана RUP
  • Единый язык моделирования — UML (Unified Modeling Language). Средство единообразного выражения архитектурных и концептуальных идей, логики и последовательности процессов, взаимодействия элементов. Рекомендуется геймдизайнерам и программистам

Кстати об UML. Вот как с помощью этой методики можно, например, показать, как игрок взаимодействует с игрой:

Или вот как работает сеанс сетевого режима:

Несмотря на перечисленные достоинства и потенциальную интересность RUP, не стоит не принимать во внимание некоторые сложности, связанные с его использованием, а именно:

 

  • Когда все универсальное, появляется много лишнего
  • Когда все универсальное, трудно найти что-то конкретное

(!)

 Секрет — в грамотной адаптации понятий RUP к конкретному проекту.

MSF (Microsoft Solution Framework)

Адаптация Microsoft, свое видение процесса разработки, основанное на опыте (немалом, да?) разработки ПО.

В общем, все как у классиков, но хотелось бы обратить внимание на два интересных момента:

 

  • Отсутствие понятия «Менеджер проекта» (смело, не правда ли?)
  • Наличие фазы «стабилизация», которая включает в себя тестирование, разумеется

Немного об этих особенностях.

Единственного менеджера проекта замещает в MSF «ролевой кластер», который в нашем с вами случае может выглядеть как сообщество лидов: главный художник, главный программист и главный геймдизайнер. Преимущества в этом такие, что нет узкого места — перегруженного менеджера; решения принимаются коллегиально и решения эти гарантированно компетентны. Три головы — не одна, думают они почти в три раза лучше и быстрее. Это немало.

Но есть и сложности, конечно, а точнее — ограничения. Эта схема будет работать, когда все три лида одинаково компетентны (в своих областях), ответственны и вообще работают как слаженная команда.

Стабилизация — это фаза, которая определяет деятельность по стабилизации полученного продукта. Здесь подразумевается и тестирование, и его завершение. Вводится два основных понятия — точка конвергенции и точка «безошибочности". Главное достоинство этих показателей — их легкая измеряемость.

Синяя кривая — это количество открытых (обнаруженных и еще не исправленных) ошибок.

Точка конвергенции — это «свет в конце тоннеля», хороший индикатор того, что проект стабилизируется (ну, или того, что тестеры совсем разленились).

Точек безошибочности, как видно, бывает много. Таким образом, ориентируясь на частоту достижения точки «безошибочности», можно судить о готовности проекта.

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

Смысл этого рисунка такой: «Мы делаем быстро, качественно и недорого! Выберите два пункта из трех!».

XP (eXtreme Programming)

Хотя в названии этой методики выведено слово «programming», тем не менее, ее можно рассматривать в общем смысле как процесс разработки.

Чем интересен метод XP? А тем, что его основная область применения — проекты, где степень неопределенности требований высока и представление о желаемых результатах весьма размыто. То есть, это проекты с высокой степенью риска. А как мы уже говорили выше, в геймдеве они встречаются особенно часто.

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

Вот «12 практик XP», которые и являются его столпами:

  1. Планирование на основе опыта
  2. Частые сборки с небольшим увеличением объемов разработки
  3. Метафоры
  4. Простота дизайна
  5. Тесты перед реализацией
  6. Постоянный refactoring
  7. Парное программирование
  8. Коллективное владение ресурсами (кодом)
  9. Постоянная интеграция
  10. 40-часовая рабочая неделя
  11. «Заказчик с нами» — тесная обратная связь
  12. Стандарты

Обсуждение, даже краткое, этих практик выходит за рамки этой статьи — все это можно найти в Интернете, литературе или докладах КРИ. Я бы хотел только выделить 3 практики, на которые стоит обратить внимание (ах, где ты, 40-часовая рабочая неделя?)

«Частые сборки с небольшим увеличением объемов разработки». Это дает нам рабочий продукт с постоянно наращиваемой функциональностью/содержимым. Скелет, обрастающий мясом. Это снижает риски, устраняя те самые долгие «мертвые» периоды, когда «все разобрано».

«Постоянная интеграция». Интеграция — это узкое место процесса, «бутылочное горлышко». Не очень хорошо, если аниматор неделю не может посмотреть на свою анимацию в движке, не правда ли? Налаживание этого процесса и его осуществление на постоянной основе улучшает взаимодействие между участниками проекта и, опять же, дает более раннее ощущение результативности своих действий.

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

Тем не менее, не стоит забывать и о трудностях использования XP, в частности, следующих практик:

«Коллективное владение» — тут опасность такая: «У семи нянек дитя без глазу». Думаю, пояснения не требуется — когда нет владения, нет и центра ответственности. Такова сущность человеческой психики.

«Постоянный рефакторинг» — уменьшение общей производительности. То есть делая много мелких шагов, мы делаем в результате много лишних.

«Парная разработка» — не всегда возможна плюс здесь очень много психологических и других барьеров.

«Написание тестов перед реализацией» — для игр это иногда вообще неприменимо. Но это отдельная тема для разговора.

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

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

Так вот, раз существующие методики разработки ПО не устраивают геймдев целиком и полностью, давайте попробуем сделать некоторую смесь (соль, перец — по вкусу).

Итак, все вышеперечисленные методики делают акцент на следующих элементах:

  • Цикличность, итерационность. Нельзя играть в гольф на площадке 100 на 100 километров и выстраивать формулу точного попадания мячиком в лунку из одного края в другой. Единственный способ — последовательно приближаться к цели, увеличивая точность и корректируя ошибки.
  • Планирование. Все, что не запланировано, является незапланированным. А разница между словами «не запланировано» и «незапланированный» огромная. Первое — констатация факта, второе — уже потенциальная угроза.
  • Ориентация на заказчика (в нашем случае — игрока). Игрок — царь и бог. Все — ради него. Особенно в играх. И поверьте, миллионы счастливых игроков могут сделать вас богатыми на многие годы!

Чем больше компания-разработчик, тем важнее для нее обратить внимание на эти методики. В крупных проектах (от 20 человек) уже могут быть эффективными элементы RUP — разделение проекта на фазы, формализация документации проекта, UML и другие.

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

Из XP стоит попробовать его гибкость, регулярные сборки и постоянную интеграцию. Это позволит наладить очень хорошие отношения с вашим издателем (ранняя и постоянная демонстрация прогресса). Частая адаптация по результатам оценки не позволит «сесть не в тот поезд».

Автор скромно надеется, что в данной статье некоторые читатели найдут что-то интересное и полезное для себя.

Tags: