Il motore di un eventuale gioco basato sul web dovrebbe iniziare come servizio web?

Di recente ho deciso di iniziare a scrivere un motore per un gioco di carte. Non sono un grande giocatore di "carte", ma un amico mi ha fatto conoscere il gioco (è un giro sul gioco danese) e mi sono innamorato.

Voglio sviluppare il gioco in 3 segmenti:

1. Il motore di base, gestisce carte / mazzi / gamestate, ecc.
2. Un'interfaccia utente (sotto forma di un'app Web mobile / desktop.)
3. Un'intelligenza artificiale con varie strategie / difficoltà, ecc.

Questi sono progetti molto distinti, nella mia mente ... e sto lottando per vedere come si adatteranno tutti insieme a lungo termine. All'inizio, non voglio nemmeno essere in grado di "giocare" usando il motore. Il motore sarà testato principalmente dai test unitari. Il test di gioco non inizierà finché non esiste un client. Quindi c'è qualcosa di una relazione client-server qui.

Il motore è un pezzo molto grande del puzzle. Quello che vorrei sapere è: come svilupperesti l'API pubblica per questo motore?

Pensavo che il motore potesse essere un servizio Web molto semplice, che restituisce il suo stato tramite query a un'API RESTful, ma sono preoccupato che lo sviluppo del motore stesso come app Web possa portare a decisioni di programmazione inadeguate. (Ad esempio, se avessi scelto un micro-framework MVC, beh, questa API non avrebbe davvero viste ... sta solo restituendo oggetti serializzati tramite JSON o qualcosa del genere. È male usare MVC per un servizio come Questo? )

L'altra mia idea era che il motore fosse solo un'app console e in seguito avrei scritto un bridge di qualche tipo per reindirizzare i dati tra esso e l'app web. (Il bridge potrebbe davvero essere qualsiasi cosa. Voglio dire, il web server e il motore di gioco potrebbero entrambi essere inattivi in ​​un server IRC e condividere il loro stato nei canali.)

Quale approccio seguiresti (sviluppalo come servizio web o sviluppalo come app autonoma e la ponte in un secondo momento), e perché?

Grazie Robbie.

EDIT: Quindi immagino che questo appartenga allo sviluppo del gioco. Per chiarire, ho intenzione di scrivere un motore di gioco di carte. Sto cercando di capire il modo migliore per esporre l'API del motore in modo che possa essere integrata in futuro con un client Web e un client AI.

Non avevo nemmeno un account qui, quindi ciao :)

Il percorso del servizio Web è probabilmente il migliore e il più scalabile.

Inoltre non vedo assolutamente NESSUN problema di utilizzo di un framework MVC per restituire JSON (asp.net mvc è eccezionale in questo). Se i controller restituiscono JSON solo all'inizio, va bene il unit test senza alcuna vista. Quando sei pronto per aggiungere l'interfaccia di gioco, puoi aggiungere visualizzazioni. Se il loro semplice HTML / CSS o Flash / Silverlight, non importa perché, come hai già detto, hai già creato il motore sottostante.

Non sono sicuro di come saranno i tuoi ambienti di sviluppo o hosting, ma non lo progetterei troppo. Un semplice set di file php che restituiscono JSON potrebbe essere tutto ciò di cui hai bisogno. Non ho familiarità con il gioco che stai costruendo, quindi non sono sicuro di quanto sarà complesso.

Secondo me, se sei nuovo nello sviluppo del gioco e lo fai da solo, ti consiglio vivamente di ottenere qualcosa che è giocabile il prima possibile, perché ti aiuterà a rimanere motivato a completare il gioco e lucidarlo ad un buon livello.

Una vista è un'entità che si registra su un modello per essere avvisato quando si verificano cambiamenti.

Se il modello risiede su un server Web, si verifica un problema perché HTTP non implementa un modo esplicito per consentire al server di avviare una comunicazione. Puoi utilizzare websocket per gestire questo, ma sacrificherai alcuni dei tuoi "RESTfulness" ... Penso che una buona soluzione possa essere quella di consentire al tuo URL web di identificare un modello e utilizzare il server HTTP push per consentire la notifica delle tue visualizzazioni Quando necessario.

Diciamo che hai una partita in corso

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

puoi usare l'URL

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

per modificare il modello e

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

per attendere le notifiche.

Notifica attenderà - per un certo periodo di tempo - per ricevere notizie dal modello: se qualcosa accade, verrà inviato un messaggio (quali dati vengono modificati o che tipo di evento accade o altro).

Il client può fare una lunga richiesta Ajax a / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notificare e registrare un callback di notifica che aggiornerà la vista e ripubblicherà la successiva richiesta di notifica.

Se games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notifica timeout sul client, viene eseguita una nuova richiesta, se si verifica il timeout sul server, le risorse allocate vengono liberate.

È possibile creare un sistema di notifica piuttosto generico sul server e una libreria di notifica sui client in modo da poter creare un MVC coerente su un livello di notifica trasparente.

Se stai cercando una tecnologia, puoi considerare di costruire il tuo motore di gioco sul server Couchdb. Couchdb è un DBMS REST non relazionale che utilizza HTTP come protocollo e JSON come formato di documento. Può anche mettere e ottenere file binari o HTML come allegati, quindi è possibile scrivere una webApp completa usando solo il DBMS (una couchApp).

Esiste una libreria javascript che consente tra l'altro di reagire agli aggiornamenti del database. Una couchdbApp è semplicemente un database in modo da poter copiare un'applicazione su un altro server sincronizzando: i tuoi clienti possono copiare la tua app sul loro server locale e quindi giocare su una LAN off-line.