Закончили систему сбора и просмотра логов. Проблема анализа логов была очень актуальной, так как у нас несколько типов серверов — игровой, ресурсный, генератор.Тем более на этапе тестирования сообщения от клиентов также потребуют обработки.

Архитектура

Сервер логгирования основан на OSGI платформе. Получение логов по RMI с использованием авторизации JAAS (для Log4j был написан appender). Сохранение логов с помощью Hibernate в базу данных PostgreSQL. Для просмотра логов были написаны плагины к Eclipse. Основные возможности — фильтрация логов по различным критериям и сохранение произвольного количества фильтров для последующего изучения.

Закончена большая часть работы по интеграции: готовы редакторы 3D мира, пользователи бегают и общаются, участки мира догружаются и выгружаются, сделана система воздействия на предметы.

Дальнейшая интеграция будет после разработки 3D-движка 5.0.

Полноразмерные скриншоты:

Тесты и нормально организованная трассировка — основные принципы создания больших программных систем. Но чаще всего в них не верят: тратят кучу времени на поиск незначительных ошибок и читают километровые тексты из консолей. Такое встречается даже у программистов с опытом работы несколько лет.
Читать полностью »

Загружается класс домиков и на его базе создаются экземпляры выстраиваясь в иерархию.

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

Условия работы для “серверных” не выносимые — отключена админка в связи с затянувшейся переделкой GUI-библиотек.
Поэтому наполнять базу данных мира товарищам приходится вручную.

Надо отметить, что самый первый треугольник был загружен ещё месяц назад, но никакого развития не получилось в связи с разработкой Alternativa3D 3.0 и серьёзными изменениями в ядре.

Вот, что видно в консоли:

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

Для примера возьмем простой ресурс — изображение. С одной стороны дизайнерам удобно рисовать в PhotoShop-е, а с другой — Flash не умеет читать и показывать такие файлы. Да и для оптимизации трафика лучше из PSD формировать две картинки JPG для изображения и GIF для хранения карты прозрачности. Если такую задачу возложить на дизайнеров, то большая часть их рабочего времени будет уходить на конвертирование файлов. А после конвертирования файлы еще надо скопировать в папку, доступную серверу по протоколу FTP.

Читать полностью »

В программировании часто встречаются задачи хранения объектов и быстрый поиск их по числовым идентификаторам. Такая задача у нас возникла при работе с трехмерными точками на сервере.

Постановка задачи

Для каждого объекта есть набор точек, каждая точка представляет собой идентификатор (Int) и координаты X, Y, Z. Точек может быть достаточно много — несколько тысяч. Идентификаторы не обязательно последовательные, но последовательность нарушается достаточно редко. С точками определены следующие операции: добавить, удалить и получить все точки для математических операций. Требуется быстрая структура для хранения, создания и редактирования точек. Самый простой способ использовать Map<Int,Vertex>, но потребление памяти и скорость нас не устроила. Сервер должен обрабатывать несколько миллионов точек в секунду и чем больше, тем лучше.
Читать полностью »

Итак, у нас задача написать сервер для многопользовательской онлайн игры. Вот тут нам повезло, никто не говорил на чем писать и что использовать, был только набор требований и идей. Требования были такие — много людей бегают по миру, общаются, живут. Клиент обязательно на Flash. Вот и всё.

Язык программирования

JAVA — простой и логичный язык, удобная среда разработки, стабильная и достаточно быстрая среда исполнения. К тому же большой набор готовых библиотек. В качестве аналога рассматривали C#. Возможности почти такие же, но менее логичный синтаксис. Только одна среда программирования и одна операционная система. Нет нормальных решений в области серверов приложений, ORM-ов и так далее. Например, попробуйте найти встроенный WEB сервер для приложения на C#. А вот для JAVA существует несколько подобных решений.

База данных

В процессе создания прототипа базы данных было решено использовать базу данных на основе разработок от BerkeleyDB. Получили достаточную скорость работы с данными, но были большие сомнения в масштабируемости и надежности такого решения. В дальнейшем перешли на SQL базу и в качестве объектной прослойки выбрали ORM Hibernate. Скорость работы упала на два порядка, но теперь у нас есть надежда на масштабируемость и надежность, а также появилось право выбора MySQL или Oracle, PostgreSQL или DB2. Первой базой была MySQL, но через месяц работы перешли на PostgreSQL, на том и остались. Вопрос о смене базы данных поднимем после альфа/бета тестирования.

Сервер приложений

Для JAVA есть выбор между JBOSS, Spring и их коммерческими аналогами. Но в итоге мы решили не использовать стандартные подходы, так как для нас они слишком громоздкие и не подходят для нашей идеологии Моделей поведения. Все же игра это не бизнес приложение и подходы здесь совсем другие. С другой стороны программировать сервер как одно большое монолитное приложение не было бы оптимальным решением. Остановились на решении использовать OSGI ядро, тоже самое, что используется в Eclipse. Такой подход позволил нам части игрового сервера оформить в виде отдельных независимых модулей. Плюсы данного подхода — разграничение прав доступа, четкое API для обмена информацией между модулями, возможность менять модули без остановки сервера. К тому же модули можно запускать на нескольких машинах, что даст нам возможность наращивать вычислительную мощность без существенных переделок программного кода.

Выбор среды программирования — Eclipse, так как с OSGI она работает лучше, чем другие IDE.

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

Ранее сервером генерировались интерфейсы для обязательного наличия сеттеров и геттеров на каждый параметр, и, соответственно, каждый Flash-класс должен был их реализовывать. Это всё превращалось в километровую портянку set/get. Помимо этого в памяти оседали совершенно уже не нужные данные.

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

Читать полностью »

Самой первой задачей в далеком 2006 году, когда игра казалась маленьким проектом и работали вечерами после основной работы, возникла первая задача — как же обмениваться данными между сервером и клиентом. Напоминаю, сервер на Java, клиент — на Flash.

Для начала рассмотрим стандартные возможности флеша по передаче данных — XML и AMF. Первый вариант отпадает практически сразу, так как текстовый формат тяжел для парсинга и не оптимальный по размеру.

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

Неделя ушла на создание первого прототипа. Сделали поддержку стандартных типов (byte, short, int, long, double), бонусом получили возможность достаточно просто добавлять другие примитивные типы. Далее задумались, как передавать структурные типы (List, Map, Array и String). В итоге пришли к решению передавать размер структуры как byte, short или int — в зависимости от размера. И в заключении ввели рекурсию, то есть можно в List положить Map в Map Array и так далее.

Разработка окончательного варианта на JAVA заняла две недели, включая JUNIT тесты. А далее самое интересное — разработка сетевой библиотеки на Flash.

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

Итог работы — быстрая, асинхронная (и на Java, и на Flash), надежная сетевая библиотека, с широкой поддержкой разных типов данных. Работает быстрее чем AMF и экономнее расходует сетевой трафик.