Ну... где-то ты, безусловно, прав
Несмотря на то, что я как бы немножко программер, подавляющее большинство моих приложений работают очень далеко от мобильных платформ. Впрочем, и от писюков тоже. Хотя и имеют гуй на писюках. Ну да ладно, давай немного пооффтопим
Итак. я не очень себе представляю как оно там всё, но всё-таки предположу, что сервер у нас умный. Памяти у него достаточно, проца тоже. Иначе какой тогда вообще смысл на нём что-то пускать. Клиент у нас тоже умный, но не настолько, да и злобный юзер на нём поназапускал всякой хрени, жрущей его и без того невеликие ресурсы. И трафик между ними, постоянно извещающий клиента об изменении состояния дел на сервере и изредка сообщающий серверу о том, что юзер надавил очередную кнопку и чего-то там сделал.
Насколько я понял: в данном случае тебе больше всего беспокоит трафик. Обсчитать все эти тайлы сервер обсчитает, он умный, но переслать столько он уже не в состоянии. Хорошо. Давай жрать слона по частям. Понятно, что при подключении клиент должен скачать карту целиком. Это неизбежно. Но на данном этапе как раз можно воспользоваться архиватором. Юзер подождёт, это однократный процесс. Да и выбора у него нет
Значит главный затык: пересылка динамических изменений. Посмотрим...
Смотри: что именно ты собрался обсчитывать ежесекундно? Если говорить о DF-е то, навскидку там постоянно идёт обсчёт физики воды, распределения температуры, поиск ресурсов на складах и, безусловно, поиск пути. Ну, давай посмотрим по порядку.
Вода. Она непрерывно болтается, что вызывает постоянное изменение кучи тайлов. Если решать задачу напрямую, то изменения всех этих тайлов ты, теоретически, должен отсылать клиентам. Скажем, лужа на 10к тайлов 10 раз в секунду. Даже будучи запакованной это всё равно, скажем, 100 байт 10 раз в секунду. Но так ли уж оно надо? Предположим, для изменения состояния воды ты имеешь детерминированный алгоритм. То бишь результат его работы не зависит от внешних факторов. Тогда зачем пересылать результат работы? Клиент у нас умный, пусть сам и считает. Дай ему единожды стартовое состояние (100 байт), дай текущее состояние рандома и его алгоритм, и пусть пашет. Фактически, тебе нужно будет извещать клиента лишь о непредсказуемых изменениях типа зачёрпывания дварфом ведра воды, прокапывания новой дырки, того же дождя (хотя, по сути, дождь точно такой же детерминированный алгоритм, его тоже можно описать коротеньким пакетом). По сути, у нас получается, что обсчёт воды грузит проц довольно сильно, и мы либо грузим им только сервер и тогда получаем кучу левого трафика, либо грузим и клиента тоже, и тогда левого трафика у нас по сути, не будет. Особенно если мы разделим воду по отдельным лужам, чтобы ведро воды, зачёрпнутое в колодце не вызывало у нас пересылки всего мирового океана.
Распределение температуры. С ним жопа
Постоянно обсчитывать всё не стал даже Тоади, именно потому у него так криво всё сделано. Но, навскидку могу сказать, что локальный переобсчёт температуры тайла у него происходит при изменении состоянии магмы на соседних тайлах, а расчёт температуры дварфов и грузов - при их перемещении. То есть, фактически, постоянного обсчёта и вовсе нет
Разве что при изменении погоды, то есть разово. По праздникам. И большая часть нагрузки на проц это у нас обсчёт изменения температуры грузов при перемещении. Но тут всё зависит от реализации. Если брать самый правильный вариант, то перемещение лварфа с грузом должно вызывать "тепловой след". Скажем, взял он кусок льда и понёс по прямой. На каждом тайле лёд должен брать часть тепла тайла, сам нагреваться, а тайл охлаждать, и по итогу за дварфом должна остаться полоска из охлаждённых тайлов разной температуры (лёд-то нагревается и охлаждает тайлы всё меньше и меньше). Но на деле Тоади с этим не заморачивается (и правильно делает!). Грузы не меняют температуру тайла, а просто принимают её со временем. Если клиент знает путь груза, то, теоретически, он может и сам обсчитать его температуру, но... зачем? Посмотри с практической точки зрения - зачем ему вообще подробное знание о температуре каждой вещи в каждую секунду? Нет, если юзер тыкнет, можно и спросить сервер, юзер не переломится пинга туда-сюда подождать, но в рабочее время эта информация нам не нужна. Нам нужно следствие из неё - смена агрегатного состояния жидкостей и вещей, возгорание тайлов, вещей и дварфов и... всё. А это, согласись, очень редкие явления. О них можно и известить клиента особо.
Поиск ресурсов на складах. Это, безусловно, серверная задача. Впрочем, она и нужна исключительно серверу - он же и будет пользоваться этими данными для раздачи задач дварфам. С точки зрения экономии трафика этой задачи нет вообще.
И остаётся отслеживание перемещения юнитов. Это классическая задача, решаемая во всех играх, где юниты есть. И решённая! Не думаю, что стоит тут на ней останавливаться.
И что же у нас по итогу получается? Расчёт температур трафик почти не ест, ибо температуры, как таковые, нафиг клиенту сдались. Обсчёт воды, если продублировать его на клиенте, жрёт проц клиента, но взамен почти не ест трафика. А юниты как бегали, как и в тысячах других игр, так и бегают, сжирая большую часть трафика. И причём здесь, собственно, размер карты? Да, он косвенно влияет на объём обсчитываемой воды, на количество бегающих юнитов, напрямую связан с количеством отжираемой памяти и временем первоначальной загрузки, но всё не так страшно. Если, как ты говоришь, вопрос "хватит ли телефону производительности" нам не интересен, то, получается, производительности ему хватит.
В общем, я бы по итогу, озаботился как раз юнитами
Скажем, сотня тел бегающих туда-сюда это, втупую, сотня координат, плюс десятки изменений носимых ими грузов, плюс, возможно, изменения их состояния, плюс хэш к ним для контроля синхронизации. А ещё они постоянно что-то роют, кого-то бьют, что-то ломают из вещей, хотя последнее, как и температуру, клиенту можно и не отсылать постоянно. Если юзер чего-то не видит, считай, оно ему и не надо
Как-то так, да...
Update: к слову, всё вышесказанное относится к случаю, если наш клиент хранит в себе все данные об игре, чтобы сделать отображение её на экране более плавной, самостоятельно заполняя промежутки между пакетами от сервера. А если вспомнить DF, то там юзер вообще видит только один Z-слой. Что тебе мешает в клиенте хранить и обрабатывать только его? Грубо говоря, пересылать только видимую юзером область и, возможно, соседние с ней для ускорения скроллинга.
