Реал тайм игра - как реализовать?

[TanaTiX]

Надеюсь автор топика не будет против если я со своим вопросом (по теме) вмешаюсь. Собственно ситуация та же - многопользовательская игрушка. Меня интересует способ реализации формирования запорсов.
Т.е. у нас н-е число переменных и соответствующих им значений. В каждый момент времени мы можем(должны) передавать серверу некоторый объем данных (т.е. значений переменных), который постоянно отличается - количественно и качественно. Каким образом проще будет формировать этот самый запрос? У меня есть желание вынести его формирование в отдельную функцию, куда бы я в качестве параметров передавал названия названия переменных (ИМХО звучит криво), которые бы считывались из некоего хранилища переменных и происходило бы формирование пары - переменная=значение, которая бы и скармливалась соккету. Понимаю что выглядит криво, но другие варианты мне почему-то кажутся не менее кривыми. Кто что подскажет по данной теме?

[dimarik]

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

Если сервер согласен с клиентом, значит он тоже рассчитывает движение по графу.
По-моему, дешевле не становится

Это домашнее задание всем, кто дочитал до сих пор.

[Rzer]

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

[gloomyBrain]

Каким образом проще будет формировать этот самый запрос?

Для начала можно внести типизацию:
- тип сообщения 1) - пришли мне координаты
- тип сообщения 2) - пришли мне цвет волос Васи
- тип сообщения 3) - пришли мне ... еще что-то

Тип сообщения определяется его первым байтом. Например, для 1) пишем в сокет 0x01. Для 2) - 0x02 и тд. Далее это будем называть тэгом сообщения.

Дальше за типом сообщения идет дата отправки... или не идет, в зависимости от того, кто отправитель. Если это сообщение клиент -> сервер, то не пишем дату, если сервер -> клиент, то пишем.

Дальше идет длина сообщения в байтах (то есть длина того, что идет за датой или за тэгом - эту часть можно называть телом сообщения)

Дальше идут "кусочки" тела сообщения. Что это? По сути 2 составляющих -
1) тип данных (1 байт: 0x00 = String, 0x01 = int, 0x02 = Boolean и т.д.) Во многих случаях тип данных определяет длину кусочка (int всегда 4 байта, Boolean всегда 1 байт...), но иногда (например, Array)... читаем дальше =)
2) нам нужно записать длину кусочка в байтах (можно называть это телом кусочка, по аналогии с телом сообщения). Записывать можно по-разному - для Array можно записать число элементов и каждый элемент рассматривать отдельно (со своими типом и длиной), а можно указывать длину в байтах

Как все это парсить?

switch(resievedData.readByte()) {
case 0x00: // координаты
this.parseCoords(resievedData.readBytes(resievedData.bytesAvailable));
break;
 
case 0x01: // цвет волос
this.parseHairColor(resievedData.readBytes(resievedData.bytesAvailable));
break;
}
 
// ... много кода
 
private function parseCoords(bytes:ByteArray) {
//... еще больше кода
}

UPD

еобходимо просто проверить валидность пути клиента

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

[Rzer]

Книжку читаешь? А про поиск пути подумать не хочешь. Ты посылаешь серверу путь (он проверяет можешь ты туда идти или нет) и двигает тебя по этому пути.

[gloomyBrain]

Я понимаю это все так:
К: хочу из А в Б через пункт Ц
С: не вопрос, поехали
К: я начал идти
С: (всем остальным) "Вася начал идти из А в Б через Ц со скоростью 3 км/ч в 17.36"
...
...
К: я закончил идти
С: (всем, включая Васю) Вася закончил идти в 17.39 в координатах x=122 y=534

Вопрос - зачем серверу иногда "поддакивать" клиенту? Расчет должен быть один раз по окончании "ходьбы".

[etc]

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

Я понимаю это все так:
К: хочу из А в Б через пункт Ц
С: не вопрос, поехали
К: я начал идти
С: (всем остальным) "Вася начал идти из А в Б через Ц со скоростью 3 км/ч в 17.36"
...
...
К: я закончил идти
С: (всем, включая Васю) Вася закончил идти в 17.39 в координатах x=122 y=534

Вопрос - зачем серверу иногда "поддакивать" клиенту? Расчет должен быть один раз по окончании "ходьбы".

В таком варианте вы замучаетесь с синхронизацией клиентов.
Должно быть так:

К: хочу из А в Б через пункт Ц
С: иди, вот тебе путь по точкам (либо путь приходит с клиента и валидируется) и вот тебе время, в которое ты должен быть в Ц
С: (всем остальным) "Вася пошел по таким-то точкам и прибудет в Ц тогда-то"

[TanaTiX]

gloomyBrain, спасибо за развернутый ответ. Наверное это действительно самый правильный вариант.

А если Вася вдруг остановился? Где он будет между этими точками и не собьет ли его собой с пути Лиза?

[Rzer]

Поиск пути это не три точки.

1) Клиент выбирает направление (ищет путь) состоящий например из 150 точек
2) Возможно Клиент при переходе из точки в точку просто спрашивает, могу ли я пройти в следующую клетку. Сервер отвечает, клиент запускает анимацию.

В твоём примере сервер умрёт. Представь, пользоватеель судорожно тыкает за 10 км каждую секунду, Сервер должен каждый раз вычислять пути и ставить его в нужную точку на 1/100 от того чем ты загрузил сервер.

На другом примере: тот же самый варкрафт 3 никогда не рассчитывает полные траектории юнитов. Там сложный алгоритм с разбиением на более крупные сектора с привязкой к карте путей, заранее просчитанной в редакторе карты.

[gloomyBrain]

Клиент при переходе из точки в точку просто спрашивает, могу ли я пройти в следующую клетку

Согласен полностью

А если Вася вдруг остановился?

Тогда он отправляет сообщение на сервер, где высчитываются его текущие координаты (исходя из точки начала движения, скорости и пункта назначения или направления)

не собьет ли его собой с пути Лиза?

А вот фиг знает =)
Можно проверку на пересечения делать на каждом клиенте и на сервере одновременно.
На сервере проверка должна вызываться пореже, чем на клиентах.
Каждый клиент может (исходя из своих данных) сказать серверу, что он с кем-то пересекается, тогда сервер должен тут это же проверить (незапланированная проверка) и восстановить реальную картину мира.
А можно не проверять на сервере вообще - все-таки пересечения клиент-клиент не такая полезная штука в играх, где игроков на карте больше 10. Если их меньше 10 (ну или еще какого-то числа, но немного), то можно проверять только на сервере.
Все зависит от задачи