Autor Wątek: W czym sie teraz tworzy niewielkie gry przegladarkowe (multiplayer).  (Przeczytany 5055 razy)

Offline WhiteLightning

  • Użytkownik

# Kwiecień 14, 2015, 13:36:19
Mam pomysl na gre przegladarkowa rozgrywana w turach w kilka osob (gra statyczna jesli chodzi o wyswietlanie obrazkow i tekstu) na zasadzie ze gracz co kolejke wybiera jedna/kilka konkretnych akcji.

Gra ogolnie mala (niewiele danych i opcji). Do tego trwa powiedzmy 20 rund.

Moje pytanie, w jakich technologiach w tym momencie pisze sie takie rzeczy?

Przykladowo taki interface by mi w zupelnosci wystarczyl: http://desercik.pl/wp-content/uploads/2012/02/gra-my-shop-na-nk-3.jpg

Chetnie tez sie dowiem co warto uzyc pod spodem (serwer, db, etc.) A jesli ktos podzieli sie rowniez informacja w czym sie robi teraz duze gry przegladarkowe (np. Duma Szlachecka) to rowniez bede wdzieczny.
 

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline timus

  • Użytkownik

  • +1
# Kwiecień 14, 2015, 14:09:57
Z tego opisu i screena wnioskuje, że w tym przypadku wystarczy server-side scripting. Tu nie ma kwestii w jakich technologiach piszą inni, lecz w jakich tobie się dobrze pisze :) Możesz użyć popularnego ostatnio na warsztacie pythona czy tez niesławionego php, jak wolisz M$ to jest ASP.net, jak wolisz kod natywny to z CGI możesz pisać w C,C++ czy D , jak wolisz javascript to jest node.js, itd. Oczywiście to tego dorzuciłbym jeszcze jakąś bazę danych np. wszechobecny MySQL.

Co do samych gier przeglądarkach to swego czasu wszyscy pisali w php+MySQL+js, dziś w czasach emscripten i chmury takie gry można pisać dosłownie we wszystkim.

Offline WhiteLightning

  • Użytkownik

# Kwiecień 14, 2015, 14:29:44
timus - wlasnie problem jest taki ze jest tego za duzo. Ale i tak Twoja odpowiedz mi sporo rozjasnila.

Jeszcze sie doprecyzuje:

- PHP - odpada, pisalem w tym w pierwszej pracy 10 lat temu i wiecej nie chce.
- Dodatkowe zalozenie: chcialbym by to dzialalo na roznych platfrmach (powiedzmy Win+Android+Linux na poczatku, wiec MS i Silverlighty odpadaja). chcialbym tez by dalo sie na Linuxie developowac.
- gra faktycznie jest statyczna, ale chce ja potraktowac jako odbicie sie do czegos co juz bedzie zawierac w sobie dynamike.
- Lubie pisac w C# (XNA, ale to powoli sie robi martwa technologia wiec nie chce w to isc).
- Lubie LibGDX (w sumie uswiadomilem sobie teraz ze mozna to pozniej portowac do HTML5) wiec to chyba jest dobry pomysl?
- Rozwazalem tez Phasera w ramach nauki, ale tutaj jestem zielony z czym to spiac.



Offline timus

  • Użytkownik

  • +1
# Kwiecień 14, 2015, 15:29:09
Z takimi zalozeniami wybrał bym c# kilka powodów:
  • Istnieje projekt który pozwala odpalać xna i c# w przeglądarce(kompilacja bytecodu .NET do JS),
  • Dzięki mono c# można używać na linuxach,
  • Jest dobre IDE c# na linuxa,
  • Stronę server można prosto napisać w c#
Ale poczekaj jeszcze na odpowiedzi innych ludzi bo ja nie jestem wszechwiedzący i mogą być lepsze alternatywy.

Offline P@tyS

  • Użytkownik
    • Patys coding

  • +2
# Kwiecień 14, 2015, 15:37:00
Hej,
Też sie interesowałem tworzeniem gry w przeglądarce, coś tam zacząłem, coś działało, ale jakoś projekt upadł.
Ja wykorzystałem html5+js+phaser + socket.io po stronie klienta oraz node.js+socket.io+mongodb.
Dzięki temu miałem klient i server w tym samym języku (javascript), real-time i obsługę bazy danych.

Logowanie robisz po prostu przez socket.io i ją zabezpieczasz przed nieautoryzowanym dostępem.

Z tym mongodb to kwestia czego potrzebujesz, np on przechowuje wszystko w stylu jak json, możesz nawet trzymać funkcje. Może to byś też sql, co chcesz.

Jak potrzebny ci darmowy hosting do node.js i mongodb to polecam https://www.openshift.com/
Używam go za każdym razem gdy stawiam swoją stronkę :)

