Najczęściej stosowane podejście to:
-
Napisać grę byle jak.
-
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.
-
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.
-
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)?
-
Gra turowa, gdzie ze średnią częstotliwością (co kilka sekund) wymieniają się dane kilku użytkowników)?
-
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!