|  |
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
| какая примерная дата релиза ядра ?
просто уже охото играть в катаклизм . а на оффу деньги жалко :) |
|
| |
|
| |
