Prezentacja mojego silnika MagicEngine


#41

Nie widziałem tego tematu wcześniej. Też piszę w Javie (właściwie to w Scali). Teraz przy okazji używam jej do pisania gry MMO. 2D więc większość rzeczy z tego tematu mnie omija :slight_smile:

Nie wiem czy ktoś wcześniej poruszył ten temat, ale jakie masz podejście do samej pracy serwera i synchronizacji danych z klientem? Jak w teorii ma wyglądać praca na Twoim silniku jeśli chodzi o warstwę sieciową?

  • Serwer chodzi w pętli, wylicza stan świata co jakiś czas, klient interpoluje? Czy jakiś sprytniejszy mechanizm?
  • Dzielisz świat na części? W jaki sposób?
  • Jak wygląda zapis do bazy danych? Serwer działa w pamięci i zapisuje dane raz na jakiś czas? Czy może pisze i czyta cały czas bazę danych (lub cache)?
  • Serwer wspiera klastrowanie?

(Jeśli gdzieś o tym pisałeś już w wątku do podeślij odnośnik. Trudno mi było przechodzić przez ściany tekstu :slight_smile: )

Zauważyłem, że w gamedevie brakuje ciekawego rozwiązania w formie frameworku/silnika ale dla samego tworzenia części sieciowej w MMO. Pomijając oprawę audiowizualną, którą można stworzyć w czymkolwiek.

Co do javy, dla mnie największy problem z nią to brak wsparcia konsol. Co jest dość kuriozalne, bo java właśnie szczyciła się byciem crossplatformową technologią :slight_smile:


#42

Właśnie coś ostatnio ktoś wspominał, że jest wielka możliwość otwarcia Javy dla Playstation 5 chociaż podobno rozmowy trwają (były też przy okazji PS4, ale wiadomo jak to się skończyło).

System podobny do tego z Counterstrike oparty na tickrate. Pętla, która zbiera informacje o ruchach/akcjach i wysyła je do gracza tyle razy na sekundę ile się ustaw w configu jednak zostanę pewnie przy 32/64.

Każdy obszar jest podzielony na lokacje. Coś jak w WOWie gdzie masz świat podzielony na krainy. Każda kraina/lokacja chodzi w oddzielnym wątku. Wątki synchronizują się tylko z głównym wątkiem, który obsługuję wysyłanie wiadomości/dodanie gracza do gry. Co do dzielenia lokacji to po prostu jest ona dzielona na mniejsze chunki, które przechowują konkretne obikety jak leżące przedmioty na ziemi/innych graczy. Ty jako gracz widzisz tylko pewien wycinek chunków.

Gra zapisuje stan gracza w momencie wylogowania się go z gry. Kopia robiona jest codziennie o wyznaczonej godzinie. W tym momencie również czyści się mapa i serwer się resetuje. Pozostałe rzeczy takie jak oferty czy bany zapisuje w czasie rzeczywistym przy użyciu LevelDB - obecnie najszybsza baza danych na rynku od Googla :slight_smile:.

Rozwiń temat bo to dość obszerne pojęcia i nie za bardzo wiem o co dokładnie chodzi :slight_smile:.

Silnik chcę by w finalnej wersji wyglądał jak Unity jednak tylko dla gier MMORPG :slight_smile:. Chcę dodać jeszcze parę bajerów, ale pracuje nad pewnym system od chyba 5-6 lat i nadal napotykam mnóstwo przeszkód, więc do końca nie wiem czy to jest realne. Być może u mnie w silniku pojawi się też nowy system, którego jeszcze nie widzieliście w żadnej innej grze, a to dlatego, że kolega pisze prace i jak opatentuje pewną rzecz to ja z niej chcę skorzystać od razu :stuck_out_tongue:.


#43

Dzięki :slight_smile: Ciekawe jak to będzie działało w praktyce :slight_smile:

Czy będzie się dało rozproszyć serwer tak by świat gry działał w jednym klastrze wielu fizycznych maszyn?
Z punktu widzenia MMO, zdolność do skalowania jest jedną z bardziej istotnych rzeczy, ale zawsze odbywa się jakimś kosztem (CAP). Ciekawi mnie jak Ty do tego podchodzisz.

Twoje przemyślenia pewnie przydadzą się każdemu kto pisze grę sieciową, w tym mnie :smiley: stąd te pytania :slight_smile:


