Начинающим разработчикам

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

Вам надо понимать, что времени «на всё про всё» у вас очень мало: 2-4 года. Когда вы немного повзрослеете, вам будет не до разработки, просто потому, что жизнь такая. Теперь надо учесть, что игр мирового уровня вы ещё не делали, и вам этому придётся научиться. А на это тоже нужно время.

1. Вы думаете, что процесс разработки каждый человек понимает одинаково? К сожалению, нет, нужно время и на то, чтобы найти общий язык.
2. Вам нужно время, чтобы сделать саму игру.
3. Написать программный код, 80% которого делается без особого эффектного результата. Нарисовать картинки/текстуры.
4. Создать модели, наложить на них текстуры, анимировать, если надо. Разработать музыку, звуки.
5. А чтобы все перечисленное было сделано осмысленно, необходимо сначала написать концепцию игры и функциональное описание. И в завершении отладить баланс. Но, даже имея на руках готовую игру, вам ещё нужно будет очень многое доделать, дабы придать ей товарный вид.
6. Пока вы общаетесь с издателем, тоже идёт время.

Только один движок, только один проект, только один шанс. Если вы это пройдёте, дальше вам поможет издатель. Не пройдёте – значит, не судьба.

Вы в себе чувствуете силы всё это пройти? Да? Тогда читайте дальше.

Выбор своей специальности

Прежде всего, вам надо определиться, что у вас лучше всего получается, к чему вас тянет. Вариантов море, я с ходу могу перечислить:

1. Менеджер проекта.
   Это человек, который задаёт план выполнения работ, командует, что и в каком НАПРАВЛЕНИИ делать, но не вмешивается в техническую сторону, хоть её и понимает немного. В общем, решает все стратегически важные вопросы. И в стратегических вопросах решающее слово именно его, так как он видит картину в целом.
2. Программист ядра движка
   Выполняет взаимодействие программы с ОС.
3. Программист логики игры.
   Меню, настройки всевозможные, организация памяти виртуального мира.
4. Программисты спецэффектов.
   Несколько людей, которые выполняют спецэффекты 3Д-графики, если таковая есть.
5. Геймдизайнер.
   Самый решающий человек. Его задача – определить концепцию игры и однозначно донести её до всех остальных (в том числе и до менеджера). Далее ему надо описать игру как можно более детально (хотя это может делать и несколько человек). Если человек не справляется, пишите вместе. Без этого документа все ваши старания сойдут на нет!
6. Сценарист.
   Человек, который пишет сюжет (если таковой есть). Описывает в литературной форме саму игру. Это нужно разработчикам, чтобы, читая, они понимали, в каком направлении трудиться, какой образ они воплощают в жизнь. Это незаметно - на текстуре лишняя линия, в коде лишняя строчка. А глядишь - вот она, атмосфера игры!
7. Описывать диалоги.
   Если в игре есть диалоги, то их кто-то должен описать, записать и внедрить в игру.
8. Художники.
   Рисовать надо очень многое: фон, меню, текстуры, панорамы.
9. Моделеры.
   Делать модели технически намного сложнее, чем картинки. Вам придётся или лепить свой формат, или использовать *.x формат. И то, и другое сложно. Практика покажет, что получится.
10. Музыка и звуки.
    Вы себе представляете игру без музыки и звуков? А ведь она иногда вносит решающий вклад. Надо, чтобы кто-то её сделал.
11. Вебмастер.
    Нужен человек, который сможет сделать сайт, новости и форум. Который сможет за общие деньги купить домен и разместить на сервере информацию.

Значение менеджера

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

Найдите потенциального менеджера. Заинтересуйте его. Докажите ему, что именно с вами он выйдет в большой бизнес. Ни в коем случае не беритесь слишком рано за большое. Читайте теорию, тренируйтесь на зайцах: маленькие, законченные программки, несложные модельки, рисунки, музыка, рассказики…

Пусть менеджер найдёт всех необходимых людей. И делать он это должен быстро, ибо времени мало. Если за 2-4 недели он не найдёт людей, которые ещё не умеют, но смогут выполнить всю работу, то он вряд ли сможет выжить в большом бизнесе. Ищите другого человека. Если не получается, попробуйте создать “совет”. Или, если совсем тяжело, сами станьте менеджером. Но тогда НИ В КОЕМ СЛУЧАЕ не выполняйте другую работу.

Дружность команды

