> единственный профит от десктопного интерфейса к движку, который я смог придумать, - это возможность настройки гуя, но кому это надо?
Пользовательские css + gracemonkey, и ты можешь так же настроить любой веб интерфейс, если уж очень нужно
> правда, win-приложение может общаться с серваком через tcp вместо http, но хз, насколько это будет быстрее.
В chrome, opera и firefox есть websockets. Они позволяют почти полностью решить проблему отклика и паразитного трафика. Если делать fullajax-морду, то уж точно на этой технологии. Правда, остаются древние мобильные браузеры и опера мини, так что это нужно будет делать альтернативным интерфейсом. С другой стороны, пока энка и дозор этим пренебрегают, думаю, мы тоже можем =)
Самой быстрой, разумеется, всегда будет выдача заданий и приём кодов через telnet :-P
> а вот если объединить навигатор и интерфейс к движку, то можно делать всякие интересности вроде предоставления оргами карты зоны прямо в навигаторе, орговских пометок на игровой карте (в тч привязанных к заданию), стилизации карты под игру и тп
Ты затронул очень интересную тему, о которой я много думал. Вот тут действительно есть определенная необходимость в клиенте. Но присутствуют следующие проблемы:
- Кроссплатформенность. Даже элементарно читать данные gps-приёмника с ком-порта на win, mac и linux придётся разными способами. Отрисовка gui и карт - тоже. Конечно, есть различные питоны с биндингами к GTK, которые частично решают проблему, но всё равно полностью от нюансов платформ не уйти. Пример: я где-то в районе мая 2009го сделал для кодоповского трекера приблуду, которая определяла координаты экипажа по ближайшим вай-фай сетям, если нет gps. Но она так и не попала в проект, потому что разная реализация под win и linux (да там даже для разных win разные способы приходилось юзать), и никто не взялся этот набор хаков приделывать к законченной системе.
- Разработка целой пачки велосипедов: смотрелки карт, расстановщика POI, канала связи, и т.д. и т.п. По моим прикидкам, одно это (+ тестирование + доводка до ума) - минимум полгода работы одного человека в свободное время (практика создания своего трекера кодопом подтверждает, что порядок примерно такой). Даже если брать тот же питон, на котором пишется довольно быстро. Кстати, сразу отметаю всевозможные сишарпы и джавы. Джавы медленные, сишарпы не кроссплатформенные, моно не предлагать.
На вебе обе задачи решаются элементарно, но тоже есть две проблемы:
- Загрузка карт жрёт трафик. На мобильном интернете это проблема. Уже думал, нельзя ли совместить что-то типа openlayers с html5 local storage, но это по сложности сравнимо с написанием своего клиента.
- Чтение данных с GPS приёмника. Пока браузеры не начнут поддерживать тэг device для com портов - это серьёзная проблема (а пока этот тэг понимает только мобильная опера, и то, компорты не поддерживаются, только камеры). Можно реализовать отдельным плагином к браузеру, но снова выплывает дофига работы.
Первая проблема, может, не так уж и значима, учитывая наличие у билайна безлимита за 345 рублей. Так что вопрос открыт для обсуждения.
Вторая проблема частично решается использованием движка с мобильника с GPS и поддержкой html5 geolocation api. Но я таких трубок пока в руках не держал (хз, может, айфоны и умеют, не пробовал), и не знаю, насколько оно даёт точные данные (может, оно только по вышкам ориентируется, а gps не трогает). А может, для областных игр и точности навигации по вышкам хватит? Там же не важно с точностью до метра знать положение экипажа, погрешность метров в 500 в принципе приемлима...
Короче, нужно очень внимательно это всё продумать, прежде чем браться предпринимать какие-то шаги в этом направлении.
И главное - помнить, что перфекционизм в таких случаях не катит. Ведь если бы я сел писать reco на голом ассемблере, но зато с подсчетом времени в миллисекундах (ну чтобы уж совсем круто было), он бы вряд ли сейчас работал (а скорее всего, никогда бы не появился на свет).