Gra przeglądarkowa - od czego zacząć

Question

Cześć wam! Mam pomysł na grę, ba, nawet mam opisane co jak ma wyglądać w niej, pomysł wizualny mam, ale nie wiem jak się zabrać za tworzenie. Mam podstawy C, C++, html, css.

Sama gra ma być najpierw przeglądarkowa a później zmodyfikowana/rozbudowana do bycia dodatkowo na android (jeżeli się da). Nie wiem czy ma sens najpierw robić 1-osobową a dopiero później rozbudować do multi-playera na zasadzie gildii, odwiedzania znajomych, wspolnych rajdów, czatu na żywo (czy da sie rozbudowac?). Gra bedzie podobna do Gladiatusa, ale calkiem inna :) Będzie główna postać do rozwijania i wszytsko wokół niej.

W jakim języku to pisać byc można było w prosty sposób pózniej to rozwijać?

Answer 1

W dużym skrócie: nie chcesz pisać takich rzeczy w C/C++, mimo, że technicznie większość by się dało. Strasznie dużo energii schodzi w tych językach na zajmowanie się wszystkim na około (z Rust jest pewnie podobnie, choć trochę lepiej).

Najprostszym wyjściem jest JavaScript albo TypeScript - oba te języki możesz wykorzystać zarówno po stronie klienta jak i po stronie serwera (bo część serwerową i tak i tak będziesz musiał napisać). Co więcej, jeśli nie potrzebujesz miliona FPSów w grze, to można w JS/TS spokojnie robić proste real-timeowe gry (choć Gladiatus po screenach real-timeowy nie jest).

Jeśli nie wiesz odczego zacząć, to zacznij od rospisania sobie absolutnie najprostszej wersji gry jaką potrzebujesz w jak największych detalach - załóż, że to będzie po prostu poprzedzający projekt, który będzie służył do nauki, zanim weźmiesz się za faktyczną grę. A potem zacznij go implementować.

Po drodzę pewnie nie zaszkodzi, jeśli byś pochylił się nad np. tym jak przeglądarka komunikuje się z częścią serwerową - napisz sobie np. jakiś prosty czat na websocketach przy użyciu wybranej technologii. Komunikacja między grą a serwerem będzie dość zbliżona od strony architektury.

Popatrz też po różnych frontendowych frameworkach - a nuż w którymś łatwiej będzie Ci się tworzyć taki frontend jaki potrzebujesz.

Co do grafik, to https://opengameart.org/ - tylko pamiętaj respektować licencje ;)

Powodzenia!

Comments

Z grubsza się zgadzam, poza JS ;) To już trochę lepiej w TS programować. Z "łatwych i przyjemnych" języków można wybrać  nawet Pythona i PyScript (ale to jeszcze nie jest dopracowane rozwiązanie). Można się pokusić także o Dart i Flutter - web obecnie nie jest dopracowany, ale mobile tak i desktop prawie tak.

Ja bym proponował na backend gry (niemal) dowolny język, a front end wykonał na bazie WebAssembly. WASM ma tę zaletę, że bardzo łatwo jest przenieść kod na inne platformy. Niby w ekosystemie JS / TS jest RN i Electron... Ale nie mam do nich przekonania.

Jeśli chodzi o grafiki, to mimo, że są ich miliony w sieci i często za free, to i tak zwykle trzeba... zlecić je grafikowi :) Tak żeby to wszystko miało ręce i nogi oraz prezentowało odpowiedni poziom.

---

@Gynvael Coldwind, a php? Bo znalazlam jakis poradnik w necie napisania gry w php... a wlasnie potrzebowalabym takiego typu porad - sciagnij to i tam pisz, jezyka to sie naucze bo wlasnie mam wersje light tej gry rozpisana, mam wstepne grafiki, ale nie mam pojecia od czego zaczac back end.

---

Nie jestem Gynvael Coldwind, ale podpowiem, że PHP też będzie OK. Aczkolwiek sugerowałbym - jeśli zaczynasz od zera - coś ciekawszego (oczywiście pojęcie względne), konkretnie Python + FastAPI na backend. Nie wiem czy jest coś łatwiejszego i przyjemniejszego jeśli chodzi o język/framework do zrobienia REST API czy GraphQL API. Serio! Jest to super rozwiązanie, szczególnie dla początkujących, chyba już prościej API nie da się napisać niż w FastAPI!

---

@reaktywny, 

WASM ma tę zaletę, że bardzo łatwo jest przenieść kod na inne platformy.

To dokładnie jak JS ;) A wychodząc z założenia, że nawet mikrofalówka ma obecnie przeglądarkę, to nawet nie trzeba przenosić. Bo Sieć jest, było, nie było, najbardziej uniwersalną platformą na ten moment. 

---

Masz rację, co do przenośności, ale ....JS, ehh nie lubię JS :)

---

@Kasaewa, PHP ujdzie, ale TBH raczej bym TS/JS polecił niż PHP. PHP ma generalnie swoje za uszami, i model w którym działa bardzo utrudnia robienie czegoś po WebSocketach.

