Разделение моделей данных

[faraday]

Здравствуйте, возникли сомнения по-поводу использования подхода разделения статичных и пользовательских данных в контексте игр. Например к динамичным данным можно отнести баланс игрока, его достижения, уровень каждой постройки, пройденные квесты. Статические же - общие для всех, например цены магазина, задания квестов, требования к постройкам зданий. Суть спорного вопроса в том, стоит ли передавать отдельно и те и другие данные в клиент или же только результирующую модель. с уже готовой - на клиенте меньше проблем по организации данных, попадает только то что надо. но в свою очередь если что-то глобальное вдруг изменится - необходимо обновлять данные у всех, как следствие этого возникает жесткая связь между отображаемыми и хранимыми данными. Вариант, когда клиент получает те же модели с которыми работает сервер - упрощает доступность данных, но в то же время они всегда избыточны. Обычно я использую второй подход, но в текущем проекте динамических данных уж очень много у каждого игрового объекта, поэтому возникло желание хранить как статику только шаблоны. На основе которых создавать и проверять актуальность пользовательских данных. Вопрос в том, что все таки предпочтительнее, и какие подводные камни нужно еще учесть.

[Tails]

Статичные данные
Предмет: [id, categoryID, title, level, power] (Ид, ид категорий предмета, название, требуемый уровень, бонус к силе.)
Категория: [id, title] (Ид категорий, название)

Модель
Предмет в инвентаре игрока: [id, quantity] (Ид предмета, количество)

[caseyryan]

Зачем вообще передавать статичные данные? Их можно вшить в клиента, раз уж они не меняются. А на сервере просто сравнивать то, что пришло, с тем, что должно быть

[faraday]

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

caseyryan, они меняются, это балансовые настройки. и на сервере и клиенте они всегда должны быть одинаковыми. Как вариант, сохранять в shared object и сравнивать хеши при инициализации, но вопрос не об этом.

[caseyryan]

Как вариант, сохранять в shared object и сравнивать хеши при инициализации
Очень ненадежный способ

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

[bifidokk]

caseyryan, они меняются, это балансовые настройки. и на сервере и клиенте они всегда должны быть одинаковыми. Как вариант, сохранять в shared object и сравнивать хеши при инициализации, но вопрос не об этом.

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

[faraday]

Неужели данных там столько, что это реально так напряжно запросить при инициализации? Что-то берут меня большие сомнения на этот счет
ну килобайт на 200, если не зиповать.
bifidokk, намного удобнее когда менять в одном месте. Хороший пример - цены и позиции магазина.
Если все таки разделять динамику и статику, то как их лучше представлять на клиенте? в виде отдельных классов. или одним, который имеет методы работы с двумя наборами данных?. Например зная текущий уровень здания(динамика), и сколько нужно для следующего апа(статика), запросить стоимость следующего улучшения

[bifidokk]

bifidokk, намного удобнее когда менять в одном месте. Хороший пример - цены и позиции магазина.
Если все таки разделять динамику и статику, то как их лучше представлять на клиенте? в виде отдельных классов. или одним, который имеет методы работы с двумя наборами данных?. Например зная текущий уровень здания(динамика), и сколько нужно для следующего апа(статика), запросить стоимость следующего улучшения

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

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

Добавлено через 2 минуты
дополню: разумеется, нужно еще и понимать и знать, для какой аудитории приложение. Если для 10 человек внутри фирмы, то пожалуйста, дергайте все статичные данные с сервера, вам действительно удобнее будет хранить и менять всё в одном месте. Если мы говорим об игре в соц. сетке, то логичнее снизить обращение к серверу по пустякам до минимума, и при оптимизации вы в первую очередь будете всю подобную статику на клиент выносить.

[faraday]

по примеру: у нас все параметры здания хранятся в отдельном классе в отдельном массиве + методы, которые дергаю, обрабатывают и отдают эти данные. зная текущий левел здания, я легко дерну все параметры для следующего левела и т.д.
спасибо за ответ, статические и динамические данные в одном этом классе? почему в виде массивов, а не объектов/словарей? При изменении данных на сервере контроллер меняет их в этом классе напрямую?
дополню: разумеется, нужно еще и понимать и знать, для какой аудитории приложение. Если для 10 человек внутри фирмы, то пожалуйста, дергайте все статичные данные с сервера, вам действительно удобнее будет хранить и менять всё в одном месте. Если мы говорим об игре в соц. сетке, то логичнее снизить обращение к серверу по пустякам до минимума, и при оптимизации вы в первую очередь будете всю подобную статику на клиент выносить.
По наблюдением это не создает никакой существенной нагрузки, тем более по сравнению с загрузкой ассетов графики. Все стат модели на серве объеденены в один объект, сериализованы, зазипованы и хранятся в памяти. при инициализации отдаются через сокет, прием и распаковка происходит за миллисекунды.

[caseyryan]

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

[bifidokk]

спасибо за ответ, статические и динамические данные в одном этом классе? почему в виде массивов, а не объектов/словарей? При изменении данных на сервере контроллер меняет их в этом классе напрямую?

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

по типу хранения, возможно и в объектах, я точно не скажу, репозитория под рукой нет, да и сам я на этом проекте с сервером работаю, не помню 100% что и как на клиенте


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

сделайте нагрузочные тесты, хотя бы 200-300rps для начала, а потом делайте выводы "создает - не создает".