Вход в систему
Логин
Пароль
 

Sprint #26: Terrain.Сейчас на сайте 0 посетителей
WoWCore
История 2.0
История 1.0
SandBox

Ресурсы
Форум
Файлы

Документация
Литература
Ссылки


Sprint #5: World classes, update system.
← назад к списку

07.03.2011, 00:09

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

Пятый спринт посвящен созданию классов организации игрового поля. Традиционно Мир делим на ячейки, юниты перемещаются по этим ячейкам, в этих ячейках формируются списки видимости для рассылки обновлений. Одним словом создаем апдейтсистему.

#1 аноним, 28.04.2011, 09:37

Когда же будит шестой спирнт,и релиз сервера?)
--
и когда же уже будут нормальные сервера.. т.е без замены exe.. ?
#2 RomanRom2, 28.04.2011, 20:29

Шестрой спринт и сразу релиз сервера? :)
На самом деле уже восьмой спринт заканчивается (спринт - это две недели). Просто писать особо не о чем или мало, будет что то вроде "продолжаем работать над ...", "продолжаем работать над...".

На сегодняшний день полностью переработана объектная модель с учетом прошлых ошибок и неудобств. Полностью реализованы классы базовых моделей объектов всех типов (UNIT / PLAYER / ITEM и т.д.) - это классы, в которых находятся исключительно свойства объекта. Игровая логика вынесена в отдельный наследуемый класс (так сделано у оригинала). Это оказалось очень удобным - в последующих билдах эти свойства обычно меняются, но это практически никак не затрагивает код игровой логики.

Полностью изменен механизм хранения данных объекта и механизм доступа до них. Сделано это с учетом, опять же, предыдущего опыта, требований, возникших в процессе разработки, когда что-то менять в архитектуре уже очень и очень сложно. Доступ к данным, например во время рассылки обновлений (апдейтполей), теперь очень простой и быстрый и не зависит от самих апдейтполей и их изменений в билдах. Более того, в новую механику заложены новые принципы аггрегации объектов - это когда в одном апдейтпакете 00А9 отсылается сразу несколько обновлений юнитов.

Старый принцип давал побочный эффект: если за время аггрегации поле у какого-либо юнита изменялось несколько раз, то в общий аггрегированный пакет такое обновления попадало столько же раз. То, что это увеличивало сетевой трафик - это еще пол беды. Основная беда возникла при реализации спеллсистемы, например когда нужно было отменить результаты всех эффектов на выполнении третьего эффекта, а обновление юнита уже произведено из первого, и еще в ряде других проблем. В последствии была сделана очень сложная аггрегация апдейтполей, а не объектов, но должный эффект достигался очень большими потерями во времени и сложности реализации. Новый принцип лишен всех этих недостатков и по крайней мере все обозримые проблемы в прошлом вроде бы успешно решаются с этим принципом :) Сложно было придумать это всё НЕ ОГЛЯДЫВАЯСЬ назад. А то так и тянулась рука использовать старые многочисленные наработки. Это и заняло основное время этих спринтов.

На текущий момент в целом концепция апдейтсистемы продумана и разработана, идет ее реализация. Вот только сейчас закончили описывать классы объектов, приступили к классам Миров.

Апдейтсистема и классы мира - это очень большая активность. Помню в прошлый раз мы тоже ее где то три месяца делали :)

А что имеется ввиду под "нормальные сервера, без замены exe"? Какие пожелания?
#3 kd, 05.05.2011, 11:00

Почему не храните копию полей объекта и, сравниватя их с оригиналом, формировать апдейт пакеты?
#4 RomanRom2, 05.05.2011, 11:50

А в какой момент считать их оригиналом? После отправки, очевидно? Или после добавления в аггрегатор? Нуу... за что не люблю современное программирование, что любую ситуацию можно решить миллионом способов и все они будут правильные :)

