Руководство по игроделанью (по версии Константина Прокопова)
Введение
Может, остался в живых кто-то, кто еще помнит напечатанное в десятом номере "Навигатора" руководство по игроделанью. В свое время я внимательно его прочел и принял за откровение свыше. С тех пор, наделав массу ошибок в этой области, я приобрел опыт, который во многих местах расходится с написанным в статье. Поэтому я предлагаю свой вариант, хотя он, скорее всего, еще более спорный, чем предыдущий.
В первую очередь, эта статья рассчитана на студентов. Объясню почему. Старшеклассник – гений в языках программирования и признанный хакер местного масштаба – не имеет одной небольшой, но важной вещи. Это опыт, которому еще неоткуда было взяться. А замечено, что при прочих равных условиях, более опытный человек пишет программы намного быстрее и легче. Кроме того, старшеклассники имеют неприятную особенность становиться студентами. Во время этого процесса разработка любой игры оказывается крепко забытой, а иначе: "Армия сделает из тебя мужчину, сынок". После института наваливаются такие заботы как молодая семья, работа не по специальности. И вообще, становится не до игр. В тоже время, у нормальных студентов десять месяцев в году практически свободны, и их можно использовать по своему усмотрению.
Я не буду рассматривать первую стадию болезни – волк-одиночка. Для каждого из этих индивидуумов процесс творчества сугубо интимен, и все полезные советы они отсылают так далеко, что это невозможно напечатать из-за цензуры. Предметом этой статьи станет самая последняя и запущенная стадия болезни – создание игры в команде.
Прежде чем у вас окончательно сформируется мысль о подобной авантюре, вы должны понять, что у вас ничего не получится. Это абсолютно точно. И можете не тыкать пальцами в работающие игры. Во-первых, это обман зрения, а во-вторых, их делали не студенты. Если же вы считаете, что это шутка, а вы крутой и самый умный всех удивите, то советую открыть телефонный справочник и позвонить частному психиатру. Лечение будет долгим и дорогим.
Работа с командой
Прежде чем начинать набирать команду, надо решить, какую роль вы в ней будете занимать. Вариантов немного: "советчик" и "начальник". "Советчик" имеет бонус быстрого набора команды и быстрого, безрезультатного завершения проекта. "Начальник" же имеет только головную боль и массу неприятностей. Естественно, для достижения результата второй вариант предпочтительнее.
Все еще до набора команды вы садитесь и подробно записываете, что вы хотите сделать. Рисуете приблизительные экраны и делаете наброски структур данных. Довольно часто, к счастью для окружающих, на этом этапе все и заканчивается.
Потратив недели две на подготовку, можно начинать самое интересное – вербовку. Естественно, что личное (в смысле, не телефонное) общение предпочтительнее всего. Тихо подходя к намеченной жертве, вы держите примерно следующую речь: " Привет, …, я начинаю делать … и мне нужен помощник. Но учти, что это все будет серьезно. Еженедельный план работ, причем если ты не выполнишь его без уважительной причины, то нам придется расстаться. Не спеши, подумай. Не будет ничего страшного, если ты откажешься". Если согласятся все, то значит вы что-то неправильно объяснили, если не согласится никто, значит вы спрашивали не в той компании. Практика показывает, что процентов семьдесят соглашается.
Начав проект подобным образом, вы уже завоюете некоторый авторитет и точно будете делать именно то, что задумали вы, а не решили сообща, попивая пиво. Естественно, что, подходя к человеку, вы должны иметь приблизительное представление, чем он будет заниматься в проекте. Часто люди сами говорят, что им более интересно, и нужно в разумных пределах прислушиваться к их мнению. Для того, чтобы окончательно решить, кто чем будет заниматься, надо первую неделю провести работу по пробному плану.
Дело в том, что, скорее всего, вы наберете людей - "универсалов", типа крестьян из "Века империй", которые и охотились, и строили, и даже немножко воевали. Так и ваши подопечные будут уметь программировать под форточки, знать наиболее популярные трехмерные редакторы и уметь составлять алгоритмы. Возраст такой – на что взгляд упал, то и любо. Конечно, уровень мастерства в каждой области у всех различен и эту разницу и выявит пробный план. Более подробно к планированию мы вернемся ниже, а сейчас рассмотрим средства поддержания дисциплины.
Такое средство всего одно – отставка. Если в настоящей фирме начальник может лишить премии, задержать отпуск, сделать строгий выговор на повышенных тонах, то у вас всех этих рычагов воздействия нет. Вернее, вы можете наорать на провинившегося, но в ответ услышите ответный ор и на этом все завершится. В смысле, вообще все.
Разрывая отношения с человеком, вы все-таки наносите небольшой вред и себе. Считалось, что участок работ, за который он отвечал, занят. Теперь же вы или ищете нового человека, которого вы скорей всего не найдете, или берете весь объем работ на себя, или распределяете его поровну между всеми, что наиболее разумно. Распрощавшись же, по тем или иным причинам, с большей частью команды, имейте мужество поговорить с оставшейся – у вас ничего не вышло. Правда можно попробовать "заморозить" проект, но графика быстро устаревает, а на код через месяц смотрят только как на чудо-юдо неведомое и неизвестно кем написанное.
Одними из первых вопросов, которые вам зададут - будут оплата и перспективы издаться. Насчет первого мой приятель ответил так: "Я не настолько крут, чтобы мне платили за то, что я делаю". На девяносто процентов он прав. Большие деньги платят за большое имя. И если у вас в команде есть подобный человек, то советую дальше не читать – калибр не тот. С другой стороны, всякий труд должен оплачиваться; но средств нет…. Насчет издаться. Видели (слышали, щупали - нужное подчеркнуть) игру "Третий Рим. Борьба за престол" или "Схватка"? Так вот, при первых же попытках создать нечто уровнем ниже (… хм, где моя любимая двухстволка? … а, ладно) голыми руками придушу. Ведь ниже же просто некуда. А ведь их издали (вторую даже локализовали). (Сразу скажу, для сохранения своего здоровья, что нарекание вызывает только технологические и изобразительные составляющие названных игр.)
Опасным моментом может стать чужое виденье игры. Порой, у других попадаются довольно интересные и стоящие идеи из разряда " ну я и болван, это же так очевидно". Хотя чаще волосы медленно занимают на голове перпендикулярное положение, когда вашу гениальную идею превращают в такое…. А ведь в самом начале вы ему все объяснили, он все понял и со всем согласился. Только оказывается, что понял он не ваши слова, а нечто свое. В этом случае надо быть дипломатом и поступать подло. Объясняю. Ваши идеи записаны, его нет. Возможно, что через некоторое время, если вы не будете заострять на этом внимание, он забудет и вопрос отпадет сам собой. В противном случае помните, что у большей части команды нет своего мнения по спорному вопросу, и они неосознанно ориентируются на ваши слова, поэтому можно сыграть в демократию. И это подло, но так надо.
Надо помнить, что ваши подчиненные отличаются от вас. Для вас создание игры – захватывающий процесс, мечта. Они же примкнули, чтобы попробовать свои силы; из уважения к вам или по старой дружбе. Поэтому не удивляйтесь их безынициативности, а лучше давайте им подробные инструкции. Если программисту, для проверки работоспособности нажатия на экране кнопок, не хватает их изображения, то в восьмидесяти процентах случаев он обратится к вам. "Нет, чтобы самому нарисовать тестовые кнопки!" – будет ваша мысль. Неправильно. Его дело – код, вы не говорили ему рисовать кнопки. Просто объясните, что художник ушел в длительный запой из-за того, что не может пройти последнюю миссию в "Хранителях II", и предложите ему самому нарисовать пробные кнопки. Он с радостью согласится.
Или же вы сказали нарисовать художнику текстуру травы. Через три дня он ее вам показывает... Конечно, это трава, даже, безусловно, трава (в противном случае попробуйте найти другого художника), но совсем не та о какой мечтали вы, да и размер маленький. После чего вы подробно объясняете художнику, что и какого размера надо сделать, и он уходит тихо (или громко) ругаясь. Вы теряете четыре дня, уважение человека и все из-за того, что подсознательно решили считать его телепатом.
Еще одна вещь, которую вы можете регулировать, это моральный дух команды. Если художник принесет вам красивый домик, то вы обрадуетесь. Поделитесь своей радостью с другими (если уж денег нет). На пару дней их работоспособность возрастет. После вставки этого домика в игру, следует обязательно показать это художнику. Он должен знать, что трудиться не один. Постоянно теребите людей. Не оставляйте их без контроля больше чем на пару дней. Причем помогают прямые контакты, с просмотром промежуточных результатов. Если какой-то этап запланирован на неделю, следите, чтобы он делался постепенно, а не в последний день, иначе результатов вы не увидите. С другой стороны, если все время давить на людей, то они становятся раздражительными, огрызаются и уходят из команды. Добиться баланса трудно. Но кто сказал, что писать игры легко.
Отдельно хочется обсудить такую вещь, как игры конкурирующих контор. Их неоспоримое преимущество в том, что они уже сделаны. Из-за этого, некоторые слабохарактерные члены команды постоянно в них играют, пренебрегая своими прямыми обязанностями. Порой, этому можно помочь. Вы можете не поверить, но при определенных действиях самого заядлого игрока можно уговорить стереть с винта все игры и отдать игровые компакты в ваши надежные руки. Что это за действия (в первую очередь вопрос, наверное, заинтересует родственников)? Надо показать ему все то, что сделали другие. Если это хоть как-то выглядит, то в человеке просыпается комплекс неполноценности, он раскаивается и легко попадает под ваше правильное влияние.
Иногда приятно помечтать о будущей славе, о том какие еще вещи можно внести в игру. В первом случае не следует забывать, что игра никогда не будет написана. А во втором следует вовремя остановиться и разграничить, что сделать реально и необходимо, а что можно было бы сделать, но не нужно т.к. затраты на выполнение задуманного и его место в игре явно не пропорциональны. Надо помнить, что в игру надо играть, а не разбираться в тысяче наворотов. Хорошо бормотать под нос фразу: "нет предела совершенству, нет предела совершенству", до тех пор, пока на вас не станут странно коситься в транспорте. Но, опять таки, это не значит, что вы должны на корню рубить свою фантазию.
Спустя несколько месяцев после начала, вы столкнетесь с таким явлением, что некоторые ваши знакомые, не занятые в проекте, приобрели дурацкую привычку интересоваться ходом работы и задавать глупые вопросы об ее окончании, не понимая - главное не результат, а сам процесс творчества. Самое смешное, что, покопавшись в памяти, вы вспомните, как своим собственным языком рассказали в восторженных тонах о своем будущем величии. Поверьте, но удовольствие от таких рассказов гораздо меньше раздражения от бесед в дальнейшем.
Работа над игрой
Рискну дать несколько рекомендаций по программированию. У меня и в мыслях нет, что вы им последуете, но все же их можно прочитать, чтобы знать, как страдают некоторые глупые люди.
Сразу после окончания вербовки и составления детального плана, надо определиться с языком программирования. Времена, когда класс программиста определялся используемыми языками давно прошли, хотя некоторые этого и не заметили, поэтому подойдет любой, кроме, пожалуй, SQL и HTML. Хотя... Это, по крайней мере, будет оригинальная игра.
Наверное, Microsoft следует лицензировать словосочетание "Must die", так как оно уже давно ассоциируется именно с их продуктами и уже не является ругательством, а этакой присказкой. Так вот писать вы будете, скорее всего, для платформы Windows (или же для DOS, если вам лень учить программирование под Windows). Для этой платформы существует DirectX SDK, о чем не знают, разве что, пингвины. Не самая удобная штука, но гораздо удобнее, чем API. Так вот, пингвины пусть пишут под API, всем остальным предлагается DirectX SDK, отдельные продвинутые индивидуумы программируют все напрямую (последние могут сразу обращаться в id software).
После выбора языка (срок от 2 часов до 2 лет), прорабатываются структуры. Грамотно составленные структуры и их продуманное взаимодействие является самой главной частью проекта. Конечно, их не пощупаешь руками, не похвастаешь перед друзьями, но, продолжая работу над игрой без присутствия структур, вы сразу сознаетесь в своем поражении. При продумывании структур важно разделить, что вам нужно для движка, а что непосредственно для игры. Имеет смысл написать отдельно движок, а затем, добавляя необходимые структуры, развить его в игру. Положительным примером в этом отношении служит игра "Conug". Графика и движок те же, но игра уже несколько иная (кстати, кто помнит статью "Летопись времен: князь" в #4 Нави).
После первых трех-четырех недель у вас должны быть готовые структуры, и вы начнете нанизывать на них мясо – код. Недель через пять наступит первый критический момент: это почти всем надоест и вам придется подключать первые картинки к коду, для чего надо заполнять поля структуры, для чего надо... А вот что для этого надо – спорный вопрос. Можно попробовать заполнять их ручками в текстовом редакторе. Для структуры с числом полей более одного это адская работа. Можно написать простенький редактор. Ключевое слово здесь "простенький". Так как редактор проще игры, а вещь, вроде бы, в высшей степени необходимая, то все бросаются делать редактор. От многих хороших проектов одни навороченные редакторы и остались.
Я надеюсь, многим понятно, что написание кода следует разбивать на маленькие этапы и постепенно писать их. Времени на это уйдет больше, чем на постройку египетской пирамиды, но "тише едешь – дальше будешь". Принцип "написать все, затем откомпилировать и это работает" проходит только для программ определенного объема. Не спорю, чем опытнее программист, тем этот объем больше. Но, поверьте, ваша игра, чтобы иметь нормальный вид, должна намного перерасти объем, максимальный для вашего программиста.
И последний совет, который сэкономит художнику дня три работы. Как ни странно, но одним из первых рисунков появляется рисунок заставки. К концу работы появление этого творения на экране монитора вызывает стон у всей команды. Эта, изученная по пикселям, картинка снится всем в кошмарах... Поэтому, под конец ее обязательно перерисовывают в целях сохранения психического здоровья. (И вообще, можно здорово сократить время, если отлаживать программу с пробной графикой, подключая финальную по мере ее поступления).
С удовольствием приму все замечания о грубых ошибках и неточностях, из которых состоит данный текст.
P.S. Автору известны и более нормальные и традиционные способы работы, чем бесконечное планирование и бумагомарание (ручкой или принтером), но почему-то результатов этой работы гораздо меньше (...и в этом углу нет, хмм, где же они), чем в том случае, что я пытался описать.
Константин Прокопов
Журнал "Самиздат"
|
|
