Gra internetowa, sposoby, optymalność, rozszerzalność Opcje

[KG-]

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.

Ten post edytował KG- 6.09.2006, 09:53:57

[Cobretti]

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.

[Turgon]

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

[raikou]

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.

[Turgon]

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.

[Fuzja]

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

[Ociu]

Po co ci po za tym silnik ? Wystarczy Framework i trochę chęci

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.

[Turgon]

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

[Cobretti]

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.

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

[SHiP]

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.

[D4rky]

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

[TrAvIkK]

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.

A) Jakbyście zapisali ustawienia użytkownika typu np: avatar, czy domyślne ustawienia wojska?

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

B ) Umieszczanie możliwych do budowy budynków, posiadania wojska?

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

B.a)Oraz do tego wymagania?

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

C) Umieszczanie w tabeli posiadane

Zdecydowanie nowa tabela

b ) wojsko
Czy optymalne jest umieszczanie każdej jednostki w nowym wierszu?

Ale jak rozumiesz każdej jednostki ?

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 tongue.gif

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!

[KG-]

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.

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

Ten post edytował KG- 21.12.2006, 18:11:01