Algo Sobre Juegos Web

[chechocossa]

 josepzin me consultó sobre ciertos aspectos del desarrollo de juegos para navegador.

Me parece que es bueno crear un hilo para responderle sobre mi experiencia y de paso que los interesados aporten lo suyo.

Yo hice un juego para navegador hace un año y medio atrás aprox.

Estaba hecho en C# y ASP.NET, usando SQL Server como base de datos.

Tenía un universo persistente y soportaba cualquier cantidad de conexiones... cuando los hacen las grandes firmas, a esos juegos se los suele llamar MMORPG  :P  Yo llegué a registrar más de 1000 jugadores diferentes (sin contar las cuentas múltiples)
Hubo días pico de más de 100 usuarios simultáneos.

Con ASP.NET creaba las páginas divididas en 2 archivos, el de presentación (puro HTML y algo de js) que es lo que baja el cliente y el code behind, que era toda la lógica del formulario. Eso era en lo referente a formularios web, pantallas de lo que sea, etc.

También tenía las clases de negocios y las de acceso a datos. Esas clases estaban todas alojadas en el servidor.

Para el acceso a los datos, usé siempre las Stored Procedures de SQL Server, es decir, nunca utilicé líneas de código para formar una sentencia de acceso a datos. Esto ganó en seguridad, velocidad, estructuración y demás. Fue además la decisión que me llevó a utilizar SQL Server. En esos momentos MySQL no soportaba procedimientos almacenados... los soporta ahora?

josepzin me pregunta si debe haber una app corriendo en el servidor. Pues yo no tenía nada de eso. Estaban las clases de lógica, pero nada "corriendo" en el sentido que lo hubiera puesto a marchar para que el juego sincronice o algo así.
Las páginas viajaban entre el cliente y el servidor, pasaban datos como parámetros a las clases de datos que los enviaban a las S.P., las clases de negocios cumplían su lógica y volvía el formulario con los datos actualizados de lo que fuera.

En realidad fue una experiencia fenomenal. Lidiar con las deficiencias y limitaciones de los navegadores  (grrr) , más las trampas de los jugadores  :D
Lamentablemente, las bases de datos y el tráfico crecieron ( nunca pensé que 10 MB de espacio para datos se fueran tan rápido ), por lo que el servidor gratuito me pidió cortesmente que me dedicara a otra cosa...

Ahora, estoy con una idea similar en lo referente a la conectividad.

Estoy haciendo un juego 3D, con un cliente liviano de no más de 30 MB. También en C#. Como no es un juego de alta acción, para mantenerlo online utilizo web services con HTTP. Con una respuesta promedio de unos 800 milisegundos es suficiente para mis necesidades y son sumamente fáciles de programar y mantener.

Saludos a todos.

[josepzin]

 Gracias por responder! :)
La verdad es que el tema me queda un poco "grande" todavía, pero de a poco tengo ganas de aprender algo.

Sobre la aplicacion corriendo en el servidor, no entiendo como NO puede haber una aplicacion que se encargue (por ejemplo) de seguir restando recursos mientras nadie esta conectado.

El juego http://ogame.com.es (a raiz de esta pagina me entró la duda) entiendo que debería existir una aplicacion en el servidor que "mantenga" el juego en marcha. Por ejemplo, me conecto, lanzo un ataque y me desconecto. Si no existe una aplicacion que gestione el desarrollo del juego, cuando me vuelva a conectar un par de dias despues, ¿que pasa con ese ataque que inicié?

Ademas decis que "Estaba hecho en C# y ASP.NET, usando SQL Server como base de datos.". ¿Para que usaste C#?

Quizas mis dudas son tonterias, pero no lo tengo claro...  :blink:

NOTA: aprovecho a hacer extensiva la invitacion a participar en ogame, hace 1 semana que me registré por la invitacion de un usuariode 3dpoder y ahora ya somos unos cuantos 3dpoderianos en la alianza ABUELA ;),  si alguien quiere agregarse, soy Ungor, del planeta Parvati, en el Universo 8... (mas friki no puede sonar esto!!) Para mas info visitar este hilo: http://www.3dpoder.com/foro3dpoder/showthr...ead.php?t=31855

