После перевода наших проектов на CMake, встал вопрос об отладке нативной части Android. Так как инструменты NDK стали неактуальны, пришлось залезть в дебри и научить Eclipse запускать удалённую отладку CDT-проекта, что называется, вручную. В идеале, чтобы это выполнялось в один клик.

Если вам не чужда разработка с использованием Android NDK, и вы хотите познать некоторые тонкости отладки, велкам под кат.

Мобильный free-to-play уже практически не обходится без использования социальных сетей в играх. Социальные сети обеспечивают то, что называют виральностью (от англ. viral – вирусный, т.е. способный распространяться как вирус, от одного человека к другому), что позволяет привлекать новых игроков с минимальными затратами. В данной статье мы поделимся опытом интеграции Facebook в игры Alawar на платформе iOS.

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

Всем привет!

Наверное, каждого, кто хотя бы раз сталкивался с CMake, посещала мысль: почему документация на официальном сайте лежит в виде большущего одностраничного документа, использование которого доставляет больше неудобств, чем должно приносить пользы? Оказывается, нужно выполнить всего несколько шагов, чтобы получить удобную документацию с деревом категорий, списком подразделов и адекватным форматированием всей информации. Подробности сего действа под катом.

Около года назад перед нашей командой была поставлена задача стартовать разработку серверных частей ряда игровых MMO проектов. Специфика такого рода проектов помимо требований к гибкости, стабильности и масштабируемости также включает в себя:

• необходимость A/B-тестирования разных версий одной и той же игры
• возможность по максимуму переиспользовать функциональность от одной игры в другой
• высокую вероятность географической удаленности от разработчиков занимающихся клиентской частью игры

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

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

Всем привет,

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

Не секрет, что в последнее время кроссплатформенные мобильные free-to-play игры стали основным направлением деятельности большого числа игровых компаний. В этой статье мы не будем говорить ни о причинах, которые к этому привели, ни о перспективах данного направления. Компании изменили свои бизнес-модели, начертили схемы монетизации и игровых циклов, помолились на SCRUM и Agile, однако в статье речь пойдет и не про это. Игры по-прежнему нужно делать качественно, нужно правильно выбирать технологии, нужно понимать, что ждать от загадочного free-to-play и с чем придется столкнуться. В этой статье мы рассмотрим 5 наиболее важных технологических проблем, возникающих при создании кроссплатформенных мобильных free-to-play игр.

Всем привет!

На прошедших выходных под Томском прошла одна из самых необычных IT-конференций, на которых мне удалось побывать.

Если вы не видите себя без общения с себе подобными, любите отдых, палатки, ночной кодинг шейдеров, игровые движки, C++ хардкор оптимизацию, игры, задушевные разговоры о LLVM и Flash под раскаты грома, красивых девушек в купальниках, способных собрать билд на 7 платформ в один клик — велкам под кат, там про то, как это было.

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

Начиная с версии 5.4.0, в PHP появится новая конструкция языка — трейты (traits), реализующая возможность использования примеси (mix in). Механизм примесей является еще одним механизмом повторного использования кода и присутствует в том или ином виде в других языках, например, Ruby, Python, Common Lisp, etc.

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

Следует отметить, что реализации примесей в PHP существуют как минимум с версии 4.0.1, и в настоящее время присутствуют, чаще всего под именем behavior, в ряде популярных фреймворков, например, в Yii, Symfony, Doctrine, CakePhp, Propel.

Цель статьи — продемонстрировать и сравнить несколько основных подходов к реализации примесей в PHP до версии 5.4.0, базирующихся только лишь на функциях самого языка и не использующих сторонние расширения, как-то, например, функцию runkit_method_copy из PECL runkit.

Всем привет! Сегодня я бы хотел рассказать о том, какие есть способы устроить бранчи под каждую задачу и как мы это сделали у себя в Alawar. Здесь рассматривается простой приём с apache2, который позволяет получить отличный результат и может быть полезна как веб-разработчиками, так и системным администраторам. Стоит отметить, что аналогичные решения уже освещались на хабре (например, тут), но часто они написаны для слишком узкой аудитории и не дают ответы на все вопросы и, главное, часто усложняют задачу. Цель же конкретно этой статьи, – показать, как на самом деле всё просто.

Здравствуйте!

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

Авторизованное подключение к iSCSI

Если вам понадобилось при подключении к iSCSI указать креденшиалы — лучше это делать в обход Proxmox. Почему?

