Топ за месяц!🔥
Книжки » Книги » Разная литература » Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан 📕 - Книга онлайн бесплатно

Книга Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан

37
0
На нашем литературном портале можно бесплатно читать книгу Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан полная версия. Жанр: Книги / Разная литература. Онлайн библиотека дает возможность прочитать весь текст произведения на мобильном телефоне или десктопе даже без регистрации и СМС подтверждения на нашем сайте онлайн книг knizki.com.

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 72 73 74 ... 130
Перейти на страницу:
Конец ознакомительного отрывкаКупить и скачать книгу

Ознакомительная версия. Доступно 26 страниц из 130

иногда кажутся угнетающими. Лично я не могу выкладываться на полную, когда чувствую, что за моей работой неустанно следят. Хорошие менеджеры проектов управляют командами, используя методы, которые помогают отдельным разработчикам работать уверенно, и они избегают систем, которые мешают атмосфере доверия и уважения.

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

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

* * *

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

Как только вы освоите базу, описанную в этой главе, вам предстоит узнать еще больше о планировании проекта цифровой игры. Профессиональные продюсеры в больших командах часто используют сложные системы планирования, и вы, возможно, захотите узнать о диаграммах Ганта, которые используются для отслеживания зависимостей между задачами. Вы можете найти передовые идеи о планировании проектов в таких книгах, как Agile Game Development: Build, Play, Repeat Клинтона Кита и The Game Production Toolbox Хетер Максуэлл Чандлер.

Вы также можете ознакомиться с инструментами планирования, входящими в состав программных пакетов по управлению проектами, таких как Asana, Basecamp, HacknPlan, Jira Software, Monday и Trello. Мередит Холл обсуждает эти инструменты и многое другое в своей статье Choosing a Project Management Tool for Game Development[133] для Gamasutra. Вы также можете найти недорогие или бесплатные инструменты управления проектами в интернете, например Top 7 Open Source Project Management Tools for Agile Teams, перечисленные на opensource.com[134].

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

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

Глава 20

Обзор майлстоунов

Культура игр полна того, что я называю сообществами обзорщиков на всех уровнях создания и прохождения видеоигр. Профессиональные обзорщики игр влияют на решение своих подписчиков, покупать ли игру. Игроки публикуют пользовательские обзоры на сайтах-агрегаторах и игровых сервисах. Медийные персоны рассказывают об играх, проходя их в прямом эфире на стримах. Издатели обозревают игровые проекты, за разработку которых они платят, и в целом существует множество различных способов, которыми издатели и другие заинтересованные стороны дают обратную связь команде разработчиков. Команды разработчиков проводят внутренние обзоры своих незавершенных проектов. Сам обзор встроен в итеративный цикл дизайна – разработки – плейтестов – анализа – дизайна, который мы обсуждали на протяжении всей этой книги (обзор тут назван анализом). Например, каждый член команды постоянно обозревает собственную проделанную работу – мы обсудим это в главе 23.

В этой главе мы сосредоточимся на обзоре всего проекта, который проводится на основных этапах – майлстоунах – проекта. Мы рассмотрим тип обзора, который объединяет команду разработчиков (или определенных членов команды, включая ее сеньоров) с группой не входящих в команду людей, которые, знакомясь с игрой, дают некоторые советы.

Когда проводить обзор майлстоуна

В процессе разработки игр обзоры проводятся на следующих этапах:

• окончание препродакшена;

• майлстоун альфа-версии;

• майлстоун бета-версии.

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

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

Внутренние и внешние обзоры майлстоуна

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

Ознакомительная версия. Доступно 26 страниц из 130

1 ... 72 73 74 ... 130
Перейти на страницу:

Внимание!

Сайт сохраняет куки вашего браузера. Вы сможете в любой момент сделать закладку и продолжить прочтение книги «Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан», после закрытия браузера.

Комментарии и отзывы (0) к книге "Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан"