Apache jako serwer gry przeglądarkowej

Witam! Czy można wykorzystać apache jako serwer gry przeglądarkowej? Tak aby tak jak to robi na żądania użytkownikó wywyłał im strony ale oprócz tego posiadał jakąś nieskonczoną pętle zawierającą timery itp.

Sam Apache nie. Potrzebujesz jeszcze jakiś inny proces zajmujący się logiką rozgrywki. Przykładowo dla Railsów może być to DelayedJob lub Resque.

?? Railsy, DelayedJob, Resque?? co to?
Ten inny proces to mam rozumieć że na tym samym fizycznym serwerze jakiś programik c++? i w jaki sposób będzie on się komunikował zuzytkownikami? przez baze danych czy sockety jakieś czy co?

W dowolnym miejscu, komunikacja dowolna, byle by wymiana była płynna. Dobrym pomysłem jest np. Redis, RabbitMQ czy MemchacheQ.

hmm, mógłbyś np podać swoje gg? Wtedy bym się ciebie jeszcze szybko o pare rzeczy spyał, bo nie wszystko rozumiem.

A nie możesz tych nazw wpisać w Google i poczytać co do czego? :/

prawie wszystko jest po angielsku i niestety nie rozumiem dokładnie

ale ten model co podalem jest prawidłowy?
stronka w php na apachu + na tym samym fizycznym serwie jakiś program c++ zawierający timery i przeliczający + jakieś połączeni między nimi (nie mam pojęcia jakie!!!)

Bez znajomości angielskiego i w tym wieku (wiem z dokładnością do 2-3 lat ile masz lat) to się nie masz co brać za coś takiego. No i wypada doliczyć do tego brak znajomości programowania pod webdeveloperkę (to, że coś liznąłeś to zdecydowanie za mało). W skrócie - takie gry tworzą długimi miesiącami ekipy doświadczonych programistów. Ty sam, bez angielskiego, bez wiedzy, zaczepiając kogoś na gg chcesz się za coś takiego brać?

Nie chcę przekreślać Twoich ambicji, nie o to mi chodzi - pisz tę grę, życzę Ci z całego serca powodzenia, ale ZANIM zaczniesz ją pisać - masz przed sobą mnóstwo innych rzeczy do nauczenia się i wiele projektów z jasnymi celami do zrealizowana.

spox, no z angielkskim jest problem, ale w c++ już robie sporo lat, a teraz się biore na razie za poznanie jak działają gry internetowe, bo w sumie wszystkie języki do tego znam. No może PHP w zbyt małym stopniu, dlatego ciągle się douczam. A po drugie to nie chce robić żadnej dużej gry, tylko domowy projekt dla satysjakcji i poznania ogólneo mechanizmu.

To po co w ogóle php? To jak używanie silnika z kosiarki w najnowszym Ferrari.

Weź taki libevent i napisz całość w c++, zapewne też znajdzie się trochę silników szablonów, np. ctemplate

@lubie placki, to nienajlepszy pomysł. Lepiej napisać to w czymś co stosuje się do aplikacji webowych (Ruby, Python, Java, C#) + jakiś message queue + worker. Przykładowe połączenie podałem. Wtedy najzwyczajniej w świecie, gdy ktoś wykonuje akcję w grze to masz informacje kiedy ona się skończy oraz worker w odpowiednim momencie wykona wszelkie potrzebne obliczenia. Używanie C++ jako samej apki to zły pomysł, jako workera to wciąż nienajlepszy, ale już bardziej inteligentny niż jako samą grę. Pamiętaj jednak, by komunikacja szła przez jakiś kanał "niewebowy" w sensie, by nikt nie mógł na nią wpłynąć, np. poprzez bazę danych (najlepiej chyba by była to baza KV, bo będzie najszybciej i najwydajniej).

musze sie chyba jednak porządnie dokształcić bo w ogóle nie rozumiem o czym do mnie mówiesz (message queue, worker ;p)
problem jest tylko taki, że mało gdzie o tym piszą, przynajmniej ja nic ciekawego nieznalazłem

Wygląda to mniej więcej tak:

1. Użytkownik/gracz naciska przycisk odpowiedzialny za akcję mającą wystąpić w przyszłości (wysłanie wojska/wyruszenie na misję/etc.)
2. Gra dodaje do bazy danych (message queue) wiadomość zawierającą wszelkie parametry potrzebne do wywołania funkcji (np. w formacie JSON)
3. Zewnętrzny proces (worker) w odpowiednim momencie wykonuje zadaną akcję.

Prościej już chyba opisać się tego nie da.

Aha, dzięki teraz już o wiele więcej rozumiem ;) Jeśli jeszcze moge zapytać to:
gdy ten użytykownik naciska ten przycisk to mam rozumieć że wywołuje (np poprzez php) żądanie do bazy danych, które zapisuje np w tabeli actions, polecenie do wykonania przez tego workera. Natomiast worker pobiera z tej tabeli dany rekord i go przetwarza (wykonuje). tak? dobrze rozumiem?

