Serialización de cierres en groovy

Question

Estoy desarrollando un juego en Groovy y estoy pensando en utilizar cierres extensamente para hacer que la arquitectura sea más limpia. Por ejemplo, para efectos de estado implementados (como envenenamiento), el objeto Player tendrá una lista de cierres para ejecutar cada turno de juego. Tendrán que ser serializados al guardar el juego.

¿Es generalmente una buena idea almacenar cierres en objetos que necesitarán serialización? ¿O debería optar por una arquitectura más tradicional (por ejemplo, almacenar una lista de objetos StatusEffect)?

Answer 1

Tener una lista de cierres para ejecutar cada turno de juego parece una muy buena idea :-)

serialising cierres es perfectamente posible. Desde Groovy 1.8.5, se ha hecho más fácil ya que los dos métodos dehydrate y rehydrate se añadieron a los cierres (para que el owner, thisObject y delegate puede ser retirados antes de la serialización)

pero tengo problemas con la serialización de Java nativo para el ahorro de datos. Para enviar datos de corta duración entre sistemas, puede ser genial (pero incluso entonces miraría protocol buffers o thrift)

Considere lo que sucede si necesita actualizar su juego? Si hay un error en el efecto poisoned, entonces cada usuario que haya guardado con el cierre envenenado con errores en su archivo guardará ese error hasta que desaparezca. En un juego de varios jugadores, también sería posible que las personas manipularan sus archivos guardados del juego para darse poderes inesperados o no deseados (ya que la funcionalidad de los poderes mismos se almacenaría en el archivo). Pude ver la manipulación de un efecto venenoso por lo que agrega HP en lugar de eliminarlos podría ser beneficioso ;-)

En resumen, supongo que lo que estoy diciendo es que escribiría una hoja de personaje, con identificaciones de cosas que afectan al usuario, inventario, puntaje, etc., y luego verifican y aplican los cierres a medida que se leen los archivos.