|
Предварительные наброски
В этом треде я оставляю за собой право удалять "лишние-устаревшие" сообщения.
Версия 0.2
Собственно всё-таки было решено сделать. Для начала для собственного использования, т.к. проще выделить как сервис.
Поскольку мне пофиг где писать "кастрированные спеки", всё равно "пишу для себя", в качестве эксперимента было решено
написать тут. Мало-ли, у кого-то может будут здравые идеи.
Документ очень приблизительный, будет дорабатываться.
Итак. Вводная. (зачеркнуто то, что будет реализовано в v2.0 - первая версия - для внутреннего употребления,
вторая для возможности интегрироваться с иными мадами (буде захотят) )
Сервис, отдельно крутящийся на отдельном железе.
Основное назначение - накопление имён и решений по ним. Первоначально в базу решений есть идея
добавить имеющиеся. Кроме автообновления-автозарубания этот сервис позволит сохранить за собой имя
персонажа, даже если сам он будет удален из базы конкретного мада.
Предполагается что для этой части будет использован в качестве реализации c# и mono, код не будет open source.
(1. нет смысла размножать такие сервисы, 2.чуть завуалирует проблемы безопасности 3.речь идет именно о серверной части сервиса)
Сырое описание БД и функционала (надо было всё-таки отдельно, но т.к. пишу для себя мне удобней в куче):
1. Создание "проектов". Один проект - один мад. Мадконнектор заведен отдельным проектом
Создаются проекты-болванки вручную, после выдачи логина-пароля редактируются из www-админки.
Для каждого проекта хранится
- адрес
- логин-пароль (административный)
- логин-пароль для "управления" мадом
- ссылка на ведущего ГМа
- мыло для нотификаций
- отдельно таблица политик
2. Политики указывают на то, из каких других проектов он хочет использовать информацию, а из каких нет,
и каким конкретно образом.
- ссылка на проект к которому принадлежит политика
- ссылка на проект-донор (all - для всех / mudconnector - для мадконнектора / конкретный проект)
- тип политики.
- Отвергать имена отвергнутые в проекте-доноре(значение буде заданным, только отвергнутые определенным ГМ-ом)
- Одобрять имена отвергнутые в проекте-доноре (значение буде заданным, только отвергнутые определенным ГМ-ом)
- Проверять имена новосозданных персонажей на дубликаты в проекте-доноре (значение если задано мин уровень персонажа, либо
минимальное время проведенное онлайн, либо что-еще-тут-может-быть?)
- использовать banlist из проекта-донора (ban / ban new / чтотамещеунас)
- политики для предтитулов и титулов
- что еще тут может быть ?
- значение/я
- автоматическая политика или ручная. Автоматические применяются сразу. Ручные выглядят как подсказки ГМу при одобрении
или неодобрении через интерфейс.(без политик считается, что используются "все")
3. Таблица пользователей ГМ-ов. Они создаются из www-админки "проекта" из которой настраиваются и права ведущим ГМом.
- ссылка на проект к которому принадлежит ГМ
- имя ГМа, логин, пароль (для системы)
- email
- права ГМ-а (одобрять, отвергать, банить итп, по каждому из типов политик)
***продолжение следует***
*** *** *** *** *** ***
API
Всё-таки telnet. И plain text.
В сторону мада - просто текстовые команды. Полный аналог ручного ввода.
Для нормального функцинирования должен быть создан ГМ с соответствующими правами в wizinvis-е.
(но без лишних прав)
Его логин-пароль должны быть забиты в информацию проекта.
Проблема усугубляется тем, что в команды надо ввести параметр типа "автор", иначе или
каждый ГМ должен иметь такого суррогат-чара, или не будет понятно кто зарубил-одобрил имя.
Список необходимых команд.
(поддержка со стороны мада)
approve [имя] [кто] - одобрить имя
reject [имя] [кто] [резон] - зарубить имя
approve list - получить список имен для одобрения
banlist - получить список забаненых сетей
who - получить список пользователей онлайн (можно использовать для отображения на мадконнекторе)
Со стороны мада тоже самое, только каждый проект имеет свой логин+пароль+идентификация по ip
Нотификация:
approved [имя] [кто] - имя одобрено
rejected [имя] [кто] [резон] - имя зарублено
banned - изменена таблица банлиста (проще пересчитать целиком встречным запросом)
char created [имя]
char gain level [имя] - возможно имеет смысл для создания выборки по "старым" игрокам
Запросы:
check [имя] [пароль] - ответ approve|reject [резон]|reserved
Пример клиентской части(то, что надо интегрировать в мад) на plain C под circle должен быть в открытом доступе.
(собственно это реализация команд). На всех этапах должна быть предусмотрена неработоспособность канала
между сервисом и мадом. Пересоединение происходит автоматически. В момент отсутствия связи никакие
команды не накапливаются и всё работает так, как будто сервиса просто нету.
При каждом соединении сервис опрашивает approve list и для каждого из чаров проверяет наличие "решения".
Если решение есть - оно применяется.
Один раз в Х минут (10? 60?), сервис переопрашивает approve list, а также who
Наибольшая проблема тут, с обработкой check -> reserved. Всё остальное можно асинхронно. Это надо
как-то синхронно. Надо посмотреть схему создания чаров.
Возможно имеет смысл просто на этапе "одобрено-нет" не одобрять автоматом таких чаров.
Но это не решает проблемы их создания. Нет, не подходит, надо всё-таки не давать их создавать как-то.
(мало ли что понапишут неодобренные)
*** ** ***
Веб-интерфейс.
Для проекта - редактирование параметров + добавление ГМ-ов. Добавление проектов вручную скриптом.
Редактирование политик.
Статистика по ГМ-ам (кто сколько решений принял и каких)
Тут-бы как-то еще двухфазное одобрение, исправление ошибок итп прикрутить... еще подумаю
Для каждого ГМ-а - тикетсистем в которой каждый запрос на одобрение, который не был автоматом
обработан превращается в тикет.
Для игроков - создания ПЕРСОН. Каждая персона имеет ФИО итп, внутри персоны можно добавлять
имена игроков зарезервированных для персоны (вопрос изначального представления данных отделен).
По каждому из имен можно регулировать видимость соответствия имени персоне.
Для каждого из имен можно получить 1 и более одноразовых паролей для регистрации.
Открытый интерфейс (доступное без авторизации):
Поиск решений по конкретному имени во всей базе
Поиск зарезервированности имени во всей базе
списки ГМ-ов по проектам (надо ли ?)
***
Возможно имеет смысл от концепции "зарезервированно" перейти к "зарезервировано в маде таком-то".
***
1. Авторизация пользователя (с каждым запросом). Пользователи заводятся в ручном режиме(не важно через веб интерфейс
или через телнет, вообще лучшеб через веб). Авторизация нужна не только для модификации данных но и для фильтровки выборок.
2. Как пользователя добавляют только ГМ-ов. Каждый из них имеет ссылку на проект в котором он ГМ.
4. Для ГМ-ов лучше бы иметь отдельный интерфейс. В него-же можно добавить возможность работы с тикетами,
связанными с титулами, и одобрением имен. Смысл в том, чтобы сделать его ВЕБ, и с удобным поиском в 1 клик
по поисковикам. (ткнул в имя - выскочила выдача гугла-яндекса). Одобрил и одобрилось в маде (тут подумать
как переопрашивать, поток информации в направлении мада не хочется делать).
5. Можно привернуть генерацию отчетов типа "кто сколько одобрил, каких итп). Как открытую так и закрытую.
Параллельно этому хотелось бы иметь некий механизм авторизации владельцев имен. Дающий следующий функционал:
1. Резервирование "своего" имени за собой
2. Подтверждение своего имени. Вероятно надо генерировать пароль-ответ. В целом схема действий мада такая:
2.1. Игрок вводит при создании персонажа имя
2.2. Мад проверяет его по сервису
2.3. Если имя есть, то он просит залогиниться игрока в сервис и сгенерировать там разовый пароль, и вбить его в мад
(тут как-то надо отвязаться от синхронизации)
2.4. Без пароля создать персонажа нельзя.
3. Есть существенная проблема связанная с тем, что регистироваться вручную на первых порах народ не будет.
А также, будет, но с чужими именами. Как это качественно разрулить пока непонятно. Будем думать.
Думается мне, что для своих я сделаю запрос какой-то личной информации что уже есть в маде, либо
пароля-части пароля.
Тут надо-бы почитать как с авторизацией работать... возможно имеет смысл иметь одну базу с мадконнектором,
хотя очень не уверен.
***
Дополнительно
засунуть ли туда-же базу по блокировкам (ban) и по местам типа клубов итп...
засунуть одобрение титулов-предтитулов
***
***
Как всё предположительно будет выглядеть со стороны сервиса:
Для проверки используется просто выборка по таблицам.
Для каждого типа зарегистрированных событий заведена отдельная табличка.
Одобрено
Зарублено
Создан
Gain level
Для ГМ-а всё выглядит следующим образом: страничка на которой
в древовидном виде указаны
Имя чара
Одобрен там-то тем-то
Создан там-то
Зарублен там-то
Кнопка для проверки в Я, в Г
Имя следующего чара
итд итп
|
Вход
Регистрация
FAQ
Поиск
?