#44

A spoko oto chodzi. Ok więc nad tym jeszcze nie myślałem bardzo i szczerze mówiąc nie wiem czy jest sens. Na pewno przy ogromym świecie (lub gdy dojdzie fizyka) zrobi się testy i zobaczę aczkolwiek wiele gier z tego co kojarzę to pomija zupełnie ten aspekt -> np. Tibia i Metin (ale tego nie jestem pewien). Na obecnym etapie za wcześnie żeby o tym myśleć aczkolwiek już kiedyś do tego tak bardzo bardzo wstępnie podchodziłem, jednak to póki co luźne pomysły :slight_smile:. Czyli podsumowując jak już będę sklejał bardziej konkretną grę gdzie będzie na mapie dużo obiektów i wejdzie fizyka to zobaczę jak to będzie wyglądać w praktyce i wtedy pomyślę. Póki co jest mi ciężko powiedzieć czy dodawanie tego ma sens :slight_smile:.
W ogóle w obecnej postaci serwer obsługuję maks 1000 graczy online tak btw. :stuck_out_tongue:


#45

Ładnie :smiley: A jakie masz parametry maszyny? To głównie o moc się wszystko rozbija :smiley: (i I/O)

Jeśli to jest zamierzony rezultat to ok :slight_smile: Mimo wszystko bez możliwości zwiększania zasobów, w pewnym momencie dochodzi się do fizycznej bariery, której nie da się przekroczyć. Kiedyś gry radziły sobie z tym zwyczajnie ograniczając liczbę graczy na serwerze i tworząc osobne instancje (zapewne jak Tibia czy Metin). Ale to już były osobne światy.

Zależy czego się oczekuje od świata MMO. Jeśli limitowanie liczby graczy na serwerze jest ok, to nie ma sensu :slight_smile:


#46

Jedyny najlepszy test jaki udało mi się zrobić robiłem po pracy na maszynie służącej tylko i wyłącznie do właśnie takich celów to nawet ona się nie zmęczyła aczkolwiek był to wtedy najlepszy procesor, płyta główna i 128 GB RAM, która była używana jako nod kryptowaluty więc no nie ma się czemu dziwić :stuck_out_tongue:.

A co do tematu zdawałem sobię właśnie sprawę z tego, że jak lokacji będzie pewnie z kilka set to może pojawić się właśnie problem o którym piszesz i wstępnię chciałem to rozwiązać tak żeby kilka lokacji było na jednej maszynie i w momencie wchodzenia do lokacji serwer przekazuje całe info z jednej maszyny do drugiej. W sumie to chyba nie byłoby tak jakoś mocno skomplikowane myślę :slight_smile:.


#47

Co za potwór :open_mouth:

No rozumiem :slight_smile: Taki sharding. To dobre podejście
Korzystam z tej technologii u siebie:
https://akka.io/

Skoro piszesz w javie, to może Cie zainteresuje. Ciekawy koncept.

Powodzenia :slight_smile: będę tu zaglądał :slight_smile:


#48

Ooo super poczytam sobie jak już jest coś gotowego to czemu nie :slight_smile:


#49

W nie dalekiej przyszłości również pojawi się wsparcie dla Vulkana z tego względu, że jestem ciekaw jak szybko będzie renderował rzeczy skoro OpenGL 4.3 robi to naprawdę szybko

OpenGL nic nie renderuje, to tylko API :smiley: Renderuje karta, to od jej mocy zależy jak szybko renderuje, jak napiszesz w Vulkanie to dalej będzie sz korzystał z mocy tego smaego sprzętu, nie oczekuj wodotrysków :slight_smile: Nawet OpenGL 2.1 będzie równie wydajny co OpenGL 4.6 na starcie, dopiero wykorzystanie dodatkowych bajerów pozwalających na lepsze wykorzystanie mocy obliczeniowej da lepsze wyniki. Z Vulkanem jest to samo, tylko że na starcie będzie wolniej niż OpenGL xD Vulkan ma pomóc odciazyć CPU (to w zasadzie odczuwa się od razu, command buffory sa mega, nawet jednowątkowo) i pomóc zwiększyć wykorzystanie GPU (poprzez eliminacje momentów kiedy GPU nie pracuje wcale). Ale ze względu na to jak wiele magii robią sterowniki to OpenGL radzi sobie super, a w Vulkanie trudno wykorzystac cały potencjał :slight_smile:


