[Bianca]

Z punktu widzenia technologicznego gry internetowe dzielą się na 2 grupy:
1) Wysokobudżetowe, napisane w Javie.
2) Małe i niskobudżetowe, napisane w PHP i Flash
Bliższa analiza wykazała, że do grupy 2) zaliczają się przede wszystkim gry:
1) Posiadające wersje „na sprzedaż”
2) W jakikolwiek sposób angażujące pieniądze i wygrane
Pierwsza grupa zrzesza przede wszystkim:
1) Gry, pisane przez małe firmy i dystrybuowane w wersji offline. Ich wersje sieciowe bywają dostępne na portalach dystrybutorów (którzy zajmują się reklamą i sprzedażą – a także często do pewnego stopnia narzucają własną platformę). Przykładem takiego dystrybutora jest np. PlayFirst. Gry mają zwykle dosyć krótki czas „aktywnego” życia – od 2 do 4 tygodni, potem spadają z listy.
2) Gry, które w ten czy inny sposób angażują pieniądze gracza. Zwykle są to tzw. „sill games”, które przyznają nagrody w zależności od uzyskanego wyniku, w związku z czym kluczowe staje się bezpieczeństwo danych i możliwość uniknięcia oszustw (np. przez spowolnienie czasu na komputerze gracza). Przykładem takiego serwisu może być midasplayer.com, a cechą charakterystyczną fakt, że praktycznie nie występują w nich opóźnienia i błędy (jest to spowodowane m.in. faktem, że wadliwe działanie gry powodować może straty finansowe).
Druga grupa wlicza gry, które:
1) Powstały małymi siłami (potem, ewentualnie, wyrosły do większych).
2) Są dostępne (całkowicie albo za wyjątkiem niektórych niekluczowych opcji) w wersji bezpłatnej.
Łatwo jest wyśledzić podstawowe słabe miejsca tego typu gier:
1) Firmy prezentują „płatną” część jako „opłatę za usługę X dotyczącą bezpłatnego konta”, co powoduje frustrację graczy i nie wydaje się być dobrym podejściem na dłuższą metę (jako przykład można podać sytuację, w której opłata za konto Premium jest zdejmowana z konta gracza nawet po skasowaniu jego konta w grze).
2) Gry takie w dużej mierze opierają się na pracy wolontariuszy, którzy często nie są odpowiednio przeszkoleni i mają tendencje do wikłania się w oszustwa.
3) Gry posiadają całą masę błędów, które często nie są naprawiane na bieżąco, a straty z nich wynikłe nie są refundowane.
4) Gry te mają problemy z obsługą wielu użytkowników na raz, w związku z czym lag często powoduje błędy (czasem spore), a z racji na projekt są bardzo słabo skalowalne.
Analizując powyższe dane łatwo dojść do wniosku, że na nasze potrzeby konieczne jest zastosowanie podejścia 2, ponieważ w przeciwnym razie w perspektywie 6 do 9 miesięcy czeka nas napisanie całego kodu od podstaw z racji na zbyt dużą ilość użytkowników. Dodatkowo, ponieważ planujemy dystrybucję gier w trybie offline i nagrody (nawet jeśli wirtualne) za ich ukończenie, musimy bezwzględnie dopilnować bezpieczeństwa i zrobić wszystko by zredukować możliwości oszustwa (w szczególności, spowalniania czasu komputera lokalnego podczas gry). Z racji na to, że będziemy oczekiwać od klienta zaangażowania i lojalności, musimy również zapewnić obsługę klienta i usuwanie błędów na przynajmniej dobrym poziomie.

