Для начала, у меня есть достаточный опыт работы в сети (аппаратное обеспечение, маршрутизаторы и т. Д.), Но очень мало знаний по основам сетевого программирования. Это может показаться глупым вопросом, но я хочу знать, во что я ввязываюсь, понимая реализацию мультиплеера в моей игре.
Я создаю мир на основе тайлов, который создается с помощью простого 2D-массива. Давайте скажем что-то вроде World [100] [100], для простоты.
В настоящее время метод рендеринга рендерит только плитки на основе разрешения окна, плюс одну плитку (для плавного рендеринга во время движения.) Независимо от размера мира (10x10, 1 млн. Х 1 млн.) Рендеринг безупречен в производительности.
Игровому процессу не нужно ничего, кроме как знать, что находится в видимой в данный момент (отображается на экране +1), и, возможно, НЕКОТОРЫЕ сведения о тайлах в области вокруг игрока.
Таким образом, все, что посылает Сервер, не будет полной информацией о плитке. Ex. Предметы, лежащие на земле, тип земли, деревья и т. Д., Не будут важны в зоне, недоступной игроку, а будут только тем, о чем клиент / игрок должен знать в этих тайлах. (Например, «входящие имена» Ultima Online, где игроки могли знать, что Персонаж [игрок или монстр] находился за пределами плиток в их визуализированном виде.)
Я не очень разбираюсь в сетях, поэтому, возможно, когда я узнаю, это может ответить на мой вопрос. Тем не менее, мне любопытно, является ли это возможным решением или идея просто смехотворна.
Отправляемая информация будет иметь площадь листов размером 10x15, и каждый элемент содержит информацию о том, что находится на элементе. Более эффективно, все было бы Объектом, где плитка содержит все Объекты на плитке. Ex. Плитка [4] [4] содержит Меч # 23452, Рок2, Дерево5, Игрок3, Монстр4.
Пустые тайлы будут отправлять не что иное, как тип местности [Трава, Песок, Вода], если они еще не были загружены во время инициализации / загрузки. Некоторые плитки могут содержать несколько объектов [Tree2, Sword # 924, Gold, Corpse, Rock3].
Поэтому я не могу себе представить, что плитка будет иметь очень много информации для отправки Клиенту с Сервера, поскольку Клиенту в основном нужно знать только текстуру, которая должна быть загружена, и Позицию, чтобы разместить ее на экране. Позиция - только два целых числа, а Texture - одно целое число для списка файлов, указывающих клиенту на рендеринг.
В самом сумасшедшем случае Сервер должен будет отправить 150 плиток с информацией только о нескольких объектах OnLOAD, и с тех пор обновление только заменяет плитки (если они есть) и любые новые плитки (от 10 до 15 каждый раз, когда игрок движется в каком-либо направлении). ) и направление движения персонажей на экране (чтобы клиент мог имитировать плавное перемещение между плитками).
Я полагаю, что я прав, полагая, что это невероятно малое количество информации, передаваемой через Интернет или между коллегами, поэтому у него не должно быть никаких проблем с производительностью даже при медленных соединениях? Или я настолько невежественен в отношении сетей, что мой ум будет потрясен, когда я наконец найду книгу, посвященную многопользовательским сетям?
Если между клиентом и сервером отправляется очень мало информации, имеет ли смысл просто загружать весь мир при инициализации? Или «Карта», если Мир слишком велик. А потом после ЗАГРУЗКИ отправлять только плитки которые обновляются?
Я все еще размышляю над тем, как конкретно следует обращаться с данными. Книга, которую я использую в качестве ссылки, хочет, чтобы у меня был связанный список, в который я добавляю и удаляю объекты, так что все будет в порядке вещей. "Есть ли персонаж? Есть ли дерево?"
Я думал о другом подходе, таком как контейнер, который содержит объекты, и серверная логика, которая отправляет только то, что требуется, чтобы сообщить клиенту, что визуализировать. Возможно, с объектами, которые содержат сетевую информацию внутри себя, которая отправляется по требованию Сервера.