• Во-первых, потому что через web-интерфейс Proxmox невозможно создать авторизованное iSCSI-подключение.
• Во-вторых, даже если вы решите создать в Proxmox неавторизованное подключение с тем, чтобы указать авторизационную информацию вручную, то вам придется бодаться с системой за возможность изменить конфигурационные файлы таргетов, так как при неудачной попытке подключения к iSCSI-хосту Proxmox перезаписывает информацию о таргетах и производит повторную попытку подключения.

Всем привет!

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

Напомню, что в проекте используется php(Yii), mysql и memcached. В проекте достаточно много сущностей, для каждой из которой есть своя модель, которая наследуется от CActiveRecord.

Хранятся файлы моделей следующим образом. В папке models создаем папку base. Когда генерируем модель через Gii, то указываем, что ее нужно положить в папку models/base и к имени класса добавляем Base. Затем создаем в models аналогичный класс без Base, который наследуется от базового класса и имеет в себе лишь метод model().

Кстати заранее скажу, что базовые модели наследуем не от CActiveRecord, а от ExtActiveRecord — расширяем CActiveRecord под наши нужды. Но об этом позже. Пока что разницы никакой.

Пример:
models/base/BaseUser.php — стандартный класс, который генерируется через Gii
models/User.php — класс, который наследуется от BaseUser и имеет в себе метод model()

	/**
	 * Returns the static model of the specified AR class.
	 * @param string $className active record class name.
	 * @return User the static model class
	 */
	public static function model($className=__CLASS__) {
		return parent::model($className);
	}
	

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

Не забываем добавить в конфиге 'application.models.base.*'.

Перейдем собственно к теме поста и поставим задачи, которые хотим решить:

1. Уменьшить количество запросов в базу на обновление
2. Уменьшить количество запросов в базу на выборку

Всем привет!

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

1. игрок совершает действие на клиенте
2. клиент проверяет возможность совершения действия
3. отсылает команду на сервер
4. сервер проверяет возможность совершения действия, выполняет команду, производя изменения в базе
5. клиент уведомляется о том, что все ок или информируется об ошибке

Все работало отлично, пока не происходило резкое возрастание количества игроков.
Сначала начались тормоза со стороны php. Основная проблема данной реализации заключалась в том, что на каждое действие игрока дергается сервер, который производит довольно много вычислений по обсчету объектов на карте перед выполнением команды. Эта проблема была решена путем добавления дополнительных серверов с обработчиками php.
Потом мы уперлись в производительность mysql. Было слишком много запросов. Так как шардинг не был заложен в систему, то выкручивались как могли. Что-то перенесли в mongodb, где-то улучшили работу с кэшем.

Кстати, mongodb оказался не таким простым хранилищем, как может показаться на первый взгляд. Учитывая то, что у нас было включено шардирование и стояли правильные индексы, мы все равно словили там тормоза, с которыми не смогли разобраться на тот момент. Периодически просто высыпалась пачка запросов в log, которые вдруг затупили. Хотя через секунду те же запросы работали нормально при том же количестве запросов. Но это тема отдельного поста.

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

Всем привет. Вот и подошла очередь нашей очередной статьи. В первой мы познакомили вас с рабочими процессами нашей студии и вскользь упомянули тулзы, которыми мы пользуемся при создании игр. Вторая статья была посвящена кроссплатформенности движка Alawar Engine и предназначалась во многом для тех, кто уже сталкивался с подобными вопросами в своей работе. К слову о кроссплатформенности – 13 марта вышла наша игра для PlayStation 3, которую мы впервые создали на движке Alawar Engine. Помимо кроссплатформенности движок поддерживает и мультижанровость, так уже были выпущены игры в таких жанрах как: арканоид Hyperballoid 2, match-3 The Treasures of Montezuma 2, аркада Space Op (iOS), готовится к выпуску тайм менеджер из серии «Веселая ферма».

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

Добрый день! В предыдущей статье была рассмотрена общая часть процесса создания игр жанра HOPA (Hidden Object Puzzle Game или «поиск предметов»). В этой статье мы рассмотрим принцип двухуровневой программной абстракции, который является парадигмой основных платформозависимых компонентов нашего движка, и общую структуру нижнего уровня движка. Такой подход позволил нам добиться гибкости в портировании как движка на новые платформы, так и самих игр с одной платформы на другую. А также нам удалось создать:

• трехуровневую структуру игры;
• унифицированную подсистему 2D графики;
• универсальную организацию исходного кода.

