![]() |
А что делать тем, у кого не Windows?
|
"не windows" на играх вообще на мой взгляд очень неудобно. разного рода спецефического для игр софта нет, в особенности навигационного и картографического, частенько задания закуриваются так, что необходимо воспользоваться определенными вин-приложениями.
|
Цитата:
|
> единственный профит от десктопного интерфейса к движку, который я смог придумать, - это возможность настройки гуя, но кому это надо?
Пользовательские css + gracemonkey, и ты можешь так же настроить любой веб интерфейс, если уж очень нужно :) > правда, win-приложение может общаться с серваком через tcp вместо http, но хз, насколько это будет быстрее. В chrome, opera и firefox есть websockets. Они позволяют почти полностью решить проблему отклика и паразитного трафика. Если делать fullajax-морду, то уж точно на этой технологии. Правда, остаются древние мобильные браузеры и опера мини, так что это нужно будет делать альтернативным интерфейсом. С другой стороны, пока энка и дозор этим пренебрегают, думаю, мы тоже можем =) Самой быстрой, разумеется, всегда будет выдача заданий и приём кодов через telnet :-P > а вот если объединить навигатор и интерфейс к движку, то можно делать всякие интересности вроде предоставления оргами карты зоны прямо в навигаторе, орговских пометок на игровой карте (в тч привязанных к заданию), стилизации карты под игру и тп :rolleyes: Ты затронул очень интересную тему, о которой я много думал. Вот тут действительно есть определенная необходимость в клиенте. Но присутствуют следующие проблемы: - Кроссплатформенность. Даже элементарно читать данные 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 на голом ассемблере, но зато с подсчетом времени в миллисекундах (ну чтобы уж совсем круто было), он бы вряд ли сейчас работал (а скорее всего, никогда бы не появился на свет). |
Цитата:
Топплан идёт в старых вайнах. Другой специфический софт без аналогов назвать затрудняюсь. |
Цитата:
Если нужно в двиг добавить отдельную страничку с картой - не вопрос. Только вот, сдаётся мне, в DPS окно с движком сделано через системный Internet Explorer, в котором самые вкусности веб-интерфейсов поддерживаются через пень-колоду (и вряд ли кто-то захочет тратить своё время на то, чтобы городить сотни хаков, обходя эти проблемы). Например. Когда я делал механизм автообновления для reco, выяснилось, что IE по непонятным причинам не выстреливает событие "ошибка загрузки", когда не может что-то откуда-то загрузить. Как прикажите проверять связь с интернетом? По таймауту? И что, ждать максимально возможного по gprs отклика при каждом рефреше? Пичалька. Решение всё-таки удалось найти, но вообще-то такими извращениями желания заниматься нет. |
Цитата:
кто пользует ДПС - сделает свою и сунет ее в дпс, и она будет оффлайновой |
Цитата:
|
Цитата:
Но игнорировать их существование - нельзя. К тому же, давай так рассуждать: продажи ноутов с линуксами медленно, но растут. А есть ещё Chrome OS. И нетбуки на андроиде. И смартфоны. И iPadы с iOS. Что, их всех в топку? Или потратить полгода на разработку клиента win-only, а потом ВНЕЗАПНО выяснить, что нужно с нуля делать аналог для других платформ? И оба поддерживать и развивать? Проект с 90% вероятностью будет заброшен при таком раскладе. А, чуть не забыл. В win же тоже веселуха. Писал для XP, тестил - бац! В семерке не завелось. И потом каждую сборку гонять на тестах на 6 виртуальных машинах с разными версиями виндов (xp, xp64, vista, vista64, win7, win7-64). Нет уж, увольте! |
Цитата:
|
Цитата:
А по делу - не понимаю зачем вообще это делать) |
Цитата:
А чехарда с разными версиями jdk, при смене которых всё ломается? Корпоратам пофиг, у них внутренняя закрытая сеть, уязвимости могут быть не критичны, обновляться не обязательно. А мы что будем делать? Дистрибутив в 100500 мб со своей версией jdk? Или каждый раз при выходе новой версии переписывать полпроекта? |
Цитата:
- Орги видят перемещения игроков. Меньше конфликтов и спорных ситуаций. - Логи общения игроков протоколируются на сервере, подделать нереально, в случае конфликтов, опять же, полезно. - Можно использовать эту опцию для создания недоступных раньше сценариев игр (ну то есть когда нужно именно по gps приехать куда-то и сделать там что-то, а орги смотрят и реагируют как-то). Вопрос, стоит ли игра свеч, для меня до сих пор открыт. Пока (т.е. пока интернет слишком дорогой, чтобы тупо сделать трекер на гуглкартах; а считывать координаты c gps из браузера - проблема) - имхо, не стоит. Через какое-то время, возможно, реализовать это будет в 100500 раз проще, и ситуация изменится. Грядёт html5, а это потрясающие возможности, конечно. Да и интернет дешевеет. |
Цитата:
Зачем под движок еще писать новый дпс? Это уже задача никак не связанная с движком. Цитата:
|
> да. Вернее с дпсом и так совмещается.
Зачем под движок еще писать новый дпс? Это уже задача никак не связанная с движком. На это и отвечал. Да, с движоком не связано, но, поскольку фигурировали такие мысли в этом треде, то счёл должным высказать, что думаю по этому поводу. > А зачем jdk? Виртуальной машины достаточно для пользователя. Почти у всех она уже подефолту стоит на ноутах. + чтоб не париться с разными версиями, то виртуальную машину можно включить в дистрибутив приложения и использовать тока для данного приложения, не заставляя сносить свои установленные. Ну и соответственно необходимость апдейтить пропадает. Ага. И набор дырок вместе со старой джавой в комплекте. Люди же половина без фаервола и антивируса сидят. Как-то странно людям заведомо дырявую виртуалку предлагать. Это где-нибудь в закрытой банковской сети годится, где всё равно выхода в инет нету, да и там-то не очень секьюрно, если совсем по-честному. Ну или тот же GWT, где байткод транслируется в JS, который всё равно в песочнице будет работать. |
Цитата:
- общение ж не только в чате происходит. При возникновении форс-мажора (например охрана появилась) обычно по телефону передается информация. Вообще я пока не вижу каких-то преимуществ от совмещения движка и проги с чатом, картой и прочими наворотами, разве что на какой-нить одной игре кто-то сделает используя эти функции задание, но вряд ли трудозатраты можно будет считать оправданными. |
Цитата:
|
Цитата:
Выше я просто детально разобрал сложности, которые встали бы перед разработчиком такой системы. |
Короче, думаю, пока что можно подвести итог, что на данный момент объективных причин отказываться от парадигмы "движок - это такая страничка" у нас нет?
|
Цитата:
|
Цитата:
|
Цитата:
|
а если надо, чтобы изменялось при выполнении определенных условий, для каждой команды независимо? :)
например, при вводе бонусных кодов появляются отметки с указанием местоположения других бонусов или становятся видны участки пути. (я не придираюсь, это все в порядке мысленного эксперимента; понятно, что всегда можно придумать заковырку, которую не реализовать существующими двуижками) |
Цитата:
|
Цитата:
хотя огромная часть фишек в играх - и так костыли разной степени упругости :) |
Цитата:
|
ох, сколько ж там было секса, наверное, со скриптами и ajaxом...)
но, значит, реализуемо |
Цитата:
Потому что если всё-всё-всё тянуть в движок - выйдет движок медленный и глючный. |
Цитата:
Цитата:
«Для прототипирования компьютерных (софтварных) систем чаще используют языки программирования высокого уровня абстракции (Java, Perl, Python, Haskell, …).» — wiki |
Цитата:
|
Часовой пояс GMT +3, время: 08:55. |
Powered by: vBulletin Version 3.8.7 (Russian)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.