Методы добавления достижений в программное обеспечение бизнес-класса

Question

Я думал о добавлении некоторых достижений в нашу внутреннюю систему отслеживания ошибок и регистрации времени. Он подключен к серверной части SQL Server.

Сначала я подумал, что систему можно запустить в базе данных, используя триггеры, чтобы, например, узнать, когда:

• вы вошли 1000 часов
• создано 1000 билетов
• закрыл свой билет
• работал над билетом, который не был затронут в течение некоторого времени.
• и т. Д. (Вы знаете - вещи из базы данных)

Но потом я понял, что мне тоже нужны чисто входные достижения

• используется расширенный поиск по способу
• отсортировано по столбцу
• сброс настроек по умолчанию
• искали 500 раз

Кажется, что логика каждого достижения должна быть закодирована вручную. Может ли кто-нибудь представить себе какой-нибудь движок правил достижений , для которого вы, например, создаете сценарии?

А как их хранить? Если достижение:

• изменить порядок сортировки столбцов 50 раз за один сеанс

это означает, что каждый раз, когда они сортируют столбец списка, он обновляет базу данных.

Есть какие-нибудь мысли по поводу этой проблемы дизайна приложений Win32? Я не думаю, что у Банды Четырех есть дизайн Достижения .

---

Примечание: Это клиентское приложение Win32, а не веб-сайт.

---

Мне определенно нравится идея системы событий. Различные действия, предпринимаемые пользователем, могут вызывать события через один объект событий:

protected void TimeEntriesListView_ColumnSort(object sender, EventArgs e)
{
    _globalListener.RaiseEvent(EventType.ListViewColumnSort, sender, e);
}

protected void TimeEntriesListView_ColumnDrag(object sender, EventArgs e)
{
    _globalListener.RaiseEvent(EventType.ListViewColumnDrag, sender, e);
}

Затем к этому объекту может быть добавлена ​​логика, чтобы решить, какие события он хочет считать. Но, что более разумно, различные слушатели событий могут подключаться к центральному слушателю событий и иметь собственную логику достижения.

Answer 1

Хитрость не в том, чтобы кодировать правила, на самом деле, они просты и могут быть простыми выражениями (number_of_bugs> 1000).

Хитрость в накоплении статистики. Вы должны взглянуть на форму обработки потока событий, чтобы записать свои достижения. Например, вы на самом деле не хотите реализовывать достижение «1000 ошибок» с помощью «select count (*) из ошибок, где user =: user» все время (вы могли бы сделать это таким образом, но, вероятно, не следует). Скорее, вы должны получать событие каждый раз, когда они публикуют сообщение об ошибке, и ваши системные достижения "обнаруживают еще одну ошибку". Затем правило может проверить «number_of_bugs> 1000».

Очевидно, вам может понадобиться, так сказать, «прокачать насос», установив для number_of_bugs текущее число в БД при запуске системы достижений.

Но цель состоит в том, чтобы облегчить фактическую обработку событий, поэтому пусть она отслеживает события, когда они проходят, со всеми событиями, работающими на общем внутреннем канале или шине.

Язык сценариев также является хорошей идеей, поскольку он может легко оценивать как выражения, так и более сложную логику. «number_of_bugs> 1000» - это совершенно допустимая программа Javascript, например. В игре только настраивается среда.

Вы также можете сохранить сценарии в БД и создать редактор «достижений», чтобы добавить их на лету, если хотите, при условии, что вы захватываете все соответствующие события.

Answer 2

Я также пытаюсь понять, как создать механизм правил достижений.

Я проверил правила движков и их основы. Вот хорошее резюме этого в википедии

По сути, вы либо цепляетесь вперед, когда, например, проверяете наличие чего-либо; в противном случае вы используете Событие Условие Действие правила. Это последнее, что привлекло мое внимание.

Таким образом, вы можете заранее определить набор запускаемых событий. В движке вы можете определить, какие проверенные условия основаны на доступных показателях, и указать достижение ассоциации.

Этот способ кажется более гибким, но вы должны определить события, возможные проверки условий и метрики.

Например, у вас могут быть различные события, такие как TicketCreated, запущенные в коде.

В механизме правил у вас может быть что-то вроде

Event: TicketCreated
Condition: UserTicketCount >= 1000
Achivement: "Created 1000 tickets"

или для «сброса настроек по умолчанию»

Event: SettingsChanged
Condition: Settings = DEFAULT
Achievement: "Reset to Default"

Я еще не пробовал, но скоро собираюсь. Это в основном теоретическое сейчас.

Answer 3

Я думаю, что одна таблица содержит каждое событие, которое вы хотите отслеживать. Например, " Выполнил поиск ". Тогда с каждым достижением может быть связан SQL.

Затем можно создать один триггер на таблице Событие , который сравнил бы достижения, относящиеся к этому событию, и добавить достижение в таблицу Достижения .

Вот примеры таблиц быстрого доступа:

EventItems:
UserId, EventName, DateOccured, AnyOtherInfo

AchievementQualifiers: 
Achievement Name, AchievementCheckSQL, EventsThisAppliesTo 
(Normalize this, if multiple events apply)

В вашей Системе, например, в Интернете или в win32, вы просто вставляете в таблицу EventItems всякий раз, когда пользователь выполняет какое-либо событие, которое вы хотите отследить. Вы могли бы сделать один класс, чтобы справиться с этим. Для событий типа DB, таких как «Отправленный элемент» или «Опубликованный комментарий», вы можете сделать это с помощью триггера.

Затем в триггерах на EventItems для каждого AchievementQualifer , который имеет это EventThisAppliesTo , запустите проверку SQL и обновите UserAchievement таблица, если это правда и еще не была присуждена.

Извините за правописание, поскольку я печатаю это, сидя в пивном пабе.

Answer 4

Как насчет хранения запроса sql, связанного с достижением, в самой базе данных, поэтому добавление нового достижения будет включать только добавление имени и запроса sql для него.

например,

вы вошли 1000 часов - «выберите сумму регистра (часы)> 1000, затем« истина », иначе« ложь »конец от пользователя, где user_id =?"

Достижения, основанные на пользовательском интерфейсе, должны будут также хранить данные в БД, потому что вы можете использовать те же данные для других достижений в будущем.

Answer 5

Внутренние достижения должны быть простыми - они основаны на уже отслеженных предметах. Внешний интерфейс, как вы правильно заявили, потребует большего отслеживания. Один из способов сделать это - внедрить механизм аналитики для вашего сайта переднего плана.

Piwik на http://www.piwik.org может помочь здесь - это клон Google Analytics, который вы размещаете сами. Идея состоит в том, чтобы использовать его возможности регистрации, чтобы отслеживать, когда достижение было завершено.

Что касается какой-либо формы сценариев правил, вам всегда придется вручную их кодировать - хотя, возможно, вы можете упростить их, создав собственный небольшой механизм сценариев или реализовав собственный набор Lua.