[CoLSoN2]

 

entiendo que debería existir una aplicacion en el servidor que "mantenga" el juego en marcha. Por ejemplo, me conecto, lanzo un ataque y me desconecto. Si no existe una aplicacion que gestione el desarrollo del juego, cuando me vuelva a conectar un par de dias despues, ¿que pasa con ese ataque que inicié?

Podría haber una aplicación corriendo en background, o lo más probable, es que todas esas acciones que tú hagas se guarden en una base de datos, y en algún momento del día (o en varios) se ejecuten todos las acciones almacenadas en el orden en que se ejecutaron. En muchos hostings web te permiten tener "cron jobs", que es precisamente esto, especificar una frecuencia en la cual quieres que se ejecute una cierta tarea, que puede ser un programa en C o un script PHP o lo que quieras.

[zupervaca]

 para mantener un juego web en marcha guarda en una base de datos todas las acciones no inmediatas que van haciendo los jugadores y cada vez que alguien realice una accion inmediata debes de mirar los registros, realizarlas y eliminarlas

[chechocossa]

 josepzin, usé C# porque lo venía utilizando desde las primeras betas para soluciones simples de escritorio.
Utilizarlo para ASP.NET fue algo natural y obtuve gran facilidad y ganancia de tiempo de desarrollo. Como siempre, hay gente a favor y en contra de esa plataforma. Pero contar con un framework sumamente rico, me resolvió infinidad de problemas.
Además del beneficio que es el tener toda la lógica del juego en clases en el servidor, dejando sólo la "presentación" en el cliente.

Como afirman CoLSoN2 y zupervaca, yo almacenaba todo lo "pendiente" (que no era mucho en mi juego) en bases de datos. Aprovechando las distintas conexiones de los usuarios, iba ejecutando tareas que estaban en cola.

Al juego Ogame lo estuve probando hace un tiempo. Pero a los pocos días lo dejé. Supongo que ya lo habrán arreglado... pero sin dudas que tenía fallas de seguridad, ya que había récords y puntajes imposibles.
Me inscribí justo al inicio de un universo y al día siguiente ya tenía varios que me triplicaban en puntaje ( y no soy novato en esto  ;)  )