Собрав всех людей, встретьтесь, попейте чего-нибудь. Поиграйте в местной игротеке. Ещё чем-нибудь интересным займитесь, главное – вместе, главное – познакомиться. Если люди из разных городов, то встреча в реале обязательна. А также нужно обменяться домашним адресом, домашним телефоном, мобильным телефоном. Узнать полное имя. Весьма странно, если человек откажется давать о себе подобную информацию. Наверняка у него на это имеются важные причины, но они не оправдают себя, если человек в самый ответственный момент исчезнет. И не откладывайте, на ближайших выходных встретьтесь. У вас времени в обрез, не забывайте этого.

Что надо делать

Значение движка

Надо направить программистов, чтобы они писали движок. Его задача – корректное взаимодействие с операционной системой, а также чёткая и простая логика написания остального кода, оставляющая возможность небольшого редизайна игры. Тонкий психологический момент: не дёргайте программистов. Спрашивайте только, сколько времени они тратят. Не оценивайте НИКАК их результаты. Если вы не программист, вы всё равно не сможете оценить, что действительно заслуживает уважения, а что действительно сделано плохо. Если визуально плохо - сообщите им об этом, обязательно со всеми техническими подробностями, но не больше одного раза. Им важно собирать информацию о том, как работает их программа на другом компьютере. А она поначалу обязательно будет работать неправильно, не удивляйтесь. Наберитесь терпения, много терпения, и они сделают все как надо. Особенно, если их не дёргать. Очень хорошо это запомните, иначе даже самый-самый энтузиаст сломается и уйдёт от вас. Его работа очень важная, большая и трудоёмкая. Но при этом он не может ничего эффектного вам показать. Понимаете? НИЧЕГО!

Значения ДизДока

Программисты пишут движок. Замечательно. Теперь надо направить геймдизайнеров на написание ДизДока¹, и для начала – концепции игры. В обсуждении будущего игрового проекта надо принять участие всем. Даже если вас ничего не интересует, кроме технической части, всё равно принимайте участие. От слов “3Д графика” + “качественные модели” + “тысячи на одном экране” программистам станет плохо, и вы очень вовремя откажетесь от глупой идеи. Если обсуждение идёт больше 10 дней, прекращайте. Оставьте геймдизайнера в покое, и он через пару дней выдаст нечто подходящее. Скорее всего, оно никого не устроит, но угодить всем и сразу нельзя. Не пререкайтесь с геймдизайнером. Как вы думаете, что лучше, принять то, что предлагает геймдизайнер, или надуться, красиво уйти и ничего не сделать, да ещё и другим людям жизнь попортить? Или вы думаете, что в другой команде другой геймдизайнер найдёт решение, которое понравится всем и сразу?

Значение ресурсов

Теперь нужно задать работу всем остальным. Сначала сценаристу. Пусть по концепции напишет рассказик на пару страниц. Геймдизайнер пусть напишет один из вариантов развития событий на экране. Начиная от “игрок запустил программу” и до “игрок вышел из программы”. Этих двух людей лучше посадить рядом, в одной комнате за соседними компьютерами. То, что пишут эти два человека, необходимо читать всем и постоянно. Пусть программисты (но не те, которые делают движок) начнут делать спецэффекты, применять хитрые оптимизации, пусть попробуют вставить модель в программу. Сразу не получится, возможно, пройдёт очень много времени, прежде чем модели, наконец, будут в программе. Возможно, придётся написать свой формат, и даже свой редактор моделей. Пусть моделеры сделают разнообразные пробные модели всех типов. Программистам нужен подопытный материал. Первыми старайтесь делать модели “на заказ” программиста. Может вызвать удивление, если он попросит как-то по-хитрому нарисовать модель, расположить её, применить “никому не нужный эффект” и убрать “очень важные” детали. Он не понимает вас, а вы – его. В этом вся проблема. Как только вы найдёте общий язык, всё пойдёт как надо. Для программистов важно набраться терпения и постараться объяснить моделерам, что от них требуется. Существует целая проблема с наложением текстур на модели. Если человек умеет рисовать модель, это совсем не значит, что он умеет накладывать на модель текстуру. Пусть этим займётся отдельный человек, и не сразу, а тогда, когда программисты и моделеры найдут общий язык. Перед наложением текстуры на модель, её (текстуру) ещё надо нарисовать. Пусть художники нарисуют то, что от них требуется, хоть в каком-то виде, но быстро. А уж потом рисуют “как надо” с их точки зрения. С музыкой и звуками дело обстоит так же, как и с моделями. Будет тяжело найти общий язык с программистами. Для начала надо сделать хоть что-нибудь, и пусть программисты сидят, разбираются с файлами. Им надо время, не удивляйтесь глупым претензиям типа «файлы должны быть в формате таком-то».

