--
pozdr ox team
Szukaj w temacie JAVA (JAVA!=JavaScript)
bo PHP nadaje się raczej na gry turowe...
--
Pozdrawiam
Lemat - www.jade.pl
RTFM->www.php.net/manual/pl
MySQL->www.mysql.com
> Szukaj w temacie JAVA (JAVA!=JavaScript)
> bo PHP nadaje się raczej na gry turowe...
dlaczego "raczej"?
i dlaczego java vs php? :)
W Twoim liście datowanym 26 maja 2003 (20:56:59) można przeczytać:
L> Użytkownik Milosz Szarek napisał:
>> Moze nie jest to temat na te grupe, ale niebardzo wiem gdzie napisac.
>> Interesuja mnie wszelkie informacje techniczne na ten temat i o probach
>> tworzenia czegos podobnego. Projekt serwera jest w fazie konceptualniej :)
>> Jezeli spotkaliscie sie juz z czyms takim to prosze o linki do "arykulow" w
>> sieci.
>> A moze macie wlasne wizje/osiagniecia w temacie?
L> Szukaj w temacie JAVA (JAVA!=JavaScript)
L> bo PHP nadaje się raczej na gry turowe...
Ano właśnie. Masz może jakieś doświadczenie jak?
Chodzi o schemat działania serwera typu Red Dragon (kilkanaście tur
dla gracza + jedna na interakcję między graczami).
Ja wyobrażam to sobie tak:
1. cron odpala skrypt inkrementujący turę
2. lookup do bazy danych do tabeli z zadaniami na tą turę
3. zagregowanie i wykonanie zadań
4. oczekiwanie na zalogowanie gracza
5. przydzielenie graczowi ilości tur
5a. wyszukanie, zagregowanie i wykonanie zadań na tą turę
5b. rozpoczęcie tury
5c. serwowanie żądanych przez gracza danych i zapisywanie decyzji
5d. zapisanie zadań do tabeli zadań i odroczenie tych, które są
interakcją z innym graczem
5e. koniec tury
5f. (zostało_tur == 0) ? wyloguj : następna tura
Ale mam wrażenie, że można jakoś lepiej.
--
Marcin FORSETI Paździora
I rzekł Mistrz Programista:
"Po trzech dniach bez programowania,
życie staje się pozbawione sensu."
--
Archiwum grupy: http://niusy.onet.pl/pl.comp.lang.php
> 2. lookup do bazy danych do tabeli z zadaniami na tą turę
ok
> 3. zagregowanie i wykonanie zadań
ok
> 4. oczekiwanie na zalogowanie gracza
> 5. przydzielenie graczowi ilości tur
> 5a. wyszukanie, zagregowanie i wykonanie zadań na tą turę
> 5b. rozpoczęcie tury
> 5c. serwowanie żądanych przez gracza danych i zapisywanie decyzji
no dobrze, ale co jak dane "zgina" po drodze z serwera do flesza?
zadamy jeszcze raz?
zadane dane to u mnie akurat dane ktora maja byc wyslane do usera (tabela
COM: adresat, msg)
wiec wyciagam takowe dane i wysylam (u mnie te dane przychodza w roznym
czasie od roznych userow i na bierzaco wyslwietlam u kazdego usera stan
gry - tury czasowe, bo trudno czekac w nieskonczonosc na przybycie danych)
wiec zeby zminimalizowac przeplyw wysylam takie dane tylko raz (klient nie
wie czego zadac) i chce miec pewnosc ze zostaly one odebrane (RAZ). po
wyslaniu kasuje je z tabeli COM. i tutaj pulapka....
co gdy dane nie dotra do klienta? myslalem o identyfikowaniu "pakietow"
danych i wysylaniu takiego id do klienta. jezeli odebral to zwraca to id i
kasujemy te paczke z tabeli (no i biezemy nastepne)
to samo w druga strone z flesza do php.
oczywiscie w twoim przypadku mozna tez rozrozniac dane w/g nru tury.
ale jakby chodzi o to zeby stworzyc cos uniwersalnego (abstrachowac od
przesylania) - gdybym mial "warstwe" mojej aplikacji ktora zapewnia mi taka
wymiane danych to byloby idealnie.
i to wlasnie chce napisac (w php i w as)
reszta to zakodowanie systemu gry w oparciu o taka wlasnie warstwe.
brzmi (bez)sensownie? :)
> 5d. zapisanie zadań do tabeli zadań i odroczenie tych, które są
> interakcją z innym graczem
> 5e. koniec tury
> 5f. (zostało_tur == 0) ? wyloguj : następna tura
>
> Ale mam wrażenie, że można jakoś lepiej.
tez mam takie wrazenie :)
a wogole to moze kombinuje jak kon pod gore?