Y hablando de esto, toco el tema que más dolores de cabezas me dio al hacer CyborgLand (así se llamaba mi juego  :( ) "LA SEGURIDAD"
Los navegadores tienen muchas deficiencias y los jugadores SIEMPRE tratarán de aprovecharse de eso... Desde el uso de F5 para recargar páginas, el backspace, el pasaje de parámetros a través de la URL... bue,  de todo.
Hay que ver la paciencia que tienen algunos para buscar errores  :P

La verdad, infinidad de anécdotas para contar en esos meses que estuvo online.

Saludos!

[josepzin]

 

Como afirman CoLSoN2 y zupervaca, yo almacenaba todo lo "pendiente" (que no era mucho en mi juego) en bases de datos. Aprovechando las distintas conexiones de los usuarios, iba ejecutando tareas que estaban en cola.

Al principio tambien lo pensé de esa manera pero me pareció un poco raro...

¿Sería algo asi:?
- Nadie conectado
- Jugador A se conecta.
- Jugador A ataca a B.  Queda grabada la orden de ataque en alguna parte.
- Jugador A se desconecta inmediatamente.
- Nadie conectado
- Jugador C se conecta. ¿Aqui seria cuando se procesa el ataque de Jugador A contra B?

chechocossa, me llama la atecion lo de usar C# porque yo lo relaciono con codigo de bajo nivel, que tiene como objetivo generar un archivo EXE. En cambio tanto ASP como PHP solo es texto. ¿Como sería la cosa?

[vincent]

 Los ASP.Net los puedes programar tanto en Visual Basic .Net como en C#. Así que supongo que chechocossa se encontraria más cómodo con C# y tiraria por allí... vamos, digo yo :P

[zupervaca]

 la ventaja del c-sharp es que sirve como lenguaje web, cuando c se conecta si que podrias procesar el ataque de b contra a, aunque si atacar es una accion que se hace directamente podrias ahorrarte el incluirlo en la base de datos a no ser que sea un juego por turnos 100%

el procedimiento si es un juego por turnos es que cada vez que un usuario realice una conexion al servidor (es decir, cada vez que el usuario solicite una pagina web) se procese todos los registros de la base de datos, puedes hacer un include del archivo que realice esto junto la comprobacion de si esta conectado o no en todas las paginas web que se tengan acceso, de esta manera el procedimiento nunca fallara ademas de que resolveras problemas de seguridad

[chechocossa]

 josepzin, es tal cual lo dice zupervaca.
Claro que hay muchas variantes dependiendo de las acciones y tipos de juegos.
En el mío, un ataque entre robots se resolvía en forma inmediata. Ejemplo:
- RobotA encuentra a RobotB y decide atacarlo.
- Le da al botón Atacar, la página viaja al servidor con esa acción.
- Se calcula el desarrollo del ataque y gana RobotA.
- Se actualizan los datos de RobotA y RobotB, si hubiera sido un ataque que generara algún récord, se actualizarían esos datos. Además de rankings, y varios etc.
- A RobotA le regresa inmediatamente toda esa info y sigue jugando.
- A las horas se conecta RobotB, antes de bajarle la info, se leen las bases de datos y el pobre player se entera que RobotA le dio una paliza...
- Pero si RobotB hubiera estado conectado, recién cuando haga alguna acción y viaje la página al servidor, cuando ésta regrese, se enterará que fue atacado.

Por otra parte. Con c# puedes programar muchas cosas. Aplicaciones windows, que generan un exe. Aplicaciones DOS, DLL´s y demás.
Cuando lo usas para ASP.NET, te genera una aplicación con extensión dll que no es de las dll tradicionales. Este archivo se sube al host que ejecuta el framework .NET y corre esa dll.

Y ya que estamos con el tema del host... La combinación .NET y SQL Server es la que necesita de los hostings más caros...  :angry:

Saludos!

[josepzin]

 De a poco se me van aclarando las ideas. Pensaba que era imprescindible un programa en el servidor que gestione el juego.

Lo de ASP.NET me marea un poco porque no conozco nada del asunto.

Por ahora estoy aprendiendo PHP/MySQL.

A ver si nos contas algunas de esas "anecdotas" de seguridad, ademas de dar consejos para manejar ese tema.

[chechocossa]

 Bueno, seguridad... y aprovechamiento de bugs por parte de los players  :P

CyborgLand fue mi primer intento de poner un juego online, así que sin dudas gran parte de lo que voy a poner es obvio para muchos... pero para los que se inician...

Paa que se entienda de qué se trata, cuento un poco lo básico del juego (antes que nada, aclaro que la idea fue una copia bastante parecida a MonstersWar, el cual había desaparecido unos meses antes... )

Controlabas un robot, el cual pertenecía a una alianza de hasta 15 jugadores.
En la pantalla principal, veías los indicadores de estado (energía, fuerza, cansancio, daño, etc), otros datos generales y el mapa del terreno, que eran "imagebuttons" en los que hacías click para moverte.
En cada sector, aparecía una lista de los robots posibles de ataque. Apuntabas a uno dentro del rango permitido y listo. Se efectuaba el combate.
Había otras pantallas del laboratorio, donde se investigaban armas y defensas.
El robot podía llevar armas, armaduras, y demás. Éstas se fabricaban o compraban en un mercado. También las levantabas de las que se perdían en los combates.
El juego era por turnos. Ganabas 8 turnos por hora. Moverte costaba un turno. Combatir, 4 turnos. Recuperar estados, 1 turno. Y todo así.
Había foros privados para la alianza.

En definitiva, sencillo pero muy adictivo.

Todavía está el viejo foro CyborgLand donde aún entran ex-jugadores a preguntar cuándo lo pondré otra vez en línea  <_<

Veamos...

- Lo primero que aprendí con la práctica: Si hay un bug, este será encontrado (y explotado) por los players a los pocos minutos que subas el juego. No importa cuánto lo hayas probado. (Suena a Murphy, pero es cierto)

- Cadenas de comandos para SQL. Yo nunca las usé, porque me manejé con las SP de SQL Server. Pero en el caso de MySQL no tenés eso (que alguien me diga si ya las implementaron!!) Aquí hay que controlar todo lo referente a SQL inyection. En google hay info.

- Control de la tecla F5 en el IE ( no sé en el FF porque no lo uso ) para recargar las páginas, al igual que la de BackSpace:
Enseguida de comenzada la beta pública, aparecieron cyborgs que eran atacados varias veces seguidas, con pocos segundos de diferencia...
Cuando le dabas click a iniciar un ataque, y enseguida varias veces a F5, el servidor no alcanzaba a procesar y devolver la página, por lo que podían repetir los ataques.
Puse código javascript para evitar esto, pero según las configuraciones de los navegadores, por ahí el js daba error e igual se repetían los ataques.
Finalmente, creé una rutina que leía la BBDD y verificaba la hora del último ataque.

- Apertura de dos o más páginas al mismo tiempo:
Había cyborgs que efectuaban ataques casi simultáneos en distintos lugares del mapa  :P  Como la unidad de medida era el turno, de esta manera recorrían más distancia con el mismo costo. También solucionado mediante control por la DDBB.

- Error de diseño, o falta de comprensión de lo que puede hacer un player entusiasmado:
Una mañana, casi al final de la beta, reviso las DDBB y veo que un escocés que jugaba en una alianza de las más avanzadas, tenía unos 200 turnos acumulados. Imposible. Como no pude encontrar trampa alguna, lo intimé por privado a que me dijera qué pasaba. Como no contestó, eliminé su cyborg.
Al rato, se fue toda la alianza  (nooo) Resulta que el tipo este había estado más de 5 horas la noche anterior, juntando todas las armas basura por el piso, caminando hasta el mercado y vendiendo... y vuelta a juntar... Moraleja: nunca subestimes las ganas de jugar que puede tener alguien  :P

- Aperturas de multicuentas:
Llegué a verificar alianzas de 12 jugadores... que eran de la misma persona  (grrr) ( y no era el escocés!!!! )
Casi imposible de controlar esto. Las IP fijas vaya y pase... pero las otras... además, si bloqueás por IP, anulás a los que juegan en cybers, facultades, etc. Ejemplo: Una alianza de 10 jugadores, pertenecían todos a la misma oficina que salía por el único router(IP)
Al final, creé un sistema que hacía referencias cruzadas, entre nombres de cyborgs, passwords, IP´s, alianzas, etc... esto me filtraba bastante a los tramposos. Por ello... NUNCA les creas cuando dicen que las 5 cuentas que pertenecen a la misma IP son: el hermanito, la hermanita, el primo, la tía y un amigo  :D

Bueno... hubo mucho más... pero esto se hace demasiado largo...  :huh:

Finalmente, todo lo anterior parece demostrar que los players son tus peores enemigos. Esto no es así. Sólo que ellos no pueden resistir la tentación de ganar a cualquier costo  (twist)

En realidad, hice muy buenos amigos (casi todos españoles) que colaboraron y mucho en mejorar el juego.

Tal vez... tal vez... este nuevo proyecto que estoy haciendo, tome rumbo a un nuevo CyborgLand... ya veré.

Saludos!

[josepzin]

 Gracias por toda la informacion! Ya seguiré preguntando :)

