Witam
Jeśli taki temat już był, to proszę, podajcie mi linka.

A więc:
Chce stworzyć grę internetową w php, typu OGame itd..
Gra była by rozbudowana, i dlatego chciałbym aby była łatwo rozszerzana, wykorzystam oczywiście szablony i pliki językowe..., oraz będzie napisana obiektowo.

Chciałbym abyście przedstawili inne, lepsze rozwiązania :


Dobrym rozwiązaniem byłoby dodawanie kolumn do tabeli użytkowników i/lub inna tabela z domyślnymi ustawieniami?

Lepszym rozwiązaniem byłoby stworzenie jednej tabeli z kolumnami właściwości, czy inna tabela dla każdego typu?

Ja to widze tak: do każdej tabeli dodaje kolumny.


a) budynki
Lepiej stworzyć nową tabele, czy dodać kolumny do tabeli użytkownika?
b ) wojsko
Czy optymalne jest umieszczanie każdej jednostki w nowym wierszu?


Może to być także złudzenie, a surowce dodawane były by przy interakcjii z użytkownikiem.
Wyczytałem że odpalanie skryptu co sekunde jest mało optymalne

Powiedzmy że user buduje kopalnie która powstanie za 2.5h
Czy zrobienie tego sposobem jak wyżej, przy czym są pewne priorytety, czyt. obliczane są surowce wyprodukowane przez kopalnie, do momentu ataku przeciwnika, po czym są dalej liczone, lub poprostu w momencie ataku przeliczane są sorowce na czas ataku, jest dobre?

Mam nadzieje że podchodzi pod pro .

Z góry dzięki za odpowiedzi

To nie ma nic wspolnego z Pro - patrzac na pytanie jakie zadajesz moge dac Ci jedna rade - daj sobie na luz.

Skala projektu przerasta niejednego (w tym mnie). To co proponujesz to nie zabawa na 2 tygodnie, tylko na co najmniej 6 miesięcy i to kilkuosobowego zespołu. Przyłączam się do NuLLa - daj na wstrzymanie.

Ponieważ sam pisze gre internetową podpowiem Ci jak można rozwiązać pare kwestii:



Ponieważ w mojej grze nie ma itemów tak więc w tej kwestii raczej nic Ci nie podpowiem. Co do budynków u siebie mam tabelę buildins w której znajduje się kolumna userId i np. kopalnie, chatkiMysliwych itp. w nich znajduje się ilość danych budynków posiadanych przez danego gracza.



Według mnie to jest bez sensu, wymagania możesz zakodować na sztywno w php.



Patrz to co napisałem na samym początku.



Co sekunde ? Według mnie to przesada, u mnie jest to co godzine. Jak ? Bardzo prosto: mam sobie tabelę resources i np. dwie kolumny:
wegiel i wegielCoTure. Raz na godzinę robie sobie zapytanie(pisane z głowy dosyć prostę chociaż nie wiem czy jest dobre):

[SQL] pobierz, plaintext 
UPDATE `resources` SET `wegiel`=`wegiel`+`wegielCoTure`
[SQL] pobierz, plaintext 

Jak masz więcej surowców to po prostu dodajesz sobie dalsze warunki.



U mnie znajduje się tabela w bazie danych o nazwie actions gdzie znajduje się nazwa akcji oraz kiedy ma się wykonać.

Wg mnie są dwa wyjścia:

1. pętla wykonująca się w nieskończoność np.

[PHP] pobierz, plaintext 
<?php
while(1) {
// i tutaj jeżeli czas wykonania danego przebiegu pętli jest większy od czasu akcj
i to wykonujemy akcję.
}
?>
[PHP] pobierz, plaintext 

2. Skrypt wywoływany cronem co np. 5 sekund który sprawdza czy akcja powinna się wykonać

No i to chyba tyle.

Polecam przeczytać ten temat: http://forum.php.pl/index.php?showtopic=30928

Pozdrawiam

A do tworzenia wojsk przyda się na pewno wzorzec Composite (kompozycja)
http://devzone.zend.com/node/view/id/7

