Em relação às atualizações:
Alguns usam trabalhos CRON que atingem uma determinada página PHP de vez em quando.
Alguns usam trabalhos CRON, desta vez executando um determinado processo.
Outra abordagem é fazer atualizações 'just in time' - sempre que uma página for carregada, execute as atualizações pendentes e execute-as nesse ponto. Isso geralmente é o que você deve fazer se não conseguir executar tarefas CRON ou processos de longa execução.
Finalmente, outros estão executando o aplicativo Web inteiro como um processo, para que possam atualizar sempre que virem a hora.
O sistema final é o melhor se você tiver essa opção disponível, pois poderá armazenar os dados na memória. Atualizar alguns milhares de jogadores uma vez por minuto é trivial se você estiver apenas alterando dados na RAM, em vez de precisar gravar em um banco de dados SQL tradicional.
Mas se você não tiver esse luxo, poderá usar algum tipo de cache. Algo como memcached pode ser uma opção (dependente da sua hospedagem), que é um ponto intermediário entre a memória e um banco de dados. Você pode armazenar valores transitórios no memcache e salvá-los apenas no banco de dados quando for absolutamente necessário.
Entre o memcache e um banco de dados SQL tradicional, existem outras opções, por exemplo. as várias lojas de chave / valor ou de documentos: coisas como MongoDB , CouchDB , Amazon ou Google, etc ... ou seja. todos os sistemas sob o termo guarda-chuva NoSQL . Normalmente, eles não oferecem o poder de consulta genérico nem sempre as mesmas garantias de segurança de um banco de dados tradicional, mas geralmente são muito mais rápidos em operação. (O que não é tão surpreendente, pois eles estão fazendo menos por você.)
Mas tudo isso assumindo que um banco de dados normal não pode lidar com a carga. De fato, na maioria dos casos, provavelmente pode. Se eu tiver que emitir 10.000 chamadas UPDATE por minuto para aumentar os níveis de recursos, isso não será muito escalável quando você começar a adicionar todo o resto. Mas se você alterar isso para atualizar o recurso para todos com 1 chamada SQL, de repente as coisas parecerão muito mais positivas. Portanto, não superestime o custo de um determinado recurso, pois ele pode ser implementado de forma mais eficiente.