Метро 2033 / Архитектура - 1
Перейдем к обсуждению серьезных вещей. На картинке первое предложение непосредственно по архитектуре игре, логический уровень.
Пройдем всю схему вместе с запросом от пользователя, от flash-клиента. Вся статика (картинки, фоны, описания) отдается, естественно, с бинарных кластеров (их непосредственное устройство пока не обсуждаем). Динамика проходит через nginx'ы и попадает на фронтенды игры (абсолютно взаимозаменяемые).
Фронтенд проводит авторизацию в менеджере сессий, который, скорее всего, построен на memcached. Менеджер сессий превращает SID (куку) в GUID, который представляет собой глобальный идентификатор пользователя в системе. Дальнейшее развитие событий зависит от класса действия (на картинке - action), которых не так уж и много.
Допустим, мы выполняем самое распространенное действие - ping(), это подтверждение существования и запрос изменений с предыдущего момента. Как происходит сбор данных? Здесь самый интересный момент. Введем понятие контроллер - контроллер это некоторый активный объект, объект, у которого каждые пять секунд вызывается метод $object->run(). Метод совершает какие-то действия (сохранение на диск, переход на новых уровень, какие-то расчеты и так далее). Контроллер персонажа котролирует все воплощения этого персонажа, все прокси-объекты этого персонажа.
Второе понятие - прокси-объект. Прокси-объект вводится, когда нужно представить один объект внутри другого. Например, персонаж участвует в бою, одновременно чатится и одновременно находится в каком-то сегменте, локации. На уровне логики это означает, что контроллер этого персонажа контролирует три прокси-объекта (один в чате, один в инцинденте-бою, один в сегменте). Прокси-объект не активен, это просто набор свойств и методов, фактически НАД НИМ совершают операции. Например, расчеты боя. При изменении в каком-либо из прокси-объектов этот прокси-объект сообщает контроллеру об изменениях и контроллер распространяет данные дальше...
Вот как происходит информация о распротранении смерти персонажа в бою:
Например, начинаем бой, персонаж сообщает контроллеру сегмента, что он хочет начать в нем бой. Контроллер сегмента содержит в себе прокси-объекты всех персонажей, которые находятся в данный момент в нем, на этом куске карты. Контроллер сергмента создает контроллер инциндента и передает всем причастным контроллерам персонажей информацию о том, что начался бой. Контроллер персонажа на основе собственных свойств принимает решение, должен ли он провалиться в бой, если да, то вновь созданный контроллер инциндента получает указания создать у себя множество прокси-объектов персонажей. Теперь уже контроллер инциндента начинает свои расчеты.
Если кто-то умирает, то в соответствии с вышеозначенным рисунком прокси-объект персонажа передает информацию в свой контроллер, который затем распространяет эту информацию по всем прокси-объектам. И сохраняет эти данные на диск.
PS: Технология, с помощью которой поддерживается целостность информации - CORBA (подробнее у Сергея Федорова - zmij_r).
PSS: Голубенькие квадратики сделаны в PhotoShop программистом Newmedia Stars - Павлом Зеленовым (_pashok_). Напоминаем, что в группе открыты вакансии дизайнеров ;)
Пройдем всю схему вместе с запросом от пользователя, от flash-клиента. Вся статика (картинки, фоны, описания) отдается, естественно, с бинарных кластеров (их непосредственное устройство пока не обсуждаем). Динамика проходит через nginx'ы и попадает на фронтенды игры (абсолютно взаимозаменяемые).
Фронтенд проводит авторизацию в менеджере сессий, который, скорее всего, построен на memcached. Менеджер сессий превращает SID (куку) в GUID, который представляет собой глобальный идентификатор пользователя в системе. Дальнейшее развитие событий зависит от класса действия (на картинке - action), которых не так уж и много.
Допустим, мы выполняем самое распространенное действие - ping(), это подтверждение существования и запрос изменений с предыдущего момента. Как происходит сбор данных? Здесь самый интересный момент. Введем понятие контроллер - контроллер это некоторый активный объект, объект, у которого каждые пять секунд вызывается метод $object->run(). Метод совершает какие-то действия (сохранение на диск, переход на новых уровень, какие-то расчеты и так далее). Контроллер персонажа котролирует все воплощения этого персонажа, все прокси-объекты этого персонажа.
Второе понятие - прокси-объект. Прокси-объект вводится, когда нужно представить один объект внутри другого. Например, персонаж участвует в бою, одновременно чатится и одновременно находится в каком-то сегменте, локации. На уровне логики это означает, что контроллер этого персонажа контролирует три прокси-объекта (один в чате, один в инцинденте-бою, один в сегменте). Прокси-объект не активен, это просто набор свойств и методов, фактически НАД НИМ совершают операции. Например, расчеты боя. При изменении в каком-либо из прокси-объектов этот прокси-объект сообщает контроллеру об изменениях и контроллер распространяет данные дальше...
Вот как происходит информация о распротранении смерти персонажа в бою:
Например, начинаем бой, персонаж сообщает контроллеру сегмента, что он хочет начать в нем бой. Контроллер сегмента содержит в себе прокси-объекты всех персонажей, которые находятся в данный момент в нем, на этом куске карты. Контроллер сергмента создает контроллер инциндента и передает всем причастным контроллерам персонажей информацию о том, что начался бой. Контроллер персонажа на основе собственных свойств принимает решение, должен ли он провалиться в бой, если да, то вновь созданный контроллер инциндента получает указания создать у себя множество прокси-объектов персонажей. Теперь уже контроллер инциндента начинает свои расчеты.
Если кто-то умирает, то в соответствии с вышеозначенным рисунком прокси-объект персонажа передает информацию в свой контроллер, который затем распространяет эту информацию по всем прокси-объектам. И сохраняет эти данные на диск.
PS: Технология, с помощью которой поддерживается целостность информации - CORBA (подробнее у Сергея Федорова - zmij_r).
PSS: Голубенькие квадратики сделаны в PhotoShop программистом Newmedia Stars - Павлом Зеленовым (_pashok_). Напоминаем, что в группе открыты вакансии дизайнеров ;)