Con CRON.

no te hace falta eso. Hay una forma de hacerlo más facil. Calculas el tiempo en el cual se conecta el usuario. Calculas las diferencias de tiempo de login, hora en la cual se actualiza un edificio o como lo tengas puesto, y entonces al cargar la pagina haces antes de mostrar los datos un update con los correspondientes multiplicadores y rates que tengas puestos. Hacer esto sin ayuda "externa" complica el desarrollo, a parte de que cada vez que un usuario cargue la pagia vas a tener que hacer cálculos, por cada actualizacion de edifico tendras que crear una entrada en la base de datos para guardar la hora en la k se ha construido...etc. Ésto es para que cuando un usuario deje construyendo un edificio y se desconecte, tenga un calculo de recursos correcto al volver a conectarse despues de que el edificio se construyese. Para ello tendras q mirar que entre el tiempo_ultimo_login y tiempo_actual tengas edificos construidos. Entonces el calculo seria sumando los datos obtenidos con dichas diferencias de tiempos...etc. Es una cosa bastante facil solo hay q darle un poco al coco. Saludos y perdona por si no me has entendido jejje. Si no me has entendido bien te pongo un ejemplo mas facil. deeeeu

En realidad, si usas un poco la picardía, solo es necesario hacer una actualizacion, y solo en el caso de que ésta sea necesaria. Si la ultima vez que se actualizaron los datos es menor que la ultima vez que se construyó un edificio (por ejemplo) actualizas. Es un calculo menor, con un coste totalmente asumible. El resto de calculos como de recursos se pueden hacer con javascript una vez obtenidos los multiplicadores. Por parte de servidor los calculos son hechos solo cuando son necesarios, nunca para adornar el cliente...xau

Evidentemente

Lo que yo propongo es, siguiendo tu linea de ejemplo y mi linea de no usar una tercera aplicacion:

Mandamos el movimiento de una pieza, en una tabla eventos guardamos el evento movimiento con la posicion x,y que sea, el id de la pieza que queremos mover, la hora a la que comenzo el movimiento y la hora a la que finalizaria el movimiento. Cada vez que cargamos la pagina selecionamos de la base de datos los eventos que se vayan a cumplir y que nos afecten a nosotros. El tiempo en "directo" y todo eso se puede hacer con ajax como dices, al igual que la supuesta casilla en la que se encontrase la pieza. Evidentemente tenemos una consulta en la base de datos con cada carga de pagina y actualizacion si el evento se ha llevado a cabo completamente. Pero en tu caso tenemos lo mismo, una consulta de cuanto tiempo quedaria (o lo que fuese) y una actualizacion después (a menos que la otra aplicacion la haga). Y es que lo que yo digo es que no hace falta saber exactamente cuantos segundos quedan para x evento, lo cual se puede calcular matematicamente siempre que conozcamos el inicio y fin de dicho evento, por lo cual no seria necesario ir actualizando valores desde otra aplicacion. No se si se entiende mi punto de vista.

El mayor coste que tendria dicha implementacion es que a un usuario se le acumulasen muchos eventos, por lo cual el tiempo de carga de pagina si que aumentaria en dicho caso (por ejemplo que haya 10000 moviemientos de piezas acumulados y nos conectemo despues de que los movimientos hayan terminado, lo cual conyevaria actualizar la posicion de las 10000 piezas en el momento en que se conecte dicho usuario, o el usuario que interactua con el).

Para evitar dicho coste está muy bien lo que propone SaXo, utilizar otra aplicacion que vaya "administrando y ejecutando" los eventos. No obstante mi propuesta creo que es válida si no dispones de una utilidad como la comentada.

Saludos!

Claro, tendrias que actualizar tambien los eventos de los jugadores que digamos interactuan contigo, pero en resumen eso son todos los eventos que te afectan a ti, o los eventos de un jugador al cual estas "afectando". Tampoco es muy costoso ya que son consultas SQL (suponiendo claro que usemos MySQL, algo que he dado por supuesto). Ejemplo: Un jugador mueve una ficha de la ajedrez. Ahora nostros queremos ver donde tiene las fichas el jugador. Comprobamos los eventos para saber donde estan sus fichas, algunas puede que estén en camino ya que tardan 1 minuto/casilla y otras pueden ya haber terminado (la hora que guardamos de finalizacion en el evento es menor a la hora actual). Si la ficha esta en movimiento no la podemos comer, si el evento de movimiento ha terminado ya la podriamos comer. Esto se sincroniza digamos al "ver" el tablero. Espero que entiendas a lo que me refiero. Es basicamente usar una tabla SQL como contenedor de ventos con los ID del jugador y resto de datos. Para "ahorrar" tiempo se ejecutan los eventos de la tabla cuyo ID sea el nuestro o aquel del jugador con el que interactuemos, así si interactuan con nosotros ejecutan nuestros eventos pendientes y si interactuamos con alguien los suyos, sincronizándo todo. Espero explicarme bien. Saludos!

PD: nos ha quedado un modelo de ajedrez asincrono interesante jaja.