Контроль процесса

Запустив процесс работы, менеджер может расслабиться и просто контролировать его. Знать, кто что делает, кто сколько времени тратит. Выслушивать все проблемы, даже если он в них ничего не понимает. Во-первых, он сам будет в курсе событий, во-вторых, тот, кто рассказывает, станет чётче понимать свою проблему. Выслушивать и успехи, которых, скорее всего, будет мало. Если успехов много, это сигнал тревоги. Если нет вообще, тоже сигнал тревоги. Менеджер должен быть в курсе событий, смотреть, как что выполняется, кого-то подгонять, если надо, а кого-то, наоборот, тормозить. Перекладывать работу с одного человека на другого (это надо делать очень осторожно, лучше вообще не делать, но в критической ситуации можно).

Проблемы выполнения

ДизДок

Важно как можно быстрее сделать ДизДок. Пример можно посмотреть тут:

Его наличие быстро наведёт порядок в понимании того, что делать, и дело пойдёт в ДЕСЯТКИ РАЗ быстрее. Его отсутствие создает непонимание «чего же мы делаем» со стороны всех. Без ДизДока проект не будет сделан вообще. В этом можно быть уверенным на 100%.

Цельность результата

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

Редизайн - это ЗЛО

Менеджеру необходимо по возможности не допускать редизайна. Большая ошибка неопытных геймдизайнеров в том, что они думают: «добавить эту детальку будет просто!».

Пример. Пусть программисты сначала сделают ландшафт. Сделали? Замечательно, теперь пусть добавят мышку и возможность скроллинга. С первого взгляда всё правильно, программисту надо добавить пару мелочей. И всё готово. Но технически, возможно, программист по-другому представлял дальнейшее развитие событий. И сделал так, что ему надо теперь всё переделать заново, чтобы добавить указанное. Это выполняется в гордом молчании. И, скорее всего, программист сделает требуемое. Далее геймдизайнер говорит: «а теперь добавьте холмики». Стиснув зубы, программист сделает заново всё то, что сделал до этого, а потом добавит нужные детали. Ничего не подозревающий геймдизайнер говорит: «теперь надо добавить реки». Я бы после этого РЕДИЗАЙНА «разжал зубы» и потерял желание сотрудничать.

Я преувеличиваю, но не намного.

Вот, например в сделанном ландшафте надо подправить детали. Пусть реки теперь бегут немного по-другому. Дизайнер описал, как. И если для внесения изменений надо переворошить много кода, то пусть программист скажет честно: «это сложно». Тогда или вообще откажитесь от изменений, или запишите себе в специальном блокнотике «ToDo». И когда наберётся много таких мелочей, можно будет добавить все сразу. Даже не программисту понятно, что полностью править код лучше только один раз. А вы представьте список из 20 пунктов, и для каждого надо написать заново полпрограммы.

Я хочу донести до геймдизайнеров две очень важные вещи:

1. Создаёте что-то новое – опишите полностью, что вы создаёте. Если вы «потом» дополните своё описание, программистам придётся заново многое делать.
2. Хотите исправить сделанное – опишите полностью всё, что вы хотите изменить. Для каждого изменения в отдельности программистам придётся переворошить половину кода. Но если вы даёте изменения пачкой - работа проводится один раз. И это очень экономит время, а главное нервы. Никто не любит пианизм².

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

Идеальный вариант

Если вы неопытны, настоятельно рекомендую не пробовать редизайн. Сначала пишите ДизДок. И ничего, НИЧЕГО не делайте, пока он не будет ПОЛНОСТЬЮ готов. Как только готов ДизДок, пусть программисты пишут техническую часть. Это тоже документ, и это НАДО сделать. Техническое описание включает в себя то, в каком виде будут сохраняться те или иные ресурсы, как, что и где применяться. Как будет реализована каждая деталь проекта. И все неточности функционального описания всплывут. И только потом приступайте к реализации.

ЗЫ. И пусть вас приветствует удача в ваших проектах и взаимоотношениях!

С уважением, Elf-Keeper!

Если у Вас возникли проблемы, вопросы или пожелания к статье – милости просим в тему поддержки этой статьи.