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

[faraday]

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

[Tails]

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

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

[caseyryan]

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

[faraday]

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

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

[caseyryan]

Как вариант, сохранять в shared object и сравнивать хеши при инициализации

Очень ненадежный способ

они меняются, это балансовые настройки. и на сервере и клиенте они всегда должны быть одинаковыми

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

[bifidokk]

Сообщение от faraday

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

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

[faraday]

Сообщение от caseyryan

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

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

[bifidokk]

Сообщение от faraday

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

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

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

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

[faraday]

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

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

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

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

[caseyryan]

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

В чем тогда проблема?