Обработка передвижений мыши в AS 3.0 на первый взгляд выглядит очень просто. И документация и десятки примеров в интернете показывают как это сделать:
sample_mc.addEventListener(MouseEvent.MOUSE_MOVE, SampleMouseMove);
Теперь, когда курсор мыши будет наведен на клип sample_mc, то будет вызвана функция SampleMouseMove, которая получит параметр типа MouseEvent из которого можно будет узнать координаты курсора и много другой информации.
Однако, внутри скрывается несколько нюансов, которые привели к тому, что у меня на правильный обработчик ушло несколько часов времени.
Читать далее…
Переиграл на днях в несколько новых игр из жанра tower defence и в самые популярные старые игры этого жанра. В результате задумался над тем какие же вообще элементы игрового процесса делают игры этого жанра столь интересными. Вот основные особенности, которые я смог выделить:
- планирование строительства башен в наилучшем месте с нужными характеристиками
- ожидание пока накопиться нужное количество ресурсов, чтобы реализовать часть плана
- волнение за реализацию плана, когда исправить уже ничего нельзя и остается только смотреть и молиться
Читать далее…
Как и собирался, занялся подключением учета стоимости устройств в окне «Upgrade». Практически сразу наткнулся на логическую неувязку в интерфейсе, которую опишу потом в отдельном посте. Отложив эту часть в сторону переключился на реализацию всплывающих подсказок. И, если сам класс, который рисует окно подсказки не вызывал никаких сложностей – все, что было нужно, это аккуратно разбить нарисованное окно на 9 частей, перенести их во Flash, задать имена и атрибуты, а потом несколькими строками кода правильно расположить их в MovieClip’е, то вывод получившегося изображения на экран оказался неожиданно сложным.
К чему бы я не пробовал прикрепить MovieClip он отрисовывался не в том месте и не по тем координатам. Впрочем, это не самая сложная часть и думаю, что большинство сложностей вызвало то, что был поздний вечер и я пытался решить задачу подбором, вместо того, чтобы подумать.
Небольшое предисловие: в 2000 году журнал Game-Exe вместе с издательством Логрус.РУ выпустил отличную книгу «Компьютерные игры. Как это делается». Книга представляет из себя подборку статей, написанных различными известными американскими разработчиками, в основном геймдизайнерами и продюсерами. Каждый писал о том, что ему было наиболее интересно, что он лучше знал и в целом книга рассказывает практически обо всех аспектах создания игр на рубеже тысячелетий.
В свое время я прочел эту книгу с огромным интересом и немного жаль, что ее сравнительно быстро «зачитали». Из всего, что там рассказывалось мне больше всего пригодился совет, кажется, Сида Мейера:
если вам надо сбалансировать какой-то процесс и вы подбираете значение переменной, то меняйте ею величину сразу в два раза, не важно увеличиваете вы ее или уменьшаете.
Цитата не точная, но смысл именно такой. Это действительно сильно ускоряет работу. Иногда бывает, что уменьшишь значение в два раза и видишь, что ничего не изменилось и тогда становится понятно, что можно сразу раз в десять уменьшать. Если уменьшать по двоечке, по троечке – на 1-2 процента, то до нужной величины можно было бы целый час добираться. А вот переборы при таком методе все равно редко происходят.
Есть часто встречающаяся задача: массив игровых объектов, состояние которых надо сохранить и загрузить позднее. Например пусть это будет множество кубиков у которых есть такие свойства, как имя, координаты и цвет. Класс, который их описывал мог бы выглядеть так:
package
{
public class clBox
{
public var mName : String;
public var mColor : Number;
public var mX : Number;
public var mY : Number;
}
} Читать далее…
Как я и подозревал, с сохранением и загрузкой все оказалось не так просто. Простые типы, вроде Number или String сохраняются просто великолепно, а вот что-то более сложное уже вызывает проблемы. Конечно, если есть строка, то уже можно сохранить все. Немного терпения и все данные кодируются в строку, а при загрузке парсятся обратно, но в кои-то веки я захотел пойти по простому пути и зарылся в документацию.
Документация вопрос сохранения структур данных освещала невнятно, но в разных местах проскальзывали ссылки, что если класс зарегистрировать, то все может получится. Лучшее, что получилось у меня – это сохранить объект унаследованный от Sprite. При этом все дополнительные свойства, которые я в него добавил, и в которых, собственно говоря, и была основная суть, были проигнорированы и не сохранились. В итоге я все же нашел решение как сохранять все, что мне нужно, но изящным оно не выглядит.
Это десятый день работы над проектом и сорок пятый календарный. Даже с учетом, что параллельно с разработкой я изучаю AS3, мой темп приводит меня в ужас. Успокаиваю себя тем, что постепенно результативность труда увеличивается.
Все мы читали множество историй о том, как популярны игры среди пользователей iPhone и как много денег можно заработать на их продаже. Маховик начал раскручиваться еще в 2008 году, но большая часть разработчиков обратила внимание на новый рынок уже в 2009 году. Во второй половине ушедшего года начали появляться уже не столь радужные истории, но я хочу рассказать сейчас не об этом.
На волне интереса произошла довольно некрасивая история, когда оригинальная flash игра Ragdoll Cannon от Johnny-K была один в один портирована американским разработчиком на iPhone без какого-либо указания авторства. Игра была платной и в первое время попала в топ-50 платных приложений, что по тем данным, которые раскрывают другие разработчики, означает получение довольно существенной прибыли: не сотни тысяч долларов, но и не несколько сотен тоже. Не надо уточнять, что никакой прибылью американец не поделился. Начало этой истории можно смотреть отсюда.
И не было бы никакого смысла об этом вспоминать, если бы не другая история с играми и iPhone, которая завершилась совсем противоположным образом. В США есть компания Mumbo Jumbo, которая является одним из лидирующих разработчиков на рынке казуальных игр. Компания серьезная: с инвесторами, юристами и довольно солидным годовым доходом. В свое время она даже купила компанию, которая занималась разработкой «больших» игр. У этой компании есть хитовая игра Luxor о которой, уверен, большая часть из вас слышали.
В Польше же есть другая компания – Codeminion. Тоже вполне серьезное предприятие, которое стала развиваться и приобрела известность после разработки удачной игры в жанре match3 – Magic Match. Некоторое время спустя они выпустили вторую оригинальную игру – StoneLoops! of Jurassica, игровая механика которой повторяла Luxor. Игра была сделана очень качественно, имела свои уникальные игровые возможности и оригинальный сеттинг. Такого же признания как Luxor или Zuma игра не получила, но мирно и спокойно продавалась вместе с ними на одних и тех же сайтах.
В начале прошлого года Codeminion выпустила StoneLoops! of Jurassica на iPhone. Через некоторое время Mumbo Jumbo выпустила на iPhone Luxor. Но Codeminion была первой. И StoneLoops становится более популярной игрой чем Luxor на этой платформе (а может дело было не только в первенстве игры). Игра два месяца находится в топ-10, а это уже очень существенный уровень дохода.
Осенью Mumbo Jumbo не выдерживает, и ее юристы подают в «Apple» жалобу на игру конкурента в которой обвиняют его во всех смертных грехах, включая и кражу исходного кода. Через три недели, в конце октября, StoneLoops! исключается из Apple App Store! Более детальное описание этой истории можно прочесть на английском языке в блоге разработчиков. С тех пор юристы Codeminion пытаются добиться возврата игры обратно в каталог, но пока безуспешно.
Из этих двух историй можно сделать следующие выводы: тот у кого юристы круче (или хотя бы просто есть), тот и получает более высокое место в рейтинге Apple App Store; на платформе iPhone запатентовать игровую идею все таки можно.
При отладке программы иногда бывает необходимо включать и исключать различные участки кода. Это легко делается с помощью комментирования не нужного на текущий момент кода и в большинстве IDE это можно сделать довольно быстро при помощи горячих клавиш.
В языках программирования, чей синтаксис во многом копирует синтаксис C я уже много лет пользуюсь еще более простым и удобным способом работы с комментариями. Все дело в правильном комбинировании двух видов комментариев. Перед закрывающей скобкой комментария «*/» добавляем комментарий строки «//»
/*
Закомментированный текст
//*/
Теперь, чтобы быстро убрать комментарий нужно добавить всего один символ «/» перед открывающей скобкой, а об закрывающей можно забыть.
//*
Теперь текст работает
//*/
Если комментируемый участок занимает больше нескольких строк, не говоря уж об экране, то выгода времени получается существенной.
Приятно результативный день для разработки игры. Все еще занимаюсь окном «Upgrade», но окончание уже видно. Выбранные элементы становятся в указанные слоты и удаляются из общего списка. Те элементы, которые были в слоте раньше – в список возвращаются. Характеристики «башни» при этом изменяются и изменения отображаются на экране. На окончательные значения влияют базовые характеристики «башни», характеристики установленного оружия и защиты и характеристики дополнительных устройств – «gadgets».
Осталось сделать всплывающие подсказки с детальными характеристиками и добавить учет бюджета, чтобы устанавливать устройства можно было только в рамках накопленной к текущей игровой ситуации суммы.
После этого остается сделать следующий режим работы, а потом чуть более простое, но все равно довольно «веселое» окно исследований. Но об этом думать сейчас несколько тоскливо: хочется уже вернуться к оружию, взрывам и интеллекту «монстров».
Это текущая версия окна «Upgrade». Все данные, включая названия, тестовые, а на кнопках нет иконок. Этот интерфейс нравился мне ровно двадцать минут после того, как я его завершил и мне постоянно хочется его изменить, как с точки зрения эргономики – слишком много пустого места вверху, так и с точки зрения дизайна – он удобный и понятный, но не атмосферный.
Основной вопрос, который не дает мне сейчас покоя – это такой: у «башни» есть слот для оружия и у разных «башен» он может быть разного уровня и разного типа (на иллюстрации слот для ракетного оружия второго уровня). Оружие, соответственно, тоже различается по типу и по уровню. Если уровень оружия больше чем уровень слота, то вставить его в «башню» нельзя. Но вот надо ли показывать такое «высокоуровневое» оружие в списке?
С одной стороны, по эргономике игроку удобней, когда ничего лишнего в списке нет. С другой, когда у него перед глазами постоянно более мощное вооружение, которое он пока не может использовать, то у него (теоретически) появляется дополнительный интерес к развитию: исследованию и постройке более мощной «башни». Понятно, что если недоступное оружие оставлять в списке, то его надо выделить цветом подложки, но на этом пока мысль заканчивается.