[TonyJ]

 Wenas,

yo llevo ya tiempo inmerso en el desarrollo de un sistema de juego para web, y la verdad que bastante complejo.

Lo de las artimañas que utilizan los jugadores para alcanzar con mayor rapidez sus objetivos si que son un quebradero de cabeza.

Yo lo estoy haciendo con PHP y MySQL, y aunque en su versión 5 ya creo que admite Stored Procedures no es algo que vaya a utilizar, al menos en una primera versión... Tal vez cambien de opinión cuando comiencen los problemas  :P pero hay que dar opción a que todos los usuarios puedan utilizarlo en sus servidores gratuitos que difícilmente están actualizados.

Me ha llamado especial atención lo que comentan de un pequeño programa que gestione constantemente las acciones pendientes de realizar.
Esto es algo que también me ha dado (y me da) bastante que pensar, pero todo depende de cómo se plantee.

En mi caso no es por turnos, sino en tiempo real, pero igualmente existen eventos que tienen que realizarse cada cierto tiempo.
Pero eso es controlable almacenando esos eventos en la base de datos por orden cronológico de ejecución. Cuando alguien realiza una acción, como moverse, que es la más común, se comprueban los eventos pendientes y se ejecutan en caso de que haya llegado el momento (puede haber eventos que se vayan a ejecutar dentro de 1 o 2 dias, o unas horas). Pero si hace tiempo q no se conecta nadie para jugar, los eventos se acumulan, pero esa comprobación y ejecución puede también realizarse en el momento en el que un jugador accede al juego.

