Autor Wątek: PHP/*ServerPages vs C++/C#/Java  (Przeczytany 29828 razy)

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Kwiecień 30, 2007, 22:47:39
peter: widzę że powoli zaczynamy się rozumieć - przyznaj że taki model request->response przypomina właśnie sklep czyli klasyczną aplikację webową, a gra przez przeglądarkę chcieć nie chcieć w pewien sposób musi się w ten model wepchać. Hacki są wszędzie, też sporo tego widziałem, ale one wynikają z innych rzeczy - złe podejście projektowe. Gdyby się to inaczej zaimplementowało to 90% sytuacji o których mówisz można wyeliminować.
W PHP nie da się aż tak pisać obiektowo? Co masz na myśli? :> Jedyne co według mnie staje na przeszkodzie sensowności (nie mówię o możliwości tylko sensowności zauważ)  zastosowania mechanizmu obiektowego w PHPie to właśnie krótki life-cycle obiektów wynikający z modelu request->response, ale user->village->nextTurn() też można zrealizować bez problemu w PHP'ie w oparciu o automatyczną serializację - ja tam problemu nie widzę.
Odnośnie Twojej gry to muszę przyznać że nie grałem w nią, tylko się zarejstrowałem, w wolnej chwili może się pobawię, ale uwierz że pomijając wygląd, wnioskuję po tym co piszesz i w jaki sposób piszesz, że Twoja aplikacja jest 20x lepiej napisana i rozbudowana niż 3/4 sklepów internetowych :]
Dla mnie wyznacznikiem sposobu pisania i wyboru języka jest tutaj sposób interackji z użytkownikiem - aplikacje webowe z założenia nie są dla mnie real-time tylko request->response i stąd moje poglądy, opinie i podejście do tematyki :)
ciesze sie ze zaczynamy sie rozumiec - taraz dopiero mozna zaczac dyskutowac ;)
przyznaje, ze model reqest-response (RR) przypomina sklep internetowy i to wlasnie jest dla mnie cos co rozni ow sklep od gry - do gry mi taki model kompletnie nie pasuje... w kazdym razie do rozbudowanej gry
w C++ moglem sobie napisac napisac sobie zgrabny scheduler - ktory notabene tez moze sie serializowac miedzy restartami serwera, bo zadania w nim sa umieszczone w czasie dzialania gry, a nie tylko statycznie przy starcie, przy modelu RR takiego czegos juz nie zrobisz.
zgadzam sie, ze w PHP da sie tak pisac (kwestia notacji jest dla mnie drugorzedna - bo prawde mowiac nie pamietam czy da sie tam przeciazac operatory), ale raz, ze jest to mniej wygodne, a dwa ze w modelu RR bedzie koszmarnie wolne - bo obiekt musisz wowczas w calosci pobrac a potem zapisac do bazy za kazdym requestem - to juz lepiej klasycznie pobierac te czesci, ktore sa akurat potrzebne, u mnie jest inaczej - bo taki obiekt po pobraniu moze byc przed zapisem wykorzystany wielokrotnie i to jest duza przewaga execa nad skryptem

z modelem RR w grach przez www staram sie wlasnie walczyc, co prawda u mnie tez tak to wyglada w poczatkowych etapach gry (osada, wioska) bo tak jest latwiej dla poczatkujacego gracza, ale potem zaczyna sie to zmieniac (zaczety grod i jeszcze nietkniete miasto)

PS. prosilbym o taktowne przemilczenie kwestii wygladu mojej gry - bicie ponizej pasa nie jest fair :P

edit:
chyba troche zabardzo zszedlem na temat wlasnej produkcji - jesli tak to przepraszam, ale topik wlanie dlatego mnie zainteresowal, ze jak ulal pasuje do tego za co sie zabralem - a nuz mnie jeszcze przekonasz, ze zle robie i rzuce to w cholere :P
tak wiec grzecznie postaram sie do tego nie wracac, a jesli chcialbys poznac nieco wiecej szczegolow proponuje przeczytac to:
http://forum.warsztat.gd/index.php/topic,3082.msg45277.html#msg45277
pewnie bedzie to bardziej interesujace zajecie niz samo granie w mocno niedokonczona gre ;)
« Ostatnia zmiana: Kwiecień 30, 2007, 22:59:44 wysłana przez peter »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline mINA87

  • Użytkownik

# Maj 01, 2007, 12:16:43
Oj swoją grą się nie przejmuj, ani wyglądem bo nikt nic nie mówi, ani tym że o niej piszesz - jest OK, oby tak dalej, bo tworzysz kawał dobrego kodu i oby tak dalej :]
Również cieszę się że zaczynamy się rozumieć :) Już dokładnie widzę w jaką stronę poszedłeś - gra jest swego rodzaju usługą a warstwa RR tylko deleguje komunikaty do schedulera. W sumie na pewno to jest bardzo elastyczne rozwiązanie i pozwala zakodzić taką grę jak normalną grę realtime. Takie podejście rozwiązuje wiele kwestii, gdyż skoro mamy usługę, to niektóre operacje wykonywane cyklicznie możemy łatwo przeprowadzać w real-time'ie i pomaga się tak trochę wyłamać z tego modelu RR.
Z drugiej strony mamy "mój" modelik RR. Dokładnie odzwierciedla on standardowe czynności - mamy akcję, mamy reakcję i tak w kółko i pozwala tą część zrealizować bardzo elastycznie i fajnie. Pozostaje jednak kwestia operacji które powinny być wykonywane cyklicznie w real-time'ie - o tym mówił Goliatus jednak niefortunnie w kontekście wielowątkowości, więc trochę się to rozmyło. W PHP'ie jest właśnie teog typu problem, że nasza aktualziacja może nastąpić tylko przy rządaniu, które może nastąpić albo za mikrosekundę, za 2 godziny albo za 3 tygodnie. To może być istotny problem, bo odpalanie skryptu PHP'a w cronie nie jest zbyt fajnym rozwiązaniem, postawienie PHP'a jako stacjonarnej usługi jest problematyczne pod kątem zarządzania life-cycle'm tej usługi, ale myślę że w oparciu o bazkę, infinite loop i jakiś frontend RR pakujący komunikaty do bazki, miałoby to szansę działania, jednak ciągle to nie to. Ostatnim możliwym uporaniem się z tym problemem jest globalna aktualizacja przy założeniu, że aktualizacja jest w pełni deterministycznie i wyznaczona jednoznacznie jako funkcja od czasu, wtedy możemy nawet po tygodniu zaaktualizować stan całej gry i żadnego problemu nie powinno być, jednak problemem może tutaj być wydajność - aktualizacja świata gry dla miliona graczy po tygodniu przerwy to ni w kij dmuchał :]
Teraz moje przemyślenia na temat aktualnego stanu rzeczy - dlaczego mamy gry online w PHP'ie a nie jako usługi C++:
- ludzie piszący tego typu rzeczy nie mają zbytniego pojęcia o programowaniu
- brak dostępu do choćby CGI - tylko do PHP'a na większości shared-hostów
- przenośność - aplikację w PHPie można bardzo szybko przenieść i odpalić na niemal dowolnym kompie
- koszty utrzymania - na pewno mniejsze w przypadku PHPa
I właśnie dlatego niestety mamy taką przewagę PHP'a. Sytuacja ta nie zmieni się też tak szybko ogólnie na rynku aplikacji webowych, bo tutaj wymagane jest tworzenie szybkich, tanich, prostych, przenośnych rozwiązań i własnie dlatego króluje PHP - w nim może programować niemal każdy.
Dochodzi też jeszcze jedna kwestia - w ogólnym kontekście gameplay gry przez przeglądarkę musi uwzględnić właśnie ten brak interackji w czasie rzeczywistym i występowanie tego modelu RR i dlatego też pomijając kwestie aktualizacji cyklicznej świata, łatwo jest zrealizować grę przez przeglądarkę w oparciu o moel RR i języki przystosowane do szybkiego tworzenia aplikacji pracujących w takim środowisku.

Offline nameczanin

  • Użytkownik
    • devlog

# Maj 01, 2007, 12:34:55
Cytat: mINA87
się tak trochę wyłamać z tego modelu RR.
Z drugiej strony mamy "mój" modelik RR. Dokładnie odzwierciedla on standardowe czynności - mamy akcję, mamy reakcję i tak w kółko i pozwala tą część zrealizować bardzo elastycznie i fajnie. Pozostaje jednak kwestia operacji które powinny być wykonywane cyklicznie w real-time'ie - o tym mówił Goliatus jednak niefortunnie w kontekście wielowątkowości, więc trochę się to rozmyło. W PHP'ie jest właśnie teog typu problem, że nasza aktualziacja może nastąpić tylko przy rządaniu, które może nastąpić albo za mikrosekundę, za 2 godziny albo za 3 tygodnie.

Cytat: mINA87
Ostatnim możliwym uporaniem się z tym problemem jest globalna aktualizacja przy założeniu, że aktualizacja jest w pełni deterministycznie i wyznaczona jednoznacznie jako funkcja od czasu, wtedy możemy nawet po tygodniu zaaktualizować stan całej gry i żadnego problemu nie powinno być, jednak problemem może tutaj być wydajność - aktualizacja świata gry dla miliona graczy po tygodniu przerwy to ni w kij dmuchał :]

W ten sposob napisalem chat w PHP [glupie i chore, ale dzialalo]. Przegladarka odswiezala niewidzialna ramke, a tam JavaScript sprawdzal czy jest jakis nowy msg z serwera - jezeli byl to dodawal tekst do page'a klienta. Wszystko opieralo sie na tym zlagowanym uaktualnianiu. Wedlug tego co napisales - delta czasu po prostu byla rozna, ale jest to zawsze jakies rozwiazanie przeciwko modelowi RR.

A o grach opartych na tym "sklepie" - co by nie bylo, nie kazdego interesuje taka gra :) Nie kazdy lubi wyobrazac sobie armie tysiecy zolnierzy. Bowiem 'x' ludu woli nacieszyc oko.

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Maj 02, 2007, 21:29:47
Ja chat oparty o sam javascript po stronie serwera bym zrobił tak:
1. po stronie klienta: pobieranie i wysyłanie danych z serwera przez ramkę xmlhttprequest czy coś innego
2. na serwerze:
- lista ostatnich wypowiedzi i listy klientów trzymana w pamięci operacyjnej, a nie przesyłana przez bazę danych, która w przypadku chatu jest wąskim gardłem
- request-response: odbieranie komend, wysyłanie nieprzeczytanych wypowiedzi
- osobny wątek, który na bieżąco prowadzi serializację listy klientów i wypowiedzi do pliku lub bazy jakieś danych

Różnica pomiędzy typowym podejściem a tym powyższym tkwi własnie w tym, że przy zapytaniu dane są pobierane i zapisywane do pamięci operacyjnej, a za tym o jakimś znaczącym lagu, który wynikałby z obciążenia bazy danych nie ma mowy. Pamięciożrne też to nie jest.

W PHP to się da zrobić w całości, ale raczej nie będzie to wyglądało tak zgrabnie i przejrzyście jakby było zrobione w Javie albo C#.

P.S A najlepiej to samemu zrobić od podstaw serwer http, bazę danych, webapp i silnik gry w jednym ;)
« Ostatnia zmiana: Maj 02, 2007, 21:31:19 wysłana przez Goliatus »

Offline nameczanin

  • Użytkownik
    • devlog

# Maj 03, 2007, 03:54:41
ten xmlhttprequest to juz AJAX ^^ Wtedy nie znalem tego. Reszte zrobilem dokladnie tak jak napisales, o ile pamiec operacyjna masz za plik na serwerze FTP. Z nieprzeczytanymi tak wlasnie bylo, z klientami rowniez, ale sie nie rozpisywalem na ten temat powyzej :) Bazy danych nie uzywalem jeszcze nigdy recznie poprzez PHP :|  Jakby nie bylo, to te watki musialem robic w ramkach automatycznie odswiezajacych sie [brak tych automatycznych requestow w tle]. W ogole potem wpadlem po tym, ze wszystko da sie w ten sposob zrobic [bagatela kiedy mamy czasy XHTML-ow, AJAX-ow, XSL-ow, ASP-ow, to wykorzystalem HTML4, PHP4 i czysty JS], nawet jakas gre real-time na smiesznym lagu odswiezania sie ramki w przegladarce :P Ale o tym to juz wspominalismy wyzej. Nikt nie bedzie dyskutowal czy sie da, ale raczej czy jest sens.

Ogolnie to swietnie, ze sie rozumiemy.

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Maj 03, 2007, 17:51:43
Teraz moje przemyślenia na temat aktualnego stanu rzeczy - dlaczego mamy gry online w PHP'ie a nie jako usługi C++:
1. ludzie piszący tego typu rzeczy nie mają zbytniego pojęcia o programowaniu
2. brak dostępu do choćby CGI - tylko do PHP'a na większości shared-hostów
3. przenośność - aplikację w PHPie można bardzo szybko przenieść i odpalić na niemal dowolnym kompie
4. koszty utrzymania - na pewno mniejsze w przypadku PHPa
I właśnie dlatego niestety mamy taką przewagę PHP'a. Sytuacja ta nie zmieni się też tak szybko ogólnie na rynku aplikacji webowych, bo tutaj wymagane jest tworzenie szybkich, tanich, prostych, przenośnych rozwiązań i własnie dlatego króluje PHP - w nim może programować niemal każdy.
1. ten pkt mnie osobiscie nie interesuje, jesli ktos (jeszcze) nie umie programowac to IMO i tak dobrej gry MMO nie napisze - nawet w PHP przez przegladrke
2. cos jak wyzej, jesli nie bedziesz mial dobrego dedydkowanego serwera to gra i tak nie bedzie mogla miec zbyt wielu graczy
3. programy w C++ rowniez sa przenosne - szczegolnie jesli taki zainstalowac na jakims lekkim notebooku, wtedy mozna go przenosic do woli ;)
a tak powaznie to rzeczywiscie jest pewien minus
4. to raczej zalezy od ilosci graczy - przy wiekszej, rozwiazanie w C++ staje szybsze  i przede wszystkim bardziej skalowalne, mam juz caly plan i nawet kawalek implementacji mechanizmu, ktory moze pozwolic rozproszyc obliczenia na wiele komputerow, ktore nie musza wcale byc razem w szybkim LANie.
Dochodzi też jeszcze jedna kwestia - w ogólnym kontekście gameplay gry przez przeglądarkę musi uwzględnić właśnie ten brak interackji w czasie rzeczywistym i występowanie tego modelu RR i dlatego też pomijając kwestie aktualizacji cyklicznej świata, łatwo jest zrealizować grę przez przeglądarkę w oparciu o moel RR i języki przystosowane do szybkiego tworzenia aplikacji pracujących w takim środowisku.
glupio sie przyznac, ale trzy razy czytalem i dalej tego kawalka nie rozumiem  ::)

Offline mINA87

  • Użytkownik

# Maj 03, 2007, 18:06:25
Dedyk załatwia punkty 2 i 3, punkt 1 powoduje tworzenie chłamu po sieci niestety, a punkt 4 w tym kontekście wypada pozytywnie, jednak nie wiem jak z utrzymaniem kodu. Hmm ciężko powiedzieć czy łatwiej utrzymać kod PHP czy C++ zapewne i to i to ma wady i zalety.
Odnośnie cytatu - miałem na myśli to w jaki sposób działa przeglądarka - sekwencyjnie z dużymi lagami. Narzuca to pewne ograniczenia na samą mechanikę gry - ciężko w tym będzie zrobić Quake'a czy RTS a'la Red Alert - mniej lub bardziej turowy system pozwala załatwić problemy z lagami i dlatego takie podejścia jak w Red Dragon, Tibia, OGame dominują.

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Maj 03, 2007, 20:08:56
A myśleliście kiedyś nad takim rozwiązaniem, że gracze instalują u siebie program, który pełni funkcję serwera HTTP i to przez ten serwer się łączą z serwerem gry? Tzn. javascriptem przez ramkę czy xmlhttprequest dane nie są pobierane z serwera gry, tylko z serwera lokalnego, którym jest ten program.
Pełni on funkcję takiego cacheu i dodatkowo przeprowadza pewne obliczenia(np. kolizje), które zmniejszają ilość przesyłanych danych i eliminują lagi. Dysponując czymś takim można się pokusić o zrobienie RTSa. Różniłby się on tylko sposobem prezentacji od tych standardowych. Dodatkowo można dorzucić do tego zagadnienie p2p i stworzyć taką formę systemu rozproszonego, o którym wspomniał peter.
Np. kiedyś tak myślałem o menadżerze piłkarskim z bardzo realistycznym symulatorem meczu. Natchnął mnie do tego projekt badawczy, którego celem było udowodnienie niedoskonałości md5. Otóż na stronie projektu był applet, który przeprowadzał obliczenia i wysyłał je na serwer.

Z moich obserwacji(z perspektywy gracza) wynika, że gracze nie wnikają w to co musieliby zainstalować, żeby pograć w daną gierkę, tylko w to ile kasy muszą wydać(najlepiej nic).
« Ostatnia zmiana: Maj 03, 2007, 20:13:35 wysłana przez Goliatus »

Offline mINA87

  • Użytkownik

# Maj 03, 2007, 20:21:30
Hmm bardzo ciekawy pomysł, ale ja bym raczej poszedł w umieszczenie u klienta jakiejś kontrolki do obsługi HTML'a i zrobienie normalnej aplikacji opartej o sockety UDP, bo stawianie serwera jako cache jest bardzo ciekawe, ale chyba przegięte trochę :] W takim rozwiązaniu tylko krok do aplikacji stacjonarnej.
Odnośnie P2P to może to być również ciekawe rozwiązanie, ale też trochę armata na komara, chyba że bawimy się w naprawdę potężny świat. BTW: słyszeliście o systemie P2P Chord? :]
Odnośnie instalowania czegoś przez graczy - zależy w kogo celujesz Goliatus. Segment gier webowych to bardzo specyficzna gałąź w której podstawowym czynnikiem napędzającym jest niesamowita mobilność - loguję się przez przeglądarkę i gram, właśnie to napędza sporo odbiorców, szczególnie spoza kręgu docelowego (nie-gracz prędzej skusi się na gierkę online niż instalowanie stacjonarnej aplikacji).

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Maj 03, 2007, 20:28:19
No masz racje i też to zrozumiałem po tej rozmowie, że instalowanie czegoś w przeglądarce, albo opieranie się o appleta jest złym pomysłem. Dlatego taka aplikacja dodatkowa wspomagająca działanie gry dodatkowo stanowiąca sieć p2p jest potęznym narzędziem. Wyobraź sobie, że to może działać tak, że z jednego takiego prywatnego serwera może korzystac kilku graczy. Jeśli nie możesz na komórce czy w jakimś innym urządzonku zainstalować serwera to łączysz się z cudzym. Najpierw łączysz się z głównym, a główny zwraca adres najbliższego/najmniej obciążonego serwera w sieci.
To drastycznie redukuje koszty utrzymania takiej gry i jednocześnie pozwala na podniesienie jej jakości, która w tradycyjny sposób mogłaby być nieosiągalna ze względu na ograniczone zasoby sprzętowe i finansowe.

Offline mINA87

  • Użytkownik

# Maj 03, 2007, 20:43:25
Tak, ale dochodzą inne sprawy - konieczność synchronizacji - jeśli ma to być wspólny świat, to tutaj mogą być spore problemy z wyważeniem i znowu wracamy do centralizacji, bo wątpię żeby dało się na równych peerach (albo równiejszych) utrzymywać świat niezależnie, może to być architektura drzewka o zmniejszającym się przepływie w stronę korzenia, ale jednak tak to chyba musi wyglądać.
Ponadto kolejne standardowe problemy sieci p2p - awaryjność - lagi które w ten sposób powstaną i lokalne desynchronizacje świata wynikłe z tego powodu.
Sieci p2p sprawdzają się dobrze w zastosowaniach w których możemy rozdzielić jednoznacznie dziedzinę  (niespójny świat np. DNSy itp) a tracenie węzła nie jest sytuacją krytyczną gdyż da się zapewnić jednoznacznie i szybko synchronizację.
Dlatego system taki widziałbym jako właśnie drzewko - w korzeniu arbiter zajmujący się synchronizacją międzysektorową globalnego świata, pierwsza warstwa node'ów odpowiadająca za sektory, kolejne odpowiadające za grupy node'ów i zapewniające efektywną komunikację między nimi. Aktualne zmiany mikro-stanów musiałby być propagowane do kilku peerów i tak w głąb stopniowo.
Hmm skomplikowane toto i dużo kwestii do rozwiązania - własnie chyba dlatego nie łatwo o gry w technologii p2p, kwestia zbalansowania systemu, żeby zysk z rozproszenia był odczuwalny, a ryzyko desynchronizacji świata niskie, ale może się okazać przyszłościowym rozwiązaniem np do tworzenia niesamowicie skomplikowanych światów do gier non-real-time. Taki świat OGame'a rozbudowany setki razy - wszyscy w jednym wszechświecie :] 

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Maj 03, 2007, 20:49:42
... albo symulacja bitwy na 10 milionów jendostek :)

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Maj 03, 2007, 20:50:34
@Goliatus:
prawde mowiac cos takiego wlasnie napisalem - czesc gry, odpowiedzialna za generowanie html'a i wysylanie go do przegladarki to pythonowy skrypt - w szczegolnosci ten skrypt moze byc u samego gracz, lub jak mowisz w jakiejs sieci lokalnej - tylko dla graczy z tej sieci. Ow skrypt natomiast gada po TCP z wlasciwym serwerem. Nie rowniez ma najmiejszego problemu, zeby skrypt zastapic dedykowana aplikacja - powiedzmy w Qt, ktora pelnilaby role klienta zamiast przegladarki. W ten sposob nie ograniczamy mobilnosci bo poza domem kazdy moze zalogowac sie przez przegladarke, ale zwiekszamy szybkosc bo wiekszosc graczy gra przez cacheujace klienty.
Napisanie takiego klienta - a przynajmniej tej jego czesci, ktoragada z serwerem - to banal, bo serwer sam jest w stanie wygenerowac odpowiednia biblioteke dla klienta (podobnie jak to ma miejsce w COM lub CORBA) tak, zeby ponownie mozna bylo oporowac bezposrednio na obiektach (fe. user->village->food() ).
tak wiec moja odpowiedz na Twoje pytanie brzmi "tak myslalem, a nawet wlasnie to robie" ;)

@mINA87:
to z czym wyszedl wlasnie Goliatus zalatiwa w pewien sposob sprawe lagow - mozna srobic czesci gry, a wiem mamy juz chyba zalatwione wszystkie punkty z Twojej listy. Musze jednak uczciwie przyznac, ze musza tu istniec pewne szczegolne warunki, zeby to co ustalilismy trzymalo sie kupy - zgadzam sie z Toba, ze niewielkie, amatorkie oraz pisane na szybko projekty (przy czym wystarczy spelnic jeden z tych 3 waronkow) sie tu nie lapia

sprawa instalacji serwera u gracza to IMO zaden klopot - przecierz to nie musi byc zaden apache, napisanie wlasnego (prostego) serwera www to banal, zreszta sa przecierz gotowce - jesli go ladnie wkomponowac to gracz nawet by nie wiedzial, ze po zainstalowaniu gry ma na kompie serwer www czy bardziej ogolnie server proxy gry (bo to zdaje sie Goliatus ma na mysli)

edit: do pomyslu z p2p jeszcze nie potrafie sie ustosunkowac...

Offline mINA87

  • Użytkownik

# Maj 03, 2007, 20:58:31
Brzmi samkowicie :]
Ciekawe jak byłoby z grywalnością takiej globalnej bitwy na tysiące jednostek, gdzie każdy gracz sterowałby jedną z nich :)
Zawsze możemy uderzyć do Akademii Podlaskiej (zaoferowali się, że udostępnią serwerki do projektu MMO) i zacząć się bawić w tworzenie takiego globalnego projektu w oparciu o sieci p2p :P

peter: nie do końca, bo jeśli przerzucimy zbyt dużo logiki na stronę klienta to tracimy arbitrażową kontrolę nad światem i stwarzamy ryzyko desynchronizacji gdy inni klienci będą się odnosić do naszych danych. Ciągle boję się o tą synchronizację - ona tutaj będzie determinowała i przesuwała wskaźnik między spójnością świata a szybkim czasem reakcji.

Odnośnie serwa www - nic to nie daje. Nie przeskoczysz w ten sposób o klasę z "prawie" real-time'u do real-time'u zachowując pełną kompatybilność.

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Maj 03, 2007, 21:00:34
Chyba nie chodzi o przerzucanie logiki, ale o pewne czasochłonne obliczenia, że np. dostajesz dane początkowe do bitwy(lub jej fragmentu) i musisz wyliczyć jej przebieg(np. jakąś 2d animację) i wynik.