Удаленные общие объекты: что лучше, один массив SO или несколько объектов SO? - PullRequest
1 голос
/ 15 сентября 2009

Я создаю многопользовательскую игру, используя Flash / Flex для клиента и FluorineFX (точно так же, как FCS / FMS, за исключением того, что написано в .NET) на стороне сервера. Мои вопросы касаются использования и производительности общих объектов по протоколу RTMP.

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

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

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

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

Кто-нибудь хочет поделиться своим опытом по теме?

Ответы [ 3 ]

0 голосов
/ 08 января 2010

У меня только ограниченный опыт работы с удаленными общими объектами, и я пока что не реализовал ничего «большого» с использованием удаленных объектов, но переосмысливая приведенный выше комментарий г-на Кардоена, представьте себе игру с 1000 комнатами и 100 игровыми объектами в каждой комнате. , Как игрок, вы можете быть только в одной комнате одновременно. Если игра была разработана таким образом, чтобы все игровые объекты находились в одной большой SO, становится очевидным, что это не хорошее решение.

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

0 голосов
/ 12 апреля 2011

Мы используем Flash и FluorineFx для нашей игры, но общие объекты казались немного «болтливыми» для наших целей, поэтому мы решили передавать сообщения подключенным клиентам. Это дало нам полный контроль над тем, какие сообщения отправлять, приоритетом сообщений и частотой.

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

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

Многие из этих типов решений зависят от типа игры, которую вы строите:

  • Пошаговая или в реальном времени?
  • Какое максимальное количество игроков для игры?
  • Сколько логики обрабатывается клиент против сервера?

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

0 голосов
/ 31 октября 2009

Мы используем Flex-WebORB-MSMQ и RTMP для реализации пессимистического параллелизма, поэтому проблема не совсем та, поскольку у нас нет постоянного подключения / отключения. Это мой вопрос, нужно ли подключаться / отключаться при использовании разных общих объектов? Как насчет использования сообщений и разных каналов для разных объектов? Интуитивно я бы выбрал второй способ, где у каждого объекта есть общий объект, но если вам действительно нужно каждый раз подключаться / отключаться, то, боюсь, все будет работать не так гладко (думаю, вам придется это проверить) , С другой стороны, если объекты не слишком сложны, использование одного удаленного объекта не кажется большой проблемой ... Конечно, если у пользователя нет разрешения на просмотр одного из объектов, сохраните их. в одном общем объекте это опасно, так как пользователь может перехватить сетевой трафик ...

...