Programowanie gier społecznościowych na Facebooka cz. 6 – miejsce na kod i dane

W czym pisać kod gry? W PHP czy w JS? No i gdzie trzymać dane o rozgrywce i grach? Dowiedz się!

W poprzednich częściach omówiłem kwestię wyboru serwera, potrzebne języki programowania, sposób komunikacji klient-serwer, typy komunikacji i pojęcie hosta gry.

Struktura całego rozwiązania wygląda mniej więcej tak:

2014-02-20_00-07-53[1]

Wiemy już, że obsługą gry zajmować się będzie instancja gry hosta, a zarówno on jak i pozostali klienci gry będą komunikować się przez HTTP z poziomu JavaScriptu. Mamy też serwer wyposażony w PHP i bazę danych MySQL.

Jeśli chodzi o dane to możemy zapisywać je po stronie klientów albo po stronie serwera, w bazie danych MySQL. Dane po stronie klientów są ulotne. Jeśli któryś z nich wyjdzie z gry, albo zamknie przeglądarkę tracimy je. Dane zapisane w bazie MySQL są zapisane na stałe (do czasu, aż je skasujemy).

Wyróżniony charakter hosta powoduje, że on również może przechowywać jakieś dane na temat gry. Tutaj pojawia się pytanie. Czy host powinien trzymać dane gry, czy też powinna to robić baza danych MySQL? Oraz analogiczne pytanie: które operacje mają być oprogramowane po stronie serwera, w PHP, a które po stronie klientów, w tym w szczególności, hosta.

Gdzie trzymać dane?

Jeśli chodzi o zbiorcze wyniki rozgrywek np. ogólną liczbę punktów gracza, to z pewnością chcielibyśmy je mieć na stałe. Naturalnie więc zapisujemy te dane w bazie danych MySQL. A na przykład dane na temat pojedynczej rozgrywki? To już zależy. Jeśli chcemy mieć takie dane na temat tego kto z kim zagrał, ile zdobył punktów w danej rozgrywce, albo np. ile punktów zdobył w danym dniu, to zapisujemy je w MySQL. Tak samo jak inne dane potrzebne nam do tworzenia list, rankingów, podsumowań, zestawień itd., a także dane dotyczące gracza np. jego awatar, nick, czy jakieś dodatkowe ustawienia np. zdobyte dodatkowe nagrody, wykupione bonusy itp.

Czytaj podobne  Jak stworzyć aplikację na Facebooku

Ale oprócz tych stałych danych są też dane potrzebne do przeprowadzenia rozgrywki, a więc używane w czasie trwania gry i niepotrzebne po jej zakończeniu. Są to więc np. informacje o tym ilu jest graczy w grze, w której rundzie gra się znajduje, czy tez informacje pojawiające się na czacie.

Te dane nie muszą być przechowywane na dłużej niż do czasu zakończenia gry, albo wyjścia z niej przez gracza. W związku z tym nie ma potrzeby trzymać ich w MySQL.

Nie tylko ulotność danych jest tu ważna. W przypadku dużego ruchu w grze, dużej liczby graczy, ilości tych danych są astronomiczne i sięgają milionów informacji w ciągu dnia. Obciążanie bazy danych nimi nie zdaje się być dobrym rozwiązaniem. Dlatego lepiej jak najwięcej danych potrzebnych do rozgrywki trzymać po stronie klientów i usuwać je po gdy nie są już nikomu potrzebne.

Gdzie trzymać kod?

Skoro już wiemy, że będziemy mieli dane stałe w MySQL, a dane rozgrywki po stronie klientów, to gdzie powinien być umieszczony kod gry? Tutaj mamy do czynienia z dwoma możliwościami. Albo więcej kodu po stronie serwera albo po stronie klientów. Jednak tak jak wcześniej, aby odciążyć serwer dobrze jest, aby podczas rozgrywki jak najwięcej kodu było wykonywanego po stronie klientów. Zresztą to ułatwia pracę, ponieważ na klientach będziemy mieli wszystkie dane potrzebne do rozgrywki.

Jaką rolę będzie więc spełniał kod po stronie serwera? Przede wszystkim rolę pośrednika między klientami, a więc punktu pozwalającego na komunikację między nimi, przesyłanie danych np. klient gracza który wykonał ruch piona przesyła do serwera informację o tym, która następnie jest odbierana przez hosta w celu obsługi tego zdarzenia.

Czytaj podobne  Testy funkcjonalne aplikacji na Grono.net

Oprócz tego kod na serwerze może służyć do przechowywania danych o rozgrywkach, zapisywania wyników gry, pomocnych danych diagnostycznych czy zwracania z bazy informacji o liczbie dostępnych stołów, informacji o nich, czy też zestawień np. listy ostatnio rozegranych gier.

Jak widać większy ciężar będzie położony na kod JS, a więc będzie trzeba programować dużo w JS, a bardzo mało w PHP. Ale nie ma co się martwić, JS to dobry język, zresztą, w wielu momentach lepszy od PHP. Ale o tym później…

 

Przeczytaj też

Programowanie RMSBG na Facebooka cz. 5 – host gry... Kim jest host gry i czy powinien znajdować się na serwerze czy powinien nim być jeden z graczy? W poprzednich częściach ustaliliśmy środowiska prog...
Programowanie RMSBG na Facebooka cz. 4 – typ... Jakie typy komunikacji trzeba uwzględnić w pisaniu gry RMSBG? W poprzednich częściach założyliśmy, że robimy grę planszową RMSBG (Realtime Multipla...
Programowanie RMSBG na Facebooka cz. 3 – kom... Jak klient w JS może komunikować się z serwerem w PHP przez HTTP? W poprzednich częściach omówiłem rozwiązania klienckie i serwerowe dla gier RMSBG...
Programowanie RMSBG na Facebooka cz. 2 – Jęz... Jakie języki programowania trzeba znać, żeby pisać RMSBG na Facebooka? Dowiedz się. W poprzedniej części poruszyłem temat decyzji czy aby napisać R...
Programowanie gier społecznościowych czasu rzeczyw... Czy aby pisać gry RMSBG trzeba korzystać z serwera? Dowiedz się! Po latach pisania gier online postanowiłem podzielić się moimi doświadczeniami na ...
Eurostaż PO – sympatyczna farma fikcyjnych f... Ostatnio głośno jest o akcji Eurostaż. Dowiedz się więcej. Kilku organizatorów prowadzi kolejną edycję konkursu. III jego etap polega na zdobyciu g...
Napisano w Społecznościowe Tagi: , , ,