Es cuestión de pensar detenidamente la solución, pero no lo veo tan complicado.

Yo creo que el problema de algunos de estos juegos es que se ejecutan acciones sobre jugadores que no están online, lo cual me parece un abuso, ya que siempre habrá gente que pueda estar jugando varias horas al día o a la semana, mientras que otros sólo podrán conectarse un par de veces al mes, o incluso menos.
Digo que lo veo un problema porque si almacenan esos eventos para ser ejecutados cuando llegue el otro jugador, posiblemente tenga un montón de tareas pendientes de ejecutar, lo cual no me parece muy lógico.

Pero como decía, todo depende del juego y en definitiva, de una serie de factores que cada uno tendrá que tener en cuenta a la hora de desarrollarlo.

En cualquier caso yo no veo especialmente útil en un juego por web una aplicación corriendo en el servidor, siempre y cuando no sea un Applet de Java, un Flash o un Director.
Pero repito, todo depende del juego.  ;)

Saludos  :rolleyes:  

[zupervaca]

 hay algo que no logro entender y es el fallo del F5 y el turno de atacar, si es por turnos ... ¿como es que le dejas atacar dos veces seguidas? para solucionar esto cada vez que un jugador realiza su turno debes de comprobar si efectivamente ha llegado su turno, si es su turno a la base de datos, si no pues mensaje diciendo que no es su turno

utilizar javascript para realizar comprobaciones de seguridad no sirve ya que el javascript se ejecuta desde el navegador y puede ser modificado, la seguridad tiene que estar en el lenguaje web que corre en el servidor, ademas en los servidores actuales cuando se solicita una web (php, asp, etc) hasta que no termina de procesar ese script no permite mas solicitudes ya que si esto no fuera asi y dos scripts accedieran a la base de datos el resultado podria ser catastrofico

[chechocossa]

 zupervaca, por eso aclaré que fueron mis inicios en juegos web on line, hace ya más de 2 años... todo eso fue corregido con el aprendizaje.

En lo del F5, no es que el juego fuera por turnos de jugar una vez cada uno. Las acciones a emprender, costaban turnos. Los turnos se te entregaban por tiempo. Por ejemplo, al día ganabas unos 100 turnos, que si los sabías administrar, te permitía jugar un buen rato.

El problema de F5, es que al ejecutarse varias veces seguidas (antes que lo corrigiera) dejaba al oponente con varios K.O. lo que le costaba puntos y muchos turnos en recuperarse.
El que hacía la trampa se gastaba unos 20 turnos, pero ganaba un montón de puntos. Además que evitaba tener que caminar buscando enemigos.

Lo de F5 lo aprendí por los propios jugadores que me avisaron del truco. Con el tiempo, lo pude "probar" en varios juegos web que no lo controlaban correctamente (ni lo hacen ahora, algunos)
(sólo con fines de investigación  ;) )