Мой доклад для UAFPUG 2010 в Харькове : “Рабочий процесс инди-игродела”
18.04.2010, автор Stormit, рубрики: Flash игры, НовостиВ последнее время не получалось написать что-то интересное, просто физически нет времени. Но я рад, что блог всё это время жил собственной жизнью, - люди общаются через комментарии помогая друг другу. Это прекрасно, это заряжает позитивом и мотивирует что-то всё-таки написать.
Начну с доклада для UAFPUG, который проходил на днях в Харькове (отдельное спасибо gamezhero за организацию встречи). Целью встречи был обмен опытом построения рабочего процесса в игровой флеш-индустрии. Я представлял Инди-разработчиков 
Честно говоря я никогда себя так не называл, но как оказалось, соответствую этому типу, когда делаю игры для дальнейшей монетизации. Основное отличие от фриланса и разного рода компаний в том, что сроки создания игры я определяю для себя сам и они могут плавать, если додумываю что-то интересное. Ещё есть разного рода риски, но сосредоточимся на позитиве.
Ниже я привожу презентацию и тезисы, по которым я строил свой доклад. Это исключительно мой опыт, поэтому я с удовольствием выслушаю все замечания.
Инди-разработка
1) Структура компании
- нет как таковой, нет отделов, есть контакты людей которые что-то могут
- рабочее место, софт, график работы
- общение через почту, аську, скайп, личные встречи
- стандартная связка - программист + художник-аниматор + озвучка
- на проект берутся незанятые люди, которые наиболее подходят по стилю (графика, звук) - один состав от начала до конца
2) Управление командой
- все равны, директоров нет, есть организатор
- организатор выполняет наибольшее количество разноплановых задач
- финансовые потоки в руках организатора
- мотивация - деньги, опыт, свободное время (Слава и почёт воспринимается как приятный бонус)
- исполнителям должна нравиться задача - у каждого есть свобода улучшения игры по его желанию
- людей нужно всё время “тормошить”
- заказчику сказать - месяц, исполнителям - 2 недели
3) Работа над проектом
- Идея вынашивается 1-2 месяца до начала разработки
- Идея обсуждается с художником, формируем общее видение
- Кто-то один, обычно инициатор идеи, берёт на себя функции гейм-дизайнера
- Он придумывает предысторию к игре, характеристику персонажей, создаёт концепт
- Формирует ДизДок на игру в текстовом виде - основные понятия
- Художник создаёт наброски чтобы утвердить графический стиль
- Структура классов рисуется на бумаге в виде дерева. Отражает иерархию классов, взаимодействие и тип передаваемых данных. Этого достаточно, остальное в голове
- Код и графика разделены - графическая часть в SWC-библиотеке
- Программирование в виде кружков и квадратов чтобы прочувствовать игровой момент
- Работа ведётся от общего к частному
- Чёткого графика работы нет - просто стремимся успеть за половину условленного срока
- По возможности все работают параллельно, у каждого есть своя территория и ожидание сводится к минимуму
- Если кто-то справляется быстрее, начинает тестировать игру или добавлять «приятные мелочи»
- Озвучка игры создаётся параллельно
- Тестерами являются участники проекта и их друзья - чтобы игра не выходила за пределы круга друзей
- Используются наработки из старых проектов. Код пишется с учётом того, что будет использоваться в будущих играх.
- Приветствуются любые улучшения игры, если изменения не отнимают много времени
4) Особенности Инди-разработки
- Постоянное самообучение
- Делать нужно только те игры, которые “цепляют”
- В голове всегда должны быть идеи на несколько хороших игр - за длительное время они отрабатываются и шлифуются, пока не заблестят
- Периодически делаются клоны с использованием движков предыдущих игр
- Всегда есть риск провала продажи игры, поэтому игр как правило делается сразу несколько (клоны, игры-недельки)
- Чтобы не закисать, периодически сами играем в игры и изучаем рынок
P.S.
Особая благодарность докладчикам и всем кто пришёл послушать. Я уже не первый раз бываю на подобных встречах, но каждый раз узнаю много нового и интересного, появляются и укрепляются контакты с людьми. Всё что хочешь можно узнать если заловить подходящего человека в курилке
Вывод: на подобные мероприятия ходить нужно и чем чаще тем лучше. И побольше общайтесь с опытными людьми - за один день приобретёте больше чем сами смогли за год.
Интересно на 55%
Отлично, спасибо за новую статью! А я уж было собрался в аську писать, спросить, как дела, почему давненько ничего нового. С возвращением, Денис, надеюсь, что дальше будет много нового и интересного!
Спасибо, очень понравился доклад! Прямо такой “ух” поселился, который требует написать игру
Сашка (тот самый дурак, который думал, что ты написал игру про машинку с грузами).
Очень хотелось бы побольше постов в этом уютном блоге)
С возвращением!
Всё так как есть:)
Единственно, у меня, как правило, в работе, всегда озвучка начинается с процессом тестирования, и занимает, по сути, меньше времени, потому как звуко-режиссёр начинает подбирать контент задолго до появления первой версии игры (хотя, и это можно назвать началом озвучки, хоть и не клеится).
Презентация очень хороша и правильна!
[…] Мой доклад для UAFPUG 2010 в Харькове : "Рабочий процесс и
to Bakame!
Обычно так и есть, музыку начинают писать когда уже можно побегать в игре и прочувствовать динамику. Главное чтобы озвучка закончилась раньше чем сама разработка игры.
С возвращением!!!!
спасибо, наконец новая статья, и при том достаточно полезная
Наконец-то новая статья и как всегда удачная! От себя хочу сказать что всё что я делаю, преходиться делать одному. А так, я сейчас работаю над своей новой игрой - Follower! На днях уже закончу первый уровень и покажу его другу на его день рожденья. Ещё хочу сказать что мне хотелось бы побольше узнать о 3D во Flash. Поэтому предлагаю вам Stormit, написать какую-нибудь новую статейку на эту тему (на мой взгляд это будет интересно не только мне).
Комментарий с текстом “прекрасная статья, спасибо” будет скорее всего забанен как спам, но черт побери: прекрасная статья, спасибо!
Продолжайте, очень познавательно.
Немного удивляет, что по такой схеме обязанности гейм-дизайнера переходящие.
Написание адекватного диздока - даже для флеш-игры - это работа не на один рабочий день. И кто-то же должен заниматься обучением игрока, левел-дизайном, единым стилем, балансом, диалогами, сценарием и т.п., там, где это надо.
К тому же, как показывает мой опыт, на пост хорошего гейм дизайна не подходит человек “с улицы”. Рисовать, скажем, все умеют, но профессиональным художникам готовы платить за работу, а Вася Пупкин просто так малюет в тетрадках по математике. Так же и с дизайном - может показаться, что всякий сгодится, идеи то у всех есть. Но только результат разный.
Я уже молчу о том, что внятно формулировать мысли и задачи способен, дай бог, один из десяти.
Еще хотелось бы поинтересоваться вот чем:
“Если кто-то справляется быстрее, начинает тестировать игру или добавлять «приятные мелочи»”
Не продуктивнее держать в разработке несколько проектов и сразу переходить на следующий?
Работа дизайнера и программера может быть совсем неравномерной: к разным играм разные требования, для многих подойдет стиль “ручкой на бумаге” за один человекочас, а другие при нехитрой механике привлекают только графикой, на которую может уйти 80% времени разработки (не говоря уже о клонах)
При такой неравномерности не вижу смысла концентрироваться на одном проекте.
to Илья
Лично я работал пока только с 3-мя разными аниматорами и все они выдавали достаточно проработанную инфу для игры (идея, история, персонажи, уровни). Сам я тоже вынашиваю несколько серьёзных игр, пока в уме. Наверное дело в опыте, со временем понимаешь что чем больше продумано на бумаге, тем меньше потом проблем с разработкой, да и сама игра получается лучше. Я же делаю игры не по принуждению, а потому что это мне нравится.
Можно и на другой проект. Если у вас задачи, как вы описали. А “приятные мелочи” всё равно нужны, они обогащают игру и располагают к себе игроков. Да и тестирования много не бывает.
Наконец то новый пост, поздравляю с оживлением)
С новым постом (надеюсь, не надо будет сидеть на диете :-))!
Ну это базару ноль) все серьезно)
01. Почему SWC для графики?
02. Почему этот пункт вы выделили отдельно?
Потому что так над проектом могут легко работать программист и аниматор без риска что аниматор нарушит код. Компиляция происходит во Flashdevelope, поэтому графику нужно как-то включать в проект - SWC идеально для этого подходит.
- а может тестирование в самом конце? а не перед озвучкой???)!
А как работать с swc?? Не понимаю. Мне дали простенький пример (Проект FD) там вложен swc. А как в нем работали не представляю..