#50

Właśnie dokładnie oto mi bardziej chodziło. Dobrym przykładem jest tutaj podmiana pikseli w teksturze:

  • glTexImage2D (od wersji 1.0) - najwolniejsza
  • glTexSubImage2D (od wersji 1.0) - troszkę szybsza
  • FBO (od wersji 3.0) - bardzo szybka
  • PBO (od wersji 3.3) - najszybsza podmiana z CPU na GPU

W zależności którą opcję wybierzesz to jesteś w stanie mieć więcej fpsów w apce :slight_smile:.

Robiłem sobie wstepne demko z oceanem i rzeczywiście jest o połowę mniejsze użycie CPU (za parę tygodni wstawię może jakieś screeny porównawcze). W przypadku terenu tutaj różnica jest już kolosalna bo tesalacja zmienia całkowicie podejście do tworzenia sandboxów. W końcu nie trzeba się martwić jak mocno ograniczyć wielkość świata i jak bardzo wpływa to na fpsy :smiley: .


#51

No w Vulkanie masz dostęp do wszystkiego jeżeli chodzi o transfer pamięci, z tym że wszystko musisz sam synchronizować, więc poprawna implementacja jest dość kłopotliwa :slight_smile: No i na Nvidii na starszych urządzeniach może i tak Vulkan zawsze działać wolniej przez słabe sterowniki :smiley:
Fajne na Vulkanie jest to ze można uzyskać niski narzut CPU i dobre wykorzystanie GPU bez magii i dziwnych triczków jakie oferuje OpenGL 4.6. Z tego prostego względu że dzięki temu całość powinna być bardziej przenośna i skalowalna.

Odnośnie funkcji takich jak np. glBufferData, glBufferSubData, glMapBuffer i to samo pewnie z teksturami to niestety nie jest tak fajnie jak w podanym przez Ciebie przykładzie. Tzn. np. wybór pomiedzy podanymi przeze mnie funkcjami może być całkowicie różny jeżeli chodzi o wydajność w zależności od producenta a nawet systemu (ze względu na różne sterowniki). Nie zawsze najnowsza funkcja jest najlepsza, a nawet nie zawsze działa :slight_smile: I tutaj znowu fajna rzecz odnośnie Vulkana. Nie masz problemu z zastanawianiem się czy lepiej zrobić orphaning, czy po prostu podmienić datę czy zrobić dodatkowy bufor bo wszystko robisz sam i sterownik nie wciśnie Ci pomiędzy własnych operacji.


#52

Znaczy jeżeli chodzi o PBO to nie miałem jeszcze z tym żadnego problemu no i zawsze było ciut szybciej niż te funkcje z wersji 1.0. Z tego co zauważyłem to największe kłopoty z fukncjami są dopiero od wersji 4.0 gdzie czasami różne rzeczy się dzieją. Póki co testuje na kartach Geforce 1050, 60 i 70 tylko bo takie niestety mam możliwości, ale wiem, że pewnie przy Radeonie będzie znowu problem (jak zawsze) bo trochę inaczej on interpretuje czasami kod.

Vulkana właśnie dopiero jeszcze się uczę od paru tygodni. Szkoda, że w robocie nikt nie chcę tego wdrożyć to bym pewnie się szybciej nauczył :stuck_out_tongue: , a tak to pewnie z kilka miesięcy a może i nawet dużo dużo więcej. Zobaczymy, ale póki co OpenGL jest priorytetem dla mnie :slight_smile:.


#53

Koniec konców stwierdziłem, że bez sensu jest zanudzać ludzi to jak coś zrobiłem i zdjęciami z poszczególnych etapów tworzenia kolejnych elementów silnika (z tego względu, że za szybko to się zmienia i czasami pewne rzeczy przerabiam od początkumilion razy :smiley: ) i będę starał się tutaj wkładać tylko zdjęcia i materiały, które będzie mógł zrozumieć każdy grafik i game designer (bo oto głównie chodziło od początku założenia tego tematu :stuck_out_tongue: ). Silnik ma być używany głównie przez ludzi, którzy nie mają żadnego pojęcia o programowaniu (wyjątek stanowią tutaj skrypty LUA, których trzeba się będzie nauczyć żeby wprowadzić jakieś zachowanie pomiędzy np. graczem a przedmiotem jednak nic więcej poza tym). Każdy będzie w stanie usiąść i napisać własną grę MMORPG.

