Ultimamente me ha picado un poco el tema de programar juegos online en PHP pero me está resultando más costoso de lo que pensaba.
Mi principal problema es que parto del esquema clásico que uso en C++ y veo que de poco sirve. Me cuesta aplicar conceptos antiguos a este contexto, cosas como patrones, o las clases mismamente.
Me gustaría encontrar información al respecto, errores más comunes, métodos para sacar el máximo partido al lenguaje,etc. Ojo que no quiero tutoriales de PHP ya que llevo varios años trasteando con el lenguaje y he hecho más de una web en él, pero hacer webs y hacer juegos (aunque esten dentro de una web) tienen poco que ver.
Quiero saber como lidiar con la concurrencia, como trabajar con clases sin que se creen y se destruyan en cada petición, etc.
Si alguien puede recomendarme un link, un libro o algun buen consejo se lo agradeceré.
Juas, yo estoy creando un juego de estrategia en php, aunque tendrias que ser mas especifico en lo que quieres exactamente
Pues principalmente el problema de como organizar el "engine", ya que no puedo hacer lo clasico de tener mil paginas desperdigadas por phps e ir llamando de una a otra.
He comenzado a usar clases pero tengo el problema de que se instancian y se destruyen en cada petición, y eso me parece una burrada. Se pueden meter las instancias en la sesión?
Existe alguna manera de crear instancias estáticas que se queden en memoria entre peticiones y que sean comunes a todos los usuarios? (supongo que no pero por pedir...)
Otro problema que tengo es la concurrencia, como en cada petición necesito todos los datos pues hago muchos querys a la DB para sacarlos. He pensado dejar esos datos en la sesión pero entonces tengo el problema de que si otro usuario hace algo que altera los datos de los demás entonces debería actualizar todas las sesiones, como gestiono eso? con algun tipo de pool de eventos?
En fin, ese tipo de cosas.
yo tb estoy en ello, y a mi las dudas me surgen a la hora de hacer un update o insert a la BD en el script o página correspondiente.
Hacerlo no es el problema, si no que a mitad "de carga" de página (cuando php está esperando a la BD) podrían hacer un F5 o actualizar y volver a mandar la peticion al servidor, o cosas así, con lo que se haría el insert/update otra vez , en los selects esto daría igual.
se podría hacer una tabla con acciones pendientes (lo que llamais pool de eventos?) en vez de los inserts a saco, pero meter una acción es un insert tb no?, php controla que un script empiece y acabe enteramente?, supongo que las sentencias a DB si que son "atómicas"...
Bueno, para lo que tu comentas basta con que cada acción tenga un identificativo unico (por ejemplo el milisegundo en que se envio el código html al navegador), antes de realizar una acción miras si en la sesión la variable "ultima_accion" tiene el mismo valor, sino lo tiene pues sobreescribes y realizas la acción, pero si es igual pues significará que era un refresh.
Ese sistema se puede complicar más si quieres evitar que el boton Atras pueda traerte el problema, pero vamos, la idea es la misma.
para que veais de que va
http://www.xalee.com/worldconqueruser:prova
pass : Contactar con migo si quereis saber como es
Para que el usuario haga "cosas que no debe" como ir para atras (ya sea mediante la flecha del navegador, el alt+flecha derecha, etc), ver el codigo fuente, etc se pueden capar tanto determinadas pulsaciones de teclas como el boton derecho del raton. Tambien se puede abrir la pagina en una ventana del navegador sin barra de herramientas ni opciones del menu.
Por muchas cosas que quieras evitar que haga el usuario, por mucho Javascript que escribas y por mucho que lo intentes, no podrás evitar que el usuario trate (y consiga de algún modo) de hacer esas cosas.
Una buena programación evitará que el ir hacia atrás y cosas parecidas sean sinónimo de hacer trampas, y podrás conseguir controlar cosas puntuales en cuanto al funcionamiento del juego, pero no del navegador.
De nada te sirve evitar que te saquen el código fuente (al fin y al cabo es sólo HTML lo que van a ver), o capar pulsaciones de ratón, o abrir una ventana del navegador sin controles (pulsa F11 en una de esas ventanas a ver qué pasa). Por cada truco que uses para "capar" una acción, habrá otro o más para saltárselo.
Céntrate en lo que al funcionamiento del juego se refiere, no al funcionamiento del navegador. Además... ¿cuántos navegadores hay?
Volviendo al tema del thread, nadie sabe nada de donde conseguir información sobre creación de sistemas complejos sobre php? optimizaciones etc.
hace unos dias lei en un libro sobre implentacion de webservices con php y soap:
Citar
en principio, cada vez que se invoque a un servicio web creado con php mediante la clase SoapServer ésta creará un nuevo objeto de la clase indicada con setClass(), lo cual significa que dicho objeto no podría mantener un estado entre llamadas consecutivas a sus métodos. Es algo que podemos modificar mediante el método setPersistence() de SoapServer entregando como argumente una de las dos constantes siguientes:
-SOAP_PERSISTENCE_REQUEST:
se crea un objeto en cada solicitud, no manteniéndose información de estado entre solicitudes.
-SOAP_PERSISTENCE_SESSION:
se crea un objeto con la primera solicitud y se mantiene su estado mediante variables de sesión, de tal forma que el objeto mantendría dicho estado entre llamadas.
Utilizando SOAP_PERSISTENCE_SESSION podríamos, por ejemplo crear un servicio web que abre una conexion con una base de datos cuando se invoca al primero de sus métodos y la mantiene en llamadas posteriores, hasta el momento en que el usuario cierre la sesión.
es decir, si es un webservice y usas soap, la clase que contiene los métodos puede estar persistente.
No he mirado más pero debería existir algo para clases "normales".
he visto algun libro en emule y por internet en google tambien hay,ahora mismo no recuerdo.
Por otro lado el tema de que el usuario vaya hacia tras y todo eso, en mi caso todo eso da igual, lo mejor es jugar con las bases de datos, en mi caso por mucho que le den, el servidor es el que manda. Una buena programación o planteamiento de que quieres hacer y que ellos no puedan hacer, es lo que ara que no puedan hacer cosas raras.
Hay un PHP Game Programming pero es una basura, te explica qué es el HTML, como se programa en PHP, como se conecta a una base de datos y cuando dices - ahora se mete en lo interesante - va y te sale con "como usar sockets", "como pintar imagenes" y "como crear un flash desde PHP", FIN
Yo busco algo que parta de que ya sabes mucho de PHP pero que nunca has programado nada medianamente grande.
Bueno, lo primero creo que es preguntarte hacia donde quieres enfocar el juego. Lo más típico es que quieras hacer un clon de "Alliance Wars", "Ogame", "Travian", "Vendetta", etc. Lo que hacen estos juegos es tirar sobretodo de base de datos, algunos quizás tengan una aplicación externa en python para actualizar los ticks, pero básicamente lo importante es organizar la base de datos (porque con una buena programación no te hará falta actualizar ticks desde fuera) y no creo que necesites comerte la cabeza pensando en estructuras, variables, clases ni demás.
Y las sesiones para identificar a los usuarios y poca cosa más. En realidad es más curre de ideas, cálculos, tiempo y (me repito, lo sé) formar una base de datos buena, más que de estructura de programación.
Bienvenido Parzival!
Parece que conoces del tema...
yo creo que no.
ya se supone que tienes bien el diseño y programación de la lógica, y base de datos, pero después hay cosas como evitar que te hagan trampas, y como las que comenta tamat como la gestión de threads, gestión de clases en memoria o permanecia etc.... y es verdad que no se encuentra nada por google, sólo lo típico para empezar (php con mysql, o con flash, o hacer graficos con GD etc...), no hay nada para grandes cosas, ni tips sobre optimizacion, ni sobre las tipicas trampas... etc
a mi lo único que se me ocurre para evitar que te corten la ejecucion del php a mitad (y las setencias sql), es usar los procedures del mysql5
No sé, yo la verdad no lo veo tan complejo. Por ejemplo, en los juegos que puse en mi primer post, al construir un edificio no te deja construir ninguno más y no hay manera de hacer trampas, guardas en la base de datos la hora a la que empezaste a hacer el edificio y comparas la diferencia de la hora actual con esa, si no sobrepasa el valor mínimo para la construcción del edificio sigues sin poder hacer nada más...
Si no, otra manera de hacerlo para que no te dé problemas el botón "atrás" es utilizar AJAX, la base de datos se actualiza sin tener que llamar a una página nueva. Pero aún así creo que el tema está en organizar bien la base de datos, que por mucho que abuses de ella en estos juegos y aunque parezca lo contrario, la verdad es que no hay ni la mitad de movimiento de datos que puede haber en un foro como este.
* Josepzin: gracias, y saludos a todos!
yo por ejemplo utilizo ajax en segun que sitios (registro, login...) para evitar un poco eso, llamadas innecesarias a paginas, aunque si alguien quiere hacer trampas las hará, ya que se puede ver a que fichero se llama en ajax, y volver a reproducirlo fuera del contexto del juego.
Lo de las construcciones está claro, lo haces por tiempo, pero como solventas el tema de por ejemplo comprar algo "instantaneo"?, es decir haces pulsas un link y te dan 1 unidad y te quita lo que sea de dinero. Es un script que en teoria es llamado una vez, si te hacen F5 a mitad de carga de pagina sabe dios lo que pasa...en el mejor caso te dan 2 unidades y te descuentan 2 veces el dinero,pero pueden salir cosas raras...
Citar... pero como solventas el tema de por ejemplo comprar algo "instantaneo"?, es decir haces pulsas un link y te dan 1 unidad y te quita lo que sea de dinero. Es un script que en teoria es llamado una vez, si te hacen F5 a mitad de carga de pagina sabe dios lo que pasa...en el mejor caso te dan 2 unidades y te descuentan 2 veces el dinero,pero pueden salir cosas raras ...
Tampoco es tan complicado controlar eso en un script, tan solo tiene que hacer algo parecido a esto:
1.- Recoges los parámetros mandados al script. (Uno de los cuales es la IP del ordenador que ha hecho la llamada al script y otro la fecha/hora del momento en que hizo la llamada).
2.- Abres conexión con la base de datos.
3.- Compruebas si para esa IP, esa fecha/hora se encuentra en la Base de datos.
4.- Si se encuentra en la BD y la fecha/hora para esa IP es mayor a la de la BD, se guarda la fecha recibida en el parámetro, en la base de datos:
5.- Se hacen el resto de acciónes (dar 1 unidad y quitar x dinero).
6.- Si para la IP recibida, la fecha/hora recibida no se encuentra en la Base de datos, no se hace nada.
7.- Se cierra la conexión con la base de datos.
8.- Se devuelve el código HTML de la página de respuesta al navegador.
Como las ejecuciones de los scripts en php se ejecutan en el servidor y no se pueden cancelar "a la mitad" una vez se ha llamado al script. (si se llama dos veces al mismo script lo que ocurre es que se ejecutará completamente 2 veces en el servidor).
De modo que si en algún momento se pulsa F5 en el navegador, ocurrirá que como los parametros recibidos por el script son los mismos que en la primera llamada y como en la primera ejecución ya se ha guardado esa fecha/hora para esa IP en la base de datos, no se hará nada y se devolverá la página sin hacer dos veces la misma acción, a efectos del juego.
No sé si me explico bien, pero creo que más o menos la idea se entiende, no? :P
Citar
4.- Si se encuentra en la BD y la fecha/hora para esa IP es mayor a la de la BD, se guarda la fecha recibida en el parámetro, en la base de datos:
5.- Se hacen el resto de acciónes (dar 1 unidad y quitar x dinero).
6.- Si para la IP recibida, la fecha/hora recibida no se encuentra en la Base de datos, no se hace nada.
gracias redhan, pero creo que el 4 y el 6 van al reves no?
4-si se encuentra, no se hace nada (ya se ha hecho antes),
6-si no se encuentra, se hace y si guarda esa fecha/ip
ya imaginaba algo asi, pero yo creía que php si se puede parar a mitad de ejecución... :P
cierto, el 4 y el 6 van al revés. Me despisté :P
Cita de: "RedHan"1.- Recoges los parámetros mandados al script. (Uno de los cuales es la IP del ordenador que ha hecho la llamada al script y otro la fecha/hora del momento en que hizo la llamada).
2.- Abres conexión con la base de datos.
3.- Compruebas si para esa IP, esa fecha/hora se encuentra en la Base de datos.
4.- Si se encuentra en la BD y la fecha/hora para esa IP es mayor a la de la BD, se guarda la fecha recibida en el parámetro, en la base de datos:
No sería mejor cambiar lo de IP por el login del tio y compararlo con una variable de sesion (por ejemplo $_SESSION['s_login']) iniciada con el login cuando se registra en el juego? Más que nada por si estoy haciendo un edificio que tarda 5 horas y me desconecto y me conecto en el curro, la ip va a ser distinta... Además, lo de la fecha/hora va bien si tienes una conexión rápida que nada más mandar los datos ya te cargue la página o/y si el servidor no está saturado y no deja el proceso en una cola. Porque si no siempre te va a dar que la fecha/hora va a ser distinta, aunque sea por un segundo. En cualquier caso el problema estará en el cliente por hacer el gañán al querer hacer trampas refrescando la web, y gastará el doble de material, en realidad no va a poder hacer trampas de ninguna manera.
En definitiva, todo eso es a lo que me refería yo, pero cuando dijo jazcks de hacer la actualización de la base de datos por procedures empezaba a dudar si el php se pararía a mitad de ejecución, cosa que al final descarté por parecerme ilógico: ¿cuántos miles de páginas están alojadas en un sólo servidor y tirando todas de php continuamente?
Salu2
A mi el tema de controlar que el usuario no se dedique a pasar parametros o hacer refresh no me preocupa tanto. Existen muchos metodos, yo por ahora uso el de tener campos ocultos con identificativos en cada posible acción (tanto si es form como enlace), y cuando le planteo al jugador una posible acción meto ese identificativo en la sesión, cuando el jugador realiza una acción chequeo el id que recibo junto con la acción, si ese id ya lo usó antes entonces es un refresh (o algo peor) y la nueva acción queda descartada, si el numero se lo ha sacado de la manga (rollo poniendolo a mano) lo detecto porque no está en la sessión así que no hago la acción y le doy un toque.
Esos numeros los puedo ir generando y guardando en la sesion con algun atributo asociado que diga si está usado o no. Es un metodo simple pero no veo como podría ser saltado. Además no tengo que preocuparme de controlarlo en cada parte, basta que el codigo encargado de pillar los request lo tenga siempre controlado y listos.
Volviendo al topic, a mi me preocupa más reescribir mucho código. Actualmente tengo varios phps con clases genericas, por ejemplo tengo un sistema de modulos, son clases que se instancian en cada petición (intento que sean lo más ligeras posibles) y al hacerlo se autoregistran en un array, despues chequeo el REQUEST y en función de los datos que recibo el sistema determina a qué modulo va dirigido el mensaje y se lo envio. Luego el modulo puede generar una salida y almacenarla en otro contenedor.
Despues con esos datos monto la página. Es un metodo que me permite agregar nuevas funcioanlidades sin necesidad de tener que cambiar más que las cuatro lineas que anclan el módulo al sistema.
Cosas así son las que yo necesito. No quiero tener 40 phps, ni phps kilometricos con cientos de peticiones. No quiero tener querys SQL por toda la aplicación, de hecho uso un sistema FACADE para acceder a la DB que me permite contener bastante los accesos y ahorrarme problemas.
Tambien uso AJAX pero no me soluciona nada, al reves, porque para computar la acción a veces necesito volver a recargar todos los datos y es igual de costoso para el servidor (aunque aquí reconozco que mi problema es no hacer un uso optimo de las sesiones).
Por cierto Parzival, interesante que comentes lo de los ticks, porque es otro problema que no se muy bien como resolver. Solo se me ocurre que cuando se haga una petición si ya ha pasado el tiempo de hacer el tick entonces lo hago y despues computo la petición, pero me preocupa qué pasaría si pasase más de un tick sin que hubiese ninguna petición, o qué pasa si quiero enviar un mail a todos al final de cada día?. Tambien puedo forzarlas con algun proceso desde mi máquina pero me parece un tanto chapucero. A la larga se que lo mejor sería albergarlo en local y tener procesos pero como por el momento me tengo que valer de un host con php pues no hay más remedio.
En fin, lo dicho. Busco ideas que agilicen el desarrollo mediante técnicas avanzadas de programación (patrones, templates, etc).
Para los ticks hoy en día la mayoría de empresas de hosting de pago te permiten añadir tareas programadas. Basta con que te hagas un script en php para actualizarlos y listo. Supongo que es la única forma de poder hacerlo a menos que no tengas un server privado.
tamat, para lo de los ticks, miraté por ahí lo referente a los CRON. Seguro que eso despeja tus dudas.