Tu nie chodzi o grę ani o przeglądarkę, ale o możliwie jak najlepiej zoptymalizowany algorytm, minimalizujący liczbę koniecznych czynności.
ROZWIĄZANIE NR. 1
Jakie będą wymiary w kafelkach? Wydaje mi się osobiście, że jedyne sensowne wyjście (biorąc pod uwagę, że plansza jest prostokątna) to 21x29 (bo pozostałe wyjścia to 3x203 i 7x87).
W takim wypadku, każdy gracz ma dwa konieczne dla Ciebie pola: położenie X z zakresu od 0 do 20 i położenie Y z zakresu od 0 do 28 (X i Y może być odwrotnie, mniejsza). Łącznie te dwie liczby zajmują 10 bitów.
Teraz załóżmy optymistyczny plan "na początek", że na serwerze znajduje się 1000 graczy. Oznacza to 10.000 bitów do pobrania co aktualizację. Oczywiście, za każdym razem wyliczasz na podstawie położenia tych graczy oraz gracza sterowanego, czy kogoś wyświetlić. 10 tys. bitów to nieco ponad kibibajt (zakładając, że 1 B = 8 b) - dokładnie 1250 bajtów. Skoro ustaliłeś interval na 300 ms (ach, te cudowne gry standalone z interwałem rzędu 17 ms
), daje to ok. 4167 bajtów na sekundę. Zakładając, że miesiąc trwa średnio 30 dni, 10 GB transferu miesięcznie.
10 GB transferu miesięcznie, zakładając, że 24 godziny na dobę, 7 dni w tygodniu, bez przerwy na serwerze znajduje się tysiąc osób.
Co to oznacza?
1. Nikt nie będzie siedział na serwerze tak długo w ciągu miesiąca, by pobrać tak dużo danych. Załóżmy, że trafi się ktoś "mocno uzależniony", który w ciągu miesiąca spędzi na twoim serwerze łączny okres, powiedzmy 5 dni. W ciągu miesiąca pobierze on około 51 MB na każdego gracza. Zakładając, że ma ograniczony transfer do powiedzmy 5 GB miesięcznie, będzie mógł "grać" ze 100 graczami bez wyczerpania transferu. Prawda jest jednak taka, że osoby "mocno uzależnione" od wszelkich gier mogą wydawać więcej pieniędzy na lepszy internet.
2. Czy naprawdę jesteś przekonany, że serwer nie wytrzyma przeciążenia rzędu 350 MB na godzinę? No, chyba że oczekujesz większej ilości graczy, niż 1000 (co na początku może być trudne do osiągnięcia). Wtedy sprawa jest prosta: zarabianie pieniędzy np. na reklamach, mikropłatnościach, Premium. Będziesz w stanie utrzymać porządne serwery.
ROZWIĄZANIE NR. 2 (na które wpadłem przypadkiem)
Sposób na "bardzo dużą ilość graczy+bardzo mały transfer".
Położenie gracza musi być zapisywane na serwerze, inaczej gracze będą mogli czitować.
Prosta funkcja wewnątrz serwera, która co interwał rysuje rysunek z kompletną mapą świata gry, a na niej nakłada postaci graczy na podstawie ich położeń. Następnie, dla każdego gracza wycina fragment mapy i mu wysyła. O ile na początku, gdy graczy jest mało, bardziej opłaca się używać sposobu pierwszego, o tyle jednak w sposobie drugim wysyłana jest stale taka sama ilość danych - czyli jeden rysunek. Jeśli ilość przesyłanych danych odnośnie położenia (czyli sposób drugi) przekroczy ilość danych koniecznych do przesłania zaledwie jednego obrazka (co może zdarzyć się dosyć szybko), wystarczy przełączyć się na rozwiązanie drugie. Bez względu na to, czy gracz będzie 1, czy 100, czy pięć miliardów, ilość danych wysyłanych do pojedynczego gracza będzie taka sama. A jeśli mimo to graczy będzie tak dużo, że serwer przestanie wyrabiać... kupić lepszy serwer (jak napisałem pod koniec rozwiązania pierwszego)