В основу программной части Alawar Engine входят 2 библиотеки: SF (Stargaze Framework library) и QE (Stargaze Quest Engine library). SF является ядром всей системы и содержит почти всю платформозависимую реализацию игры. При этом библиотека имеет одну общую ветку исходников для всех платформ. На данный момент SF функционирует под шестью платформами: Windows (XP, Vista, Windows 7), Mac OS X, iOS, Android, PS3 и Windows 8 (в разработке).

Привет. Сегодня мы начинаем цикл статей, который познакомит вас с процессом разработки игр на движке Alawar Engine. Первая статья вводная, в ней мы в общих чертах расскажем о создании игрового контента, блочной системе скриптования, с помощью которой из разрозненных частей собирается игра, а также немного о других бизнес-процессах в студии Alawar Stargaze. На текущий момент движок лицензируется внешними студиями, сотрудничающими с Alawar, в разработке находится около 20 проектов. Некоторые проекты, созданные лицензиатами, уже выпущены, например Weird Park.Broken Tune.

Разработка игры начинается с человека, у которого есть идея будущей игры. Да, как обычно без большой и заразительной идеи никуда. Она должна включать в себя общее представление о создаваемой игре, описание игрового мира и персонажей. Из идеи рождается сценарий, в котором прописываются основные сюжетные линии и повороты. Гейм-дизайнеры создают проектную документацию, которая, по сути, является техническим заданием для 3D-моделлеров, 2D-художников, аниматоров, специалистов по созданию эффектов, скриптеров, композиторов и других участников команды.

Здравствуйте!

Это вторая часть статьи о работе c кластерным хранилищем в Proxmox. Сегодня поговорим о подключении хранилища к кластеру.

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

В нашем случае проблема организации общего хранилища сводится к двум аспектам:

1. У нас есть блочное устройство, отдаваемое по сети, к которому будут иметь доступ несколько хостов одновременно. Для того, чтобы эти хосты не подрались за место на устройстве, нам нужен CLVM — Clustered Logical Volume Manager. Это то же самое, что LVM, только Clustered. Благодаря CLVM каждый хост имеет актуальную информацию (и может ее безопасно изменять, без риска нарушить целостность) о состоянии LVM-томов на Shared Storage. Логические тома в CLVM живут точно так же, как в обычном LVM. В логических томах находятся либо KVM-образы, либо кластерная FS.
2. В случае с OpenVZ у нас есть логический том, на котором расположена файловая система. Одновременная работа нескольких машин с некластерной файловой системой ведет к неминуемым ошибкам в работе всего — это лебедь, рак и щука, только хуже. Файловая система обязательно должна знать о том, что она живет на общем ресурсе, и уметь работать в таком режиме.

В качестве кластерной файловой системы мы используем Global File System 2.

Всем привет!

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

Мы столкнулись с необходимостью автоматизировать сборку и деплоймент на тестовые устройства, когда размер парка устройств превысил два десятка, а количество проектов, одновременно находящихся в QA достигло 30+. При таких объемах деплоймент билда на тестовые устройства с помощью “Build & Run” в XCode начал заметно затормаживать процесс прохождения QA. Было принято решение об автоматизации процесса сборки и заливки билдов на устройства.

Наша обновленная билд-система состоит из трех основных компонентов:

• Репозитории с исходными кодами проектов;
• Сервер сборки;
• Сервер раздачи билдов на устройства.

Процесс прохождения версии проекта от разработчиков до тестировщиков выглядит следующим образом:

• Разработчик делает коммит версии в репозиторий;
• Билд-сервер запускает сборку соответствующего проекта;
• В случае успешной сборки, билд выкладывается на сервер раздачи;
• Итоговый IPA устанавливается на устройства “по воздуху”.

Не так давно, прочитав статью idoroshenko «Почему eval — это не всегда плохо», я задумался, можно ли использовать подход с генерацией тела функции для клонирования объектов. Даже написал небольшую библиотеку для этого. Бенчмарки давали невероятные результаты, но применимость этого подхода ограничивалась лишь множественным клонированием одинаковых объектов.

Поэтому и у меня возник вопрос: неужели в v8 нет другой возможности избежать расходов, связанных со множественным пересозданием скрытых классов? Ведь это составляет основные траты ресурсов, когда мы клонируем объекты. Как оказалось, такая возможность действительно есть: в самом v8 у объектов существует метод v8::Object::Clone. Этот метод клонирует объекты в широком смысле этого слова, то есть собственно объекты, а также массивы, даты, регулярные выражения, функции и т.д., при этом сохраняя все их свойства, в том числе нестандартные (например, именованные свойства массивов) и даже скрытые.

Была только одна маленькая проблема. Этот метод использовался только в недрах node.js, и не был открыт наружу, для javascript'а.