[juegos webs] Mas experimentos y test tecnologicos.

[Capiflash]

Puedes por ejemplo tener un programa "corriendo" en el servidor , revisando la finalizacion de construcciones , la llegada de ataques y demas , o bien , puedes aprovechar las conexiones de los jugadores al entrar , para hacer todo eso "pendiente".

En este hilo se hablo de algo relacionado con este tema  , lo rescato por si ayuda a alguien

http://www.stratos-ad.com/forums3/viewtopic.php?t=5732&highlight=

[Tei]

Una forma seria programar una cola de acciones programadas, el servidor en cada frame no consume toda la cola, solo los eventos "caducados", y en orden cronologico.  Realizado asi, te da igual si entre ejecucion y ejecución ha pasado un segundo, o dos meses.
El problema es que si han pasado muchas horas desde que se conecto un jugador, pues a lo mejor en lugar de consumir 30 eventos, tiene que consumir 3000. Y es mucho mas lento. La velocidad de ejecucion seria irregular, dependiendo de si eres el primero de la mañana, por ejemplo, o eres el segundo (si eres el segundo te va instantaneo).

Asi que parece que es interesante tener una aplicacion corriendo todo el tiempo, que invoque estos frames del servidor. Ademas esta tarea podria realizar labores de mantenimiento.  Suponte que tienes una tabla de precios de productos. Podrias actualizar esta tabla cada 3 horas. O podrias regenerrar los ficheros del mapa como ficheros estaticos. De este modo cuando alguien los descargue, se descargara ficheros estaticos, lo que siempre es interesante.  Enfin, que tener un servidor o tarea corriendo te puede servir para que todo funcione mucho mejor.

No he escrito nada de este estilo. Asi que tampoco me hagas mucho caso.

nota: Si te da por invocar una pagina del servidor desde cron. Estilo wget http://localhost/game/serverframe.php?do=rulea. Ten cuidado y ponlo con limitacion de intentos. "wget -t 1 http://localhost/game/serverframe.php?do=rulea". Sino wget cuando vea que hay un problema,lo hara mas grave pidiendo la pagina una y otra vez hasta que el servidor no tenga CPU suficiente..

[waveland]

Capiflash, interesante el hilo que posteaste.

Añado duda: que creéis mejor, procesar las solicitudes pendientes de la base de datos mediante scripts PHP o bien mediante los cron jobs (primera vez que lo escucho pero supongo que son algo así como tareas programadas, verdad?), o tal vez mediante ambos. La duda me surge porque me da la impresión de que, si se almacenan muchas solicitudes, se puede saturar el servidor? es decir, sabéis donde puede estar el límite mas o menos?

[jazcks]

creo que el límite depende de cómo lo implemente cada uno.
Si las solicitudes están en la base de datos, el cron job puede recoger varias de esas solicitudes cada X tiempo, según el orden en que se grabaron y ejecutarlas.
Si lo programas cada 24horas seguramente tendrá muchas más que hacer que si el job corre cada 1h por ejemplo.
Es decir, no creo que se sature el servidor, las bases de datos están hechas para eso, entre otras cosas para almacenar grandes cantidades.

[Tei]

Capiflash, interesante el hilo que posteaste.

Añado duda: que creéis mejor, procesar las solicitudes pendientes de la base de datos mediante scripts PHP o bien mediante los cron jobs (primera vez que lo escucho pero supongo que son algo así como tareas programadas, verdad?), o tal vez mediante ambos. La duda me surge porque me da la impresión de que, si se almacenan muchas solicitudes, se puede saturar el servidor? es decir, sabéis donde puede estar el límite mas o menos?

cron es un programador de tareas, puedes programarle que ejecute lo que sea con la periodicidad que quieras. Por ejemplo cada viernes, o cada 15 minutos.

osea, es una opcion para hacer lo mismo:
 - o usas un demonio
 - o ejecutas una tarea con una periodicidad X.

El demonio puede ser mas delicado: No te interesa que haya leaks. Seria un desastre que hubiera un bucle infinito. Y tienes que disponer de un modo que si el demonio se muere, se relance. Y deberia ejecutarse al reiniciar el servidor, que se puede resetear solo por razones hardware.

con cron podrias ejecutar una aplicacion php de linea de comandos, o podrias invocar una pagina publica. lo de wget es invocando una pagina publica.

para un juego web hacer labores auxiliares en php tiene la ventaja de que reutilizas toda las librerias de la aplicacion. Sino se haria en Perl o algo asi.

Windows tambien tiene un servicio de ejecucion programada. Y si tienes contratado un hosting barato podria usarse para que tu ordenador invocara una pagina del juego web cada 30 minutos, corriendo asi los frames del servidor.  Y evitando asi la necesidad de un servidor dedicado.
Aunque si se quiere hacer algo serio yo apostaria por PHP5 y MySQL4. Y a lo mejor un hosting barato no te da mas que PHP4 y MySQL3.

[Kr0n]

En general, hacer un daemon no es mucho más complicado, sólo que tienes que hacerlo "mejor" porque va a estar siempre corriendo, y deberías pues tener cierto control sobre si muere (que mande un mensaje o señal cuando muera), logs que genera, etc. Digamos que en comparación con un script auxiliar en cron, el daemon necesita más "envoltorio" alrededor de la misma funcionalidad para controlar ese tipo de cosas.

Hay situaciones en las que un daemon es 100% imprescindible. En el caso de un juego web, no creo que sea tan imprescindible. Pero aquí también juega en tu contra el tema servidor. O tienes servidor propio (o virtualizado), u olvídate de daemon porque te tendrás que conformar con un script ejecutándose en cron.

Y como ya han dicho, si tu aplicación está en PHP, una gran ventaja que tiene hacer el script auxiliar correspondiente en PHP es que puedes reaprovechar toda la funcionalidad de las capas de servicios y de dominio que tengas en tu aplicación/juego. Y eso es una gran baza porque además de ahorrarte tiempo, te aseguras que la arquitectura de tu software se respeta. Sino, pues eliges el lenguaje que mejor te venga, no tiene porqué ser Perl: Python, Shell script (si hablamos de tareas auxiliares de mover/copiar archivos, etc) o incluso una solución compilada en C/C++ (por motivos de velocidad, aunque el cuello de botella lo suele tener la BD, no el script)

[Vicente]

Sino, pues eliges el lenguaje que mejor te venga, no tiene porqué ser Perl: Python, Shell script (si hablamos de tareas auxiliares de mover/copiar archivos, etc) o incluso una solución compilada en C/C++ (por motivos de velocidad, aunque el cuello de botella lo suele tener la BD, no el script)

Yo no tengo mucha idea de juegos web, pero para que el cuello de botella esté en la BD la tienes que estar dando muchísima caña...

Un saludo!

Vicente

[Kr0n]

Si, la verdad es que tenía más en mente una aplicación web con mucha carga (estilo flickr, meneame, etc.) donde la escalabilidad tiene que andar muy afinada.

Al final todo depende de la carga que le metas al juego o aplicación, claro.