Niezly sposob na zarzniecie maszyny

@Matrach: popieram zdanie poprzednikow, jezeli masz takie problemy juz na etapie projektowania, to moze lepiej daruj sobie ten skrypt, napisz cos prostszego prosty CMS, lub Forum.

postaram sie krotko odpowiedziec jak ja to widze:

Ad. A) serializacja odpada, trzeba byc konsekwentnym, jesli trzymasz dane w bazie to trzymaj tam wszystkie (czyt. wiekszosc), ulatwi to m.in. wyszukiwanie

Ad. B ) zalezy jakich umiejetnosci

Ad. Ca) tak, kolumny w tabeli: np.
id | budynek | wymagania_zlota | wymagania_drewna | wymagania_srebra

Ad. D) ja bym to rozwiazal tak:
tabela: budynki_uzytkownika
id_uzytkownika | id_budynku | procent_budowy

Ad. E) F) crona bym nie radzil uzywac w tym przypadku
ilosc danych jakie kopalnia nam dala, nie musi byc dla nas znana co sekunde, wystarczy te dane obliczac w momencie zadania pokazania danej wartosci

np. mamy kopalnie ktora daje nam 1 zloto co 5 sekund
przed zamknieciem przegladarki mieliscmy powiedzmy 120 zlota
po co mamy na darmo uruchamiac co 5 sekund zapytanie do bazy i aktualizowac dane, wystarczy w momencie wejscia uzytkownika do serwisu (np. po uplywie 2 godzin) obliczyc i wyswietlic aktualna ilosc zlota.

w tym celu potrzebne bedzie zapisywanie daty wyjscia uzytkownika z serwisu, a nastepnie obliczenie czasu nieobecnosci usera (czas_powrotu-czas_wyjscia) podzielenie tego przez 5 (5 sekund, bo co tyle dostajemy 1 zlota) i aktualizacja zawartosci zlota w tabeli uzytkownika (120 zlota + obliczona wartosc)
chyba to jest logiczne, ale nie w kazdym przypadku sie sprawdzi.

Przypuscmy, ze budujemy jakas budowle, ktora ma zwiekszyc wydobycie zlota z 1 grudki na 2 grudki co 5 sekund. Wtedy w momencie zakonczenia budowy trzeba by uruchomic przez crona funkcje, ktora zwiekszy nam liczbe grudek wydobywanych przez dana kopalnie i zapisze czas w ktorym ta zmiana nastapila, lub jak kto woli nie trywialne rozwiazania - obliczyc to w momencie powrotu uzytkownika, ale konieczne bedzie uwzglednie tego momentu zmiany (zakonczenia budowy).

Przyznam sie, ze nie pisalem nigdy gry internetowej, ale z powyzszych rozwiazan bym chyba korzystal.

To był tylko przykład, zdaje sobie sprawę że bardzo łatwo czymś takim "zabić" serwer . Chociaż jak narazie nie widzę innego rozwiązania.

Pozdrawiam

Czy ja mam tu jakieś problemy? Ja sie pytam czy znacie lepsze rozwiązanie od tech króre podałem w komentarzach.

Co do E) i F) to znalazłem odpowiedz, przeliczanie będzie sie wykonywało w momencie interakcii z użytkownikiem. A serializacja tylko mi przeleciała przez myśl

Mam wrazenie, ze 1 post byl postem w stylu, podrzuccie mi cala logike (czyt. Jak przechowywac rozne typy obiektow w bazie, jak zrobic to, jak zrobic tamto)

Mysle ze sam powinienes sie nad tym zastanowic i pisac dopiero z wlasna propozycja - tzn: Co myslicie nad tym, ze to i to rozwiaze w taki a taki sposob.

Rowniez odnioslem wrazenie, ze nawet nie masz scenariusza napisanego - ale moge sie mylic Scenariusz przy grze to podstawa, bez tego nawet nie zaczynaj programowac, a nawet planowac.

Teraz lepiej?

