Внедрение динамической системы премий

Question

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

Я думал об использовании кода Python для каждой награды.Затем, когда сервер проверяет, имеет ли пользователь право на вознаграждение, он запускает сценарий python с Jython (сервер находится на Java и Netty NIO), и если функция возвращает определенное значение, я присуждаю вознаграждение пользователю.Это может сработать, но, может быть, есть более эффективный метод, который не заставит меня запускать сотни скриптов Python каждый раз, когда мне нужно проверить, получил ли пользователь награду.

А когда лучше всего проводить эти проверки?Я думал о системе ловушек, где я буду указывать такие ловушки, как ([onconnect] [ondisconnect] [chatmessage.received]).Это также может сработать, но кажется немного грубым, и мне все равно придется запускать все сценарии из базы данных.

Answer 1

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

Ваше основное приложение, ориентированное на клиента, знает о наградах, но все, что оно знает о них, - это данные, загружаемые из БД -что-то вроде заголовка, изображения, описания, может быть, сколько людей получили награду и т. д. и (на основе таблиц БД), кто выиграл награду.

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

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

PS - при запуске чего-то вроде сервера онлайн-покера вы собираетесь запуститьв версии этой проблемы все время.Вам абсолютно необходимо разработать способ развертывания нового кода, не разрушая вашу службу и не имея окна простоя.Работа над Java-ориентированным программным решением для наград не решит эту проблему в долгосрочной перспективе.Вам следует изучить литературу по работе с настоящими 24/7 сервисами, есть немало способов решить эту проблему, и в наши дни это не так уж и сложно.

Answer 2

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

Пакетные процессы могут находиться на отдельном сервере / машине, поэтому вы можете перекомпилировать приложение или перезапустить сервер в любое время. Наличие этих новых наград можно обрабатывать, используя, например, упомянутый подход с добавлением jar-файлов и перезапуском сервера, также можно вводить новые пакетные задания в любое время и так далее. Так что ваше основное приложение работает в 99% случаев, пакетный сервер можно часто перезагружать. Поэтому хорошо иметь отдельные партии машин.

Когда вам нужно развернуть новую версию основного приложения, я думаю, что вы можете просто остановить, развернуть и запустить его с уведомлением об обслуживании для пользователей. Этот подход используется даже ведущими покер-румами с отличным программным обеспечением (например, FullTiltPoker сделал это, сейчас он недоступен из-за потери лицензии, но на их сайте написано «Обновление системы» :)).

Таким образом, один из подходов к обновлению версий - это повторное развертывание / перезапуск в нерабочее время.

Другой подход - обновления в реальном времени. Как правило, это делается путем миграции пользователей кучей за новой версией. Так что в то же время некоторые пользователи используют старую версию, некоторые - новую. Не очень круто для покерного софта, где могут взаимодействовать пользователи с разными версиями. Но если вы уверены в «совместимости» версий, вы можете использовать этот подход, проверяя версию клиента пользователя, например, при входе в систему.

В своем ответе я попытался сказать, что вам не нужно вводить логику поддержки 24/7 в ваш код. Оставьте проблемы с доступностью системы для аппаратного обеспечения (аварийное переключение, балансировка нагрузки и т. Д.). Вы можете следовать любым хорошим методам, которые вы использовали для написания кода, только вам нужно помнить, что ваша ключевая логика ядра развертывается не часто (например, раз в неделю), и пакетная часть может быть обновлена ​​/ перезапущена в любое время, если это необходимо. *

Answer 3

Я могу придумать несколько вариантов:

• OSGi, как описано выше - стоит дорого, но, вероятно, является наиболее универсальным и динамичным решением из всех
• Если вы открыты для перезапуска (но не для перекомпиляции), набор банок в хорошо известной папке и пружине даст вам более дешевое, но не менее общее решение. Просто сделайте так, чтобы ваши бины-награды реализовали стандартный интерфейс, будьте бобами, и пусть Spring вычислит все доступные награды в вашу шашку.
• Если вы присуждаете исполнение довольно стандартно, и единственное различие между наградами - это сами правила, у вас может быть какая-то скриптовая конфигурация. Там много вариантов, от описанного вами питона (за исключением того, что я бы пошел на несколько больших скриптов, управляющих всеми наградами), до базовых регулярных выражений с LUA и Drools в середине. Во всех случаях вы рассматриваете какую-то архитектуру механизма правил, которая является гибкой с точки зрения того, к чему может привести награда, но не предлагает большой гибкости с точки зрения того, к чему может привести награда (то есть идеально подходит для достижений).

Answer 4

Насколько я понимаю, вам, вероятно, не нужно ни запускать внешние процессы из вашего приложения, ни использовать OSGI. Просто создайте простой интерфейс Java и реализуйте каждый плагин (наградой) как класс, реализующий интерфейс. Затем вы можете просто скомпилировать любой новый плагин и загрузить его как файл класса из вашего приложения во время выполнения, используя Class.forName(String className). Любая логика, необходимая для такого плагина, будет содержаться в методах интерфейса.

http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Class.html#forName(java.lang.String)