Этот вариант имеет право на жизнь, но мне показалось, что хранить копии полей - расточительство. Дешевле хранить булевский флаг, который автоматически выставляется сеттерами пропертей. Тогда при рассылке отлично работает выделенный код типа:

p:= TWorldPlayer.Create;

p.BaseObject.GUID:= $FFFF;
p.BaseObject.XP:= 1000;
p.BaseObject.Health:= 52;

for i:= 0 to 1000 do begin
if p.BaseObject.UpdateFieldsIsChanged[i] then
... // аггрегируем апдейтполе
end;


p.Free;
, где i - это собственно код апдейтполя, удобно рассылать без привязки к мнемоникам, в цикле пробежался и всё. Цикл от 0 до 1000 - от балды; в реальности тут должно быть последнее поле соответствующего объекта (у меня это UNIT_PAD, PLAYER_PAD и т.п.). Да это и не важно, можно и 1000, геттеры проверят все диапазоны.
#5 kd, 05.05.2011, 14:09

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

Насчет хранения полей: мне так кажется что близзы вообще хранят копию полей для каждого клиента и на стороне сервера, ведь такие вещи как флаги видимости полей(кто-то таким заморачивался?) по-другому не реализовать. Тут расход памяти еще более сумасшедшим будет или использовать ваш подход и слать поля которые стали видимы :)
#6 RomanRom2, 05.05.2011, 15:53

ведь такие вещи как флаги видимости полей(кто-то таким заморачивался?)
конечно заморачивался :)

type

TUpdateField = record
Flags: byte;
Value: longint;
Changed: boolean;
end;

CBaseObjectData = class
private
FUpdateFields: array[OBJECT_BEGIN..OBJECT_END] of TUpdateField;
...



Да, задержка будет изза нетворка, все верно. Но клиент в данном случае рассматривается как проекция серверных процессов, поэтому об этом типе задержок не будем говорить. И близы в любом случае хранят копию полей на сервере для каждого клиента :)

Тут расход памяти еще более сумасшедшим будет или использовать ваш подход и слать поля которые стали видимы :)
Почему же? Копия полей (основная) все равно существует, к ней прилагаются лишь однобитные флаги. Это вместо еще одной копии полей по вашему варианту, а это 32 бит на поле. По-моему очевидно, что второй вариант сильнее расходует память :) Более того, операция сравнения переменных в случае второй копии полей будет выполнятся медленнее, чем битовая операция проверки установленного бита. Конечно это все такие мелочи на наших современных процессорах, что почти не стоит с этим заморачиваться :)

Целью данной оптимизации было упростить доступ к данным апдейтполей.
#7 atmorozock, 11.05.2011, 11:44

скорее бы увидеть ваше ядро. думаю найдутся такие которые набьют его скриптами и разными наработками =).. но это ещё не скоро..
---
когда вы планируете релиз ядра?
#8 reply, 11.05.2011, 20:15

они получают кайф от процесса.. а вы хотите результат
это несовместимые вещи
имхо
#9 RomanRom2, 11.05.2011, 20:22

не, wowcore-2 позиционируется как релизный продукт. Т.е. мы собираемся не скилл прокачивать, не фан разводить, а вполне себе рабочий сервер создать.

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

Постараемся конечно параллельно вести работу в плане создания играбельности, - наполнение Миров, AI и т.п.
#10 atmorozock, 06.06.2011, 12:13

Что то новостей уже 3 месяца нету =)
#11 RomanRom2, 07.06.2011, 12:44

:)
Топик почти закончен, проводятся многочисленные тесты для разных сценариев и доводка кода.
#12 atmorozock, 08.06.2011, 12:33

Скорее бы . а то на оффе уже патч 4,2,2 намечается. а мы даже ядро без замены Exe реализовать не можем =)
#13 Atmorozock, 20.06.2011, 11:19

какая примерная дата релиза ядра ?
просто уже охото играть в катаклизм . а на оффу деньги жалко :)



Copyright © 2005-2024 WoWCore Team