|  | Sprint #25: Transport: everything has been done.
28.12.2011, 03:18
Не могу не сообщить, что реализация второй части транспортной системы закончена! Эмоции конечно переполняют, сидим играемся (тестируем) :) Это GO_TYPE=15, телепортирующий транспорт. С этого момента передвижение по Мирам производится без каких либо ограничений. 25-ый спринт, последний в году - закончен.
Что же до наших планов завершить ядро к концу года - не успели, увы. Итоги таковы:
- неожиданно много ушло времени на реализацию транспорта, теперь вполне понятно, почему он толком нигде не реализован и почему возникают проблемы и недоделки с ним. Столько потраченного времени вероятно связано с доработкой апдейт-системы и уход в сторону динамической видимости объектов.
- достаточно много ушло времени на реализацию такси, планировалось меньше. Для ее тестирования потребовалось немного отвлечься и заняться заселением :)
- и пожалуй немного больше ушло времени на разбор и реализацию мувемента, в частности на синхронизацию юнитов. На сколько я могу судить по дальнейшим ее обсуждениям в аськах/форумах/скайпах, пока что еще никто не приблизился к правильной синхронизации. Как обычно это всего лишь предположения, я не со всем миром общаюсь, а лишь с некоторыми компетентными его представителями в этой области :)
- все остальное шло по заранее спланированному плану. Вроде.
По этому плану мы должны были еще реализовать ландшафт и поиск пути. И плану отводилось на это от 4 до 6 последних спринтов года. По сути ландшафт - это последняя область для завершения нашего фреймворка, который обеспечивает низкоуровневое взаимодействие объектов и который пока что еще не зависит от версии транка. Сюда конечно еще можно отнести чат, группы/рейды, но это скорее фича, чем фреймворк. Такая же фича, как такси и вообще вся транспортная система. Транспорт мы решили просто реализовать одной из первых фич, все таки это перемещение по Мирам. Есть еще мнение, что инвентарь может быть тоже частью фреймворка, вроде как просматривается взаимодействие объектов на низком уровне и по неким правилам. В общем это такие тонкие вопросы, в которые не хочется особо вникать, что есть ядро, а что еще нет. В любом случае нам потребуется это всё в сервере.
Ну а пока мы уходим на заслуженный отдых на новогодние каникулы :)
Будем думать и возможно что-то менять в дальнейших планах. Накопился некоторый список хотелок и мыслей, что где можно улучшить, что где нужно еще доработать, ну и что где нужно зарефакторить. Всё же мы считаем, что за год с нуля написать это - хороший результат. Не самый лучший, да, но вполне достойный. Особенно в условиях только самомотивации и особенно, когда все вокруг говорят "вов умер".
Всем спасибо за участие, что были с нами, следили за проектом. Судя по статистике посещений у нас уже набралась некоторая аудитория постоянных читателей :)
Всех с наступающими праздниками! До встречи в новом году.
Transport: Quaternion.
14.11.2011, 17:18
Закончена реализация системы динамической видимости. Шикарная вещь, я вам скажу, получилась. В посте про нее я выложил небольшой лог ее работы. Суть ее в том, что некоторые объекты могут видеть другие, а наоборот - нет. Живой пример - роги, их не видно, но они видят. Благодаря этой системе можно реализовывать различные игровые сценарии, связанные с видимостью объектов. Видимость, разумеется, можно изменять на лету, т.е. увеличив ее - сразу стать видимым для окружающих в некотором радиусе. Или, например, огромные высокорослые мобы должны быть (могут быть) видны издалека. Или например в инсте blackrock depths ворота-мост видны через весь инстанс. Так же решилась проблема с вагонами метро, которые скрываются в подземке будучи видимыми и только потом дестроятся наблюдающим. В общем вырисовывается уже неплохой API управления юнитами.
Но как всегда постоянно возникают новые препятствия на пути к победе :) Собственно проблема возникла в обновлении пассажиров транспорта, когда те передвигаются по нему. Наконец стало понятно, зачем нужны относительные координаты плеера. Они нужны не только для рассылки окружающим, как предполагалось ранее (впрочем это чисто клиентская сторона вопроса и для этого они нужны тоже), а еще и для серверных расчетов, что бы эти обновления выполнить правильно.
Положение модели транспорта в пространстве задано кватернионом, который передается в А9 (те самые PARENT_ROTATION). В частности вагоны в метро располагаются в разном направлении на одной из веток. Грубо говоря два вагона смотрят вперед по ходу движения, третий против движения. Зачем это было сделано остается загадкой, т.к. это повлекло за собой во первых - разные кватернионы в А9, а во вторых - разные дельты в transport_animation.dbc для разных вагонов (точнее разные направления). Единственным объяснением может стать то, что разработчики внедряя эту систему таким образом тестировали правильность ее работы, а после деливери кода все так и осталось, работает же.
Во время движения плеера по транспорту от него приходят абсолютные координаты как обычно, плюс блок относительных координат на транспорте. Главное понять, что не важно как транспорт ориентирован в пространстве, относительные координаты будут всегда в его (транспорта) системе координат. Т.е. если мы бежим с кормы корабля к носу, то будет изменяться относительная координата Y и только она, назависимо от того, как плывет корабль относительно абсолютной системы координат.
Таким образом получаем классическую задачу движения одной системы координат внутри другой. При перемещении одного из пассажиров апдейт системе нужно знать местоположения остальных в абсолютной системе координат для коррекной работы. Здесь у нас две проблемы: первая - транспорт движется, вторая - остальные стоят и соответственно не присылают свои абсолютные координаты.
Задача сводится к нахождению абсолютных координат транспорта, используя абсолютные и относительные координаты перемещающегося плеера. Затем можно вычислить абсолютные координаты других пассажиров, используя вычисленные абсолютные координаты транспорта и зная относительные координаты этих пассажиров. После получения абсолютных координат пассажиров все расчеты с видимостью будут корректными. Они, кстати, должны выполняться по тем же правилам, что и на земле (тесты с оффа, спасибо Energy).
Пока мы не будем реализовывать поворот одной системы координат относительно другой за неимением достаточного опыта, посему эта активность пока отложена на позднее время. Перемещаться на транспорте стало возможным, хоть и с небольшими проблемами - визуально это выглядит как постоянные destroy/create окружающих пассажиров и только в тех случаях, когда один из плееров имеет низкий detect area, например рога в стелсе. В обычном режиме визуализация перемещения плееров нормальная.
В этом спринте мы решили закончить всё остальное по транспортной системе. Из оставшегося - 15ый тип транспорта, который телепортирует с одной карты на другую. Собственно весь вопрос в телепорте и синхронизации движений с одной и с другой карты. Напомню, пока разные карты (WorldServer) работают на одной машине - никаких проблем нет. Кластерная архитектура позволяет запускать разные Миры на разных машинах и у них могут быть разные процессорные времена (TickCount).
Custom Installer
09.11.2011, 16:33
Однажды на просторах Интернета были найдены упоминания об инсталлере классика сразу на версию 1.12.0 и очень захотелось эту версию заполучить. Поиски приводили на давно умершие линки и торренты, что инсталлер заполучить так и не удалось.
Однако пытливый ум не дает рукам покоя :) Мы полностью разобрались в инсталяционных процессах и сделали свой кастомный инсталлер. Для начала решили потренероваться на старой доброй альфе 0.5.3, к которой инсталлера никогда и не было.
Написан тул, который делает как бы обратный процесс, - собирает инсталлер из установленного (и пропатченного) клиента. Инсталлер для альфы несет в себе чисто академический интерес. В последующем мы подготовим кастомные инсталлеры клиента под последнюю версию каждого из транков, 1.12.1, 2.4.3, 3.3.5а.
Инсталлер альфы готов, протестирован и будет скоро выложен на торрентах, следите за раздачами.
Впервые в истории можно кастомизировать игру добавлением нового контента. Вплоть до полной его замены (контента и пользовательских интерфейсов), сделав таким образом "свою игру" на оригинальном движке.
Не боги горшки обжигают.
09.11.2011, 13:04
В процессе общения с коллегами по цеху очень понравилась фраза, которая по моему мнению может еще стать крылатой. Цитирую:
У нас клиентура не школьники с булочками, а состоявшиеся люди с хорошими деньгами, готовые выложить круглую сумму за то чтобы быть богами.
(с) Scorpyar
Sprint #21: Transport: Dynamic Visible Area.
18.10.2011, 01:41
Первая часть реализации транспортных объектов, можно сказать, закончена. Реализован 11-ый тип объектов, это всякие лифты, эскалаторы и т.п. Сюда в том числе входит и метро из Сторма в Айрон.
Самое важное достижение состоит в том, что мы научились точно определять где в пространстве находится объект в любой момент времени. Это позволило нам "перемещать" объекты по карте вместе с пассажирами, а реализованная ранее апдейсистема, как оказалось, отлично справляется с функцией определения видимости объектов. Грубо говоря, когда вы проезжаете центральную "аквариумную" часть метро, мы можете наблюдать соседний проходящий мимо в обратном направлении поезд и всех его пассажиров, прыгающих, стоящих, сидячих, каких угодно. Ну и конечно же окружающий по дороге мир. Это очень важное замечание, подчеркивающее значимость грамотно спроектированной апдейтсистемы.
Но возникло одно но :)
Заключается оно в том, что по умолчанию область видимости объектов у нас равна float 100.0, и уходящие вагоны метро не скрываются в подземке, а дестроятся буквально въехав в тоннель (ровно на расстоянии 100.0 от наблюдающего плеера). Стало понятно, что нужно уметь как то управлять дистанцией видимости объектов.
Была разработана уникальная с точки зрения вов-серверо-строения (такого еще нигде нет или мне об этом неизвестно, обязательно дайте знать, если знаете где) система динамически изменяемой дистанции видимости. Звучит умно, но на самом деле всё очень и очень просто: каждый объект в своих свойствах (где же еще) имеет float поле, задающее эту дистанцию. По умолчанию она равна значению по умолчанию данного Мира, для Миров 0 и 1 оно равно 100.0 (для инстов чуть меньше). В то же время область видимости объектов может изменяться в зависимости от игровых ситуаций, например видимость Роги или видимость объектов-ловушек может быть изменена в меньшую сторону (это зависит от многих игровых факторов, например как от уровня объектов, наложенных аур и т.п.). И конечно же эта область может быть расширена в большую сторону. Например, это может быть применительно как раз к вагонам метро, а так же к летящему на грифоне плееру, расширяя его кругозор с высоты, так сказать, птичьего полета.
Кстати говоря о грифонах. В данный момент у нас реализован фокус, что плеер летит как бы немного впереди своего реального расположения в Мире, поэтому он видит впереди объекты на довольно большом расстоянии, в то время как сзади они практически сразу дестроятся, как он их пролетел. С пристрастием наблюдая за оффом, можно с уверенностью сказать, что там такая же картина и это можно объяснить только подобной реализацией. Теперь же можно немного расширить визуальные возможности.
Итак, 21 спринт посвящен реализации (напомню, она только спроектирована) Dynamic Visible Area. Ну и разумеется имплементации ее использования в существующих на данных момент системах. Начнем с главного - с транспорта.
Sprint #20: Ships & Zipps.
03.10.2011, 12:01
Никак нам не удавалось приступить к реализации транспорта. Система Такси все требовала и требовала к себе внимание. Было организовано массовое тестирование (ну как массовое, ~50 клиентов), которое показало в целом отлично работающую систему, за исключением тех недоработок, о которых я говорил в предыдущем посте.
Собственно по "недоработкам": в качестве финальной точки пути будет использована последняя из списка с взятой координатой Z из карты высот (terrain пока не реализован и будет следующим этапом после транспорта); промежуточные скип-точки вынесены в таблицу и их можно там исправлять (для будущих разработчиков базы); разная скорость пролетов так же регулируется из базы в таблице путей. Одна скорость на все пролеты экспресс такси. На этом можно считать систему Такси законченной.
Во время тестирования было выявлено неприятное поведение клиента: частенько его крашило во время создания юнитов. Уж был пересмотрен весь код, отвечающий за сборку А9 и код, отвечающий за данные для билдера, и всё всё всё остальное - никак не удавалось отловить ошибку. Краш клиента, самое обидное, был нестабильным, т.е. не найдены стабильные сценарии, приводящие к крашу. Был только сужен круг - выяснилось, что клиента крашит чаще, если почистить перед запуском весь кеш (WDB, WTF), что еще больше сбивало с толку.
В результате разбора стек-трейсов, что выдавал клиент и дебага процесса в IDA (да, уже дошли и до этого) выяснилось, что клиента крашит на отрисовке M2 объекта. Далее несложными выводами было выявлено, что вся проблема состоит в "кривых" драйверах видеокарт ATI. Перевод клиента в режим OpenGL полностью снимает проблему. Ну и конечно же наблюдения показали, что на клиентах, работающих не на картах ATI проблем не наблюдается. К сожалению, этот факт отнял большинство времени предыдущего спринта.
В двадцатом спринте, мы наконец-то занялись реализацией кораблей и зиппелинов, ура :)
64-bit Platform
29.09.2011, 03:46
Успешно выполнено портирование кода под 64х битный компилятор Delphi XE2. Только портирования как такового и не было...
Проблемы как всегда возникли в библиотеке mysql и криптографии. mysql.pas был обновлен до последней версии с официального сайта, а для openssl была заменена libeay32.dll на 64х битную. libmysql.dll, разумеется, так же была заменена.
Что касается нашего кода, то возникла небольшая нестыковка в классе таймеров: мультимедийный таймер использует фунцию timeSetEvent и в качестве callback функции передается параметр типа NativeUInt. Все бы хорошо, но в 64х битной среде NativeUInt эквивалентен UInt64, в то время как в 32х битной - Cardinal. Поэтому строчка кода
MMTimer1 := timeSetEvent(FTimerInterval, 1, MyTimerCallBackProg, 100, TIME_PERIODIC);
давала ошибку
[DCC Error] ObjTimer.pas(659): E2010 Incompatible types: NativeUInt and Cardinal
В данном случае замена MyTimerCallBackProg на @MyTimerCallBackProg решило проблему.
Вот, пожалуй, и все трудности перевода. Впечатляет.
Что касается выгоды перехода на 64х битную платформу, то пока рано что-либо говорить. Нужно проводить массивное тестирование обоих платформ и снимать показатели. Важно одно - мы получили долгожданную возможность создавать 64х битные приложения и в целом более менее понятны их преимущества.
Sprint #19: Taxi.
19.09.2011, 12:00
Реализована система Такси, все функции.
- ноды разучиваются, изначально их известно сколько то - эти данные из dbc.
- плеер во время полета перемещается в Мире, что обеспечивает видимость объектов друг другу
- возобновление полета после логаута/дисконнекта с прерванного места
- экспресс перелеты (через несколько узлов)
- точный расчет времени полета и обеспечение синхронизации времени прибытия в точку назначения. Иными словами время когда полет заканчивается визуально в клиенте, он заканчивается и на сервере, ничего не запаздывает. Пакет MOVE_SPLINE_DONE показывает расчетное время прибытия и фактическое время прибытия, максимальная разница по тестам составляла 16 тиков функции GetTickTime().
- синхронизация MoveTimestamp плееров
Изменения.
Все системы сервера разрабатываются с учетом оргининального порядка следования пакетов (со снифов), система такси тоже не исключение. Но в данной реализации мы позволили себе немного изменить последовательность: мы сначала одеваем маунт на плеера, а затем отправляем его в полет. В оригинале это происходит наоборот.
Ограничения.
Из недоработок осталось следующее:
1. Финальная точка пути по снифам не принадлежит ни одной точке пути из dbc. Эта точка где то рядом и эти точки нам неизвестны. Их можно собрать только со снифов. Визуально всё выглядит так, что когда плеер прилетает, он оказывается в последней точке пути, а она находится гораздо выше поверхности земли. И после окончания полета плеер как бы немного падает. Эту проблему можно решить двумя способами:
- собрать финальные точки со снифов и использовать их.
- после реализации карты высот использовать высоту последней точки пути не из dbc, а используя карту высот. Скорее всего так и поступим.
2. В экспресс такси неизвестно, сколько точек в начале и в конце не используются в промежуточных путях. Тесты показали, что универсального значения нет и эти данные можно собрать тоже только со снифов. В данный момент для каждого пути эти поля вынесены в базу и присвоено значение по умолчанию 2. В будущем можно его исправлять для всех этих красивостей.
3. На разных путях может быть разная скорость полета. Тесты показали, что некоторые перелеты выглядят немного заторможенными, по ощущениям вроде бы скорость должна быть чуть больше. Догадки подтвердились сообщениями разработчиков других проектов (спасибо SilverIce). Эта фича будет реализована позже.
Приступаем к реализации самого интересного - к транспортной системе кораблей и зиппелинов :)
Sprint #17: Population.
22.08.2011, 17:26
Продолжаем планомерно двигаться к транспорту. Закончена реализация спаун-системы. Реализованы требуемые сценарии, плюс некоторый запас по ним (т.е. такие, которые вроде как не используются в оригинале, но ни что не мешает использовать их в своих каких то целях).
В параллели работаем над заселением, данные традиционно со снифов. Проводим работу по фильтрации мусора. Вообще вырисовалась некая концепция clientless утилиты, позволяющей редактировать заселение. Будем потихоньку двигаться в этом направлении тоже.
В этом спринте приступаем непосредственно к реализации транспортных функций. Для начала нужно расставить всех грифонщиков и настроить перемещение среди них. Затем уже будем реализовывать транспортные ГО.
Так же медленно, но верно надвигается необходимость работающего инвентаря. Все зависимости для него реализованы. Так же в параллели будем реализовывать и его.
Sprint #16: Spawn system.
08.08.2011, 12:00
Продолжаем двигаться к созданию транспортной системы. На сегодня почти все зависимости реализованы в коде, за исключением спаун-системы и системы контроля и выдачи лута (бугога).
Сама по себе спаун-система не сложная, но ее реализация займет некоторое время, чем и займемся в этом спринте. Для ее реализации почти все готово, лут пока пропустим, т.к. не готовы группы и инвентарь. Главное проверить и хорошенько оттестировать спавн объектов в мире и рассылку обновлений от них другим объектам.
Предыдущий пост "всякая всячина" пока будет обновляться на предмет реализации тех или иных модулей. И самому удобно и вам виден прогресс :)
Sprint #15: Much more stuff.
25.07.2011, 23:39
Возникла занимательная ситуация: для того, что бы полноценно реализовать Транспорт, необходимо дополнительно реализовать множество подсистем. Если в кратце, то выглядит это примерно так:
апдейтсистема. (done)
============
требует:
1. ядро
2. нетворк
3. GameLink
4. SPBL
5. механизмы подключения и дисконнектов плееров, обработчики
6. логика входа в мир
7. классы мира:
- список миров
- список ячеек в мире
- список объектов в ячейке
8. синхронизация объектов
мувемент. (done)
========
требует:
1. апдейтсистема
2. классы миров
3. синхронизация объектов
спаун система. (done)
============
требует:
1. база шаблонов объектов (респонсы), юниты и геймобъекты
2. база спаун-шаблонов
3. механизмы добавления объекта в мир по шаблону
4. доработка билдера А9
5. апдейтсистема
система контроля и выдачи лута.
==========================
требует:
1. группы
2. инвентарь
3. квестовая система
квестовая система.
===============
1. группы
2. инвентарь
3. комбат, система боя
4. спелл-система
5. скиллы
6. репутация
7. управление юнитами: scripts/fsm/events/spawn
8. gossip (in progress)
9. база квестовых шаблонов (done)
10. база остальных шаблонов, тексты, кричеры, итемы, геймобъекты (done)
чат.
===
требует:
1. каналы
2. группы
командный процессор WorldServer. (done)
===========================
требует:
1. база шаблонов объектов (респонсы), юниты и геймобъекты
2. механизмы добавления объекта в мир по шаблону
3. доработка билдера А9
4. инвентарь.
база шаблонов (респонсов). (done)
======================
требует:
1. утилита zResponser - парсер снифов
2. sql база респонсов
3. классы и загрузчики респонсов на сервере
база спаун-шаблонов. (done)
================
требует:
1. утилита zWorldBuilder - парсер снифов, заселялка
2. sql база
3. классы и загрузчики спаун-шаблонов на сервере
группы
=====
требует:
1. межсерверная рассылка через CharServer с трансляцией данных на серверы Миров
инвентарь (in progress)
========
требует:
1. база шаблонов объектов (респонсы), итемы (done)
2. механизмы добавления объекта в мир по шаблону (done)
3. доработка билдера А9 (done)
4. апдейтсистема (done)
5. управление характеристиками персонажа, свойства и методы (done)
***
Это сильно в кратце, могут возникнуть дополнительные зависимости. Кто вспомнит какие еще - дайте знать :)
Чата на WorldServer не существует, он должен быть реализован на центральном компоненте CharServer. Следовательно, чар-сервер пусть "пробрасывает" клиентские сообщения на серверы Миров, тут уже должен быть реализован командный процессор.
Он нужен для разработчиков в основном, при помощи команд мы будем тестировать тот или иной функционал. Например, для тестирования спаун-системы - создавать в Мирах игровые объекты и редактировать их. Для тестирования лута и инвентаря. И т.д.
Что бы начать двигаться на транспорте, нужно уметь спавнить объекты. Что бы спавнить объекты, нужно уметь их создавать по шаблону и добавлять в Мир. Что бы создавать объекты по шаблону, нужно где то эти шаблоны взять. Что бы их взять, нужен, например, игровой трафик (снифы) и утилита, которая их оттуда добывает и складывает в базу.
Вот в этом примерно направлении и двигаемся в этом спринте.
Sprint #14: Transport.
11.07.2011, 22:15
В первом приближении movement реализован и слинкован с апдейтсистемой. Спаун-система так же интегрирована, в связи с чем начата большая работа над транспортной системой.
Для начала будет реализован слой заселения - грифонщики, при помощи которых будем перемещаться в Мирах. Грузится он будет отдельно от остального для удобства обслуживания. Анимацию планируем сделать выключаемую из конфига, т.к. на этапе разработки и тестирования не очень удобно ждать по несколько минут самого перелета. Ну и за одно будет оттестирована спаун-система.
После чего начнется работа над транспортными ГО, в первую очередь корабли между материками, метро и пепелацы. Затем все остальное сопутствующее, типа лифтов, кранов, всяких элеваторов и т.п.
Sprint #13: Movement.
27.06.2011, 21:50
Закончена реализация апдейтсистемы в спринтах 5-12, всё бегает, всё апдейтится, обновления рассылаются. Дальнейшая и несомненно обязательная доработка будет производиться в процессе реализации новых компонентов сервера.
Начиная с 13го спринта приступаем к системе перемещений, используя все известные на сегодня флаги и типы. Так же планируется реализация транспортной системы: лифты, пепелацы, корабли и т.п. Потребуется реализация спаун-системы, которая уже в принципе готова с предыдущих версий.
Sprint #5: World classes, update system.
07.03.2011, 00:09
Идем с небольшим опережением :) Запланированные UserStories в четвертом спринте были выполнены на неделю раньше, а в пятом спринте был запланирован большой рефакторинг кода для уже законченного, как мы его называем, сетевого фреймворка. В связи с этим рефакторинг был выполнен за вторую неделю спринта. В принципе этот фреймворк самодостачен, отделен от игрового кода и может быть использован для любой другой игры, схожей по своей архитектуре.
Пятый спринт посвящен созданию классов организации игрового поля. Традиционно Мир делим на ячейки, юниты перемещаются по этим ячейкам, в этих ячейках формируются списки видимости для рассылки обновлений. Одним словом создаем апдейтсистему.
Sprint #4: Dynamic cluster architecture.
21.02.2011, 01:01
Закончился третий спринт. Он принес нам продвижения в следующих областях:
- закончен CharManager
- закончен AuthServer, все функции за исключением системы раздачи обновлений XFER. Нужна ли она сейчас?
- реализована авторегистрация Реалма в реалмлисте. Реалм авторизуется в AuthServer и регистрирует данные о себе, таким образом обновляя о себе информацию в списке реалмов (онлайн/оффлайн/население и т.п.).
В четвертом спринте мы будем реализовывать авторегистрацию World серверов на CharServer. Эта система позволяет полностью избавиться от ручных конфигураций и строит Реалм динамически. Какие Миры подключились к CharServer, те и обслуживаются (какие Реалмы подключились к AuthServer, те и есть в реалмлисте). А так же будем реализовывать прокси-функции CharServer - проброс Клиентов в Миры, таким образом завершая реализацию нашей полностью динамической кластерной архитектуры.
Sprint #3: CharManager. Realms autoregistration.
07.02.2011, 13:29
В третьем спринте мы продолжим работу над созданием CharManager. Напомню, этот менеджер (класс) взаимодействует с клиентом несколькими опкодами, создает полноценную запись нового персонажа в базе данных (race-class ability, start info, outfit, spellbook, skillline, proficiency, taxi, etc...).
Основные затруднения заключаются в большом количестве полей данных, которые нужно постараться грамотно описать, постараться избежать дублей, ничего не упустить и не использовать лишнего. В виду того, что пока существует некоторая неустойчивость классов в коде, этот процесс несколько растянулся.
Главной особенностью данного менеджера в отличии от всех предыдущих вариантов является обработка динамических данных. Иными словами раньше мы прямо в коде объявляли статические данные с начальными характеристиками персонажа. Теперь эти данные вынесены в таблицы базы данных, при старте сервера начальные данные персонажей грузятся в структуры и в дальнейшем используются в CharManager. Т.е. теперь не нужно перекомпилировать CharServer, что бы добавить новый спелл в спеллбук какому либо темплейту или просто добавить новую расу или новое сочетание рас и классов.
На выходе работы CharManager создаются все необходимые записи в базе данных для дальнейшего использования этого профайла персонажа для входа в игровые миры и для трансферов на другие реалмы.
Sprint #2: AuthServer. SPB library. CharManager.
24.01.2011, 13:26
Закончен первый двухнедельный спринт, который был традиционно легкий для нас. Был создан биллинговый сервер, где происходит авторизация, выбор реалма и проброс клиента далее на выбранный реалм.
Благодаря старым наработкам код был написан с учетом предыдущих ошибок в архитектуре. Главная задача заключалась в том, что бы отделить код ядра от логики, а в логике создать гибкую систему обработки данных, независящую от формата этих данных.
Второй спринт посвящен полноценному менеджеру чаров, который на самом деле не так прост, как кажется. Задача состоит в полноценном создании персонажа со всеми возможными характеристиками, сохранении данных в базу и последующем чтении. Главная задача этого спринта заключается в создании класса, формирующего класс персонажа со всеми данными по входящим параметрам расы и класса.
Новый WoWCore
20.12.2010, 21:00
Мы возвращаемся к работе, почти полностью в обновленном составе. И начинаем с обновленного сайта. Помимо внешних изменений в дизайне и нового способа подачи информации мы внедрили систему ведения проекта типа ClarifyCRM, которая поможет нам тщательно спланировать и максимально эффективно сконцентироваться на поставленных задачах. Ну и для истории - скриншоты старого сайта :)
 
|
| |
