Obsługa gry internetowej - jakie rozwiązanie będzie optymalne?

Dzień dobry

Na swoje (na razie) potrzeby chcę stworzyć grę internetową - taką prezentację. To ma być manager tenisowy. Pytanie dotyczy rozgrywki meczowej.

Zasadniczo nie jest to wielki problem. Jest dwóch zawodników, każdy ma pewne parametry (np. siła, technika, refleks). I sobie grają. W zależności od wspomnianych parametrów i czynnika losowego, zdobywają punkty, gemy, sety itd. Nie jest to skomplikowane.

Ale chciałbym, aby można było nie tylko zobaczyć końcowy rezultat, ale żeby można było obejrzeć rozgrywkę punkt po punkcie. I tu pojawia się problem, bo cały mecz rozgrywa się w ciągu sekund, a ja bym chciał żeby dla "widzów" trwał on, powiedzmy, kilka minut.

1. Cron co 5 sekund sprawdza, czy są jakieś mecze, które się rozpoczęły, a nie zakończyły. Jeśli tak, pobiera z bazy parametry zawodników, oraz sprawdza, który zawodnik serwuje i jaki jest wynik. Rozgrywa piłkę. Wprowadza do bazy zaktualizowany wynik. Strona, na której można śledzić mecz odświeża co kilka sekund jakiegoś diva, na którym aktualizuje wynik.

• Wydaje mi się, że to rozwiązanie bardzo obciąży bazę danych, a także serwer (mnóstwo połączeń strona-serwer i serwer-baza danych). Ale widzowie faktycznie oglądają mecz "na żywo"

2. Cron co minutę sprawdza, czy są jakieś mecze, które się rozpoczęły, a nie zakończyły. Jeśli tak, pobiera odpowiednie dane z bazy i rozgrywa cały mecz. Wynik końcowy zapisuje w bazie, i generuje ciąg złożony z 0 i 1 (gdy punkt wygrał 1 gracz zapisuje "0", w przeciwnym razie zapisuje "1"), który zapisuje w pliku (przebieg meczu można sobie odtworzyć w ciągu iluś-tam godzin od początku meczu).

a) Strona odwołuje się do powstałego pliku i na jego podstawie generuje "aktualny" wynik

• Skrypt nie obciąży bazy danych, ale serwer ma trochę pracy. Mecz jest niby na żywo - gdy połączenie z serwerem zostanie przerwane, wynik zostaje "zamrożony"

b) Javascript pobiera dane z pliku i na ich podstawie generuje przebieg meczu.

• Mecz wygląda jak na żywo i trwa nawet gdy dojdzie do zerwania połączenia z internetem. "Sprytny" gracz może sobie "podejrzeć" wynik bez oglądania całości (wystarczy sprawdzić, kto zdobył ostatni punkt), poza tym może bezkarnie sobie odczytać stworzony przeze mnie skrypt i kopiować bez pytania o zgodę...

c) przebieg każdego gema/seta jest zapisywany w oddzielnym pliku, a JS pobiera dane tylko z jednego pliku - czyli rozwiązanie "pomiędzy a i b"
Które z tych trzech rozwiązań jest najlepsze? A może jest jakieś inne, jeszcze ciekawsze niż to, co zaproponowałem?

jeżeli dla Ciebie jest to faktycznie jedna operacja, i masz możesz ją faktycznie zamodelować jako X komunikatów, to najlepszym wyborem jest **SSE **
http://www.html5rocks.com/en/tutorials/eventsource/basics/ - to zwykły HTTP, także nie ma problemu z obsługą. Najprościej mówiąc, wchodzisz na stronę na której trwa mecz, i jest robiony jeden request przez JavaScript, tylko jeden, i przez niego możesz do clienta wysyłać message, także nie ma problemu z narzutem.

Ewentualnie możesz zrobić to przez Websockety,czyli podobnie, wchodzisz na stronę, idzie request, ale ten request jest tylko subskrypcją jakiegoś zdarzenia, dzięki temu możesz powiadamiać dwóch userów na raz (co w przypadku SSE nie jest chyba możliwe), dodatkowo możesz wyjść ze strony na której toczy się mecz, i np: na stronie głównej dalej otrzymywać informacje i aktualnym stanie gry. Wadą tego rozwiązania jest to, że nie korzystasz z 50% możliwości Websocketów, czyli tylko słuchasz a nie wysyłasz wiadomości do serwera.

skorzystaj z nodejs, po co masz cokolwiek zapisywać do pliku? choć to kwestia wyboru, bo nodejs ma też dostęp do plików
a cron niech zajmuje się generowaniem serwer w nodei zapytań podczas realizacji wyników z meczu a potem przesyłaj to przez JSON-a do bazy pośrednicząc Pehapem w obsłudzie