Меню

Сергей Драган

О программировании

Как я HTML5-игру с OpenFL делал (и наплодил больше багов, чем там было самой игры)

В этом посте я собрал список проблем, с которыми столкнулся при разработке простой HTML5-игры на связке Haxe-OpenFL-Box2D. И самому себе на будущее, и кому-нибудь, может, тоже пригодится.

В первую очередь дисклеймер: мои руки растут из жопы, я плохо разбираюсь в OpenFL и Haxe в целом. Я понимаю, что это опенсорс и «если что-то не устраивает — возьми и почини сам». Также я очень благодарен всему русскому сообществу Haxe за неоднократные консультации и помощь!

На киевском DevGamm 2013 я хотел штурмовать Speed Game Dating, и для этого на пару с художником мы сделали за две недели Cake Break — Box2D-физпаззл на флеше. Времени было немного, поучаствовать хотелось, а игры такого плана делаются как раз быстро.

Спонсоры, глядя на игру, с равнодушным лицом отвечали: «Meh», добавляя, что вот если бы она была на модном HTML5 — то было бы, конечно, совсем другое дело, и что как только её портирую — сразу идти к ним.

Не вопрос! Откопал Haxe, сделал «haxelib install box2d», восхитился: «Как же легко портировать с флешика на хакс! Вот буквально только int на Int заменить и void на Void!», а дальше маленько обосрался, наивно полагая, что раз работает на десктопе и айпаде, то и везде будет работать. Как же я был наивен.

bad-computer

(далее…)

OpenFL: Float32Array is not defined

Я знаком с OpenFL крайне поверхностно, потому каждый раз, когда он ведёт себя «как-то не так, как вёл бы Flash» — искренне пугаюсь и теряюсь.

Всё было хорошо, пока не обнаружилось, что HTML5-игра не запускалась в IE9, говоря: «Float32Array is not defined».

Наверняка, есть изящные и удобные способы решить эту проблему, но мне помогло открыть сгенерированный .js, найти в нём эту строку

this.__array = new Float32Array([a,b,c,d,tx,ty,0,0,1]);

и заменить на эту:

this.__array = [a,b,c,d,tx,ty,0,0,1];

Уверен, что это не лучшее решение, и скорее всего при этом от игры что-то втихаря отваливается — но у меня всё вроде бы заработало.

cat_smiling

Уроки, вынесенные из не слишком удачной социалки

Примерно два с половиной года назад я был нанят компанией, не связанной с разработкой игр, чтобы принять участие в их экспериментальном проекте — разработке f2p-социалочки с продакт-плейсментом. До этого весь мой опыт в геймдеве ограничивался полутора десятками небольших флеш-казуалок.

Команда подобралась настолько компактной, насколько возможно: серверщик, клиентщик, дизайнер, художник-аниматор. Раздувать штат инвестор не хотел, потому как сам не был уверен в целесообразности данного предприятия. При этом каждый (кроме, пожалуй, меня) хорошо знал своё дело, и был в нём действительно хорош. Казалось бы, всё должно получиться!

Ошеломляющего успеха не было, retention и платежные показатели оказались крайне скромными (правда, и деньги в раскрутку не вкладывались — оценки делали по первым 200к игроков, пришедших в игру в первые недели просто из каталога Вконтакте, пока игра висела в разделе «новые»). В вопросах монетизации и геймдизайна я много опыта всё равно не набрал, однако несколько выводов для себя сделал, и хотел бы ими поделиться — может, кому пригодится. Тем более, сейчас, работая в большой игровой компании, я особенно чётко вижу, как умные и опытные люди избегают моих «детских» ошибок.

На эту же тему, к слову, я ещё могу порекомендовать хорошие статьи «как умудриться совершить 14 ошибок, разработав одну социальную игру» и «Целенаправленный сбор и анализ граблей в разработке игр для соцсетей«.

Нижеизложенное, повторюсь — это сугубо мои персональные выводы (во многом капитанские), основанные на собственных наблюдениях и (часто) ошибках. Итак!..

Я понятия не имею как проектировать

Не переоценивать себя

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

Возможный выход: попросить подробную консультацию тех людей, которые уже таким занимались и съели собаку. Даже если за это придётся заплатить денег — оно себя окупит. (далее…)

О «волшебной» частоте кадров

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

И вот недавно стало ну совсем уж интересно: так что же в этой частоте такого особенного?

Если очень вкратце и без подробностей, то, оказывается, уходит это дело в самое начало тысячелетия (ух, как звучит!), и заключается в том, как Flash Player старых версий (в районе четвёртой-пятой, которые жили примерно в 1999 – 2002 годах) хранил, конвертировал и обрабатывал само число — значение частоты кадров, в результате чего при указанных в настройках 24 кадрах в секунду реальное значение частоты кадров равнялось, уже 24,39. Из-за этого анимация «проскакивала», и гладкость терялась. А 31 было оптимальным в плане минимальных потерь точности и хорошего быстродействия.

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

P.S. Немного почитать по теме можно здесь: http://brajeshwar.com/2004/magic-framerate/http://stackoverflow.com/questions/1067498/flash-player-magical-frame-ratehttp://www.kirupa.com/forum/archive/index.php/t-262897.html.

Создание iOS приложения с Flash CS5.5 + AIR 2.7

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

В двух словах о процедуре

Вышедший в 2011 году Adobe Flash CS5.5 в отличие от предыдущих версий, поддерживает «из коробки» не только возможность сборки приложения AIR для Android, но и для iOS без каких-либо дополнительных ухищрений. В целом, суть процедуры довольно проста: пишем приложение, оптимизированное под (относительно) маломощное железо, небольшое разрешение экрана и тачскрин, собираем в AIR, подписав персональным сертификатом, и вуаля! — заливаем на телефон/планшет и играемся вдоволь.

А теперь немножко практики. (далее…)