Implementación de un sistema de concesión dinámica

Question

He estado desarrollando un juego de póker en línea. Pero sigo golpeando una pared. Quiero implementar premios en el sistema, pero quiero que sean dinámicos. Lo que significa que no quiero volver a compilar para cada premio que me gustaría agregar.

He pensado en usar el código de Python para cada premio. Luego, cuando el servidor comprueba si el usuario califica para el premio, ejecuta el script de python con Jython (el servidor está en Java y Netty NIO) y si la función devuelve cierto valor, otorgo el premio al usuario. Lo cual podría funcionar, pero ¿existe quizás una técnica más eficiente que no me obligue a ejecutar cientos de scripts de Python cada vez que necesito verificar si un usuario recibió un premio?

¿Y cuándo son los mejores momentos para hacer estos controles? He pensado en un sistema de anzuelo donde especificaré los ganchos como ([onconnect] [ondisconnect] [chatmessage.received]). Lo cual también podría funcionar, pero se siente un poco crudo y todavía tendré que ejecutar todos los scripts de la base de datos.

Answer 1

Si fuera usted, tendría un proceso totalmente independiente que otorga premios. Se ejecuta tal vez una vez al día en la base de datos subyacente que contiene todos sus datos de jugador/juego.

Su aplicación principal orientada al cliente sabe de premios, pero todo lo que sabe sobre ellos son datos que carga de la base de datos, algo así como un título, imagen, descripción, tal vez cuántas personas tienen el premio, etc. (basado en tablas DB) que ha ganado el premio.

Su proceso de "concesión de premios" simplemente se ejecuta en modo por lotes, una vez por día/hora, etc., y otorga nuevos premios a los jugadores elegibles. Luego, la aplicación principal orientada al cliente les notifica, pero en realidad no tiene que saber la inteligencia de cómo otorgarlos. Esto le da la libertad de volver a compilar y volver a ejecutar el otorgante de premios en cualquier momento que desee sin impacto en la aplicación principal.

Otro enfoque, dependiendo de cuán restringidos sean sus premios, sería escribir una interfaz de reglas simple que le permita definir reglas en los datos. Eso sería ideal para lograr lo que describes, pero es bastante trabajo para no mucha recompensa, en mi opinión.

PD: al ejecutar algo así como un servidor de póquer en línea, te vas a encontrar con versiones de este problema todo el tiempo. Necesitará desarrollar una forma de implementar código nuevo sin matar su servicio o tener una ventana de tiempo de inactividad. Trabajar alrededor de una solución de código centrada en Java para premios no va a resolver ese problema para usted a largo plazo. Debe buscar en la literatura sobre la ejecución de verdaderos servicios 24/7, hay bastantes maneras de abordar el problema y en realidad no es tan difícil en estos días.

Answer 2

Por lo que le entiendo, probablemente no tenga que ejecutar procesos externos desde su aplicación ni usar OSGI. Simplemente cree una interfaz Java simple e implemente cada complemento ('premio') como una clase que implementa la interfaz. Simplemente podría compilar cualquier nuevo complemento y cargarlo como un archivo de clase desde su aplicación en tiempo de ejecución usando Class.forName(String className). Cualquier lógica que necesite de dicho complemento estaría contenida en los métodos en la interfaz.

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

Answer 3

Hay una serie de opciones que se me ocurre:

• OSGi como se describió anteriormente - que tiene un costo, pero es probablemente la solución más genérica y dinámico por ahí
• Si está abierto para reiniciar (simplemente no recompilar), una colección de jarras en una carpeta conocida y en la primavera le dan una solución más barata pero igualmente genérica. Simplemente haga que sus premios frijoles implementen una interfaz estándar, sean frijoles, y deje que Spring figure @Autowire todos los premios disponibles en su comprobador.
• Si otorga la ejecución es bastante estándar, y la única variación entre las adjudicaciones son las mismas reglas, puede tener algún tipo de configuración con guiones. Aquí hay muchas opciones, desde la python que describiste (excepto que elegiría un gran guión que administre todos los premios), hasta las expresiones regulares básicas, con LUA y Drools en el medio. En todos los casos está buscando algún tipo de arquitectura de motor de reglas, que es flexible en términos de lo que el premio puede activar pero no ofrece mucha flexibilidad en términos de lo que un premio puede generar (es decir, perfecto para los logros).

Answer 4

Algunos comentarios a la respuesta con las ideas de lote: Implementing a Dynamic Award System

que los procesos por lotes puede ser separada de servidor/máquina, por lo que puede volver a compilar la aplicación o reiniciar el servidor en cualquier momento. Teniendo que los nuevos premios se pueden manejar utilizando, por ejemplo, el enfoque mencionado con la adición de jarras y reiniciar el servidor, también se pueden introducir nuevos trabajos por lotes en cualquier momento y así sucesivamente. De modo que su aplicación principal se ejecuta el 99% del tiempo, el servidor por lotes se puede reiniciar con frecuencia. Por lo tanto, es bueno tener máquinas de lote separadas.

Cuando necesite implementar una nueva versión de la aplicación principal, creo que puede detenerla, implementarla e iniciarla con un aviso de mantenimiento a los usuarios. Ese enfoque es utilizado incluso por las mejores salas de poker con un excelente software (por ejemplo, FullTiltPoker lo hizo, ahora mismo está inactivo debido a la pérdida de la licencia, pero su sitio dice 'Actualización del sistema' :)).

De modo que un enfoque para la actualización de versiones es volver a desplegar/reiniciar fuera de horario.

Otro enfoque son las actualizaciones en tiempo real. Como regla, se realiza migrando usuarios agrupados a la nueva versión. Entonces, al mismo tiempo, algunos usuarios están usando versiones antiguas, algunas nuevas. No es muy bueno para el software de póquer donde los usuarios con diferentes versiones pueden interactuar. Pero si está seguro en la compatibilidad de las versiones, puede seguir ese enfoque, verificando la versión del cliente del usuario, por ejemplo, al iniciar sesión.

En mi respuesta traté de decir que no necesita introducir una lógica de soporte 24/7 a su código. Deje que los problemas de disponibilidad del sistema para el hardware (failovers, loadbalancers, etc.). Puede seguir las buenas técnicas que utilizó para escribir el código, solo debe recordar que su lógica central crucial se implementa con poca frecuencia (por ejemplo, una vez a la semana), y la parte del lote puede actualizarse/reiniciarse en cualquier momento si es necesario.