Cronvid Blog

Для меня знакомство с жанром tower defense началось с бонусного уровня в игре Warcraft III: The Frozen Throne. Было это в 2003 году. Как и многие другие игроки я ошибочно думал, что эта игровая механика изобретение дизайнеров Blizzard. Думал я так до сегодняшнего дня, пока не посмотрел в Википедию, что же про этот жанр написано там.
Оказалось, что Blizzard лишь отлично реализовали уже хорошо известную игровую механику. Первая tower defense стратегия была выпущена фирмой Atari Games в уже далеком 1990 году. Игра называлась Rampart и ее дизайнером был Джон Сальвитц (John Salwitz), который до сих пор активно работает в игровой индустрии. Судя по всему, именно этому человеку можно посылать благодарности за Desktop Tower Defense, GemCraft и Plants vs. Zombies.

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

• планирование строительства башен в наилучшем месте с нужными характеристиками
• ожидание пока накопиться нужное количество ресурсов, чтобы реализовать часть плана
• волнение за реализацию плана, когда исправить уже ничего нельзя и остается только смотреть и молиться

Читать далее…

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

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

Цитата не точная, но смысл именно такой. Это действительно сильно ускоряет работу. Иногда бывает, что уменьшишь значение в два раза и видишь, что ничего не изменилось и тогда становится понятно, что можно сразу раз в десять уменьшать. Если уменьшать по двоечке, по троечке – на 1-2 процента, то до нужной величины можно было бы целый час добираться. А вот переборы при таком методе все равно редко происходят.

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

В своей первой flash игре, которую я выпустил год назад, я сделал 3 игровых режима, перевел интерфейс на 4 языка, встроил Kongregate API, сделал пошаговую обучалку и ничего из этого не понадобилось, потому, что сама игра оказалась излишне сложной, не интересной и в нее практически никто не играл.

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

Безусловно, качество flash игр не должно быть низким и, к примеру, плохая реализация интерфейса не должна мешать запустить первый уровень. Но и вкладывать дополнительный месяц работы, чтобы все сверкало и блестело бессмысленно. Такие усилия помогут успешной игре стать популярной, но не спасут не интересную игру от забвения.

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

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

Но я быстро понял, что симпатичную картинку в данном сеттинге я не нарисую, по той простой причине, что рисовать не умею. Выходом, конечно, было нанять художника или скооперироваться с кем-то, но что-то мне с художниками не везет и в этот раз я решил не рисковать. Делать что-то абстрактное вроде «Bloons Tower Defense» тоже не хотелось, поэтому в результате недолгого перебора я остановился именно на космосе. Плюсы следующие:

• Фон игрового поля сделать довольно легко.
• Отсутствие анимации рук, ног и развевающихся плащей – это фича, а не баг. У космических кораблей рук не бывает.
• Можно сделать красивые взрывы.
• Это довольно устоявшийся и узнаваемый сеттинг со своими правилами (лазеры, космолеты, подпространство и т.д.) и приверженцами.

Минусы я пока вижу такие:

• Картинка получается несколько темной.
• Не все игроки любят этот сеттинг.

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

Читать далее…

Игра разрабатывается для Flash на ActionScript 3.0. Это довольно новый для меня язык программирования, поэтому параллельно я буду учить его тонкости. Жанр игры: tower defense. Сеттинг: космос. Основные особенности игры:

• Игровое поле не меняется по мере прохождения, аналогично тому, как это сделано в «Desktop Tower Defense».
• Небольшое количество «башен», которые можно построить. Основной упор сделан на их развитие и модернизацию.
• Строительство новых «башен» возможно только между миссиями.
• Во время миссии игрок занимается микроменеджментом уже построенных «башен».
• Более или менее «серьезная» система исследований, использующая отдельные «очки».

На текущий момент у меня есть боевой движок, который я год назад написал на ActionScript 2.0, графика «монстров» и графика основных игровых экранов, которые я нарисовал на прошлой неделе. Теперь это надо все собрать вместе, добавить графику «башен», звук, уровни, протестировать и настроить баланс. Со стороны может показаться, что за неделю можно справиться, но по опыту я больше рассчитываю на конец января. Внутренний «дедлайн» – 25 декабря.