¿Debe el motor de un eventual juego basado en la web comenzar como un servicio web?

Recientemente he decidido comenzar a escribir un motor para un juego de cartas. No soy un gran jugador de "cartas", pero un amigo me presentó el juego (es un giro en el juego danés), y me enamoré.

Quiero desarrollar el juego en 3 segmentos:

1. El motor básico, maneja cartas / mazos / estado del juego, etc.
2. Una interfaz de usuario (en forma de una aplicación web móvil / de escritorio).
3. Una inteligencia artificial con diversas estrategias / dificultades, etc.

Estos son proyectos muy distintos, en mi opinión ... y estoy luchando para ver cómo encajarán todos a la larga. Al principio, ni siquiera quiero poder "jugar" el juego usando el motor. El motor será probado principalmente por sus pruebas unitarias. Las pruebas de juego no comenzarán hasta que exista un cliente. Entonces hay algo de una relación cliente-servidor aquí.

El motor es una pieza muy grande del rompecabezas. Lo que me gustaría saber es: ¿cómo haría para desarrollar la "API pública" para este motor?

Estaba pensando que el motor podría ser un servicio web muy básico, que devuelve su estado a través de consultas a una API RESTful, pero me preocupa que desarrollar el motor en sí mismo como una aplicación web pueda conducir a malas decisiones de programación. (Por ejemplo, si elijo un micro marco MVC, bueno, esta API realmente no tendría vistas ... solo está devolviendo objetos serializados a través de JSON, o algo por el estilo. ¿Es malo usar MVC para un servicio como ¿esta? )

Mi otra idea era que el motor sería una aplicación de consola, y luego escribiría un puente de algún tipo para canalizar datos entre él y la aplicación web. (El puente realmente podría ser cualquier cosa. Quiero decir, el servidor web y el motor del juego podrían estar inactivos en un servidor IRC y compartir su estado en canales).

¿Qué enfoque adoptarías (desarrollar como un servicio web, o desarrollar como una aplicación independiente y cerrarlo más tarde), y por qué?

Gracias Robbie

EDITAR: Supongo que esto pertenece al desarrollo del juego. Para aclarar, voy a escribir un motor de juego de cartas. Estoy tratando de descubrir la mejor manera de exponer la API del motor para que pueda integrarse en el futuro con un cliente web y un cliente de IA.

Ni siquiera tenía una cuenta aquí, así que hola :)

La ruta del servicio web es probablemente la mejor y más escalable.

También veo absolutamente NO problema utilizando un framework MVC para volver JSON (asp.net MVC es grande en este). Si sus controladores solo devuelven JSON al principio, está bien, puede realizar una prueba unitaria sin ninguna vista. Cuando esté listo para agregar su interfaz de juego, puede agregar vistas. Si son simples html / css o flash / silverlight, no importa porque, como has dicho, ya has construido el motor subyacente.

No estoy seguro de cómo son sus entornos de desarrollo o de alojamiento, pero no lo diseñaría en exceso. Un simple conjunto de archivos php que devuelven JSON puede ser todo lo que necesita. No estoy familiarizado con el juego que estás creando, así que no estoy seguro de lo complejo que será.

En mi opinión, si eres nuevo en el desarrollo del juego y lo estás haciendo tú mismo, te recomiendo que obtengas algo que sea jugable lo antes posible, porque te ayudará a mantenerte motivado para completar el juego y pulirlo. a un buen nivel

Una vista es una entidad que se registra en un modelo para ser notificado cuando ocurren cambios.

Si su modelo reside en un servidor web, tiene un problema porque el HTTP no implementa una forma explícita de permitir que el servidor inicie una comunicación. Puede usar websocket para manejar esto, pero sacrificará parte de su "RESTfulness" ... Creo que una buena solución puede ser permitir que su URL web identifique un modelo y use el servidor HTTP para que sus vistas sean notificadas cuando sea necesario.

Digamos que tienes un juego en ejecución en

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/

puedes usar la URL

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/playCard?id=3&place=stack 

para modificar el modelo y

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify 

esperar las notificaciones

Notify esperará, durante cierto tiempo, para recibir noticias del modelo: si algo sucede, se enviará un mensaje (qué datos se cambian o qué tipo de evento ocurre o lo que sea).

El cliente puede hacer una solicitud ajax larga a / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notify y registrar una devolución de llamada de notificación que actualizará la vista y volverá a publicar la próxima solicitud de notificación.

Si games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notifica los tiempos de espera en el cliente, se realiza una nueva solicitud, si el tiempo de espera en el servidor, los recursos asignados se liberan.

Puede crear un sistema de notificaciones bastante genérico en su servidor y una biblioteca de notificaciones en sus clientes para que pueda crear un MVC consistente sobre una capa de notificación transparente.

Si está buscando una tecnología, puede considerar construir su motor de juego en el servidor Couchdb. Couchdb es un DBMS REST no relacional que utiliza HTTP como protocolo y JSON como formato de documento. También puede PONER y OBTENER archivos binarios o HTML como archivos adjuntos, por lo que es posible escribir una aplicación web completa utilizando solo el DBMS (una aplicación de sofá).

Existe una biblioteca de JavaScript que permite reaccionar a las actualizaciones de la base de datos, entre otras cosas. Un couchdbApp es simplemente una base de datos para que pueda copiar una aplicación a otro servidor mediante sincronización: sus clientes pueden copiar su aplicación a su servidor local y luego jugar en una LAN desconectada.