Offline Karol

  • Użytkownik

# Kwiecień 14, 2015, 15:57:43
- PHP - odpada, pisalem w tym w pierwszej pracy 10 lat temu i wiecej nie chce.
Przez 10 lat wiele się zmienia, z takim podejściem można odrzucić ~95%* technologii.

* wiadomo jak to jest z procentami w internetach :P

Offline 10log

  • Użytkownik

# Kwiecień 14, 2015, 16:02:54
Może spróbuj w http://cocos2d-x.org/products#cocos2d-js ?
Możesz pisać pod przeglądarkę albo skompilować natywną apke.

Offline BrunonDEV

  • Użytkownik
    • Construgia -- RPG

# Kwiecień 14, 2015, 17:08:46
Ja bym wybrał PHP* + JavaScript* + HTML5*. ;)

*PHP - tylko do takich czysto technicznych rzeczy, połączenie z bazą danych, logowanie/rejestracja, itp.

*JavaScript - ogólnie gra; grafika, logika.

*HTML5 - To raczej wiadomo. Podstawy. :)
« Ostatnia zmiana: Kwiecień 14, 2015, 17:28:18 wysłana przez BrunonDEV »

Offline wozix

  • Użytkownik

# Kwiecień 15, 2015, 00:57:11
Przy wyborze technologii zastanów się na ile logika może być przejrzysta dla script kiddiesów. Obfuscatory to nie do końca rozwiązanie.

Offline Xion

  • Redaktor
    • xion.log

  • +9
# Kwiecień 15, 2015, 09:42:40
Ach, znowu ten temat. Przydałoby się zrobić z tego jakiś FAQ czy coś w tym rodzaju, bo zahacza to już trochę o standardowe pytania typu "W jakim języku kodować?" albo "Czy pisać własny silnik czy nie?". Jakby co, to niniejszy post może służyć za podstawę ;-)

Zanim zdecydujemy się na wybór jakiejkolwiek technologii do jakiekolwiek zastosowania, zawsze należy określić kluczowe wymagania i założenia projektu. Problem w tym, że trudno to zrobić, jeśli nie miało się doświadczenia w podobnych projektach czy technologiach. Postaram się więc nieco wyklarować kilka podstawowych faktów.

"Gry przeglądarkowe" to tak naprawdę aplikacje webowe
Dobrze zdawać sobie z tego sprawę, bo wynikają z tego przynajmniej dwie kwestie: jedna niezbyt przyjemna, druga trochę bardziej.

Po pierwsze, aplikacje webowe do gigantyczny temat sam w sobie, co najmniej tak duży jak tradycyjnie pojmowany gamedev i grafika 3D. Obejmuje, w ogólności, programowanie systemów rozproszonych: jeśli nawet nie po stronie naszego własnego backendu (bo jest on przysłowiowym 'skryptem w pehape'), to co najmniej w sensie wielu użytkowników korzystających z niego w tym samym czasie. Problemy z tym związane są trochę podobne do programowania współbieżnego na pojedynczym komputerze; czasem bywają prostsze, chociaż nierzadko bardziej skomplikowane.
Do tego dochodzą też wszystkie "normalne" kwestie związane z tworzeniem jakiegokolwiek oprogramowania: UI/grafika, wydajność, security, etc. Worek radości i zabawy, krótko mówiąc ;)

Dobra wiadomość jest taka, że programowanie tychże aplikacji (w przynajmniej jednym z ich licznych aspektów) to prawdopodobnie najpopularniejsze zajęcie dzisiejszych developerów. Odpowiedzi na większość problemów łatwo można więc znaleźć jednym zapytaniem do Google lub wizytą na Stack Overflow. Dodatkowo, GitHub wręcz ugina się od pomocnych bibliotek, narzędzi, frameworków, skryptów, itd.

Aplikacja webowa to backend + frontend
...gdzie przez backend rozumiem to, co często jest nazywane mało precyzyjnym pojęciem "serwera". Frontend to z kolei (z grubsza) część aplikacji działająca w przeglądarce po stronie użytkownika. Te dwie części zawsze dobrze jest rozważać osobno, co jednak nie znaczy wcale że muszą być ściśle od siebie oddzielone (np. osobne repozytoria). Ważniejsze jest osobne podejście np. do wyboru technologii na których zbudujemy każdą z tych części.

