Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[idea] realtime multiplayer flash/php/mysql

0 views
Skip to first unread message

Milosz Szarek

unread,
May 26, 2003, 1:38:12 PM5/26/03
to
Witam grupowiczow!
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?

--
pozdr ox team


Lemat

unread,
May 26, 2003, 2:56:59 PM5/26/03
to
Użytkownik Milosz Szarek napisał:

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

Milosz Szarek

unread,
May 26, 2003, 3:34:29 PM5/26/03
to

Użytkownik "Lemat" <lemat_ha...@tenbit.very_very.pl> napisał w
wiadomości news:bato72$ipm$1...@atlantis.news.tpi.pl...

> Szukaj w temacie JAVA (JAVA!=JavaScript)
> bo PHP nadaje się raczej na gry turowe...

dlaczego "raczej"?
i dlaczego java vs php? :)


Marcin FORSETI Paździora

unread,
May 30, 2003, 4:11:52 AM5/30/03
to
Witaj Lemat,

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

Milosz Szarek

unread,
May 30, 2003, 8:45:26 AM5/30/03
to
> 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ę
bez crona sie obejdzie chyba?

> 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?


0 new messages