Odrazu widać Mam narazie ogólnokształt, wiem że podstawa, ale ja staram się najpierw wymyślić sposób, a potem jak to będzie wygladać. W przeciwnym wypadku, mogłoby sie okazać, że musze z czegoś zrezygnować, a jeśli z czegoś zrezygnuje to będe musiał i z czegoś innego zrezygnować itd.

Skoro to już pro (a na taki raczej ten temat nie wygląda) to powinieneś wiedzieć że gre zaczyna sie pisać od scenariusza (tzn co ma być, jak ma funkcjinować) a dopiero potem sie planuje jak.

~Bora mylisz się moim zdaniem. Wg. Ciebie jeśli zmieni się scenariusz to ma się zmienic engine gry?
Nie, oczywiście że nie.

Grę moim zdaniem zaczyna się pisać od stworzenia środowiska, oprogramowania, e.t.c.

oj mike_mech, poczytaj artykuły na warsztacie ( http://regedit.gamedev.pl/warsztat/ ) jak się gry tworzy

@mike_mech: Scenariusz gry nie obejmuje tylko historyjki jaką zobaczysz na stronie głównej przed zalogowaniem się. To także opcje programu, założenia, możliwości. Nie stworzysz engine-u gry nie mając tego w dobry sposób zaplanowane i rozpisane. Chyba że mowisz o engine-ie typu 'klasa dla bazy danych' i 'klasa dla szablonów' ale w takim razie z samą grą to ma tyle wspólnego co z każdą inną stroną napisaną w php.

@matrach: Wydaje mi się że musisz się nauczyć mierzyć siły na zamiary, poważnie. Już sam fakt, że chcesz umieszczać informacje typu możliwość wybudowania danego budynku i jego wymagania (może jeszcze opisy budynków?) w bazie danych świadczy o tym że jeszcze długa droga przed Tobą. Fajnie że chcesz podjąć jakieś wyzwanie, nauczyć się czegoś nowego w praktyce ale wierz mi że zaprojektowanie i zaprogramowanie gry nie jest wcale takie proste jak Ci sie wydaje.

Pozdrawiam.

Witam
Napisanie gry to duże wyzwanie i ciekawe.
Ja bym uzył do tego oracla i cały engine na bazie i nie bawił bym sie w crony czy phpcli.
A php zastosował bym tylko jako prezentacja.
W sumie też w zależosci od tego jaka to by miała być gra jak turowa to może być w php jesli real time to raczej np. w C#. Bo jakoś js mnie nie przekonuje:D

Jeżeli chodzi o pisanie gry to najlepiej wyglądałoby to w flashu jako prezentacja danych, łądnie podpiąć php do przesyłu danych, a jako baza to postgres lub mysql bo oracle to troche droga licencja.

Wydaje mi się że jemu chodziło o grę opartą o przeglądarkę, nie o klienta napisanego w C#.

Po drugie gra może być pseudo-realtime, czyli może ci się tylko wydawać że toczy się w czasie rzeczywistym, w ten sposób działa kilka gier online opartych o przeglądarkę na naszym rynku.

Co do real time to tak naprawde real time nie moze to byc, bo to sa systemy oparte o jezyki skryptowe jak np php, a nie dzialajace w tle serwery tej gry, ktore ciagle cos robia, ale da sie to obejsc. Gracz rpzeciez nie widzi ciagle zmianiajacych sie wartosci surowcow itp, tylko dopiero jak przeladuje strone, wiec wtedy powinno byc wszystko przeliczane. Ewentualnie jesli tego gracza nie ma a ktos robic cos co ma wplyw na jego wojsko, surowce itp, to tez nalezaloby przeliczyc surowce itp. tego gracza.

Tworzenie tego typu gier to proces dosc zlozony, nie trzeba wbrew pozorom miec od razu calego planu, ale jakis zarys silnika musi byc aby to pozniej rozplanowac. Pozatym jak juz ktos napisal tego nie tworzy sie w tydzien, tylko to jest kilka miesiecy zmudnej pracy (min 2 aby zrobic jakis poczatkowy silnik), tym bardziej ze sama gra zazwyczaj sie zmienia wedlug sugestii pierwszych graczy.

A co do pierwszego posta to nie licz na to, ze ktos Ci zaprojektuje ja za Ciebie, jak chcesz cos takiego stworzyc to musisz sie sam wziasc za to, wiekszosc tego typu projektow pada po jakims czasie, bo nie ma kto nad tym pracowac.

A i nie trzeba wbrew pozorom wielkiej ekipy ludzi do tego, wystarczy jeden programista i jakis grafik i juz sobie poradza.

a co powiesz o FarCry i Crytek?? przeciez najpierw był engine a dopiero później żeby go sprzedawać napisali do niego grę. A co powiesz o engine najnowszego Unreal Tournament? gra wydaje się być także jedynie prezentacją ponieważ engine pozwala stworzyć FPS, RTS, RPG (? - jak ja nienawidze tej nazwy), Przygodówkę, Bilarda... i co tylko sobie zapragniesz. Chodzą nawet pogłoski że na engine UT można zrobić system operacyjny

Jeżeli chodzi i temat to zgadzam się jednak z przedmówcami... mimo iż nie masz scenariusza i tak powienieneś zdać sobie szybciutko sprawę, że to co stworzysz teraz będzie na pewno niegrywalne i po skończeniu albo jeszcze przed porzucisz projekt. Aczkolwiek jako trening możesz to zastosować (polecał bym jednak księgę gości, forum, moze nawet galerie z zastosowaniem drzewek i obsługa modelowania miniaturek)

Tutaj jest więcej problemów do rozwiązania i to na wcześniejszym etapie (planowanie, projektowanie ?) niż ten, od którego zacząłeś.

Konkludując - nie spodziewaj się zbyt wiele, a najlepiej nie spodziewaj się niczego... tzn niczego to akurat mozesz się spodziewać

@Pianandrill: no ok, ale zauwaz ze takie enginy to kobyly ktore wszystko sa w stanie zrobic... Tak? Sam napisales od fpp po strategie, a nawet bilard... Jak chcesz napisac sobie gre sam, z kumplami, nie majac enginu, to Robisz najpierw scenariusz zeby wiedziec czego potrzebowac do pisania, z jakiego jezyka skorzystac, jak ma sie grac via www, czy tez aplikacja okienkowa, czy po prostu gra w c# + directX. To wszystko okresla scenariusz. A pozniej siadacie do kodowania i wiecie co kodowac czego nie.

Mowisz Ze w FarCry i Crytek najpierw byl engine. A ja powiem, ze napewno ten engine kreowal sie z czasem, napisali jedna gre, pozniej druga, pozniej kolejna. Mieli doswiadczenie i wiedzieli jak zrobic super engine ktory pociagnie jeszcze wiecej. I napisali engine, na ktorym pozniej stworzyli gre...

Jesli zazcynasz od 0, to nie piszesz enginu, tylko scenariusz. Majac scenariusz zastanawiasz sie jak to napisac. Taka jest kolej rzeczy. Mozna na odwrot, ale po co rzucac sobie klody pod nogi? To jest tak jak z tworzeniem stron. Chcesz zrobic portal, nie majac doswiadczenia - najpierw okreslasz co chcesz osiagnac, a pozniej realizujesz ten cel jakimis srodkami. Pisanie portalu bez wiedzy bez wyobrazni jak ma wygladac, karze ciebie na porazke.

Pianandrill
Ja również się nie zgodzę z kwestią engine-u. Inny engine będzie miała gra handlowa, inny gra rpg a jeszcze inny np scrabble. Chyba że mówisz o engine typu obsługa bazy, szablonów, system wiadomości, ale to, jak już pisałem wcześniej, ma tyle wspólnego z samą grą co każda inna strona pisana w php
Innymi słowy - jeśli chcesz coś napisać to musisz wiedzieć co to będzie. Poczynić pewne założenia, cele i do tego dążyć. Inaczej wyjdzie niewiadomo co, lub porzucisz projekt w połowie.

Oczywiście potem taki silnik możesz rozbudować, stworzyć modyfikacje na jego podstawie, wykorzystać pewne jego części do modyfikacji gry itd. Ale pierwotna wersja powinna powstać na bazie czegoś ustalonego.

Tak, najpierw scenariusz, pozniej engine, a w rzeczywistosci konczy sie wszystko tym, ze masz niby scenariusz, system jakis walki opracowany mniej wiecej do gry, a jak zaczynasz to pisac to wychodzi na to ze od strony programowania ten system walki jest bez sensu i wprowadzasz w nim kolejne zmiany


Pozniej osoby testujace gre mowia Ci ze ten system jest zupelnie bez sensu i sa kolejne zmiany.

Powiem tak, pisać będę grę w najbliższym czasie i powiem ci szczerze. Najpierw solidny scenariusz, a potem tylko ciągłe naprawianie i poprawianie. To niekończąca się droga.
Po co ci po za tym silnik ? Wystarczy Framework i trochę chęci

W sumie to gra sieciowa dla przeglądarki opiera się głównie na założeniach nie na silniku. Jeśli dobrze sobie wszystko obmyślisz, rozpiszesz, wymyślisz wzory na których to będzie działało, to napisanie tego nie będzie raczej problemem, niezależnie czy strukturalnie czy obiektowo.

Kwestią problematyczną może być obciążenie maszyny, skrypt naprawde powinien być jak najszybszy i możliwie najmniej bolesny dla dostępnych zasobów.

To wszystko wiąże się z armią betatesterów, którzy będą męczyć grę etc. tak, żeby sprawdzić ją.
Dlatego prosty Plan:
1. Scenariusz.
a) fabuła
gry
2. Kod.
a) engine
otoczka
3. Wygląd.
4. Betatestowanie.
a) jeśli coś nie pasuje przerabiamy efekt 2.
jak wszystko okej - publikacja
5. Użytkowanie.
a) ciągły powrót do etapu 4.

