Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Сообщения за день
 

Вернуться   Форум Flasher.ru > Flash > Серверные технологии и Flash

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 29.10.2015, 03:01
faraday вне форума Посмотреть профиль Отправить личное сообщение для faraday Найти все сообщения от faraday
  № 1  
Ответить с цитированием
faraday
 
Аватар для faraday

Регистрация: Apr 2009
Сообщений: 409
По умолчанию Разделение моделей данных

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

Старый 29.10.2015, 10:05
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 2  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Статичные данные
Предмет: [id, categoryID, title, level, power] (Ид, ид категорий предмета, название, требуемый уровень, бонус к силе.)
Категория: [id, title] (Ид категорий, название)

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

Старый 29.10.2015, 10:54
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 3  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Зачем вообще передавать статичные данные? Их можно вшить в клиента, раз уж они не меняются. А на сервере просто сравнивать то, что пришло, с тем, что должно быть

Старый 29.10.2015, 16:40
faraday вне форума Посмотреть профиль Отправить личное сообщение для faraday Найти все сообщения от faraday
  № 4  
Ответить с цитированием
faraday
 
Аватар для faraday

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

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

Старый 30.10.2015, 08:46
bifidokk вне форума Посмотреть профиль Отправить личное сообщение для bifidokk Найти все сообщения от bifidokk
  № 5  
Ответить с цитированием
bifidokk
 
Аватар для bifidokk

Регистрация: Jan 2011
Сообщений: 200
Цитата:
Сообщение от faraday Посмотреть сообщение

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

Старый 30.10.2015, 06:47
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 6  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Как вариант, сохранять в shared object и сравнивать хеши при инициализации
Очень ненадежный способ

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

Старый 30.10.2015, 16:46
faraday вне форума Посмотреть профиль Отправить личное сообщение для faraday Найти все сообщения от faraday
  № 7  
Ответить с цитированием
faraday
 
Аватар для faraday

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

Старый 31.10.2015, 11:36
bifidokk вне форума Посмотреть профиль Отправить личное сообщение для bifidokk Найти все сообщения от bifidokk
  № 8  
Ответить с цитированием
bifidokk
 
Аватар для bifidokk

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

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

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

Старый 31.10.2015, 15:05
faraday вне форума Посмотреть профиль Отправить личное сообщение для faraday Найти все сообщения от faraday
  № 9  
Ответить с цитированием
faraday
 
Аватар для faraday

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

Старый 02.11.2015, 08:32
bifidokk вне форума Посмотреть профиль Отправить личное сообщение для bifidokk Найти все сообщения от bifidokk
  № 10  
Ответить с цитированием
bifidokk
 
Аватар для bifidokk

Регистрация: Jan 2011
Сообщений: 200
Цитата:
Сообщение от faraday Посмотреть сообщение
спасибо за ответ, статические и динамические данные в одном этом классе? почему в виде массивов, а не объектов/словарей? При изменении данных на сервере контроллер меняет их в этом классе напрямую?
на клиенте храним только статику. то есть например параметры уровней зданий (здоровье, стоимость). если данные меняются, то мы просто перекомпиливаем клиент, т.к. происходит это редко. динамических данных у нас мало и они уж слишком динамические, поэтому ими всегда сервер плюется.

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

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

Создать новую тему Ответ Часовой пояс GMT +4, время: 00:18.
Быстрый переход
  « Предыдущая тема | Следующая тема »  

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


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


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