Z frontendem rozprawię się najpierw, bo pod pewnymi względami sprawa jest tu prostsza. Przede wszystkim: bardzo, bardzo, bardzo odradzam pakowanie się w jakiekolwiek wtyczki i inne przeglądarkowe pluginy. Popełniając taką gafę od razu obcinamy sobie większość potencjalnych użytkowników, bo (1) nikt nie lubi instalowania dodatkowych wtyczek, zwłaszcza z powodu jakiejś nieznanej, randomowej gry; (2) nie wszystkie platformy obsługują wszystkie wtyczki, włączając w to te najważniejsze, czyli platformy mobilne. Paradoksalnie też, pomimo ciągle zmieniających się standardów webowych, tradycyjna kombinacja HTML+CSS+JS ma o wiele stabilniejszą perspektywę: nie ma ryzyka, że powtórzy się np. sytuacja z Flashem na iOS, którego implementacji Apple po prostu odmówił.

(WebGL zasługuje na osobną wzmiankę. Nie jest to wtyczka per se, ale pod względem developmentu jest to doświadczenie o wiele bliższe zwykłemu OpenGL niż jakimkolwiek zwykłym technikom webowego frontendu. Większość poniższych komentarzy nt. HTML+CSS+JS do WebGL właściwie się nie stosuje.)

Zakładając, że podejmiesz słuszną decyzję żeby frontend oprzeć na standardach webowych, przygotuj się na ostrą jazdę :) Przenośność nie jest już wprawdzie aż takim wyzwaniem, jakim była na początku zeszłej dekady (głównie dzięki Firefoksowi i Chrome), ale pojawiły się inne problemy. Skrócona lista:
  • JavaScript to kiepski język, którego trudno używać efektywnie (w sensie produktywności programisty). Alternatywy wymagają tak czy siak "kompilacji" do JavaScriptu, co komplikuje proces "budowania" aplikacji i czasami utrudnia debuggowanie.
  • Web frontend jako platforma programistyczna jest mniej więcej na poziomie C/C++ z przełomu stuleci. Oczywistości typu zarządzanie zależnościami czy wieloma wersjami aplikacji ("Debug" vs "Release") są zrealizowane kiepsko, wcale, albo na N różnych sposobów z których każdy ssie z różnych powodów.
  • "N sposobów na zrobienie X" to zresztą typowe w całym frontendzie, gdzie N inkrementuje się mniej więcej co miesiąc. Odróżnienie co jest rzeczywistą innowacją, a co hype'em jest, oględnie mówiąc, kłopotliwe.
  • Złożenie wszystkich elementów w jakiś sensowny proces wymaga sporej ilości własnego kodu i rozwiązywania problemów, z którymi prawdopodobnie nie chciałeś się spotykać.
...to oczywiście przy założeniu, że chciałbyś napisać Porządną Aplikację(r) zgodnie z Najlepszymi Przemysłowymi Praktykami(tm). W praktyce "frontend" to często kolekcja HTML-i zrzucona na serwer przez FTP i posklejana <script>'ami i <link>'ami z JS i CSS. Takie podejście skaluje się do małej aplikacji; zalecam jednak w międzyczasie myśleć o planie B.

Backend ma mnóstwo fajnych opcji
Przechodząc do backendu, pytaniem na którego na pewno powinienem odpowiedzieć jest "Dlaczego nie PHP?". Ponieważ jednak nie chcę spędzać nad tym tematem zbyt dużo czasu, stwierdzę jedynie że PHP to po prostu jeszcze bardziej kiepski język niz JavaScript. Prawie każdy inny będzie mniej zaskakujący i łatwiejszy do bezpiecznego używania. Większość innych języków będzie też bardziej podatna na stosowanie dobrych praktyk (web)devowych, jak np. oddzielania widoków od reszty kodu i testowania.

Co więc poza tym? Dobrze jest zawęzić listę przy pomocy kilku pomocniczych kryteriów:
  • Szybsze prototypowanie czy większa kontrola poprawności? Opcja numer 1 to języki i platformy bardziej "dynamiczne", jak node.js, Python, Ruby. Opcja numer 2 to kompilacja i statyczność: C#, Go, Java, Scala, ...
  • Aplikacja głównie serwerowa, czy też backend będących głównie API dla głównie statycznego frontendu? Opcja #1 to pełnoprawne frameworki webowe, jak Python/Django, Ruby/Rails, C#/ASP, etc. Opcja #2 to mikroframeworki: Python/Flask, Ruby/Sinatra, Go/net.http, node.js/express, etc. Zastrzeżenie jest takie, że nawet z opcji #2 da się wycisnąć to samo co z #1, często z lepszym rezultatem, ale wymaga to o wiele więcej doświadczenia.
  • Unix czy Windows? Zdecydowana większość środowisk jest wygodniejsza do programowania pod Uniksami. C#/.NET prawdopodobnie wciąż jest o wiele lepszy pod Windows, chociaż Mono wydaje jakieś pomruki. Java jest prawdopodobnie tak samo używalna tu i tu. (Zastrzeżenie: wspomniany "własny kod" do składania frontendu z klocków Lego i klejenia ich taśmą klejącą jest o wiele przyjemniejszy do pisania, gdy mamy pod ręką porządny shell i terminal. Just sayin').