Zaprzeczasz Turgon sam sobie, raz piszesz, że silnik nie potrzebny, a potem w punkcie 2. wpisujesz go.

Wiesz o czym Ty piszesz ? Przecież framework to tak naprawde silnik.

Poza tym Twój plan jest tak ogólnikowy, jak to, że atomy istnieją. Nie jest powiedziane jak to wszystko współpracuje, co ma być w środku jądra, a co będzie tylko addonsem.

Ociu jak chcesz... Ja w tej chwilę kończę dopisywać konfiguracje do FrameWorka . Potem jak skończę Bloga, to napiszę o tym notkę

I dlatego raczej pisze sie strukturalnie. W tego typu projekcie uzytkownik bardzo dlugo jest zalogowany, duzo klika, a wiec dosc czesto silnik gry musi przeliczyc dla danego gracza jakies dane. Oszczedza sie na wszystkim, wlacznie z grafika, ktora powinna byc ladna, ale zarazem jak najmniej obciazac system.
Mozna tez dodac mozliwosc czytania grafiki z dysku, co duzo transferu moze oszczedzic jesli gracze zaczna tego uzywac.

A i nikt nie napisal Im bardziej popularna gra tym wiecej nerwow stracisz w rozmowach z graczami, tym czesciej jacys beda Cie oskarzali o oszustwa, pomaganie coniektorym graczom itp. Do tego tez sie trzeba przyzwyczaic