Z punktu widzenia technologicznego gry internetowe dzielą się na 2 grupy:
1) Wysokobudżetowe, napisane w Javie.
2) Małe i niskobudżetowe, napisane w PHP i Flash
Bliższa analiza wykazała, że do grupy 2) zaliczają się przede wszystkim gry:
1) Posiadające wersje „na sprzedaż”
2) W jakikolwiek sposób angażujące pieniądze i wygrane
Pierwsza grupa zrzesza przede wszystkim:
1) Gry, pisane przez małe firmy i dystrybuowane w wersji offline. Ich wersje sieciowe bywają dostępne na portalach dystrybutorów (którzy zajmują się reklamą i sprzedażą – a także często do pewnego stopnia narzucają własną platformę). Przykładem takiego dystrybutora jest np. PlayFirst. Gry mają zwykle dosyć krótki czas „aktywnego” życia – od 2 do 4 tygodni, potem spadają z listy.
2) Gry, które w ten czy inny sposób angażują pieniądze gracza. Zwykle są to tzw. „sill games”, które przyznają nagrody w zależności od uzyskanego wyniku, w związku z czym kluczowe staje się bezpieczeństwo danych i możliwość uniknięcia oszustw (np. przez spowolnienie czasu na komputerze gracza). Przykładem takiego serwisu może być midasplayer.com, a cechą charakterystyczną fakt, że praktycznie nie występują w nich opóźnienia i błędy (jest to spowodowane m.in. faktem, że wadliwe działanie gry powodować może straty finansowe).
Druga grupa wlicza gry, które:
1) Powstały małymi siłami (potem, ewentualnie, wyrosły do większych).
2) Są dostępne (całkowicie albo za wyjątkiem niektórych niekluczowych opcji) w wersji bezpłatnej.
Łatwo jest wyśledzić podstawowe słabe miejsca tego typu gier:
1) Firmy prezentują „płatną” część jako „opłatę za usługę X dotyczącą bezpłatnego konta”, co powoduje frustrację graczy i nie wydaje się być dobrym podejściem na dłuższą metę (jako przykład można podać sytuację, w której opłata za konto Premium jest zdejmowana z konta gracza nawet po skasowaniu jego konta w grze).
2) Gry takie w dużej mierze opierają się na pracy wolontariuszy, którzy często nie są odpowiednio przeszkoleni i mają tendencje do wikłania się w oszustwa.
3) Gry posiadają całą masę błędów, które często nie są naprawiane na bieżąco, a straty z nich wynikłe nie są refundowane.
4) Gry te mają problemy z obsługą wielu użytkowników na raz, w związku z czym lag często powoduje błędy (czasem spore), a z racji na projekt są bardzo słabo skalowalne.
Analizując powyższe dane łatwo dojść do wniosku, że na nasze potrzeby konieczne jest zastosowanie podejścia 2, ponieważ w przeciwnym razie w perspektywie 6 do 9 miesięcy czeka nas napisanie całego kodu od podstaw z racji na zbyt dużą ilość użytkowników. Dodatkowo, ponieważ planujemy dystrybucję gier w trybie offline i nagrody (nawet jeśli wirtualne) za ich ukończenie, musimy bezwzględnie dopilnować bezpieczeństwa i zrobić wszystko by zredukować możliwości oszustwa (w szczególności, spowalniania czasu komputera lokalnego podczas gry). Z racji na to, że będziemy oczekiwać od klienta zaangażowania i lojalności, musimy również zapewnić obsługę klienta i usuwanie błędów na przynajmniej dobrym poziomie.

[Bianca]

dobra, to skoro o grach juz jest, to kawalek o stronie.

de facto mamy wybor pomiedzy 2 technologiami, PHP i JS-pochodnymi (JSP, JSF itepe, osadzone na javie)

no wiec, pierwsze i podstawowe:
PHP da kazdego dzialania musi odpalic proces, wykonac dzialanie i zamknac proces. W praktyce bedzie to wolniejsze od JSP (ktore zwykle trzyma proces per sesje usera) i przy wiekszej liczbie userow bedzie generowac znacznie wieksze obciazenie na serwerze. Wymaga tez znacznie wiecej roboty jesli chodzi o bezpieczenstwo (szczegolnie jesli idzie o komunikacje z grami java).

Ma to wade: niestety deployment bedzie oznaczal chwilowe wylaczenie wszystkich serwerow (ale obstawiam, ze powiedzenie "sorry, ale w godzinach tych-a-tych mamy deploy" ma szanse byc w miare skuteczne. Eve ma codziennie godzinny downtime i jakos ludzie z tym zyja)

Ale ma tez zalete: pozwala z defaultu na programowanie w wielu jezykach (w sensie lingwistycznym a nie programistycznym)

dobra, to skoro o grach juz jest, to kawalek o stronie.

de facto mamy wybor pomiedzy 2 technologiami, PHP i JS-pochodnymi (JSP, JSF itepe, osadzone na javie)

no wiec, pierwsze i podstawowe:
PHP da kazdego dzialania musi odpalic proces, wykonac dzialanie i zamknac proces. W praktyce bedzie to wolniejsze od JSP (ktore zwykle trzyma proces per sesje usera) i przy wiekszej liczbie userow bedzie generowac znacznie wieksze obciazenie na serwerze. Wymaga tez znacznie wiecej roboty jesli chodzi o bezpieczenstwo (szczegolnie jesli idzie o komunikacje z grami java).

Ma to wade: niestety deployment bedzie oznaczal chwilowe wylaczenie wszystkich serwerow (ale obstawiam, ze powiedzenie "sorry, ale w godzinach tych-a-tych mamy deploy" ma szanse byc w miare skuteczne. Eve ma codziennie godzinny downtime i jakos ludzie z tym zyja)

Ale ma tez zalete: pozwala z defaultu na programowanie w wielu jezykach (w sensie lingwistycznym a nie programistycznym)