Inne rzeczy
Jak wspomniałem na początku, aplikacja webowa to tak naprawdę system rozproszony. Poza frontendem i backendem możesz więc potrzebować takich rzeczy jak:
  • Coś do składowania trwałych danych. Tutaj wyłamię się spod neutralności i powiem wprost: jeśli nie masz bardzo dobrego powodu by postąpić inaczej, Postgres jest świetnym domyślnym wyborem. Jakikolwiek NoSQL (zwłaszcza MongoDB) na 90% nie jest. Zastrzeżenie jest takie, że przy odpowiedniej wielkości aplikacji/danych prędzej czy poźniej potrzeba różnych rodzajów baz dla różnych danych.
  • Coś do nietrwałych danych (np. danych pojednycznej rozgrywki która jest ograniczona czasowo). Nie jest to absolutnie konieczne (możesz katować swoją główną bazę), ale technologie typu Redis czy memcache są czasami o wiele prostsze w użyciu niż tworzenie tabel i pisanie zapytań. Bonusem jest też lepsza skalowalność.
  • Coś do robienia rzeczy w tle. Prędzej czy później napotkasz coś, czego nie powinieneś robić w czasie obsługiwania normalnych requestów HTTP. Prostym przykładem jest wysyłanie maila potwierdzającego rejestrację na stronie. Kolejki zadań (task queues) to dobre rozwiązanie w takiej sytuacji; popularne języki powinny mieć implementacje takowych (np. Python ma Celery). Widziałem też nie raz odpalany co minutę przez cron skrypt który używał bazy danych jako listy zadań do zrobienia; zgadnij ktore rozwiązanie jest lepsze? ;-)
Lista jest oczywiście niekompletna, ale nie sądzę żeby na początku trzeba było się przejmować takimi rzeczami jak np. load balancer :)

Reasumując
Ponieważ wiem, że jednoznacznie nie powiedziałem właściwie nic, mam nadzieję chociaż, że to uświadamia trochę, z czym mamy tutaj do czynienia :) Decyzję tak czy inaczej trzeba podjąć samemu; tutaj chciałem głównie dać podstawy do własnych poszukiwań.

Offline WhiteLightning

  • Użytkownik

# Kwiecień 15, 2015, 11:13:24
Xion - wielkie dzieki za tak obszerna odpowiedz, jak bede mial wiecej czasu odpisze cos wiecej. Koniecznie to gdzies przyklej. Moze na bloga tez wrzuc? :)

Z webem dla mnie jest jeden problem w tym momencie stad kolejne pytanie o technologie: te technologie mnoza sie jak kroliki, a ja nie mialem z nimi do czynienia, wiec w tym momencie jesli sie czyta posty czy artykuly w necie sprzed kilku lat, potrafia byc mocno nieaktualne.

Offline wozix

  • Użytkownik

# Kwiecień 15, 2015, 12:21:59
Technologie się mnożą, ale powinieneś też uważać na to, które są na tyle dojrzałe, by mogły być używane do poważnego developmentu. Na poziomie planowania nie powinieneś też robić czegoś w stylu "PHP nie - bo nie".

Offline WhiteLightning

  • Użytkownik

# Kwiecień 15, 2015, 13:06:23
wozix - nie robie tak (dopusczam np. JS do ktorego sie dawno temu zrazilem). Z drugiej strony glownym zalozeniem projektu jest zrobic cos malego, zupelnie dla mnie nowego i dociagnac to do konca - uczac sie przy okazji czegos zupelnie nowego.

Offline wozix

  • Użytkownik

# Kwiecień 15, 2015, 13:18:41
wozix - nie robie tak (dopusczam np. JS do ktorego sie dawno temu zrazilem). Z drugiej strony glownym zalozeniem projektu jest zrobic cos malego, zupelnie dla mnie nowego i dociagnac to do konca - uczac sie przy okazji czegos zupelnie nowego.
Łaskawy jesteś dopuszczając dość standardową technologię.
Wcześniej nie uzasadniłeś swojej niechęci do PHP.

Offline WhiteLightning

  • Użytkownik

# Kwiecień 15, 2015, 13:41:13
wozix - Xion to dobrze uzasadnil odnosnie PHP. Jesli uwazasz ze warto pchac sie w PHP - prosze uzasadnij.
 
Co do standardowych technologii - sa takie ktore sa w jakis sposob standardowe, ale odnosnie "funu" z pracy z nimi lepiej sie trzymac z daleka.