Jak wygląda pisanie gry przeglądarkowej?


(Edward 1) #1

Witam

 

Od dłuższego czasu zastanawiam się nad stworzeniem gry przeglądarkowej, coś w stylu farmy jak np. Zielone Imperium. na początek postanowiłem zrobić testową grę, na której mógłbym się uczyć. HTML i CSS znam na perfekt, z MySQL też sobie radzę, PHP jestem w trakcie nauki, z grafiką też sobie w miarę radzę. Jednak mam problem z tym jak zacząć pisać taką grę, jak to dokładnie wygląda. Przewertowałem masę poradników jednak nic z tego. Czy takie gry typowo się piszę jak strony www w np. Notepad++? Czy może wygląda to inaczej?


(rgabrysiak) #2

 

Dlatego też proszę zapoznać się z tym tematem: Poradnik zakładania i edycji tematu

A następnie korzystając z przycisku Edytuj i opcji Użyj pełnego edytora , dokonać korekty tytułu, tak aby konkretnie mówił o problemie.

W przeciwnym razie temat trafi do Kosza.


(somekind) #3

 

Do programowania czegokolwiek używa się raczej bardziej efektywnych narzędzi niż prosty edytor tekstowy.

 

Tak w skrócie proces wygląda tak: analiza wymagań, projekt, implementacja, testy, naprawianie błędów, ponowne testy, wdrożenie.


(rycerz2000) #4

Dołączam się do tematu bo mam pytanie także związane z grami przeglądarkowymi. Jaki język wybrać do napisania takiej gry? Mi konkretnie chodzi o grę 2d “wyścigową”. Że gracz wybiera samochód i następnie jest wyścig z innym graczem który polega na porównywaniu parametrów obu samochodów (gracz tylko czeka na wyniki)

Do autora: Znam HTML, PHP i radze sobie z CSS. Jakbyś robił jakąś grę przeglądarkową to ja mogę pomóc.


(Ryan) #5

Najczęściej stosowane podejście to:

  1. Napisać grę byle jak.

  2. Jeśli pojawi się problem z obciążeniem serwerów, ale gra przynosi zyski, to nie ma problemu: zatrudniasz kogoś kompetentnego, kto naprawi/przepisze Twój kod.

  3. Jeśli pojawi się problem z obciążeniem serwerów, a gra nie przynosi zysków, to łatasz samemu, albo projekt porzucasz.

Może to cyniczne podejście, ale w gruncie rzeczy jedyne, jeśli nie masz doświadczenia w dziedzinie, za którą się zabierasz. Bo na przestrzeni jednego projektu szalenie rozbudowanego doświadczenia nie nabędziesz.

A jak się pisze? Jak kto lubi. Jedni piszą w N++ (tak, są tacy ludzie), inni w dedykowanych IDE, jeszcze inni w VIMie. Ważne, żeby autorowi było wygodnie, a nie żeby było słusznie (cokolwiek to znaczy). Co i jak pisać zależy od tego, jaka to ma być gra.

  1. Gra turowa o niskiej częstotliwości (rzędu: raz na minutę) wymiany danych z serwerem (nie ma żywej interakcji z grą turową innego użytkownika)?

  2. Gra turowa, gdzie ze średnią częstotliwością (co kilka sekund) wymieniają się dane kilku użytkowników)?

  3. Gra czasu (prawie) rzeczywistego, gdzie zmiany u gracza A muszą znaleźć odzwierciedlenie u gracza B?

Poziom trudności rośnie od 1 do 3. W każdym przypadku znaczenie ma ilość przesyłanych danych między przeglądarką a serwerem, ale dla 2 i 3 ma też bardzo duże znaczenie jak mocno musi te dane obrabiać serwer (w pierwszym przypadku ma też oczywiście niezerowe znaczenia, ale nie jest szczególnie istotne na początku). Dodatkowo w przypadku 3. znaczenie ma nie tylko ilość danych, ale też akceptowalne opóźnienie (lag). I generalnie to słaby wybór dla gry przeglądarkowej w HTML+JS (chyba, że używa się nowoczesnych API, ale wtedy pytanie OPa nie pojawiłoby się na tym forum i nie miałoby postaci “jak wygląda pisanie gry X?”).

A poza tym, tak bardziej ogólnie, to proces wygląda tak, jak opisał go somekind. Prawdopodobnie najlepiej zacząć od gry “do poduszki” (no, może na githuba, żeby w portfolio była, ale nie na potrzeby produkcyjne), gdzie mechanika i warstwa wizualna ograniczone są do minimum, ale problemy do rozwiązania sa takie, jak w Waszym wymarzonym, docelowym projekcie. I tak na przykład jeśli marzycie o grze, gdzie gracze budują miasta, wydobywają surowce, wysyłają szpiegów do innych graczy, i tak dalej - zacznijcie od najprostszej możliwej mechaniki zbliżonej do tego (np. gracze dostają po 2 z 3 możliwych fabryk rzeczy i cyklicznie, co ileś minut im się produkują te rzeczy; rzeczy można wymieniać na ulepszenia fabryk, albo wymieniać z innymi graczami wg kursu 1 za 2; proste jak konstrukcja cepa, ale pozwala zapoznać się z trudnościami docelowej gry). Po szczegółowym opisaniu wymagań i opisaniu projektu, można przystąpić do implementacji. Taki prosty skończony projekt jest wart 100x więcej, niż ambitny, nieukończony projekt życia. Co więcej: coś tak małego macie szansę ukończyć mając 0 doświadczenia w temacie. I nauczycie się wystarczająco dużo, żeby zabrać się za kolejny, nieco bardziej ambitny projekt.

Powodzenia!


(Uzi123) #6

Mogę tylko potwierdzić większość uwag/zaleceń wydanych przez Ryan

 

Ja ze swojej strony dodam parę słów:

każda strona/gra przeglądarka składa się z dwóch podstawowych elementów: 

  1. wykonywany po stronie użytkownika

  2. wykonywana po stronie serwera

 

W idealnym przypadku, praktycznie wszystkie operacje wykonywane są po stronie użytkownika (1), a serwer służy tylko do

a) wysłania samego kodu gry do użytkownika

b) przesyłania i odbierania “dobrze upakowanych” informacji na temat zmian statusu u gracza/graczy

 

Każde odejście od tego modelu powoduje dość szybki wzrost obciążenia serwera i ilości wysyłanych danych. Tak więc polecam zapoznanie się dokładniejsze z jakąś technologią typu (na początek) JS, JQuery, ActionScript, Dart, Java itd. Na początek nie ma większego znaczenia jaką konkretną technologię wybierzecie, aczkolwiek później mogą być problemy z optymalizacją kodu. Oczywiście, im bardziej fikuśnych wtyczek będziecie wymagać, tym trudniej będzie wam znaleźć użytkowników.