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

Поработав в среде несколько часов убедился, что пока придётся работать во Flex.
Из всех имеющихся плугинов заработало 5%, т.е. всего один.
Есть пачка нерешённых проблем (нет замены, рефактора, дебаггера), большинство настроек приходится делать ручками через копирование файлов, и прописывание путей.

Когда же выйдет FDT3!?

http://haxe.org/hxasm
Библиотека может динамически генерировать массив байтов ByteArray, представляющий SWF-файл со скомплированными методами ассемблера. Затем этот код может быть выполнен при помощи метода flash.display.Loader.loadBytes.

Насколько библиотека hxASM может ускорить выполнение Flash9-приложений?

В качестве примера — вычисление ряда Фибоначчи. Ускорение достигает 30%.

// fib takes an integer argument and returns an integer
var m = ctx.beginMethod(“fib”,[tint],tint);
// we will have up to 3 values on the stack
m.maxStack = 3;
ctx.ops([
OReg(1),      // register 1 = first argument
OSmallInt(1), // the integer 1
OJump(JGt,3), // jump 3 bytes if reg1 > 1
OInt(1),
ORet,         //   return 1
ODecrIReg(1), // decrement register 1
OThis,
OReg(1),
// call this.fib(reg1) with 1 argument
OCallProperty(ctx.property(“fib”),1),
ODecrIReg(1), // decrement register 1
OThis,
OReg(1),
// call this.fib(reg1) with 1 argument
OCallProperty(ctx.property(“fib”),1),
OOp(OpIAdd),  // add the two values
ORet,         // returns
]);

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

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

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

Колёсиком мыши можно изменять детализацию геосферы.

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

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

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

Боевая система “Альтернативы” позволяет напасть на кого угодно где угодно. Однако, как и в реальной жизни, агрессор столкнётся с последствиями, которые сложно игнорировать. Игрок может быть схвачен на месте преступления либо отловлен полицией “по горячим следам”. Лишившись своего имущества, он будет вынужден долгое время просидеть в тюрьме с такими же преступниками, а его жертва, оправившись от ран в ближайшем госпитале, сможет продолжать игру в своё удовольствие.

Математика боевой системы довольно проста и работает на “модификаторах”, которые применяются к различным частям тела. К модификаторам относятся ушибы, порезы, переломы, огнестрельные ранения и прочие неприятности. Получив повреждение ноги, игрок не сможет быстро перемещаться, а сломанная рука не позволит стрелять из автомата.

Мы сознательно не хотим усложнять систему, вводя в неё различные “Автомат +4″ и “Бронежилет +2″. Конечно, есть разница, получить пулю из пистолета или из пулемёта, но для механики нашей игры несущественная. Важно не оружие, а способ его применения без последствий для стреляющего. Иными словами, при желании купить пистолет может каждый, но каждый ли сможет из него выстрелить? Сможете ли вы выманить жертву в неохраняемый район и там “приделать” её без свидетелей? Или устроить стрельбу на центральной улице и потом исчезнуть, используя заранее отработанный маршрут отхода?

Итак, у нас задача написать сервер для многопользовательской онлайн игры. Вот тут нам повезло, никто не говорил на чем писать и что использовать, был только набор требований и идей. Требования были такие — много людей бегают по миру, общаются, живут. Клиент обязательно на 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 и экономнее расходует сетевой трафик.

Доска — незаменимый помощник для кодера.