O mecanismo de um eventual jogo baseado na Web deve começar como um serviço da Web?

Decidi recentemente começar a escrever um mecanismo para um jogo de cartas. Eu não sou um grande jogador de "cartas", mas um amigo me apresentou o jogo (é um giro no jogo dinamarquês), e eu me apaixonei.

Eu quero desenvolver o jogo em 3 segmentos:

1. O mecanismo básico, lida com cartões / baralhos / estado do jogo, etc.
2. Uma interface do usuário (na forma de um aplicativo Web para celular / desktop).
3. Uma inteligência artificial com várias estratégias / dificuldades, etc.

Estes são projetos muito distintos, na minha opinião ... e estou lutando para ver como eles se encaixam a longo prazo. No começo, nem quero ser capaz de "jogar" o jogo usando o mecanismo. O motor será testado principalmente por seus testes de unidade. O teste de reprodução não será iniciado até que um cliente exista. Portanto, há algo de um relacionamento cliente-servidor aqui.

O motor é uma peça muito grande do quebra-cabeça. O que eu gostaria de saber é: como você desenvolveria a "API pública" para esse mecanismo?

Eu estava pensando que o mecanismo poderia ser um serviço da Web muito básico, que retorna seu estado por meio de consultas a uma API RESTful, mas estou preocupado que o desenvolvimento do próprio mecanismo como um aplicativo da Web possa levar a más decisões de programação. (Por exemplo, se eu escolhesse uma microestrutura MVC, bem, essa API não teria realmente visualizações ... está apenas retornando objetos serializados via JSON ou algo nesse sentido. É ruim usar o MVC para um serviço como esta? )

Minha outra idéia era que o mecanismo seria apenas um aplicativo de console e, posteriormente, eu escreveria uma ponte de algum tipo para canalizar dados entre ele e o aplicativo da web. (A ponte pode realmente ser qualquer coisa. Quero dizer, o servidor da Web e o mecanismo de jogo podem ficar ociosos em um servidor de IRC e compartilhar seu estado nos canais.)

Que abordagem você adotaria (desenvolver como um serviço da Web ou como um aplicativo independente e fazer a ponte posteriormente) e por quê?

Obrigado, Robbie.

EDIT: Então eu acho que isso pertence ao desenvolvimento de jogos. Para esclarecer, vou escrever um mecanismo de jogo de cartas. Estou tentando descobrir a melhor maneira de expor a API do mecanismo para que possa ser integrada no futuro com um cliente da Web e um cliente de IA.

Eu nem tinha uma conta aqui, então olá :)

A rota de serviço da web é provavelmente a melhor e mais escalável.

Também não vejo absolutamente nenhum problema ao usar uma estrutura MVC para retornar JSON (o asp.net mvc é ótimo nisso). Se seus controladores retornarem JSON apenas no início, tudo bem, você poderá fazer o teste de unidade sem nenhuma visualização. Quando você estiver pronto para adicionar a interface do jogo, você pode adicionar visualizações. Se o seu html / css ou flash / silverlight simples, não importa, porque, como você afirmou, você já criou o mecanismo subjacente.

Não tenho certeza de como são os seus ambientes de desenvolvimento ou hospedagem, mas eu não faria isso demais. Um conjunto simples de arquivos php que retornam JSON pode ser tudo o que você precisa. Eu não estou familiarizado com o jogo que você está construindo, então não tenho certeza de quão complexo será.

Na minha opinião, se você é novo no desenvolvimento de jogos, e você mesmo, recomendo que você obtenha algo que possa ser jogado o mais rápido possível, porque isso ajudará a mantê-lo motivado para concluir o jogo e aperfeiçoá-lo. para um bom nível.

Uma visão é uma entidade que se registra em um modelo para ser notificado quando mudanças ocorrem.

Se o seu modelo reside em um servidor da Web, você tem um problema porque o HTTP não implementa uma maneira explícita de permitir que o servidor inicie uma comunicação. Você pode usar o websocket para lidar com isso, mas sacrificará um pouco do seu "RESTfulness" ... Acho que uma boa solução pode ser deixar o URL da web identificar um modelo e usar o servidor HTTP para permitir que suas visualizações sejam notificadas quando necessário.

Vamos dizer que você tem um jogo de corrida em

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

você pode usar o URL

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

para modificar o modelo e

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

aguardar notificações.

O Notify aguardará - por algum tempo - para receber notícias do modelo: se algo acontecer, uma mensagem será enviada (que dados são alterados ou que tipo de evento ocorre ou o que for).

O cliente pode fazer uma solicitação ajax longa para / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notificar e registrar um retorno de chamada de notificação que atualizará a exibição e repassará a próxima solicitação de notificação.

Se games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / notificar o tempo limite no cliente, uma nova solicitação será feita, se o tempo limite for excedido no servidor, os recursos alocados serão liberados.

Você pode criar um sistema de notificação bastante genérico em seu servidor e uma biblioteca de notificação em seus clientes para criar um MVC consistente sobre uma camada de notificação transparente.

Se você estiver procurando por uma tecnologia, considere criar seu mecanismo de jogo no servidor Couchdb. O Couchdb é um REST DBMS não relacional que usa HTTP como protocolo e JSON como formato de documento. Ele também pode colocar e obter arquivos binários ou HTML como anexos, para que seja possível gravar um webApp completo usando apenas o DBMS (um couchApp).

Existe uma biblioteca javascript que permite reagir às atualizações do banco de dados, entre outras coisas. Um couchdbApp é simplesmente um banco de dados para que você possa copiar um aplicativo para outro servidor por sincronização: seus clientes podem copiar seu aplicativo para o servidor local e, em seguida, reproduzir em uma LAN offline.