Hace mucho tiempo hubo un juego basado en la web llamado Utopía (y estoy seguro de que todavía está disponible), los turnos son por hora. Solo obtienes oro / madera nueva o qué, no cada hora.
Algunos juegos basados en web más nuevos tienen recursos que se incrementan en una resolución más fina, como por minuto. Entonces, supongamos que un jugador tiene una tasa de producción de alimentos de 5 por minuto: el jugador aumentará su cantidad de comida cada minuto. No estoy seguro de si es aconsejable configurar constantemente un trabajo CRON para actualizar la base de datos SQL, que supongo que lo están utilizando, ya que está basado en la web. Quizás me equivoque, cada minuto.
¿Qué técnicas usan esos juegos basados en la web? Agregado en Editar: ¿ Y la base de datos puede realmente manejar la carga?
Las bases de datos SQL modernas que se usan comúnmente (MySQL, Postgres, Oracle, MSSQL, etc.) le permiten programar procedimientos almacenados para que se ejecuten con intervalos de tiempo arbitrarios. Es un método muy liviano para ejecutar actualizaciones como esta y elimina la necesidad de invocar un script o programa externo para hacerlo por usted.
Esto también permite que la base de datos optimice la consulta que ejecuta solo una vez, en lugar de hacerlo cada vez que lo invoca un script externo, por lo que es muy útil desde el punto de vista del rendimiento. Por supuesto, esto solo se aplica si sus actualizaciones son lo suficientemente triviales como para ser programadas en el lenguaje de scripting de su base de datos. Las actualizaciones de recursos, las desconexiones automáticas de intervalos de tiempo, la depuración de registros y los gustos son excelentes candidatos para estos procedimientos almacenados programados.
Lo más probable es que la carga que está experimentando su base de datos provenga del 99.9% de las cargas de página, actualizaciones del motor del juego y similares, ya que un juego popular puede tener fácilmente cientos de miles de consultas por segundo. En comparación con la carga que surge de ejecutar algunas consultas (aunque las que tocan gran parte de una tabla) una vez por minuto, la carga no debería ser un problema. Es decir, a menos que actualice los valores indexados por la base de datos. Debe evitar actualizar las columnas indexadas a toda costa si le preocupa el rendimiento.
fuente
En cuanto a las actualizaciones:
Algunos usan trabajos CRON que llegan a una determinada página PHP de vez en cuando.
Algunos usan trabajos CRON, esta vez ejecutando cierto proceso.
Otro enfoque es hacer actualizaciones 'justo a tiempo': cada vez que se carga una página, ejecuta las actualizaciones pendientes y realizalas en ese punto. Generalmente, esto es lo que debe hacer si no puede ejecutar trabajos CRON o procesos de larga duración.
Finalmente, otros ejecutan toda la aplicación web como un solo proceso, por lo que pueden actualizarse cada vez que lo vean.
El sistema final es el mejor si tiene esa opción disponible, ya que puede almacenar los datos en la memoria. Actualizar unos pocos miles de jugadores una vez por minuto es trivial si solo está cambiando datos en RAM en lugar de tener que escribir en una base de datos SQL tradicional.
Pero si no tiene ese lujo, puede usar algún tipo de almacenamiento en caché. Algo como memcached puede ser una opción (dependiendo de su alojamiento) que es un punto intermedio entre la memoria y una base de datos. Puede almacenar valores transitorios en memcache y solo guardarlos en la base de datos cuando sea absolutamente necesario.
Entre memcache y una base de datos SQL tradicional hay otras opciones, por ejemplo. las diversas tiendas de clave / valor o tiendas de documentos: cosas como MongoDB , CouchDB , las ofertas de Amazon o Google, etc. Todos los sistemas bajo el término general NoSQL . Por lo general, estos no le brindan el poder de consulta genérico ni siempre las mismas garantías de seguridad de una base de datos tradicional, pero a menudo son mucho más rápidos en la operación. (Lo cual no es tan sorprendente, ya que están haciendo menos por ti).
Pero todo esto supone que una base de datos normal no puede manejar la carga. De hecho, en la mayoría de los casos probablemente sí. Si tengo que emitir 10,000 llamadas de ACTUALIZACIÓN por minuto para aumentar los niveles de recursos, eso no es muy escalable una vez que comience a agregar todo lo demás en la parte superior. Pero si cambia eso para actualizar el recurso para todos con 1 llamada SQL, de repente las cosas se ven mucho más positivas. Por lo tanto, no sobreestime lo costosa que es cierta característica, ya que a menudo se puede implementar de una manera más eficiente.
fuente
Estoy a favor de KISS : "Keep It Simple, Stupid!"
No veo ninguna razón por la que un trabajo cron no funcione, y la ventaja es que las opciones de alojamiento web baratas a menudo no le permiten ejecutar comandos directamente, pero sí le permiten ejecutar comandos cron. Por lo tanto, no hay necesidad de un servidor dedicado costoso.
También puede hacer su código de actualización en PHP o en su idioma de preferencia, con el comando cron o usando el navegador de texto. Las instrucciones en Configuración de trabajos cron tienen varios comandos de ejemplo que puede usar para hacer ping a su propia página a intervalos.
wget --spider http://yoursite.com/secretphppage.phplynxfuente
Recuerdo haber echado un vistazo al código de un clon de Planetarion. Todo es PHP, pero el código de ticker está en C sin procesar, con enlaces de MySQL en C. Debido a que el modelo de datos era muy simple, las actualizaciones ocurren muy rápido.
fuente