moje 3 lata na infie w liceum przerobiłem sam w rok w domu i to w gimnazjum :D i wiem jak każdy poważny użytkownik że bez eng się nie obejdzie, ty nawet nie masz pomysłu jak coś takiego zbudować... popatrz sobie na xnova (klon ogame) albo gladiatusa jest tego pełno, co prawda w PHP ale przecież możesz się nauczyć jak sam powiedziałeś :D, masz także coś takiego jak WebServices to podchodzi pod IIS windy choc pod apache też da się pisać, albo użyj jakiegoś prostego silnika HTTP na pewno są jakieś do C, ja przynajmniej 3 widziałem pod Delphi z tego co kojarzę to Synapse i ICS (z http://overbyte.be) mają takie silniczki. Chociaż najlepszym rozwiązaniem byłoby jak kolega wspomniał napisanie dllki pod apache albo użyć CGI czy pear

no spox, ale to co napisałem w poprzednim poście to prawda?

Zależy czego używasz i co chcesz stworzyć, ale z poziomu PHP to mniej więcej tak wygląda, jak dla gier typu ogame gdzie nie ma bezpośredniej interakcji między userami to styknie, ale minecraft czy runescape to za mało :D
Najpierw ustal co chcesz osiągnąć i jak jakich technologi chcesz użyć :D

tak, no chodzi o gre pokroju ogame ogame. Jakbym miał się zabrać za minecrafta (oczywiście 1*10^10 razy gorszego) to myśle że bym sobie napisał serwa w c++ w całoci i jeśli klienkt miałby być c++ i korzystać np z open gl to myśle że dużo lepiej bym sobie poradził niz z nawet prościutką grą przeglądarkową.

http://proqixproj.comze.com/ogame.zip

dzięki, na pewno to przeanalizuje, chociać nie wiem od czego zacząć

Skąd wiecie ze ogame jest w czystym PHPie? Jak kiedyś w to grałem po zachowaniu miałem przynajmniej kilka powodów i podejrzeń żeby przypuszczać, że stoi tam jeszcze jakiś serwer i koordynuje wszystkie zdarzenia zależne od czasu. Tak to się robi profesjonalnie.

Co do kodu proqixa trzymałbym nieco dystansu, szczególnie ze względu na jego współczynnik reputacji na forum...

winerfresh napisał(a):

Wygląda to mniej więcej tak:

1. Użytkownik/gracz naciska przycisk odpowiedzialny za akcję mającą wystąpić w przyszłości (wysłanie wojska/wyruszenie na misję/etc.)
2. Gra dodaje do bazy danych (message queue) wiadomość zawierającą wszelkie parametry potrzebne do wywołania funkcji (np. w formacie JSON)
3. Zewnętrzny proces (worker) w odpowiednim momencie wykonuje zadaną akcję.

Prościej już chyba opisać się tego nie da.

Przepraszam za moją niwiedzę ale chciałbym się jeszcze o czymś upewnić.
"# Gra dodaje do bazy danych (message queue) wiadomość zawierającą wszelkie parametry potrzebne do wywołania funkcji (np. w formacie JSON)" - tzn że dodaje na końcu jakiejś tabeli rekord do wykonania?
i drugie. czym może być ten worker?

Koniec, początek, to nie ma znaczenia, w szczególności, że najlepiej użyć bazy, która nie ma czegoś takiego jak początek i koniec, ba nie ma nawet tabel.
Worker to dodatkowy proces, który zajmuje się tylko i włącznie pracą nad danymi, zero interakcji z użyszkodnikiem.

skoro nie ma końca to skąd worker wie który rekord preanalizować najpierw? i po przeanalizowaniu kasuje go? btw ten worker ma jeden wątek i przetważa rekordy jeden po drugim?

Po prostu - wykonuje zdarzenia które powinny się zdarzyć w aktualnym czasie. Nic więcej.

skoro nie ma żadnego porządku to skąd ma wiedzieć co akurat wykonać? niby może za każdym razem porównywać cok iedy się kończy czy coś ale to chyba nie będzie najwydajniejsze :/

Baza danych/kolejka/wtf powinna przekazywać te dane do workera w odpowiednim momencie, a jak to zrobi to już jej problem.

@Demonical Monk
jemu właśnie chodzi o to jak to działa, koleś sobie klika buduj zamek i co dalej np wysyła to do servera, i np php dodaje sobie to do bazy danych że budynek się zbuduje CzasAktualny+1h i worker opiepsza bazę co sekundę i jak trafi na rekord o tej godzinie to go wykonuje, a kolesiowi i innym graczom się pokazuje że jest koxem bo sobie zamek postawił. (schemat który zaprezentowałem jest dość prymitywny, ale myślę że wystarczy)

Nie ma sensu do tego używać takiej bazy, którą będzie trzeba pytać co sekundę. Winerfresh linkował warte uwagi rzeczy.