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

Author: Anlide

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно как можно быстрее сделать ДизДок пример можно посмотреть тут:
http://games.1c.ru/4_files/desdocpack.zip Есть также множество статей на:
http://dtf.ru/articles/articles.php, http://gamedev.ru/articles/ Его наличие быстро наведёт порядок в понимании того что делать и дело пойдёт в ДЕСТКИ РАЗ быстрее. Его отсутствие делает непонимание со стороны всех «чего же мы делаем». Без ДизДока проект будет не сделан вообще. В этом можно быть уверенным на 100%.

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

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

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

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

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

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

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

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

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

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

• Надо выделить главные части в статье и каждой отвести свой подзаголовок, а то читать невозможно. Разбить по параграфам. У каждого параграфа - своя цель.

А теперь?

Romtek: Оформление гораздо лучше, хотя ошибки всё ещё есть.

Может стоит именно в таком виде и оставить?

Romtek: В принципе, да. Остальное подправят корректоры или ещё кто-то.

А можно перед релизом посмотреть что они исправили? Кстати о птицах - релиз скоро?

Romtek: Это зависит от политики редакторов. Я бы держал последнюю корректную версию именно здесь, т.к. это удобно. Когда релиз - спрашивать на форуме.

Ну.. а что скажут собственно сами редакторы? Или вообще как это всё происходит?

orb: А что это за статья??? И как сюда попала?