[ Pobierz całość w formacie PDF ]
Spis treci
Wstp ........................................................................................................................................ 7
1.
Podstawy grafiki: pótno i duszki ............................................................................... 13
Praca z obiektem canvas
13
Tworzenie pynnych animacji
20
Praca z duszkami
23
Manipulowanie pikselami
28
Wybór metody renderowania grafiki
37
2.
Zmiana perspektywy ................................................................................................... 51
3.
Interfejs uytkownika ................................................................................................. 67
Graficzny interfejs uytkownika i interakcje w grach internetowych
67
Implementowanie graficznego interfejsu uytkownika
69
4.
Dwiki w HTML5 i optymalizacja przetwarzania ....................................................83
Dodawanie dwiku za pomoc znacznika audio
83
Wykonywanie wymagajcych zada w wtkach roboczych
92
Skadowanie danych: localStorage i sessionStorage
99
5.
Niech wiat pozna Twoj gr! ................................................................................... 103
Zabezpieczenie przed oszustwami i operacje na serwerze
103
Ostatnia prosta
108
Ostatni szlif
118
Gra trafia do spoecznoci — integracja z Facebookiem
125
5
 6
Spis treci
ROZDZIA 5.
Niech wiat pozna Twoj gr!
Stworzye atrakcyjn gr z interaktywn grafik oraz muzyk. Teraz wystarczy pokaza
j wiatu. Musisz wic umieci logik na serwerze, tak by uniemoliwi „grzebanie” w niej
i uchroni si przed spowodowanymi tym uszkodzeniami, a nastpnie poczy gr z miej-
scem, gdzie przebywa duo ludzi, czyli Facebookiem.
Zabezpieczenie przed oszustwami
i operacje na serwerze
Jednym z gównych problemów zwizanych z grami dziaajcymi online jest skuteczna ochro-
na przed oszustwami. Podobnie jak w przypadku zwykych witryn internetowych, równie
tu nie moemy ufa wszystkim uytkownikom, wic zabezpieczenie aplikacji przed szkodli-
wymi dziaaniami oraz waciwa obsuga niewaciwych danych wejciowych i zwracanych
wartoci powinny mie najwyszy priorytet.
W grach rozpowszechnianych na zasadach open source ryzyko jest nawet wiksze, zwaszcza
jeli zostay utworzone w technologiach takich jak JavaScript i HTML, poniewa atwo w nich
manipulowa zmiennymi (oraz daniami
POST
i
GET
), a nawet modyfikowa kod w kliencie
w czasie dziaania aplikacji.
Niestety nie ma idealnego sposobu na wszystkie problemy — w kadej grze i aplikacji sprawa
wyglda troch inaczej. Mona jednak wyróni dwa kluczowe (ale zwykle mao skuteczne)
rozwizania, które stosuje si we wstpnej fazie projektowania oraz póniej, w trakcie progra-
mowania:
Postaraj si ju w projekcie zminimalizowa ryzyko popenienia oszustwa na poziomie
klienta (przegldarki internetowej).
Sprawdzaj
wszystkie
dane trafiajce do serwera.
W przypadku naszej gry, jak w wikszoci spoecznociowych gier strategicznych, musimy
pamita o kilku sprawach:
Stan konta w grze kadego uytkownika powinien by zapisany w bazie danych (w polu
lub osobnej tabeli, w zalenoci od tego, czy chcemy przechowywa informacje o pojedyn-
czych transakcjach), a kada operacja sprzeday i kupna powinna aktualizowa t warto.
Musimy regularnie synchronizowa czas midzy serwerem i klientem.
103
 By moe najistotniejsze (i najskuteczniejsze w walce z oszustwami) jest takie zaprojekto-
wanie gry, by w kadej chwili niezawodnie przewidywa punktacj uytkownika
na ser-
werze
, bez koniecznoci kontaktowania si z klientem.
Jak to osign? Przyjrzyjmy si poniszemu scenariuszowi:
Pocztkowy stan posiadania uytkownika wynosi 2000 zotych monet, 0 budynków, czas
utworzenia konta równy 1293861600 (co zgodnie z uniksowym czasem odpowiada dacie
1 stycznia 2011 roku i godzinie 00:00:00), a czas ostatniej modyfikacji to 1293861600 (czyli taki
sam jak wyej).
Uytkownik ma do wyboru trzy budynki:
budk z lodami za 250 zotych monet, która co 30 minut przynosi 5 zotych monet zysku,
hotel za 1000 zotych monet przynoszcy zysk 30 zotych monet co godzin,
kino za 500 zotych monet, które przynosi zysk 12 zotych monet co 30 minut.
Uytkownik zbudowa budk z lodami w chwili 1293861660 (1 stycznia 2011 o godzinie 00:01:00,
czyli minut po utworzeniu konta).
Kolejnym posuniciem byo zbudowanie hotelu (1294084800 — 3 stycznia 2011 o godzinie
14:00:00).
W chwili 1294120800 (4 stycznia 2011 o godzinie 00:00:00) uytkownik zbudowa kino.
W chwili 1294639200 (10 stycznia 2011 o godzinie 00:00:00) uytkownik powróci do gry i po-
stanowi sprawdzi stan konta.
Jednym z moliwych rozwiza mogoby by zapisywanie informacji o wszystkich budynkach
stawianych przez uytkownika i dodanie do stanu konta pola przechowujcego dane ostatniej
modyfikacji, w którym zapisany byby te czas operacji przegldania stanu konta albo kupna
bd sprzeday budynku. Dziki temu w sytuacji, gdy uytkownik chce zobaczy stan konta
albo kupi bd sprzeda jaki budynek, mona wykona poniszy algorytm:
1.
Uaktualnij pole ostatniej modyfikacji biecym czasem.
2.
Rozpocznij przegldanie wszystkich budynków uytkownika.
3.
Przelicz rónic (w sekundach) midzy biecym czasem a czasem ostatniej modyfikacji
zapisanym w polu uytkownika.
4.
Wynik podziel przez liczb sekund przypadajc na patnoci, a wynik dzielenia zaokr-
glij w dó.
5.
Wynik pomnó przez liczb zotych monet otrzymywanych w kadej jednostce czasu.
6.
Uaktualnij stan konta, dodajc wynik powyszych operacji.
7.
W zalenoci od wykonywanej operacji (wywietlanie, budowanie lub sprzedawanie) wy-
wietl stan konta, dodaj zysk z budynku albo odejmij jego warto.
Jeli budynek by sprzedawany, usu powizanie.
Po zastosowaniu tego algorytmu do powyszego scenariusza uzyskamy nastpujce efekty:
8.
W chwili 1293861660 uytkownik postanowi zbudowa budk z lodami. Poniewa nie
ma innych budynków, wystarczy, e uaktualnimy konto i czas ostatniej modyfikacji oraz
utworzymy powizanie. Czas ostatniej modyfikacji bdzie równy 1293861660.
104
Rozdzia 5. Niech wiat pozna Twoj gr!
[ Pobierz całość w formacie PDF ]