Обычно игроки еще очень любят знать точно, сколько по времени на них висит тот или иной эффект. Уверен, что это будет следующая вещь, которую они попросят.
Ведь для мобильной версии нужно передавать кучу дополнительной инфы — команды, подсказки, ту же разметку.
У нас в nmud сейчас единсвенным протоколом являетя http. Был какое-то время назад и telnet, но я от него отказался, когда правил GateService (тот кусок кода, который обсепечивает поддержку протоколов клиента) — просто потому что не пользуемся им. А поддерживать неиспользуемый код не вижу смысла.
В будущем планирую вернуть telnet (когда/если будет для кого возвращать) и, может быть, запилю ssh.
Не обязательно отказываться от телнета. По крайней мере в dreamland, со стороны сервера всегда видно, какой вид соединения у игрока, websocket или обычный. В websocket пихаем псевдо-гипертекстовую разметку, в telnet — обычные ansi-последовательности, вот это всё.
Сейчас как раз работаем над кликабельными элементами, пока для справки, в перспективе для контекстных меню. Поделюсь скриншотами когда будет что показать.
Вот примерно, что я предлагаю. Границы блоков могут быть и прозрачными.
И еще. Нужна ли тут вертикальная прокрутка текста как в консоли? Почему бы не сделать комнату со всем содержимым в виде единичного сплошного объекта, типа html-странички?
Есть предложение организовать процесс более экономно:
Основную часть экрана занимает ScrollView с текстом (ровно также как сейчас сделано в вебморде — на большом экране остаются поля, на маленьком — во весь экран).
Активные элементы нажимабильны. По нажатию появляется оверлейное контекстное меню возможностей, в котором выбираем действие. Отказавшись от нижней панели мы экономим место. Кроме того, контекстные меню — более очевидная вещь для пользователя смартфона.
Общие команды (не связанные с объектом) я бы поместил
— на маленьких экранах в выдвигающееся боковое меню навигации (NavigationDrawer одним словом);
— или на маленьких экранах в полноэкранный оверлей или диалог;
— на крупных кранах — на поля слева и справа от текста.
Конечно, сложно судить без макета, но как думаешь будет лучше?
Ну и понятное дело, что мобильный вид лучше организовать не на сервере, но в отдельном мобильном клиенте.
А вот насчет клавы не уверен — у современных мобилок/планшетов достаточно большой экран: клава занимает 25...40% экрана, поэтому остается достаточно места под текст и прочую полезную информацию.
Да, отдельное приложение на смартфон сейчас в моде. Но пока я ограничусь одним клиентом — браузерным, т.к. не так много ресурсов, чтобы делить их между несколькими проектами с одинаковым функционалом. В будущем же надо сделать прогу хотя бы под андроид обязательно.
Писать что-то на экранной клавиатуре — это боль. Даже короткие сообщения. Поэтому надо продумать интерфейс так, чтобы в текстовой игре не надо было писать практически никогда. А надо было просто ткнуть пальцем в нужную часть экрана.
Я представляю это в виде двух скроллируемых панелей с кнопками внизу и вверху экрана. Верхняя панель связана с общими командами, типа перемещения, боевые команды и т.д.
Сам текст игры должен разбиваться на интерактивные блоки, выделяющие элементы игры — обыекты, мобы и т.д. Это что-то типа гиперсылок только большего размера, чтобы по ним можно было тыкнуть пальцем. При этом на нижней скроллируемой панели должны появляться кнопки связанные с этим объектом. Например, ткнули на сообщение «Вы видите здесь красивый фонтан» и появляются кнопки — пить, наполнить флягу, пописать в фонтан и т.д.
Если не понятно, вечером могу попробовать нарисовать как это примерно может выглядеть.
Первое же о чем нас попросили — кнопки настройки размера шрифта (кнопки плюс-минус на скриншотах клиента).
Еще удобны стрелки навигации, но в вашей концепции они ни к чему, если нету четких направлений по сторонам света.
А вообще голубая мечта — это полупрозрачная клавиатура, чтобы при вводе текста было все еще видно, что происходит.
Но это уже больше в сторону мобильного приложения, нежели браузера.
С тора заходит нормально:
Заходил также со смартфона, но играть на нем не удобно. Если мобильные устройства будут рассматриваться в качестве играбельных устройств, то интерфейс надо будет дорабатывать.
Последующие эксперименты показали, что проблема в прокси сервере squid. Когда я отключаю прокси, всё работает. Браузер Mozilla Firefox 54.0. OS Ubuntu.
Или не в браузере. Потому что браузер Epiphany из той же ОС нормально работает через прокси.
Любопытства ради можно проверить, заработает ли nmud сервер с клиентом mudjs (https://github.com/filths/mudjs). По сути надо выложить на хостинге master branch и в index.html поменять wsUrl на ws://94.127.69.186:3000
Ведь для мобильной версии нужно передавать кучу дополнительной инфы — команды, подсказки, ту же разметку.
У нас в nmud сейчас единсвенным протоколом являетя http. Был какое-то время назад и telnet, но я от него отказался, когда правил GateService (тот кусок кода, который обсепечивает поддержку протоколов клиента) — просто потому что не пользуемся им. А поддерживать неиспользуемый код не вижу смысла.
В будущем планирую вернуть telnet (когда/если будет для кого возвращать) и, может быть, запилю ssh.
Сейчас как раз работаем над кликабельными элементами, пока для справки, в перспективе для контекстных меню. Поделюсь скриншотами когда будет что показать.
Вот примерно, что я предлагаю. Границы блоков могут быть и прозрачными.
И еще. Нужна ли тут вертикальная прокрутка текста как в консоли? Почему бы не сделать комнату со всем содержимым в виде единичного сплошного объекта, типа html-странички?
Основную часть экрана занимает ScrollView с текстом (ровно также как сейчас сделано в вебморде — на большом экране остаются поля, на маленьком — во весь экран).
Активные элементы нажимабильны. По нажатию появляется оверлейное контекстное меню возможностей, в котором выбираем действие. Отказавшись от нижней панели мы экономим место. Кроме того, контекстные меню — более очевидная вещь для пользователя смартфона.
Общие команды (не связанные с объектом) я бы поместил
— на маленьких экранах в выдвигающееся боковое меню навигации (NavigationDrawer одним словом);
— или на маленьких экранах в полноэкранный оверлей или диалог;
— на крупных кранах — на поля слева и справа от текста.
Конечно, сложно судить без макета, но как думаешь будет лучше?
Ну и понятное дело, что мобильный вид лучше организовать не на сервере, но в отдельном мобильном клиенте.
P.S. Поздравляю с 900 комментарием!
А вот насчет клавы не уверен — у современных мобилок/планшетов достаточно большой экран: клава занимает 25...40% экрана, поэтому остается достаточно места под текст и прочую полезную информацию.
Да, отдельное приложение на смартфон сейчас в моде. Но пока я ограничусь одним клиентом — браузерным, т.к. не так много ресурсов, чтобы делить их между несколькими проектами с одинаковым функционалом. В будущем же надо сделать прогу хотя бы под андроид обязательно.
Я представляю это в виде двух скроллируемых панелей с кнопками внизу и вверху экрана. Верхняя панель связана с общими командами, типа перемещения, боевые команды и т.д.
Сам текст игры должен разбиваться на интерактивные блоки, выделяющие элементы игры — обыекты, мобы и т.д. Это что-то типа гиперсылок только большего размера, чтобы по ним можно было тыкнуть пальцем. При этом на нижней скроллируемой панели должны появляться кнопки связанные с этим объектом. Например, ткнули на сообщение «Вы видите здесь красивый фонтан» и появляются кнопки — пить, наполнить флягу, пописать в фонтан и т.д.
Если не понятно, вечером могу попробовать нарисовать как это примерно может выглядеть.
Еще удобны стрелки навигации, но в вашей концепции они ни к чему, если нету четких направлений по сторонам света.
А вообще голубая мечта — это полупрозрачная клавиатура, чтобы при вводе текста было все еще видно, что происходит.
Но это уже больше в сторону мобильного приложения, нежели браузера.
Да, мобильные устройства также рассматриваем в качестве играбельных.
Что именно нужно доработать в интерфейсе для удобства на мобильных?
Заходил также со смартфона, но играть на нем не удобно. Если мобильные устройства будут рассматриваться в качестве играбельных устройств, то интерфейс надо будет дорабатывать.
Поговаривают, что wss работает через прокси стабильнее, чем обычный ws. Учту это, когда буду прикручивать криптографию (https).
Или не в браузере. Потому что браузер Epiphany из той же ОС нормально работает через прокси.
Можете подсказать, с чего заходили?
Логи браузера тоже очень помогли бы.
P.S. Спасибо за отзыв!
Залил измененные test.html и main.js на гитхаб: github.com/nmud/mudjs/tree/nmud
Connecting to 94.127.69.186:3000
Ошибка undefined (undefined)
Соединение разорвано. Пожалуйста, обновите страницу.