Le moteur d'un éventuel jeu sur le Web devrait-il démarrer en tant que service Web?

J'ai récemment décidé de commencer à écrire un moteur pour un jeu de cartes. Je ne suis pas un grand joueur de "cartes", mais un ami m'a présenté le jeu (c'est un tour sur le jeu danois), et je suis tombé amoureux.

Je souhaite développer le jeu en 3 segments:

1. Le moteur de base, gère les cartes / decks / gamestate, etc.
2. Une interface utilisateur (sous la forme d'une application Web mobile / de bureau.)
3. Une intelligence artificielle aux stratégies / difficultés diverses, etc.

Ce sont des projets très distincts, dans mon esprit ... et j'ai du mal à voir comment ils s'intégreront tous à long terme. Au début, je ne veux même pas pouvoir "jouer" le jeu en utilisant le moteur. Le moteur sera principalement testé par ses tests unitaires. Le test de lecture ne démarre pas tant qu'un client n'existe pas. Il y a donc ici une relation client-serveur.

Le moteur est une très grande pièce du puzzle. Ce que je voudrais savoir, c'est: comment feriez-vous pour développer "l'API publique" pour ce moteur?

Je pensais que le moteur pourrait être un service Web très basique, qui renvoie son état via des requêtes à une API RESTful, mais je crains que le développement du moteur lui-même en tant qu'application Web puisse conduire à de mauvaises décisions de programmation. (Par exemple, si je choisis un micro-framework MVC, eh bien, cette API n'aurait pas vraiment de vues ... elle renvoie simplement des objets sérialisés via JSON, ou quelque chose dans ce sens. Est-ce mauvais d'utiliser MVC pour un service comme ce? )

Mon autre idée était que le moteur ne serait qu'une application console, et j'écrirais plus tard un pont quelconque pour diriger les données entre celui-ci et l'application Web. (Le pont pourrait vraiment être n'importe quoi. Je veux dire, le serveur Web et le moteur de jeu pourraient tous deux être inactifs sur un serveur IRC et partager leur état sur des canaux.)

Quelle approche adopteriez-vous (développer en tant que service Web, ou développer en tant qu'application autonome et la relier plus tard), et pourquoi?

Merci, Robbie.

EDIT: Donc je suppose que cela appartient au développement de jeux. Pour clarifier, je vais écrire un moteur de jeu de cartes. J'essaie de trouver la meilleure façon d'exposer l'API du moteur afin qu'elle puisse être intégrée à l'avenir avec un client Web et un client AI.

Je n'avais même pas de compte ici, alors salut :)

L'itinéraire du service Web est probablement le meilleur et le plus évolutif.

Je ne vois également absolument aucun problème en utilisant un framework MVC pour renvoyer JSON (asp.net mvc est génial à cela). Si vos contrôleurs ne renvoient JSON que dans un premier temps, cela vous convient, vous pouvez effectuer des tests unitaires sans aucune vue. Lorsque vous êtes prêt à ajouter votre interface de jeu, vous pouvez ajouter des vues. Si leur html / css simple ou flash / silverlight, cela n'a pas d'importance parce que, comme vous l'avez dit, vous avez déjà construit le moteur sous-jacent.

Je ne sais pas à quoi ressemblent vos environnements de développement ou d'hébergement, mais je ne le ferais pas trop. Un simple ensemble de fichiers php qui renvoient JSON peut être tout ce dont vous avez besoin. Je ne connais pas le jeu que vous construisez, donc je ne sais pas à quel point il sera complexe.

À mon avis, si vous êtes nouveau dans le développement de jeux et que vous y allez vous-même, je vous recommande fortement d'obtenir quelque chose de jouable dès que possible, car cela vous aidera à rester motivé pour terminer le jeu et le peaufiner à un bon niveau.

Une vue est une entité qui s'enregistre auprès d'un modèle pour être notifiée lorsque des modifications se produisent.

Si votre modèle réside sur un serveur Web, vous avez un problème car le HTTP n'implémente pas de manière explicite de laisser le serveur démarrer une communication. Vous pouvez utiliser websocket pour gérer cela, mais vous sacrifierez une partie de votre "RESTfulness" ... Je pense qu'une bonne solution peut être de laisser votre URL Web pour identifier un modèle et d'utiliser la poussée du serveur HTTP pour laisser vos vues être notifiées si nécessaire.

Disons que vous avez un jeu de course

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

vous pouvez utiliser l'URL

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

pour modifier le modèle et

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

attendre les notifications.

Notify attendra - pendant un certain temps - pour obtenir des nouvelles du modèle: si quelque chose se passe, un message sera envoyé (quelles données sont modifiées ou quel type d'événement se produit ou autre).

Le client peut effectuer une longue requête ajax vers / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notify et enregistrer un rappel de notification qui mettra à jour la vue et republiera la prochaine demande de notification.

Si games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notifient les dépassements de délai sur le client, une nouvelle demande est effectuée, s'il expire sur le serveur, les ressources allouées sont libérées.

Vous pouvez créer un système de notification assez générique sur votre serveur et une bibliothèque de notifications sur vos clients afin de pouvoir créer un MVC cohérent sur une couche de notification transparente.

Si vous recherchez une technologie, vous pouvez envisager de construire votre moteur de jeu sur le serveur Couchdb. Couchdb est un SGBD REST non relationnel qui utilise HTTP comme protocole et JSON comme format de document. Il peut également PUT et GET des fichiers binaires ou HTML en tant que pièces jointes, il est donc possible d'écrire une webApp complète en utilisant uniquement le SGBD (un couchApp).

Il existe une bibliothèque javascript qui permet notamment de réagir aux mises à jour de la base de données. Un couchdbApp est simplement une base de données afin que vous puissiez copier une application sur un autre serveur par synchronisation: vos clients peuvent copier votre application sur leur serveur local puis jouer sur un réseau local hors ligne.