Myśle ze problem obiektowo - strukturalnie nie ma duzego znaczenia, to są naprawde cyfry po 8 miejscu po przecinku. Kiedyś pisałem taką gre i to rpg ;] i przyznam ze ciekawym elementem moze być silnik w ajaxie. W mojej grze gracz pobieral tylko co klikniecie małe pakieciki zawierające jakies dane potrzebne do wyswietnienia danej opcji.

Cóż, ja sam w tej chwili piszę ogólnodostępny silnik do gry (rpgc0re). Może nie jest superpr0, nie 1337uje itp, ale na pewno jest lepszy od tego syfu, co teraz można ściagnąć (np Vallheru, GF2.5 itp). Porównywałem prędkościowo z Vallheru samo logowanie, i wyszło, że mój skrypt robi to 6x szybciej, ale to też kwestia mniejszej ilości kodu na głównej ;>

Jeżeli projekt aktualny...

Wymagania co do budynków zrobić w php...
Większej głupoty nie słyszałem.

Jeżeli będizesz chciał coś zmienić, to będziesz musiał przegrzebać pół kodu w odnalezieniu jednej linijki. Przy tym powstaną bugi, przypadek - X-Wars.

Najlepiej zapisać wszystkie wymagania w bazie. Baza to potęga.
Mozna zmienić wymagania jednym kliknięciem, i nic się nie wysypie.