Osobiście preferuje Python na backend, ale zasugerowałem TS/JS tak żebyś nie musiał się dwóch różnych nowych języków uczyć na front/back.

---

@Nałogowiec, odnośnie:

Jeśli chodzi o grafiki, to mimo, że są ich miliony w sieci i często za free, to i tak zwykle trzeba... zlecić je grafikowi :) Tak żeby to wszystko miało ręce i nogi oraz prezentowało odpowiedni poziom.

Ogólnie się zgadzam, ale da się całkiem sporo fajnych rzeczy zrobić bazując na darmowych grafikach + poprosić grafika, żeby skupił się na uspójnianiu rzeczy (palety kolorów, etc). No i dorabiając trochę rzeczy samemu :)

Oczywiście efekt zawsze będzie lepszy jeśli ma się dobrego grafika pod ręką, ale jeśli się robi coś na małym budżecie, to to podejście wspomniane wyżej też da radę.

---

@Gynvael Coldwind, ts/js od czego zaczac? Sa jakies poradniki? Jakies srodowisko do pisania kodu?

---

Są są, spokojnie na sieci znajdziesz info - to bardzo popularne języki :)

Answer 2

Zainteresuj się WebAssembly (WASM). To takie appki, bardziej webowe (ale nie tylko), wspierane przez najważniejsze przeglądarki internetowe. Bardzo fajne rzeczy w tym powstają! I nie trzeba znać TS / JS!

Nie wiem jakie znasz języki, ale wydaje mi się, że najrozsądniejsze dla WASM to: Go, C++ i Rust, ewentualnie C# (głównie Blazor). Teoretycznie WebAssembly można zrobić w niemal każdym języku, ale różnie to wychodzi (jakość kodu, wydajność, finalny rozmiar pliku) no i różny jest komfort (przyjemność) programowania.

Jeśli chodzi przykładowo o Rust, to ekosystem WASM jest bardzo rozbudowany i dość dojrzały, masz tu wiele frameworków WASM/Rust, a najciekawsze to Yew, Leptos, Dioxus i Sycamore (choć jest cała masa innych).

Musisz mieć sporo wytrwałości i wiele wolnego czasu, aby ukończyć tak duży projekt! :)  Życzę powodzenia!

Wykorzystując przykładowo Dioxus, będzie można niedługo robić appki także dla mobile i desktop. W innych przypadkach też, ale czasami będzie potrzebny jeszcze framework typu Tauri (który ma WebView i w nim osadzasz swój WASM). Ogólnie wszystkie najważniejsze platformy są w Twoim zasięgu :)

Poniżej porównanie czterech najciekawszych frameworków RUST dla WASM:

 

Yew

• Most mature and widely-used

• JSX-like template syntax

• React-like (historically Elm-like struct components, now React-like function components)

• More boilerplate for things like event callbacks, need to `.clone()` things into closures, etc.

• Relatively good performance (think something like Preact/Vue, faster than React)

• Safe Rust

• Medium WASM binary sizes

• Community-maintained (i.e., original creator has lost); it's well-maintained, reviewers do a good job looking at PRs etc., but (subjective take here) I don't see much of a vision driving it forward longer term

Dioxus

• Relatively new, fast moving

• Explicitly models/markets itself as being React-like

• Unique template syntax (not JSX-like)

• Lots of unsafe Rust

• Very good performance based on newish block-DOM approach (less flexible than React/Yew VDOM, but more performant)

• Large WASM binary sizes

• Lots of emphasis on targeting desktop/native UI as well

Leptos (full disclosure: I am the creator)

• Relatively new, fast moving

• Based on SolidJS/fine-grained reactivity, with no virtual DOM overhead

• JSX-like template syntax

• Entirely safe Rust

• Very, very good performance; outcompetes others listed here not only on rendering speed but on memory usage and on server-rendering speed

• Small WASM binary sizes (slightly larger than Sycamore)

• Fastest server rendering and strong emphasis on/support for integrations with the server, including multiple server-rendering modes (like both in-order and out-of-order HTML streaming)

Sycamore

• More mature than Dioxus/Leptos, relatively slow-moving

• Based on SolidJS/fine-grained reactivity

• Unique template syntax (not JSX-like)

• Lots of unsafe Rust

• Small WASM binary sizes

• Quite good performance, faster than Yew, slower than Dioxus/Leptos, but probably plenty for whatever you need

• Major bonus: the Perseus metaframework

Powyższe opracowanie / porównanie zaciągnięte z forum Rust (reddit), napisane przez autora Leptosa.

Jak nie Rust, to jest sporo innych możliwości, ale osobiście poszedłbym w Rust. Sporo gier powstaje właśnie w tym języku.

Może być od biedy Csharp, jest sporo przykładów i dobra dokumentacja Blazora (ich sztandarowy WASM).

Jeszcze raz - powodzenia!