Часть графики для игры мне пришлось заказывать на стороне. Задача выглядела несложной: сделать несколько вращающихся камней и я понадеялся, что с ней сможет справиться большое число 3D дизайнеров. Поэтому, пропустив стадию поиска нужного человека через знакомых, я сразу пошел на сайт free-lance.ru. Зарегистрировался, создал проект и уже через пол дня получил 12 сообщений и еще 2 сообщения не следующее утро. После этого новых предложений не поступало.
В проекте я составил детальное описание, ответив на большинство возможных вопросов, дал ссылки на статическое изображение того, что я хочу получить в финале и на пример анимации на YouTube. До технического задания текст не дотягивал, но давал возможность точно оценить сложность и объем нужной работы. Ориентировочную стоимость подобной работы я представлял, но в тексте не указывать не стал, ожидая предложений от исполнителей.
Один из тестовых вариантов и финальный вид
Читать далее…
В разрабатываемой мною игре игрок может влиять на ситуацию на поле не только через башни. Еще у него есть возможность использовать магию. Заклинания реализуются по обычным правилам: для того, чтобы сотворить заклинание нужно использовать определенное количество манны, после того как заклинание использовано, оно некоторое время недоступно для повторного вызова. Игроку доступно большое числа заклинаний, но на каждом уровне он может использовать только пять из них. Перед каждым уровнем он должен выбрать какие заклинания взять с собой и в зависимости от этого выбора стратегия прохождения уровня будет меняться.
Возможность выбора подтолкнула меня к идеи использовать карту как метафору одного заклинания. Таким образом игрок перед каждым уровнем формирует подходящую колоду и с ней ведет игру. Такой подход часто используется в других играх и дает дополнительный бонус: новые карты можно прятать на игровом поле и награждать ими игрока за значительные достижения. Все тоже самое можно делать и с обычными заклинаниями, но с картами оно выглядит более естественно и логично.
Читать далее…
На днях доделал финальный вариант индикатора волны «монстров». Задача, которую я перед собой ставил:сделать компактный индикатор, который одновременно показывает общий прогресс на уровне (число волн), время ожидания до следующей волны и информацию об этой волне. Дополнительной задачей было сделать индикатор похожим на кнопку, чтобы игрок понимал, что на него можно нажать и вызвать волну сразу, более того, чтобы игрок хотел нажать. Вместе с тем, должно было быть понятно, что когда «монстры» из волны появляются на поле, то никаких действий игрок пока сделать не может.
С некоторыми вещами я определился сразу: нужно два прогресс-бара – один на уровень, другой на время между волнами и они должны заметно отличаться друг от друга; информация о следующей волне должна выводиться в круге, просто потому, что мои «монстры»-камни круглые. В первом наброске я попробовал индикатор времени между волнами выводить снизу круга с информацией и прятать его, когда время заканчивается. Логика была бы такой: есть индикатор – можно нажимать, нет индикатора – ждем. Но как только я нарисовал это, то сразу понял, что постоянное мельтешение индикатора туда-сюда будет раздражать игрока. Тем более, на кнопку все это никак не похоже. Оставив индикатор в покое, я занялся другими вещами.
Читать далее…
Не все можно масштабировать. Если игра сделана для разрешения 640×480, то сжав графику в два раза ее легко можно перенести на разрешение 320×240 используемое в смартфонах в 2009 году. Но вот перенести ее на современные устройства Nokia с разрешением 640×360 будет уже сложно. Решений два: уменьшить графику на 75%, получить разрешение 480×360 и появившиеся пустое место (160×360) закрыть заглушкой. Или же полностью переработать уровень и размещение элементов интерфейса, чтобы занять все пространство экрана.
Первый способ приводит к появлению “недоигр” и не имеет никакого смысла: при таком половинчатом портировании игра не получит популярности и есть риск не окупить затраты при достаточной насыщенности рынка. Второй способ забирает больше времени и денег.
Выбирая разрешение для игры я рассчитывал на возможность портировать ее на мобильную платформу, поэтому смотрел в первую очередь на разрешение популярных смартфонов. Закончив прототип игры я решил, что сделать его играбельным на экране размеров в 3-4 дюйма (не важно какое там при этом будет разрешение) будет очень сложно, поэтому переключил свое внимание со смартофнов на планшеты и вновь занялся выбором размера игрового поля.
Как видно из первоначально приведенного примера основная сложность не в разрешении экрана, а в соотношение его сторон. Наиболее часто используются соотношения 5:3 и 16:9. 5:3 используется в большинстве топовых смартфоноы, как уже продающихся, так и только анонсированных (разрешение 800×480). Это же соотношение используется в большинстве планшетов на операционной системе Android 2.x (разрешение 1024×600).
16:9 в основном продвигают Nokia и Motorola. Nokia пока не выбирается за разрешение 360×640, а вот Motorola экспериментирует с увеличением разрешения. Большая часть ее устройств имеют разрешение 480×854, но анонсированный на CES 2011 флагман Motorola Atrix 4G подымает разрешение до 960×540.
Пока непонятно, что будет с соотношением 16:10, которое будет использоваться в анонсированных планшетах на операционной системе Android 3.0. С одной стороны это соотношение становится все более популярным в телевизорах и мониторах, а с другой стороны, если на планшете нужно не только смотреть HDTV видео, то это соотношение менее удобно чем 4:3 у iPad.
Под катом таблица основных используемых сейчас пропорций экрана и разрешений.
Читать далее…
Во всех играх, которые я делал основной проблемой всегда была графика. Сам я рисовать не умею: могу наложить тень и блики в графическом редакторе или уместно использовать градиент, но не более. Найти же хорошего художника для совместной работы у меня не получается уже много лет. И по объявлению искал и через знакомых, но каждый раз неудачно.
Для текущей игры я большую часть графики рисую самостоятельно. Один раз воспользовался услугами фрилансера для анимированного изображения “монстров” и, видимо, воспользуюсь еще раз для создания фона в главном меню и для создания иконки игры. Есть еще большое желание реализовать брифинг перед миссией в виде общения персонажей и, соответственно, заказать еще и прорисовку четырех персонажей. Но пока что я с этим желанием успешно борюсь.
На графику уходит очень много времени и мне еще ни разу не удалось нарисовать то, что мне полностью нравиться. Приходиться в какой-то момент просто останавливаться и использовать лучшее из того, что получилось создать. При этом остается много готовых вариантов, которые не войдут в игру. Например, вот один из вариантов башни:
По состоянию блога в это трудно поверить, но я продолжаю разработку игры. И даже той же самой игры. Работаю не каждый вечер, а несколько месяцев пропустил вообще полностью, но сейчас стараюсь финализировать как минимум один игровой элемент в неделю.
Текущее состояние: игровой процесс полностью готов и теперь из него надо сделать интересную игру, для чего закончить графику, настроить баланс, подобрать звук, запрограммировать спецэффекты и достижения, сделать меню, глобальную карту и обучение. В целом, такое впечатление, что объем работы, которую надо сделать, только увеличился за прошедшее время.
Цель: сделать игру до того, как HTML 5 полностью вытеснит Flash. Хотя в реальности, хотелось бы сделать ее даже на несколько лет раньше. А если более серьезно, то задача максимум сделать один полностью законченный уровень к концу этого месяца. Задача мало реальна, есть и запасной план, но буду стремиться именно к этому результату.
Свернул немного в сторону от процесса разработки игры, чтобы сделать демку движения мячиков по игровому полю. Это сразу выявило множество мелких проблем, которые были не заметны на этапе разработки. В итоге механизм отвечающий за «слипание» мячиков в группы пришлось полностью переделать.
Нажатие на один из мячиков справа выкладывает его на поле. Нажатие на мячик на поле удаляет его. Задние мячики толкают передние, но насколько успешно это происходит – зависит от их веса. Мячик «Ram» очень быстрый и очень тяжелый, как-то замедлить его скорость может только тяжелый синий мячик.
Фоновое изображение в игре будет примерно такое же, как и здесь, но более тщательно проработанное. Вид кнопок и мячиков – временные заглушки.
Раньше очень многие свои игры я начинал с программирования редактора игрового мира. Часто им же и заканчивал. Потом я отказался от этой порочной практики и перешел на использование ini файлов, а позднее xml. Но новую игру я начал именно с редактора, потому, что надо было разобраться как работать со сплайнами, а когда я этим разобрался, то оказалось, что для того, чтобы получился нормальный редактор надо добавить всего несколько дополнительных возможностей.
Основная сложность, с которой я столкнулся – это как сохранить данные. Сохранять в «cookie» в данном случае бессмысленно, а для того, чтобы сохранить бинарный или текстовой файл надо писать обертку на чем-то вроде Php. Это не сложно, но разворачивать ради этого на локальной машине сервер Apachi – это как-то чересчур. Перепробовав несколько вариантов, я остановился на самом простом: при сохранении генерируется xml файл, который затем выводится в текстовое поле, появляющиеся на экране. Я копирую текст в буфер обмена и сохраняю его туда, куда мне нужно.
А редактор, возможно, мне еще пригодиться. В него вставить финальную графику, научить работать с БД и можно выпускать на потеху фанатам. Но смысл все это сделать будет тогда, когда фанаты у игры появятся.
spline-sampleТак получилось, что за все то долгое время, что я занимаюсь программированием, мне не приходилось сталкиваться с математикой. В новой игре объекты должны двигаться по плавно изогнутому пути. Обычно такой путь задается сплайнами и с их реализации я и начал. Зашел на wiki и в английском разделе увидел кучу длинных формул от которых мне стало грустно. Не отчаиваясь, я начал искать исходные коды реализованных сплайнов и чем больше я их находил, тем грустнее мне становилось. Так было до тех пор пока я не нашел похожий код:
function spline(t : Number, P0:Number, P1: Number, P2:Number, P3:Number):Number
{
return 0.5 * ((2 * P1) + (-P0 + P2) * t + (2*P0 - 5*P1 + 4*P2 - P3) * t * t + (-P0 + 3*P1 - 3*P2 + P3) * t * t * t);
}Он возвращает t точку сплайна между точками P1 и P2. При этом t меняется от 0 до 1, то есть, если точек в сплайне 10 и надо посчитать восьмую, то значение t будет 8/10. P0 и P2 – это точки перед и после основных точек. Если точки, к примеру, всего 3, то можно считать, что P3=P2. И самое главное: P0, P1, P2, P3 – это значение только одной координаты. То есть функцию надо вызвать 2 раза, один раз подставив туда координаты X точек, а второй раз координаты Y.
Ниже небольшой пример, как это работает. У меня он вызывает больше восторга, чем большая часть того, что я запрограммировал за последний год.
Зеленные точки можно передвигать
Работе с интерфейсом в игре не видно ни конца ни края. Текущими темпами я без всяких шуток буду делать ее год. По этой причине я решил остановить текущую разработку и сделать другую игру с минимумом интерфейса.
У меня давно есть подходящая идея – «казуальные» tower defence. «Казуальные» в данном случае означает очень простые и понятные. Никаких исследований, никакой починки или смены оборудования. Не будет даже строительства башен. Интерфейс, соответственно, тоже будет простой – без всяких закладок и перетаскиваемых объектов. Полной уверенности что такая игра будет интересна обычным игрокам с flash порталов нет, но сделать ее можно быстро, поэтому рассчитываю вскоре получить ответ на этот вопрос.
Визуально игра будет здорово напоминать игру Zuma: каменная подложка с желобками по которым катятся разноцветные мячики. «Лягушек» будет несколько и стрелять они будут автоматически. Задача игрока задавать цвет мячиков, которыми они стреляют. Цель игры не меняется – не дать мячикам докатиться до конца пути.
Будут и другие возможности, но база именно такая.
