вроде бы что-то я наконец понял. и вроде как надежда еще есть. конечно еще вопрос почему мой клиент, скатина, вечно отваливается на попытке логина, попадает в бан на сервере, приходится менять сервер, опять логинится, надеяться что в этот раз проскочит... это все портит малину.
а суть работы с 0x12 Game Data такой:
1. от клиента первый 0х12 должен быть нулями. самый первый 0х12 по сути задает размер пакета, который будет одинаковый на всю игру. поскольку пакеты ZT примерно 14 байт, один раз правда видел что два пакета склеились в одного и было 16 (14 и 2 байта), то наверное надо тройной размер сделать 14х3 = 42 байта, ну или двойной чтоб системе проще было 28 байт. хотя нет - 36 скорей всего. еще по 2 байта для начала и конца пакета по системе ZT надо будет.
сервер вернет свой 0х12, где будет по сути два набора данного пакета. типа если скажем я слал 36 байт (14х2 и 4х2 на координаты пакета в ZT). один получается Эмулятора1 и второй Эмулятора2.
2. нормальные игры делают как: событие в игре1, игра1 шлет игре2 это событие, игра2 обрабатывает. основное время по сути игры простаивают. Kaillera - события шлются постоянно через короткий промежуток. даже если это старое событие, уже обработанное. и если хочешь получить пакет - надо со своей стороны послать пакет и тогда в ответ прилетит и твой пакет, типа подтверждение что он долетел и последний пакет со второй стороны. бред конечно и лишняя нагрузка на сеть, но что поделать. расчитывалось то на синхронизацию кнопок между эмуляторами, когда игра по сути одна - типа Баттл Сити к примеру. один экран, ничего не происходит и тебе просто надо синхронизировать кнопки. с ZT, где у каждого свой экран такая система подойдет не очень.
схема весьма примерная. с неточностями, но иллюстрирует примерную схему работы. получается первая часть серверного пакета - один клиент, вторая часть второй клиент.
3. тут внезапно афторы решили задуматься об экономии траффика. прилетающие пакеты по сути должны писаться в архив. типа массив кусочков памяти на 256 слотов (0-255). правда пока не знаю что именно туда должно писаться - только та часть пакета, что от другого клиента, или прям весь ответ сервера сразу для двоих клиентов. ну не суть. суть в том, что если прилетаемый ответ уже ранее случался, то вместо полного пакета 0х12 прилетит 0х13 где всего лишь 2 байта инфы - номер ячейки в архиве, где лежит точно такой-же пакет, который должен был только что прилететь. для ZT бы выкинуть этот функционал и по идее мои дополнительные байты для координат пакета в ZT в принципе должны будут сделать такой пакет уникальным, чтобы избежать этой вакханалии с архивом, но все-же существует такая вероятность, что пакет полностью совпадется с каким-то из старых и тогда прилетит 0х13 от сервера несколько спутав мне карты.
4. и да, не следует забывать что для отправки надо дописывать два предыдущих сообщения в конец пакета
опять-таки создавая дополнительные проблемы для тырнет соединения... получается размер пакетов раздуется до безобразия.
36 байт на одного клиента * 2 = 72 + 10 байт примерно заголовки пакета = 82 * 3 пакета в с учетом двух предыдущих пакетов = 246 + 1 пакет с количеством сообщений внутри пакета (3) =
247 байт.
эх. по моему диванно икспердному мнению 247 все-ж многовато. может конечно современные интернеты, когда космические спутники Илона Маска бороздят просторы вселенной, и потянут. но хотелось бы все-ж пакеты поменьше.
