Меня немного терзает мысль, что одна возможность, которую я сделал в клиенте, очень важную, для написания плагинов, способствует написанию этих ботов. Какую именно не буду говорить. Кому надо и так уже догадались.
Я думаю что первая, которая на сайте Tintina. Исходники не смотрел, но по словам Стрибога, тинтин уже рисует карту. Кстати в черепахе реализация MSDP сделана именно по версии Tintin-a.
Мне любопытны идеи насчет интерфейса такого редактора. Мой же опыт, как программиста, говорит, что максимум, что можно выжать из этой идеи — текстовый редактор, но с помощником, который будет подсказывать как писать, подставлять шаблоны для описания комнат, мобов и т.д., в которые потом нужно подставить нужные значения.
Я конечно не сторонник блокировок, но нельзя писать абсолютно любые статьи, это уже анархия. Я знаю что можно обойти блокировку и знаю как обходить, и Тор как один из вариантов, но это уже нарушение закона, и это на совести каждого лично, сажать думаю не будут. Конечно способ блокировки не сильно эффективен, но эффект он дает. А в википедии я пока не видел опасных статей, по крайней мере в русском сегменте.
Еще забыл добавить, что нужно поддержка инстансов отдельных зон. Псевдографика в юникоде это хорошо и можно использовать, но нужно будет подыскать шрифт где она есть. Я не думаю что в шрифтах рисуют все символы юникода. Или придется костлять такие символы в клиенте вручную.
Такой подход и нужно делать. Проблема в том что редактор по трудозатратам не меньше чем сам сервер, а то и больше. Плюс навернуть текстовыми конфигами можно гораздо больше чем сделать редактором. Тут придется тщательно выбрать какую часть функционала сделать в редакторе, и там не будут все возможности сервера. Разработка редактора никогда не будет успевать за сервером.
Если в редакторе есть кнопка — генерировать моба 15 уровня, то в моем варианте можно будут сделать примерно так: mob=Generate{level = 15}, но если в редакторе функция генерации моба зашита и ее не поменять, то в моем варианте ее можно менять, причем можно генерировать моба не только по уровню, а по любому набору параметров. А еще как пример можно будет сделать примерно так: mob = { parent = «black.wolf», name = «Белый волк», drop_coins = сhar_level*10+20 } — создать белого волка на базе черного волка, добавить ему дроп монет и привязать его к уровню персонажа, который его убил.
Редактор не дает видеть всю картину целиком, ты заблуждаешься. Ты об этом сам же и сказал. Если что-то нужно особенное — нужно залезть в файлы зоны. А редактор такое не покажет — это особенное, т.е. — картина не целиком. А для поддержки нестандартных выходов — нужно было сделать поддержку карты в маде, так чтобы маппер жабы это понимал, т.е. отдавать внум конматы мапперу, чтобы он не путался в комнатах.
Изменения без перезапуска или бекап без перезапуска — вполне реализуем, если заранее закладывать такую возможность. Например язык Erlang, он позволяет без перезагрузки и остановки сервера вообще менять его бинарный код. Как это работает я не изучал, но это заявлено.
Изменение — это обычная замена скрипта, как переменную в коде.
Бекап — тут можно остановить игровой процесс, оставить например только чат, чтобы не было скучно ждать бекап.
Два разных проекта писать не потребуется. Если взять С++11 то он уже давно стандарт — работает везде одинаково. Уверяю, поддержать несколько ОС совсем не сложно. Все давно для этого в сфере разработки сделано. Различия совсем незначительные.
Отладочный мад, которые в сети, а не локально на виртуальной машине — вполне нужная штука, где можно обкатывать зоны всеми сразу, а не в одиночку.
Два сервера на одном порту — это не опечатка. Это вполне реализуемо, но программно. Это похоже на технологию Load Balancer.
1. По поводу автоматизации нудных процессов — проставление флагов для однотипных мобов. Тут редактор будет даже хуже. Так как в моем варианте — можно наследовать одного моба от другого (наследование характеристик). Чтобы поставить общий флаг на моба — достаточно его поставить у прородителя таких мобов. В текстовом редакторе это будет сделать не намного сложнее. И в текстовом редакторе есть поиск. Плюс я повторюсь — редактором ты не сможешь кастомизировать индивидуально какую то характеристику для отдельного моба, т.к. придется наворачивать редактор, а это время.
2. Действительно без миникарты — картину в целом невидно, но нарисовать ее на бумаге несложно. Я не считаю что это прошлый век, но тратить время на редактор не вижу смысла, т.к. на него уходит гигантское время программиста. Что проще — нарисовать зону на бумаге, а потом ее соединить в коде или ждать пока программист сделает миникарту. В редакторе ты сможешь соединить только тем механизмом, что позволяет сам редактор (простой переход, дверь и пожалуй это все), а если делать это кодом, можно делать вообще все угодно (переходы в зависимости от характеристик персонажей, наличие предметов, висящих аффектов ).
В крайнем случае можно сделать миникарту чисто для ориентирования, но она не будет отражать все ньюансы. Очень сложно визуализировать ту механику, которую можно задать в виде кода.
Редактор удобен билдерам, согласен, они привыкли к нему, но он очень сильно их ограничивает в возможностях. Редактором можно сделать только то, что поддержал программист в этом редакторе, а движок мада сможет гораздо гораздо больше. Редактор — это камень на шее мадов. Это можно будет только продемонстрировать примером в будущем.
Потому что Unity готовый инструмент, который уже все делает много сам, не нужно заморачиватся подключением этой либы, изучать ее ограничения, требования к коду для нее, внедрять ее и т.д. Плюс в Unity огромное количество уже готовых блоков, которое можно использовать в проекте. Огромный магазин таких блоков. Это не только удобный GUI — это среда разработки с отладчиками, и прочими инструментами заточенных под работу. Unity решает огромное количество второстепенных задач, экономит время.
Я мельком глянул на данный движок. Я конечно тоже за отечественный софт, но нужно исходить из возможностей движка, комьюнити у движка, готовые проекты на движке, примеры и т.д. Я рассмотрю и этот движок когда вплотную займусь, но пока что это сомнительный вариант (не увидел поддержки сети, динамической подгрузки сцен, хотя глубоко не копал). Придется еще учить и JavaScript, минус также, что нельзя пользоваться с++, а в юнити можно, и с# я уже более менее освоил. А русский комьюнити у юнити огромный. На данный момент буду читать pdf по движку когда будет возможность.
На сайте пока ничего играбельного нет, я чисто изучаю возможности Unity3d в плане WebGL (ограничения, сколько будет весить игра, как работают браузеры, как собирать игру, публиковать и т. д.). Начал именно с WebGL — так как тут не все возможности Unity можно использовать, есть ограничения, но WebGL — это единственный сейчас вариант запустить на браузере игру без всяких плагинов. Сейчас браузеры ужесточают требования к плагинам, поэтому плеер Unity для браузеров больше не работает на основных браузерах, остается только WebGL.
То что я задумал, это эксперимент. Попытаться сделать мад с графикой. Т.е. управление по прежнему с клавиатуры, максимум кнопки на экране для мобильных устройств (но об этом думал пока мало). Сейчас хочу чисто проверить игровую концепцию — клетки остаются, но одна клетка (рума) — это небольшая квадратная зона например 100 на 100 метров (размер подберется позднее экспериментальным путем). На этой территории и идет игра. Перемещение в другую руму — как это объяснить, когда у тебя клетка 100на100 пока не знаю. Графика красивая пока тоже не планируется.
На первом этапе — 4 румы (квадрат). Перемещение по руме и между румами. Чат, взаимодействие с объектами.
Но время сейчас уходит — на доделку черерпахи.
tintin.sourceforge.net/mssp/mudlist.html
Изменение — это обычная замена скрипта, как переменную в коде.
Бекап — тут можно остановить игровой процесс, оставить например только чат, чтобы не было скучно ждать бекап.
Отладочный мад, которые в сети, а не локально на виртуальной машине — вполне нужная штука, где можно обкатывать зоны всеми сразу, а не в одиночку.
Два сервера на одном порту — это не опечатка. Это вполне реализуемо, но программно. Это похоже на технологию Load Balancer.
2. Действительно без миникарты — картину в целом невидно, но нарисовать ее на бумаге несложно. Я не считаю что это прошлый век, но тратить время на редактор не вижу смысла, т.к. на него уходит гигантское время программиста. Что проще — нарисовать зону на бумаге, а потом ее соединить в коде или ждать пока программист сделает миникарту. В редакторе ты сможешь соединить только тем механизмом, что позволяет сам редактор (простой переход, дверь и пожалуй это все), а если делать это кодом, можно делать вообще все угодно (переходы в зависимости от характеристик персонажей, наличие предметов, висящих аффектов ).
В крайнем случае можно сделать миникарту чисто для ориентирования, но она не будет отражать все ньюансы. Очень сложно визуализировать ту механику, которую можно задать в виде кода.
Редактор удобен билдерам, согласен, они привыкли к нему, но он очень сильно их ограничивает в возможностях. Редактором можно сделать только то, что поддержал программист в этом редакторе, а движок мада сможет гораздо гораздо больше. Редактор — это камень на шее мадов. Это можно будет только продемонстрировать примером в будущем.
То что я задумал, это эксперимент. Попытаться сделать мад с графикой. Т.е. управление по прежнему с клавиатуры, максимум кнопки на экране для мобильных устройств (но об этом думал пока мало). Сейчас хочу чисто проверить игровую концепцию — клетки остаются, но одна клетка (рума) — это небольшая квадратная зона например 100 на 100 метров (размер подберется позднее экспериментальным путем). На этой территории и идет игра. Перемещение в другую руму — как это объяснить, когда у тебя клетка 100на100 пока не знаю. Графика красивая пока тоже не планируется.
На первом этапе — 4 румы (квадрат). Перемещение по руме и между румами. Чат, взаимодействие с объектами.
Но время сейчас уходит — на доделку черерпахи.