MMORPG 2d (typu Tibia) - wybór technologii

1

Cześć. Czuję trochę wypalenie w klepaniu biznesowych apek - czy to w robocie czy jakieś dodatkowe zlecenia/projekty.

Pograłem sobie ostatnio w starą Tibijkę i przypomniałem sobie, że w sumie to za dzieciaka dzięki tej grze zacząłem uczyć się programowania, bo po prostu marzyło mi się kiedyś stworzyć tego typu gierkę.

No i właśnie chyba nadszedł ten czas.. potrzebuję jakiegoś nowego projektu, który mnie pochłonie.

Moje corowe technologie to Java, Spring, ostatnio też next js.

Wstępnie myślałem o stacku: serwer - Spring Boot, client - java i libgdx i komunikacja WebSocketem.
Ewentualnie zrobić całość w Next JS i przeglądarce, ale nie wiem czy takie gierki robi się w przeglądarkach.

Doradzi ktoś ?
Pozdrowienia

1

Mam dokładnie taki sam pomysł jak Ty, natomiast zastanawiałem się nad backendem w C#. Klienta chciałem napisać w Unity ze względu na przenośność. JS nie tykam za bardzo. Ciekawy temat. Chcesz dłubać sam czy planujesz zespół?

2

W tibii to co widzi gracz pokrywa się ze stanem serwera. Najłatwiej coś takiego osiągnąć z użyciem TCP.
Z open source to kojarzę dwa projekty. OpenCoreMMO jest napisany w c#, ale jest w nim sporo błędów. Ten drugi to bardziej dojrzały projekt napisany w c++.

C# jest o tyle wygodny, że masz duży wybór technologii do tworzenia klienta gry. Z tych które znam to:

  • fna
  • monogame
  • unity
  • godot

Co do gier w przeglądarce to znam "Margonem" - https://pl.wikipedia.org/wiki/Margonem

Od 2006 roku Margonem funkcjonowało w oparciu o silnik PHP po stronie serwera oraz DHTML po stronie klienta. W 2008 roku wydajność PHP okazała się niewystarczająca do obsłużenia wzrastającej liczby graczy, dlatego rozpoczęto prace nad przepisaniem silnika gry w języku C++. Od 2010 roku Margonem oparty jest na silniku napisanym w języku C++ oraz nowym kliencie napisanym w HTML przy użyciu biblioteki jQuery. Oprawa graficzna gry jest dwuwymiarowa i wykonana metodą pixel art. Najczęściej wykorzystywanym formatem graficznym jest GIF z przezroczystością. Grafika stylistyką nawiązuje do programu RPG Maker XP. Mapy oparte są na tzw. tilesetach (zestawach grafik do gry), których kafelki posiadają rozmiar 32x32 pikseli.

0
roark.dev napisał(a):

Mam dokładnie taki sam pomysł jak Ty, natomiast zastanawiałem się nad backendem w C#. Klienta chciałem napisać w Unity ze względu na przenośność. JS nie tykam za bardzo. Ciekawy temat. Chcesz dłubać sam czy planujesz zespół?

Kurde myślałem o Unity, ale oni tam teraz wprowadzili jakieś opłaty, a poza tym nie potrzebuję całego silnika. Sam chcę zaimplementować mechanikę.
C# to umiem w sumie tyle co dłubałem proste gierki w Unity właśnie.
Java jest moim corem, więc co do klienta póki co robię rozkminę libgdx w Javie VS przeglądarka. Z tego co się orientuję to przeglądarka oferuje mniej zabezpieczeń typu multiclient itd ...

Na razie to ja badam temat technologii i się umówiłem z kumplem na pomyślenie nad mechaniką i jakąś fabułą :D

Pewnie będę pisał sam, ale chcę od samego początku dać znać co robię gdzieś na grupach typu wykop itd.
I może będę to opisywał wszystko na jakimś blogu lub rzucę się na kanał YT.

1
Bambo napisał(a):

I może będę to opisywał wszystko na jakimś blogu lub rzucę się na kanał YT.

Nom, devdziennik to dobra sprawa. Jest taki gostek ThinMatrix, który od iluś lat już opisuje postępy z developerki swoich gier na YT. Fajnie się to ogląda.

MMORPG 2d (typu Tibia) - wybór technologii

Chyba to nie wybór technologii będzie tutaj najtrudniejszy, tylko choćby synchronizacja klient-serwer (czy jeśli się ruszę w pewne miejsce i inny gracz w to samo miejsce się ruszy, mimo że nie miał prawa, ale jeszcze o tym nie wiedział? To co wtedy? A co z lagami? itp.), zabezpieczenia itp.

0
LukeJL napisał(a):
Bambo napisał(a):

I może będę to opisywał wszystko na jakimś blogu lub rzucę się na kanał YT.

Nom, devdziennik to dobra sprawa. Jest taki gostek ThinMatrix, który od iluś lat już opisuje postępy z developerki swoich gier na YT. Fajnie się to ogląda.

MMORPG 2d (typu Tibia) - wybór technologii

Chyba to nie wybór technologii będzie tutaj najtrudniejszy, tylko choćby synchronizacja klient-serwer (czy jeśli się ruszę w pewne miejsce i inny gracz w to samo miejsce się ruszy, mimo że nie miał prawa, ale jeszcze o tym nie wiedział? To co wtedy? A co z lagami? itp.), zabezpieczenia itp.