Oto finalna wersja terenu o wielkości 8km (chyba) - jest to jakieś losowe zdjęcie księżyca, które zostało przekształcone na heightmape więc fajerwerków nie ma. Póki co można wygenerować w edytorze sobie gotową mapkę terenu ustawiając kilka parametrów:

  • wielkość terenu (od 32m do 8km - kolejne potęgi 2)
  • maksymalna wysokość terenu (od 0m do 6km aczkolwiek może to ulec jeszcze zmianie)
  • parametry tessalacji (dla bardziej zaawansowanych jednak mogą zostać domyślne)
  • liczba level of detail (do maks 10 chociaż 7 daje już fajny zadawalający efekt)
  • kolejne stopnie level of detail

Teraz zabieram się za:

  • możliwość edytowania kilku parametrów terenu (już po stworzeniu go)
  • dodanie do drzewa elementów sceny takich jak teren
  • dodanie pędzla do rzeźbienia w terenie (pomysły będę brał z RedEngine2/Esenthel engine/RME Map Editor -> bo fajnie mi się tam i szybko tworzy teren)
  • możliwość dodania ocenu wraz z konkretnym umiejscowaniem go na mapie (współrzędne oraz rozmiar) -> ocen pokaże dopiero wtedy bo jeszcze sporo pracy żeby go pokazać komuś

Dodatkowo w przyszłości chcę też dodać możliwość edytowania pixeli terenu/ocenu w moim shader edytorze jakby ktoś chciał coś fajnego nowego dodać.


#54

Nie dziwię się ze nie chcą w pracy Vulkana :smiley: Tylko dodatkowe problemy, a zysk raczej znikomy.
Vulkan jest fajny (moim skromnym zdaniem fajniejszy jak OpenGL), ale wymaga też dużo więcej pracy dla tych samych prostych czynności.

przy Radeonie będzie znowu problem (jak zawsze) bo trochę inaczej on interpretuje czasami kod.

Radeon ostro trzyma się standardu, a Nvidia praktycznie wcalem, do tego czyni czarną magię wewnątrz żeby uzyskać 100% wydajności. Na Nvidii działają nawet rzeczy które nie mają prawa działać, a np. podanie nieodpowiedniego formatu tekstur i danych zazwyczaj daje taki wynik, że sterownik sam dobierze odpowiedni format, wyjściowo przekonwertuje do tego co chcesz, stracisz na wydajności poprzez dodatkowe opcje, ale debugger nawet nie piśnie że coś robisz nie tak xD

Oto finalna wersja terenu o wielkości 8km

8km^2 czy 8km długości i 8km szerokości (czyli 64km^2)?

LOD seamless czy zwykłe przeskoki? (Pewnie seamless skoro tesselacja)


#55

Ostatnio testowałem na Radeonie i na szczęście 0 błędów i problemów z płynnością :smiley:.

64km^2 i taka jest heightmapa bez żadnego podziału na mniejsze tekstury. Co do typu to nie jestem pewien. Wziąłem pomysł z dokumentu DICE z drzewem czwórkowym. Dodałem demko od NIVIDI z tessalacją i funckję przesuwania wierzchołków patcha już w vertex shaderze. Także jak wiesz jak to się nazywa konkretnie to daj znać aczkolwiek całość bazuje tak jak mówiłem na dokumencie DICE :slight_smile:.


#56

Dobra robota. Jeżeli masz ochotę na darmowe szkolenie z zakresu OpenGL pisz do mnie na maila. Nazywam się Tomek mam 18 lat od 2 lat siedzę w Gamedevie. Aktualnie steruje 6 osobową grupą razem tworzymy grę na Unreal Engine 4. Jeżeli masz ochotę się do nas przyłączyć i kończyć prace nad silnikiem już w grupie zapraszam do nas.

tomeknawrocki2000@gmail.com

Pozdrawiam


#57

Cześć dzięki za odpowiedź, ale sam pracuje w gamedevie/grafice, a ten silnik robię po pracy i szczerze to już mnie bardzo męczy. Ciężko tak po 8 godzinach w robocie usiąść i napisać kod znowu przez te 2-4 godziny :stuck_out_tongue: . Także dzięki za propozycję, ale niestety muszę odmówić bo wiem ile to czasu by mi zajmowało dziennie :slight_smile: