Zastanawiam się nad napisaniem prostej gry coś w deseń plemiona (aby się poduczyć) i interesuje mnie jak są rozwiązane zdarzenia w tego typu grach.
Cron odpada ponieważ wykonuje się on minimum co minutę, więc nie zda on egzaminu. W tego typu grach czas jest ważny, przykładowo o 11:23:03 ma powstać jakiś żołnierz a 11:23:04 mamy atak.

Wydumałem, że dobrym rozwiązaniem było by utworzenie tabeli `cron` w której będę przechowywał dokładny czas oraz co należy wykonać. Przykładowo gracz tworzy 300 żołnierzy, gdzie każdy będzie produkował się dokładnie 1 min. Więc należy dodać do bazy danych około 300 rekordów gdzie czas to time()+($i*60). Następnie za każdym razem kiedy "ktoś" odwiedzi grę, automatycznie sprawdzi czy w tabeli `cron` nie ma do wykonania zadań. Jeśli są oczywiście wykonać je w odpowiedniej kolejności. Jednak moje pytanie jest następujące, gdy graczy mam 300 i każdy zleci budowę po 300 żołnierzy, jest to 90000(!) zapytań do bazy (jeśli dobrze liczę jest to 5 zapytań na sekundę). Do tego dochodzą kolejne zdarzenia typu budowa budynku, ataki i inne pierdoły co myślę że dojdzie do 10 zapytań na sekundę. Jak wtedy z wydajnością mySQL'a? Będzie dawał radę? Czy może błędnie podchodzę do tego?

Kompletnie nie rozumiesz chyba idei na jakiej tego typu rzeczy działają. Osobne zapytanie dla każdej jednostki? A robiąc obiad każdą nitkę spaghetti też osobno gotujesz? Problem na jaki napotykasz to "proces rekrutacji". Albo wyrzucasz co "czas produkcji" jednostkę z "koszar", albo robisz to hurtem po zakończeniu "pakietu produkcyjnego". Działania i tak nie będa sie wykonywały co "czas produkcji", ale i tak zrobią "hurtem od zdarzenia do zdarzenia". Najczęsciej to zdarzenie wiąże się z Twoja akcją jako użytkownika, albo akcją kogoś wobec Twojego konta. Każda inna forma "rozwiązania problemu", to zarżynanie bazy.