Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   Серверные технологии и Flash (http://www.flasher.ru/forum/forumdisplay.php?f=62)
-   -   Разделение моделей данных (http://www.flasher.ru/forum/showthread.php?t=211746)

faraday 29.10.2015 03:01

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

Tails 29.10.2015 10:05

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

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

caseyryan 29.10.2015 10:54

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

faraday 29.10.2015 16:40

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

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

caseyryan 30.10.2015 06:47

Цитата:

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

Цитата:

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

bifidokk 30.10.2015 08:46

Цитата:

Сообщение от faraday (Сообщение 1188516)

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

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

faraday 30.10.2015 16:46

Цитата:

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

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

bifidokk 31.10.2015 11:36

Цитата:

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

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

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

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

faraday 31.10.2015 15:05

Цитата:

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

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

caseyryan 31.10.2015 16:46

Цитата:

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


Часовой пояс GMT +4, время: 03:01.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.