http://cinu.pl/projects/2012/ninjatyper/

Gra jest klonem konsolowej gry typespeed. Powinna działać na chrome / ff / opera. Na ie ze względu na dźwięk a raczej brak obsługi .ogg jest niegrywalna (jest to raczej eksperyment, więc to olałem).

Przypuśćmy teraz, że chciałbym zrobić listę z wynikami. Zabezpieczenie polegałoby na tym, aby to serwer tak naprawdę decydował o wszystkim, tzn. losował/generował kolejne słowa, po przesłaniu słowa, które wprowadza użytkownik, to serwer decydował by o przyznaniu punktów (musiałby również sprawdzać czas, który upłynął od wygenerowania do wpisania - bo użytkownik może sobie przecież całą grę zwolnić do dowolnego tempa) itd. Dodatkowo dochodzi problem, że gdy serwer prześle słowo do klienta nie może być ono ani jawne, ani szyfrowane symetryczne (użytkownik musi wpisywać słowa "ręcznie", a nie z automatu). Myślałem nad generowaniem obrazka z tekstem (tak jak w przypadku captcha), aby potencjalny użyszkodnik nie miał by już tak łatwo. W tym przypadku mógłbym za każdym razem generować obrazek ze słowem w czasie rzeczywistym i wysyłać do klienta, lub też przy starcie gry wygenerować od razu je wszystkie razem z unikalnymi hashami dla każdego odświeżenia strony (lub sesji), przesłać je wszystkie do klienta, a później serwer przesyłałby tylko odpowiednie hashe.

Co myślicie ? Może ktoś ma jeszcze jakiś pomysł?

PS. Nie chodzi mi o zaciemnianie kodu czy inne tego typu praktyki.

Dosyć popularny problem dotyczący gier jako takich. Materiałów jest na prawdę sporo - może nie wszystkie dotyczą JS, ale ogólne metody/założenia są wszędzie takie same: https://www.google.pl/search?q=javascript+s...me&ie=UTF-8

To że wszystko musi się weryfikować po stronie serwera, a nie w warstwie prezentacyjnej to ja wiem (najlepiej i tu i tu, ale i tak tylko serwer "ma ostatnie zdanie"). Wydaje mi się, że tutaj problem będzie leżał bardziej w synchronizacji czasowej, wydajnością samej aplikacji server-side i samej architektury protokołu HTTP. IMHO w tym momencie ciężko ugryźć ten temat jeżeli chodzi o "szybkie" gry czasu rzeczywistego w HTML/JS, w których czas ma ogromne znaczenie przy punktowaniu gracza, głównie dlatego że brakuje stałego, szybkiego połączenia między aplikacją klienta a serwerem. Nie można też użyć mechaniki stosowanej np. w grach FPS, gdzie jest przesyłanych paredziesiąt pakietów UDP na sekundę (UDP jest protokołem stratnym, jednak o niższej latencji niż TCP). Prawdopodobnie kluczem będzie/jest WebSockets, jednak nie miałem jeszcze przyjemności

Komunikacja: Nie przesadzaj z UDP tutaj. Przy takiej grze nawet AJAX + Long Polling pewnie dałby radę bez najmniejszego problemu, jednak użycie WebSockets będzie lepszym rozwiązaniem. Tutaj opóźnienie rzędu pół(torej) sekundy nie powinno być specjalnie odczuwalne dla gracza. Chyba, że pytasz ogólnie o gry, w tym np. FPS-y. Wtedy rzeczywiście szybka komunikacja i dublowanie połowy silnika w kliencie jest istotne.

Co do Twojej gry:
1. Serwer musiałby posiadać kolekcję z wyświetlanymi napisami w danej rozgrywce, gdzie co chwila dodawałby nowe pozycje. Po wpisaniu "strtotime" w grze, serwer sprawdzałby czy taki wpis istnieje. Jak nie, nic nie robi. Jak tak, usuwa go i dodaje punkty. Dodatkowo co jakiś czas po stronie serwera musiałoby dojść do usunięcia przestarzałych wpisów (tj. tych, które są już poza ekranem rozgrywki).
2. Jak sam zauważyłeś, serwer nie mógłby jawnie przesyłać do klienta informacji o pojawieniu się nowego elementu (np. "filter_var"). Przesłanie linka do unikalnego* obrazu, a którym byłby dynamicznie generowany napis do dobry pomysł. Przed OCR-em w takiej grze nic Cię nie ochroni, no chyba, że napisy a'la reCAPTCHA.

* unikalnego, to znaczy że jeżeli w ciągu 5 sekund pojawi się dwa razy pozycja "var_dump" to jeden link będzie prowadził do /images/dsadsfvcxvnsdkf.png, a drugi do /images/tyutuitputyu.png.

UDP (oraz samo podejście "x pakietów na sekundę") dałem tylko jako przykład rozwiązania tego w szybkich grach czasu rzeczywistego, realizowanych w innych technologiach niż HTML/JS. Zresztą chyba wyraźnie to napisałem w drugim poście, że w przypadku HTML/JS nie da się zastosować tutaj takiego rozwiązania.

Co do ajax/long polling to ciekawym projektem jest http://http://www.ape-project.org/. Chwalą się, że jeden "węzeł serwerowy" jest w stanie udźwignąć 100 000 klientów jednocześnie i jeśli chodzi o ajax/long polling to wydaje mi się, że jest to liczba dosyć imponująca.

Nie mam też zamiaru niczego implementować ani rozwijać dalej tej gry (przynajmniej na chwilę obecną), zależało mi bardziej nad teoretyzowaniem na temat szybkich gier czasu rzeczywistego w HTML/JS, a ta prosta gierka i problemy które niosłaby implementacja listy wyników była tylko jako przykładem