Cronvid Blog

Обработка передвижений мыши в AS 3.0 на первый взгляд выглядит очень просто. И документация и десятки примеров в интернете показывают как это сделать:

sample_mc.addEventListener(MouseEvent.MOUSE_MOVE, SampleMouseMove);

Теперь, когда курсор мыши будет наведен на клип sample_mc, то будет вызвана функция SampleMouseMove, которая получит параметр типа MouseEvent из которого можно будет узнать координаты курсора и много другой информации.
Однако, внутри скрывается несколько нюансов, которые привели к тому, что у меня на правильный обработчик ушло несколько часов времени.
Читать далее…

Небольшое предисловие: в 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;
	}
}

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

Все мы читали множество историй о том, как популярны игры среди пользователей 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 я уже много лет пользуюсь еще более простым и удобным способом работы с комментариями. Все дело в правильном комбинировании двух видов комментариев. Перед закрывающей скобкой комментария «*/» добавляем комментарий строки «//»

/*
Закомментированный текст
//*/

Теперь, чтобы быстро убрать комментарий нужно добавить всего один символ «/» перед открывающей скобкой, а об закрывающей можно забыть.

//*
Теперь текст работает
//*/

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

Если вдруг кто-то пропустил, то на сайте dtf.ru выложенна отличная статья Петра Прохоренко «Огонь, иди со мной» о мотивации, вовлеченности и ответственности создателя игры.
Информация для тех кто вышел на этот пост по архиву: на dtf.ru статьи в свободном доступе находятся только месяц, так, что с середины февраля ссылка работать не будет.

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

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

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

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

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

Решение задачи я нашел в блоге Мэта Торсона (Matt Thorson) в посте Embedding XML in AS3. В принципе на этом можно было бы и остановиться, но для удобства я переработал статью на русский язык.

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