Te problemy, które wymieniasz, chcę rozwiązać eksperymentalnie bawiąc się i testując różne rozwiązania :)

1

Najprostsze będzie użycia gotowego silnika np. Unity, który pozwoli ci na łatwe napisanie serwera i klienta.

Alternatywą jest dosłownie wszystko. Wszystkie popularne technologie mają mnóstwo rozwiązań do pisania serwera, klienta i spraw typowo growych jak grafika/audio/input

2

Technologia nie ma znaczenia. Jeśli na prawdę chcesz znaleźć jakieś wartościowe materiały, to obejrzyj filmiki od ludzi którzy już robili jakieś indie games. Tylko nie kieruj się technologiami które wybierali, to jest random.

Tu masz przykład:

Po prostu wpisz w yt simple python game, simple c# game, simple js game, simple java game; i obejrzyj kilka-kilkanaście filmików od ludzi którzy robili takie gry w różnych językach.

Dodatkowo możesz wpisać 2d tree in games, 2d games simple, simple 2d multiplier game.

I powtarzam: nie kieruj się językiem i technologiami w tych filmikach - bo to jest przechodnie, ale zwróć uwagę na rzeczy wspólne - jak reprezentować gracza, jak nim sterować, etc.

1

Dawaj w przeglądarce w Next.js + Node.js. Podobno Node jest dobry do wielu 'live' requestów. :D Z chęcią bym to zobaczył jak to idzie i jakie będą problemy po drodze. W ogóle to zrób z robienia tego kurs i go sprzedaj. xD

1

Zalezy. Mozesz wykorzystac jakiegos istniejacego klienta Tibii (lub czegos podobnego jak np zezenia) i dopisac tylko serwer. Robilem tak kiedys, fajna zabawa :)
Tibijski serwer obecnie lata na protobufach jbc. Jezeli chcesz pisac cala gierke lacznie z klientem i cala strona to nie doradze, ale sam kiedys uczac sie GO staralem sie zaimplementowac serwerowy protokol Tibii wzorujac sie na TFS i bylo to calkiem rozwijajace.

1

Oryginalna Tibia pewnie jest napisana w C++. Chociaż na Wikipedii nie mogę znaleźć żadnego info na ten temat. Generalnie tak prosta gra może być napisana we wszystkim co byś chciał.

1

@Czitels: Niby to jest prosta gra. Ale rozmiar tego świata to problem niezbyt trywialny... Zwłaszcza w tamtych czasach, kiedy to powstawało.

Minecraft podobnie.
Wygląda niepozornie, ale kiedy sobie zdasz sprawę ile tam obiektów musisz wydajnie obsłużyć, to zaczynają się schody...

1
Spine napisał(a):

@Czitels: Niby to jest prosta gra. Ale rozmiar tego świata to problem niezbyt trywialny... Zwłaszcza w tamtych czasach.

Minecraft podobnie.
Wygląda niepozornie, ale kiedy sobie zdasz sprawę ile tam obiektów musisz wydajnie obsłużyć, to zaczynają się schody...

A no to prawda. Jak chcesz do tego podejść od zera na poważnie to oprócz C++ nic nie polecę. Chyba, że eksperyment z Rustem. Zawsze uważałem, że w gamedevie można znaleźć najlepszych wymiataczy spośród programistów.

3

Zrób coś prostszego na początek. Co jest z ludźmi że zawsze zaczynają od rozbudowanego MMORPG xD i tak chwała Ci za to że założyłeś że będzie to gra 2d

0

@Kokoniłaj
No właśnie rozkminiałem protokół i niby Tibia jest TCP, ale z kolei UDP jest szybsze..

1

Mi się podoba mmorpg.js
Ale to co będzie najłatwiejsze to gameplay w przypadku takiego projektu, a najtrudniejsza warstwa sieciowa.

Najlepsza warstwa sieciowa obecnie jest w unreal engine, dziala out of the box.
Unity przerobilo swoja warstwę sieciowa ostatnio ale mało dokumentacji jest jeszcze.

Najważniejsze żeby był protokół UDP, dlatego przeglądarka to słaby pomysl bo wspiera tylko TCP.
Za to w przeglądarce najłatwiej się koduje ;)

2
Bambo napisał(a):

@Kokoniłaj
No właśnie rozkminiałem protokół i niby Tibia jest TCP, ale z kolei UDP jest szybsze..

UDP to dużo więcej pracy, bo musisz obsługiwać zgubione pakiety. Kod obsługujący UDP musi:

  • intepretować stan gry na podstawie pakietów, które mogą przyjść w złej kolejności albo mogą się zgubić
  • być w stanie dogadać się z serwerem tak, żeby zregenerować stan w razie zgubionych pakietów. Twój serwer musi umieć przesyłać cały stan gry (np. pozycja wszystkich graczy) jak i zmiany w stanie (gracz A poszedł w górę)

Dopóki nie piszesz hardkorowej gry w stylu strzelanka 3D to nie ma sensu iść w UDP. Do tego w dzisiejszych czasach sieć jest dużo lepsza niż te 25 lat temu i użycie TCP jest bardziej wybaczalne,

1 użytkowników online, w tym zalogowanych: 0, gości: 1