1. Перезапись URL на стороне веб-сервера. Запрашиваемый URL обрабатывается веб-сервером (сейчас Apache, потом лучше всего фронт-енд вынести на Nginx). Используя правила для mod_rewrite из корневого файла .htaccess, производится перенаправление запроса на index.php в корне сайта, при этом запрашиваемый URL передается как GET-переменная __route__. Все остальные переменные из запроса сохраняются в неизменном виде.

2. Определение главной страницы входа.  На входе в скрипт проверяется существование такого URL и его сравнение с относительным адресом корня сайта (’/'). Если адреса нет, он пустой или указывает на корень сайта, он подменяется на адрес по-умолчанию, обычно это ‘game/index’. В принципе, это можно реализовать и через правила для mod_rewrite, что, видимо, будет сделано в следующих версиях при переходе на Nginx.

3. Подключение основных файлов платформы. Здесь несколько стадий, который выполняются последовательно:

1. Подключение ядра платформы ( файл  ‘inc/agplatform_core.php’);
2. Установка путей для подключения файлов, мы указываем, что все далее подключаемые файлы будут указаны относительно директории /inc/lib, там хранятся все используемые библиотеки проекта.
3. Инициализируем основные компоненты Zend Framework – Registry и устанавливаем автозагрузчик классов Zend_Loader.
4. Объявляется функция для инициализации  отладочного инструмента – FirePHP, который используется для проверки и отладки на всех стадиях. Поэтому эта стадия вынесена из самой платформы, так как только так можно задействовать FirePHP для отладки даже ядра системы и механизма роутинга. В релизной системе можно отключить или даже удалить все отладочные вызовы, что повысит быстродействие и уменьшит трафик.
5. Подключаем описание интерфейса для менеджеров сигналов (файл ‘IconnectManager.php’)
6. Подключаем модуль системы роутинга (файл ‘agplatform_routing.php’);
   • Подключается файл с описанием исключений (файл ‘agplatform_exceptions.php’);
   • Подключение всех  менеджеров сигналов. Их четыре и они размещаются в корневых директориях, где лежат другие файлы этих модулей. В корне  – системный менеджер, отвечающий за сигналы платформы, в директории Admin – менеджер системы управления игрой и админ-панели, в AGPsource – менеджер стандартной библиотеки классов, в Game – специфические для конкретного проекта классы и обработчики.

4. Инициализация системы роутинга. Мы создаем экземпляр класса AGPlatform_Routing, но если быть точным – это синглтон, поэтому мы получаем экземпляр объекта через статический метод getInstance.

1. Если объект ещё не был создан, то вызывается его конструктор, который, в свою очередь:
   • Вызывает метод _constructRoutesTable для создания полной таблицы роутинга, для чего опрашиваются все подключенные ранее менеджеры сигналов, а результат сводится в единый массив URL, которые обрабатываются игровой платформой.
   • Инициализируется внутренний массив параметров $param, который передается во все обработчики сигналов. Пока он пустой.
   • Читается стандартный конфигурационный файл  /inc/config/game_config.ini, который возвращается как ассоциативный массив и сохраняется в реестре, а также добавляется к массиву обязательных параметров (см. предыдущий шаг).

5. Локализация. Далее системы пытается выяснить, есть ли в запросе или его параметрах указание на язык локализации. Для этого мы пробуем выделить первую часть из адреса, а также проверяем, присутствует ли параметр lang в запросе или в сессионных переменных. Также проверяется, есть ли указанный язык в списке поддерживаемых языков из конфигурационного файла. В случае отсутствия указания языка или его поддержки, используется язык по умолчанию (устанавливается в конфиге). Поиск языка происходит в следующем порядке:

• Проверяется первая часть из запрашиваемого URL (например, вида ru/game/new_user). Если там найден язык, эта часть из URL удаляется и в дальнейшем все обработчики получают URL вида game/new_user, без кода языка.
• Проверяется массив переменных из запроса – $_REQUEST['lang'];
• Проверяется массив сессионных переменных.
• Установленный код языка передается в статичный метод ядра для инициализации локализации – AGPlatform_Core::set_locale, где сохраняется в реестре для использования далее. Следует отметить, что больше никаких действий не производится, поэтому если вы не используете локализацию при обработке какого-либо URL, то падений производительности нет, так как подсистема локализации инициализируется только после явного вызова ассоциированных с ней сигналов.

6. Построение таблицы роутинга. Обработанный URL передается объекту роутинга в метод dispatchURL, который и производит дальнейшую обработку запрашиваемого адреса.

1. Запрашиваемый URL предварительно обрабатывается и приводится к стандартному виду (метод prepareURL) – переводится в нижний регистр и убирается начальный слеш, если присутствует. Также может проверяться длина запроса (пока она максимум 4096 символов).
2. Если URL не пустой и проверка не вернула false, адрес сохраняется в списке параметров.
3. Обрабатываются все переменные из запроса в методе prepareHTTPRequest, в дальнейшем они сохраняются в массиве обязательных переменных под ключом ‘httprequest’.
   • Обработка параметров происходит для всех типов запроса, кроме application/x-amf, которые пропускаются (они бинарные и преобразуются внутри AMF сервера).
   • Проверяются все имена переменных, максимальная длина названия – 1024.
   • Проверяются все значения переменных, максимальный размер  – 4096 символов.
   • Служебные переменные,имена которых начинаются с символа подчеркивания ‘_’, исключаются из обработки.
   • Следует отметить, что приложение всегда может получить доступ к исходным значения параметров через суперглобальный массив $_REQUEST, однако это не рекомендуется без особой надобности.
4. Формируется массив сигналов, которые соответствуют указанному URL.
   1. Вызывается метод getRoutingToURL, который ищет совпадение в массиве адресов и, находя первый адрес, совпадающий с тем, что есть в таблице, возвращает ассоциированый с ним массив сигналов. Обратите внимание, что URL без начального слеша, в нижнем регистре и ищется полное совпадение (то есть, URL вида user/add/1 и user/add это разные адреса, соответственно все параметры и переменные должны передаваться в GET/POST, а не в адресе). В случае отсутствия URL в таблице роутинга, возвращается определенный по умолчанию сигнал или массив сигналов ( default_empty_url_signal)
   2. Вызывается метод buildFullSignalsTable, который строит полную таблицу сигналов для обработки. Для этого он объединяет в один массив следующие сигналы:
      • Обязательные начальные сигналы, которые вызываются ДО определенных для конкретного URL (описаны в переменной класса pre_dispatch_signals);
      • Список сигналов для этого URL, найденный методом getRoutingToURL;
      • Обязательные заключительные сигналы из таблицы в переменной post_dispatch_signals.
5. Окончательный массив сигналов сохраняется в списке обязательных переменных.
6. Для всех указанных сигналов производится проверка и подключение сигналов к их обработчикам
   1. Проверка сигнала состоит в выделении префикса  (пространства имен сигналов, строки до первого знака подчеркивания).
   2. Проверяется, существует ли такое пространство имён
   3. Проверка всех менеджеров сигналов через их переменную $prefix, которая хранит массив пространств имен для тех сигналов, за которые отвечает этот менеджер. Учтите, что хотя разные менеджеры могут отвечать за одно и то же пространство имен, но механизм проверки проверит лишь первый менеджер из списка. Изменение способа  проверки планируется в версии 3.5.
   4. Вызывается метод signalManager для менеджера, который обслуживает данный сигнал. Внутри менеджера ищется описание обработчика для сигнала и если он найдет, вызывается метод connect  механизма роутинга ( метод класса AGPlatform_Routing).
   5. Для каждого сигнала создается своя таблица обработчиков – их может быть несколько и они вызываются в порядке подключения или согласно приоритету. По умолчанию приоритет 1000. Таблица обработчиков для сигналов хранится в переменной _connecting экземпляра роутера.

7. Обработка таблицы сигналов. Производится обработка окончательной таблицы сигналов. Это финальный момент обработки всего запроса ядром платформы.

1. Если не установлен флаг прерывания обработки, текущий сигнал помещается в массив стандартных параметров.
2. Генерируется сигнал путем вызова метода emit роутера, которому передается текущий сигнал и массив обязательных параметров.
3. В случае генерации исключения в любом месте обработки выставляется флаг остановки обработки сигнала и завершения работы роутера. Стек ошибки и бектрейс пишется в лог и выводится через FirePHP.
4. При генерации сигнала, в методе emit проверяется таблица уже обработанных сигналов, а также таблица, где указаны все сигналы, которые могут генерироваться несколько раз. Обычно сигнал может быть сгенерирован только один раз, иначе будут коллизии, если, к примеру, сигнал устанавливает соединение с базой данных. Однако есть определенные сигналы, которые безопасно вызывать несколько раз (хотя и в обычных обработчиках стоят проверки, поэтому это не приведет к фатальным последствиям), поэтому они описываются в отдельной служебной таблице.
5. Для проверки, был ли уже обработан сигнал, служит метод isEmited($signal);
6. Если сигнал не обрабатывался ранее или разрешен к повторной обработке, проверяется, есть ли подключенные к этому сигналу обработчики. Если нет – производится попытка их подключить. Далее передается вызов в служебный метод _emit().
7. Подключенные обработчики сортируются исходя из своего приоритета.
8. Проверяется, является ли обработчик вызываемой сущностью – функцией или методом класса. Стандартно обработчики сигналов – это публичные статические методы классов.
9. Метод-обработчик вызывается через call_user_func_array, в качестве параметров передаются две переменные – массив обязательных параметров, который формируется роутером и опциональные, которые передаются только конкретному сигналу (в отличие от стандартных параметров, передаваемых во все обработчики).
10. Результат выполнения обработчика заносится в специальный массив (emit_results), ключом служит имя сигнала (так как обработчиков может быть несколько, формируется массив).
11. В случае ошибки -  исключение AGPlatform_Unknown_Connect_Exception.

Требования:

• PHP 5
• JavaScript/AJAX (Jquery, ExtJS будет плюсом)
• ZendFramework (или его быстрое освоение, да, MVC не требуется, у нас Signal/Slot архитектура)
• желательно опыт подобных проектов и интерес к браузерным играм вообще
• понимание кеширования (APC, Memcached, файловое)
• Опыт работы с MySQL
• письменный английский (для документирования кода, чтения документации)
• навыки работы с системами контроля версий (SVN) и тикет-системами
• возможность быть онлайн большую часть суток

Приветствуется:

• коммуникабельность
• интерес к новым технологиям и профессиональному росту
• базовые навыки администрирования Linux (не критично)
• базовые знания/понимание Flash-а.

Условия

Варианты разные – офис в Львове (пока обсуждается), удаленная работа но желательно с периодическими встречами. Гибкий график.

Карьерный рост в случае желания – у нас много работы и в будущем, видимо, будет еще больше.

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

Очень интересные проекты и задачи!

Финансовый пакет:  по результатам обсуждения.

Контакты:

• aleks.raiden@gmail.com
• ICQ: 346525015
• GTalk/Jabber: aleks.raiden@gmail.com

• excluded ezComponents requirments, own signal/slot system
• updated ExtJS and other librray
• ZendFramework updated to 1.8.2
• default site url added (site/index)
• updated xml config for PHP-IDS
• full rewrite ACL system (now with cache)
• full rewrite DB support (both, direct mysqli and Zend_DB support)
• added FirePHP logging support
• added DB profiling (if use FirePHP and output buffering)
• many bugfix and small improving

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

Функционально все разделено на три больших части – инфраструктурная часть, на базе которой работают все остальные компоненты, основные библиотеки и фреймворки, обеспечивающие функционал для последней и основной части проекта – собственно, самой игровой платформы, которая как раз полностью наша собственная разработка (не включая отдельные скрипты для реализации околоигровых сервисов).

Инфраструктура

• ОС: Linux (CentOS 5.3) или Nexenta Platform (OpenSolaris/Ubuntu platform), которые развернуты на виртуальных серверах или в облачной системе
• PHP 5.3 + OpCache – основа для работы всей программной системы. Мы используем именно версию 5.3, так как она максимально гибкая и предоставляет все современные возможности для приложений, включая целый ряд новых модулей и расширения, которые требуются нашему проекту. В качестве кеша и акселератора мы рекомендуем использовать APC или XCache, также возможна работа с Zend Platform (тогда доступны некоторые продвинутые функции, например, кластеризация и т.п., однако лицензия на платформу покупается отдельно).
• MySQL 5.4 или Drizzle – в качестве основной базы данных мы используем последние сборки MySQL, оптимизированные для многопроцессорных и многоядерных архитектур. В следующей версии 3.5 платформы мы планируем перейти на использование специальной базы данных Drizzle, которая является облегченной и максимально гибкой и масштабированной системой для современных Web 2.0 приложений.
• Memcached – система распределенного кеширования, используется для быстрого общего кеша, а также для хранения сессий и данных пользователей для максимальной производительности.
• MemcacheDB/Q - системы постоянного хранения и очередей сообщений на базе memcached, используются для реализации постоянного хранения данных при перезагрузках или сбоях, а также для взаимодействия отдельных модулей (система очередей сообщений). Эти решения выбраны потому, что обеспечивают прозрачное интегрирование в общий стек технологий, так как мы уже используем Memcached, то они стали лучшим выбором и обеспечивают максимальную производительность.
• Gearman используется как распределенная платформа для сложных вычислений, например обработки логов, ведение статистики, а также для сложных игровых модулей, таких как расчет сражений (как в играх типа OGame, Travian, Война Племен).

Основные библиотеки

• Zend Framework – основной фреймворк, на базе которого реализуются большинство компонент, также именно он обеспечивает ряд базовых возможностей игровой платформы. Вместе с тем мы понимаем некоторую избыточность такого решения и поэтому не используем некоторые ресурсоемкие или неудачные в плане архитектуры компоненты, предпочитая строить свою платформу максимально гибкой. Также благодаря ZF игровая платформа изначально ориентированная на взаимодействие с различными внешними сервисами, социальными сетями и системами (Facebook, Twitter, OpenId), а также реализует собственный открытый внешний API.
• Template engine – учитывая различные подходы к проектированию современных веб-систем, мы остановились на отлично зарекомендовавшем себя, простом и быстром решении с применением специальной системы шаблонов (движка шаблонов) TemplateLite.
• AJAX библиотеки: ExtJS, Dojo Toolkit, SoundManager 2 и другие. Для создания интерфейсов, админ-панели и различных игровых компонент мы активно применяем технологию Ajax, все наши проекты максимально использую все ее возможности. Не без гордости заявляем, что мы впервые на рынке браузерных игр разработали первую полностью Ajax игру, где после авторизации игрока нет ни одной перезагрузки страницы (и без фреймов)!
• PECL – мы используем расширения для обеспечения максимального функционала в РНР и для связи с другими библиотеками, некоторые функциональные возможности также могут выноситься в расширения языка, чтобы обеспечить наибольшую скорость. Для работы платформы мы тщательно отбираем те расширения, которые требуются и следим за совместимостью и стабильностью всей системы, отключая все невостребованные возможности.

AGPsource Platform

• Admin panel - для слежения и управления всей игровой системой мы разработали специальную унифицированную игровую админ-панель, с которой все сотрудники могут управлять и следить за всеми аспектами игрового процесса. В удобной форме отображены и логи действий пользователей, и отчеты системы безопасности и основные финансовые и аналитические показатели игры. Также мы используем встроенную систему безопасности и контрольных проверок, а интегрированных рабочий стол позволяет в удобной и компактной форме сразу получить все ключевые данные и их изменения, одним взглядом давая всю картину игры.
• AGPsource Core Platform – базовая платформа для всех компонент, обеспечивает механизмы инициализации всех компонент, обработку URL и данных, а также другие основные функции, служит слоем абстрагирования от нюансов остальных уровней системы. Именно с платформой и ее API работают все игровые классы, таким образом разработчик  освобождается от рутины и от него не требуется учет всех особенностей и тонких моментов остальных технологий.
• Game Class Library – набор готовых к использованию компонент, реализующих базовую игровую логику. Это те функции, которые приходится создавать для каждого проекта и мы решили собрать их в одну библиотеку, чтобы облегчить и себе и вам разработку или прототипирование своих проектов. Все компоненты унифицированы и работают с админ-панелью и другими частями системы, управляются и конфигурируются стандартным образом. Вы можете буквально через один-два дня сразу приступить к разработке уникальных игровых фич вашего проекта, оставив реализацию и поддержку основных рутинных моментов готовым классам. Также сюда включены стандартные игровые классы для реализации типовых игр и их возможностей, например – гибкая финансовая система, различные варианты карты игрового мира, перемещения, игровых персонажей, чата и т.п.
• Game- specific Class – это уже классы конкретного проекта, которые используются платформой и взаимодействуют в ее рамках друг с другом и с остальными модулями игры.
• Social service. Игра это не только сам по себе игровой мир, но и ряд социальных сервисов вокруг комьюнити игроков, которые имеют значение, подчас не меньше, чем сама игра. Например, новостная система, блоги, интеграция с современными социальными сервисами, такими как Twitter, Facebook, вКонтакте и другие. Даже собственная социальная сеть, объединяющая ваших игроков (а ведь у вас может быть и не один проект!) – и это реально! Все эти функции тесно интегрированы в игру, пользователь, зарегистрировавшись в проекте, сразу получает возможность с одними данными получить доступ ко всем возможностям и сервисам, видеть и общаться с другими игроками.

Wheemplay, Ltd

Направление браузерных игр

О компании

Компания Wheemplay Ltd основана в мае 2009 года путем слияния нескольких студий для обеспечения максимального качества работы и производства широкого спектра игр. Основа компании – разработка Flash-игр для игровых порталов, аутсорсинг, разработка казуальных игр и продуктов под мобильные платформы (iPhone). Отделение браузерных игр сосредоточено в г. Львове и образовано после слияния с командой AGPsource Lab Team.

Команда и опыт в браузерных играх

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

Ключевые сотрудники:

Александр Лозовюк – 26 лет, г. Львов, глава направления браузерных игр, более пяти лет в веб-индустрии. Главный разработчик большинства проектов компании. Опыт операционного управления и создания комьюнити, геймдизайн и проектирование игр. http://dtf.ru/person/info.php?id=6118

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

Стефан Кейш – руководитель Wheemplay Ltd, специалист в области флеш и казуальных игр. Руководит внутренней студией по производству графики и флеш-элементов для всех проектов компании. http://dtf.ru/person/info.php?id=16263

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

Основные проекты, в которых мы участвовали

SanCity.ru – онлайновая экономическая стратегия.

Что мы делали: подготовка сделки покупки, управление проектом, стратегическое развитие, создание и управление комьюнити, разработка инструментария для экономического анализа игрового мира.

URL: www.sancity.ru (работает)

WarAliance – космический тактико-стратегический симулятор

Что мы делали: полностью наша разработка, работа с привлеченным инвестором. Проектирование  архитектуры проекта, разработка (клиентская и серверная часть, графика), первый этап внутреннего тестирования.

URL: в настоящее время проект заморожен на стадии Beta-версии. Доступно описание процесса разработки в виде двух статей (+ скриншоты различных версий игры, http://abrdev.com/?p=602 и http://abrdev.com/?p=618)

Роза Ветров – браузерная RPG-игра о войнах на море

Что мы делали: аутсорсинг. Налаживание процесса разработки, уточнение ТЗ и геймдизайна. Весь цикл разработки клиентской и серверной части, тестирование. Графика и флеш-часть предоставлена заказчиком.

URL: www.seahopes.com (работает)

Повелитель островов – браузерная стратегия

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

URL: www.islandslords.ru (работает)

Printime – экономический обучающий симулятор

Что мы делали: наш собственный проект, совместно с Академией печати.

В настоящее время публичной информации нет (идет разработка).

Защитники – тактическая онлайн браузерная игра

Что мы делали: проект куплен и в настоящее время мы проводим редизайн и доработку проекта для нового владельца.

URL: www.defenders-game.ru (временно закрыт на доработку)

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

Используя опыт в разработке и поддержке различных игровых игр, мы с января 2009 года ведем разработку собственного продукта – платформы для быстрой разработки и прототипирования браузерных игр в жанре стратегии/менеджеров и симуляторов. Наше ПО позволяет сократить время для получения первого играбельного прототипа Вашего проекта, обеспечивает гибкость и простоту для разработчиков. В настоящее время все наши проекты разрабатываются на базе собственной платформы.  Публичный анонс технологии запланирован на июнь 2009 года, в настоящее время доступна презентация: http://www.slideshare.net/aleks_raiden/agpsource-game-platform-30

Основные технологии и средства, которые мы используем для разработки проектов: PHP 5 (Zend Framework, TemplateLite/Smarty, ezComponents, собственная платформа), AJAX (ExtJS и Dojo Toolkit), базу данных MySQL. Для отдельных систем применяется Flash/ActionScript и специализированные средства для клиентов (Adobe AIR). Все работы контролируются через систему контроля версий и багтрек, для управления процессом разработки мы используем коммерческую версию сервиса Assembla.com. Все ПО, используемое в процессе разработки, лицензионное. В случае использования в проектах стороннего ПО, необходимые лицензии на него входят в стоимость контракта и поставляются вместе с дистрибутивом.