Servidor de juegos para un juego de mesa por turnos Android / iOS

9

Actualmente estoy programando un juego para iPhone y me gustaría crear un modo multijugador en línea. En el futuro, esta aplicación será compatible con dispositivos Android, así que me preguntaba cómo crear el servidor de juegos.

En primer lugar, ¿qué idioma debo elegir? ¿Cómo hacer que un servidor pueda comunicarse tanto con programas escritos en Objective-C como en Java?

Entonces, ¿cómo hacerlo efectivamente? ¿Es bueno si abro un socket por cliente (habrá 2)? ¿Qué tipo de información debo enviar al servidor? a los clientes?

Cirilo
fuente

Respuestas:

7

No me refiero a comenzar una guerra santa aquí, pero la mayoría de los servicios de Internet (flickr, twitter, facebook y demás) han dejado caer SOAP a favor de los servicios web RESTful y JSON como formato serializado. Aunque esencialmente lo mismo, los servicios REST se basan en el método url y http para definir lo que se debe hacer, por ejemplo

GET /articles - list all articles
POST /articles - add a new article
PUT /articles/123 - update article 123 with new data

JSON, descrito en json.org, también es más simple que XML, y aunque tal vez sea irrelevante, le ahorrará algunos bytes por solicitud. Siguiendo el ejemplo anterior, así es como se describiría un artículo en notación JSON:

{ 
 "id": 123,
 "author": "Cyril",
 "content": "Hello, this is an article",
 "tags": [ "gamedev", "webservices", "multiplayer" ] 
}

Para el IOS hay este bonito artículo http://petermcintyre.wordpress.com/2010/11/04/consume-json-rest-in-ios/ que menciona http://code.google.com/p/json-framework / para analizar y generar los datos.

Al estar basado en turnos, puede confiar en las sesiones http en el servidor para mantener el estado, por lo que no es necesario mantener una conexión de socket persistente al servidor. Cualquier lenguaje del lado del servidor lo admite (php, python, java, etc.).

Esta arquitectura le permite escalar horizontalmente (agregando más servidores) de manera transparente.

guigouz
fuente
4

Dado que tu juego estará basado en turnos, las actualizaciones en tiempo real no son súper importantes. La forma más fácil de hacer esto es usar un servidor ya construido, iría con un servidor web. Cualquier plataforma que valga la pena portar su juego debería facilitar el acceso a los servicios web ubicados en un servidor web.

Para proporcionar actualizaciones casi en tiempo real, le recomiendo que busque encuestas largas. El código en ese enlace proporciona la implementación más básica de sondeo largo desde el lado del servidor. Pero la conclusión es que una vez que se realiza una solicitud a un recurso, el servidor ejecuta una llamada de bloqueo hasta que los datos solicitados estén disponibles. Luego repite el proceso una y otra vez.

En términos de qué datos debe enviar, trate siempre al cliente como hostil. El cliente debe enviar cualquiera que sea su "estado de giro", el servidor lo valida y luego, si todo se verifica, envía el nuevo "estado de juego" a todos los clientes conectados.

-

Los servicios web SOAP son probablemente el mejor lugar para comenzar ( enlace ), son fáciles de comenzar y la mayoría de los marcos web proporcionan un método para exponerlos. También es posible que desee ver los servicios RESTful, pero generalmente dejan un poco más del proceso de serialización al consumidor.

Para consumir servicios web SOAP en Android, buscaría aquí .

Nate
fuente
Hola y gracias por tu respuesta. ¿Pero todavía no entiendo cómo enviar datos a mi servicio web? ¿Cómo serializar la entrada del usuario (aquí un movimiento en mi tablero 8 * 8, por ejemplo: jugador 1 de [0,0] a [1,1]) y luego cómo serializar el estado del juego?
Cirilo
Verifique los dos enlaces que agregué. Deben ayudarlo a comenzar con los servicios web SOAP, que es probablemente la forma más sencilla de comenzar.
Nate
Para Android e iOS no debería necesitar usar encuestas largas. Las notificaciones push de Apple o la mensajería en la nube de Google le permitirán enviar datos del servidor a sus dispositivos.
Matt,
2

Creo que usar SOAP o incluso HTTP es excesivo. Simplemente defina su propio protocolo sobre conexiones TCP de vainilla. Por ejemplo, interprete cada línea de texto enviada como un comando. Defina qué comandos / respuestas puede enviar el cliente y el servidor.

FICS funciona de esa manera y ha estado sirviendo a miles de jugadores de ajedrez durante muchos años. IRC también funciona de esa manera (ver RFC 1459).

mdm
fuente
HTTP ofrece varias ventajas, sin embargo: se puede usar proxies, es casi nunca un cortafuegos, que ofrece cifrado casi transparente mediante HTTPS, tiene varios métodos de autenticación ...
Sam Hocevar