Do danych użytkownika proponuje 2 tabele.

1. Tutaj będą dane dot. konta, np. login, alias, hasło, email...
2. Dane wymienione w cytacie

Do każdego typu "rzeczy" zrób osobną tabelę.


Wymagania zrób tak jak napisałem wyżej


Zdecydowanie nowa tabela


Ale jak rozumiesz każdej jednostki ?



Zdecydowanie tak, mało optymalne...
Najlepiej zrobić tabelę "klików"...
Umieszczasz w niej czas ostatniego kliknięcia, i potem od aktualnego czasu odlicas ów czas, i obliczasz wg. ustalonego wzoru ile surowców powinno przybyć.
Takie obliczenia będa przy każdej akcji - wybudowanie budynku, atak na Twoją planetę itp...


Sam pracuje nad grą, wraz ze znajomym. Minął miesiąc a ja nauczyłem się tyle, jak nigdy, więc nie zabieraj się do robienia, tylko rób!

Widzisz, różnica między nami polega na tym, że ja napisałem taką grę oraz mam w tym doświadczenie praktyczne również od strony administracji serwerem na którym stoi, Ty dopiero piszesz i uczysz się, a jednak wyśmiewasz to co powinno być właśnie w ten sposób zrobione.

Więc tak:
1) jeśli dobrze napiszesz kod, to zmiana czegokolwiek będzie polegała na prostej zmianie jednej liczby w jednym miejscu. Jeśli dodatkowo dobrze to zaplanujesz i pomyślisz to znalezienie miejsca do zmiany będzie kwestią 1-5 sekund. Chyba mi nie powiesz że zmieniając jedną liczbę spowodujesz bugi w kodzie
2) jeśli już napiszesz tę grę w taki sposób jak piszesz i wpuścisz na nią kilka tysięcy graczy którzy będą klikali w miarę często, to szybko zauważysz że mysql zabierze ci 90% procka, będzie się wieszał w trakcie zapytań a wszelkie lagi, spowolnienia i błędy będą wynikały właśnie w tego. Baza to potęga, ale jeśli się jej źle używa to szybko słabnie

Rozwiązaniem jest tutaj zastosowanie cache-u zapytań (który i tak będziesz musiał zastosować, inaczej nie wyrobisz nawet na Dual Opteronie z 4gb ramu; polecam do tego celu memcache), jednak wtedy po każdej zmianie będziesz musiał wyczyścić cache. Natomiast umieszczenie takich rzeczy w plikach sprawi że mając np. eacceleratora, xcache albo apc, pliki te będą prekompilowane i cache-owane automatycznie przez serwer.

Generalnie jak będziesz miał duży ruch, to będziesz kombinował jak ograniczyć ilość zapytań i jak najmniej korzystać z bazy, będziesz się zastanawiał nad każdym zapytaniem, strukturą bazy, jak to zrobić żeby było wydajniej, szybciej i mniej obciążało serwer. A Ty chcesz jeszcze dokładać bazie dodatkowe tabele i zapytania, na dodatek takie które są całkowicie zbędne.

Do tego dochodzi np sytuacja w której mając kilka serwerów będziesz chciał zmienić coś na wszystkich. W Twoim przypadku musisz się łączyć z każdą bazą i wykonywać zapytania, w przypadku plików po prostu używasz subversiona, który możesz zautomatyzować do tego stopnia że jednym kliknięciem będziesz aktualizował pliki nawet na 500 serwerach jednocześnie.

Pozdrawiam, powodzenia i życzę Wesołych Świąt

PS. Jak zrobisz tą grę to podeślij linka na PW, chętnie zobaczę, z góry dzięki