Stworzyłem mały generator terenu dla swojej planowanej gry bazowanej na "kratkach" (tiles). Tak jakoś przerodził się on w stojący na własnych nogach i całkowicie oddzielony projekt - jest w stanie wygenerować teren i zapisać go jednocześnie jako obrazy .png i jako format danych, który możecie sami stworzyć (wymagana wiedza programistyczna).
Wiem, że parę osób interesuje się na tym forum programowaniem więc wrzucam to - być może komuś przyda się wygenerowany teren albo ktoś chce przestudiować kod i czegoś się nauczyć.
"Zwykły" użytkownik nie będzie póki miał z tego wiele pożytku. Póki co do modyfikacji parametrów generatora trzeba edytować plik źródłowy (więcej info na githubie) ale niedługo pewnie dodam jakiś bardzo prosty interfejs (prawdopodobnie plik konfiguracyjny).
Link do projektu: https://github.com/Myzreal/MyzoGEN
(polecam "download as ZIP file", zaimportować projekt do Eclipse i tam łatwo można zmodyfikować parametry generator w pliku Main.java w paczce main)
Jak to mniej więcej działa (kliknij obrazek aby powiększyć):
To czego nie lubię w hnh i występuje w przykładzie u Ciebie to zbyt duża ilość lądów, brak oceanów i mórz. Rozumiem, że to kwestia parametryzacji.
Kolejna sprawa to kulistość świata, ewentualnie cylindryczność. Do szewskiej pasji doprowadza mnie nieprzekraczalna granica w grze, jakby wielkim problemem było dopasowanie lewego brzegu z prawym...
Diagramy Voronoia fajna sprawa, bawiłem się nimi trochę ale produkują generalnie o wiele zbyt skomplikowany teren, co zresztą widać na przykładzie, który podałeś. No i problem z nimi jest taki, że nadają się bardziej do generacji wysp niż ciągłego lądu, chociaż mam pewien pomysł jak wycisnąć z Voronoia bardziej rozległy i mniej wyspowaty teren.
Problem rozległych mórz i oceanów to problem zmarnowanej pamięci. Woda w grze takiej jak hnh, gdzie możesz po niej płynąć, musiałaby być reprezentowana w pamięci i te wielkie połacie wody zajęłyby mnóstwo miejsca w pamięci a byłyby generalnie niegrywalne.
Nie można generować rzek diagramami Voronoia gdy teren wygenerowany jest za pomocą Perlina bo nie będą dopasowane do terenu, nie będą spływać z gór i kończyć się w wodzie, będą po prostu całkowicie randomowe.
Dopasowanie lewego brzegu z prawym jest niemożliwe za pomocą proceduralnej generacji bo te funkcje generują teoretycznie nieskończoną funkcję i w żadnym miejscu dwie strony tej funkcji nie spotykają się. Jedyną opcją byłaby ręczna edycja mapy tak aby obie części "pasowały". Ewentualnie inna opcja to ocean na skrajach mapy, który w naturalny sposób zawsze pasuje do tej drugiej strony. Problemem jest jednak to, że w grach takich jak HnH grywalny obszar to jedynie wycinek całego świata. Gdyby to była "planeta" to musiałaby być bardzo, bardzo mała, nienaturalnie wręcz.
Oj, oj, oj. Do każdego punktu Myzreal mógłbym się doczepić :p. Nie mogę nic powiedzieć na temat skomplikowania map, bo to bardzo subiektywne, natomiast:
Myzreal napisał(a):Problem rozległych mórz i oceanów to problem zmarnowanej pamięci. Woda w grze takiej jak hnh, gdzie możesz po niej płynąć, musiałaby być reprezentowana w pamięci i te wielkie połacie wody zajęłyby mnóstwo miejsca w pamięci a byłyby generalnie niegrywalne.
Kwestia przechowywania danych. Nikt nie mówi, że musisz mieć dwuwymiarową tablice tile'i. Niegrywalność jest kolejnym argumentem, którego nie mogę podważyć, bo to Twoja gra, Twoje założenia. W mojej wymarzonej grze rozległe oceany byłyby bardzo grywalne .
Myzreal napisał(a):Nie można generować rzek diagramami Voronoia gdy teren wygenerowany jest za pomocą Perlina bo nie będą dopasowane do terenu, nie będą spływać z gór i kończyć się w wodzie, będą po prostu całkowicie randomowe.
Oczywiście, że można. Dlaczego nie będą dopasowane jeśli użyjesz danych z wygenerowanego terenu Perlinem?
Myzreal napisał(a):Dopasowanie lewego brzegu z prawym jest niemożliwe za pomocą proceduralnej generacji bo te funkcje generują teoretycznie nieskończoną funkcję i w żadnym miejscu dwie strony tej funkcji nie spotykają się. Jedyną opcją byłaby ręczna edycja mapy tak aby obie części "pasowały".
A to jest wierutne kłamstwo! Nie widziałeś map z cywilizacji? Nie słyszałeś o spherical mapping? Generacja proceduralna nie polega na nieskończoności tylko na stworzeniu czegoś z automatu bez ingerencji ręcznej właśnie. Nawet pętla, która wsadza drzewo w pole modulo 3 to wygenerowany proceduralnie las.
Dodam tylko, że kiedyś generowałem mapy gdzie prawa strona łączyła się z lewą i góra z dołem. Miałem zamiar zrobić grę z ogromnym światem, gdzie ludzie mogą tworzyć państwa i ingerować w świat. Potem zagrałem w hnh i się załamałem .
Ostatnia rzecz, to nie odbieraj tego jako ataku na swoją osobę. Potraktuj to jako rady osoby, która ma jakieś tam doświadczenie (programowałem między innymi gry 3d na urządzenia mobilne, tutaj to dopiero są problemy z pamięcią!) i nigdy nie uznaje sformułowania "nie da się" .
[ Dodano: 14 Wrz 2013 10:19 ]
Taki przykład wykorzystania tablic i oszczędności pamięci, który mi wpadł do głowy . Da się?
Kod:
class Map
{
private Grid[] m_grids;
}
interface Grid
{
public static int W;
public static int H;
public Tile getTile(int x, int y);
}
class NormalGrid : Grid
{
private Tile[] m_tiles;
public Tile getTile(int x, int y)
{
return m_tiles[W * x + y];
}
}
class OceanGrid : Grid
{
public Tile getTile(int x, int y)
{
return Tile::WATER;
}
}
Cytat:Kwestia przechowywania danych. Nikt nie mówi, że musisz mieć dwuwymiarową tablice tile'i. Niegrywalność jest kolejnym argumentem, którego nie mogę podważyć, bo to Twoja gra, Twoje założenia. W mojej wymarzonej grze rozległe oceany byłyby bardzo grywalne .
Myślałem nad tym i w sumie morza i oceany można stworzyć metodą "braku reprezentacji" czyli jak gdzieś brakuje informacji o tile'sie to znaczy, że jest to ocean. Z tym, że to stwarza szereg problemów, choćby z ograniczoną ingerencją w wodę (nie można zmienić pojedynczego tile), fragmentacją tablic (gdyby dwukontynentowy świat z wielkim oceanem na środku był reprezentowany przez jedną tablicę to byłoby to bez sensu mieć w środku od cholery "pustych" tile, no ale kto trzyma świat w jednej tablicy :p) no i coś czego bardzo nie lubię, czyli konieczność wprowadzenia wyjątków - o ile zmiany na zwykłym terenie mogłyby być zapisane w tradycyjny sposób tak zmiany w "pustych" tile trzeba by ogarniać w inny sposób a to już zmula kod.
Cytat:Oczywiście, że można. Dlaczego nie będą dopasowane jeśli użyjesz danych z wygenerowanego terenu Perlinem?
Byłem za głęboko w swoim kodzie żeby ogarnąć temat i dopiero nabrałem dystansu to widzę, że się myliłem :p Co nie zmienia faktu, że IMO algorytm A* nadaje się do tego lepiej bo odpowiednio zrobiony generuje rzeki w statycznym czasie niezależnym od wielkości mapy a i same rzeczki ładnie zaczynają w górach i spływają po utworzonych dolinach do innych rzek lub jezior.
Cytat:A to jest wierutne kłamstwo! Nie widziałeś map z cywilizacji? Nie słyszałeś o spherical mapping? Generacja proceduralna nie polega na nieskończoności tylko na stworzeniu czegoś z automatu bez ingerencji ręcznej właśnie. Nawet pętla, która wsadza drzewo w pole modulo 3 to wygenerowany proceduralnie las.
W sumie nie wiem jak z innymi funkcjami ale w Perlinie raczej nie bardzo da się to osiągnąć, przynajmniej nie w bibliotekach, których używam.
Fajną masz architekturę, zaimplementowałem bardzo podobną, ale bardziej rozbudowaną bo potrzebowałem między innymi dynamiczne ładowanie mapy, to jest przy starcie serwera mapa nie jest nawet załadowana a dopiero gdy zaloguje się gracz to serwer wyciąga z pliku odpowiedni chunk i ma do dyspozycji wszystkie jego tile i tak sobie je potem dalej dynamicznie ładuje kiedy są potrzebne. Oosobny wątek działa trochę jak Garbage Collector, co jakiś czas przelatuje przez wszystkie załadowane chunki i usuwa z pamięci te, z których nie korzysta żaden gracz. Dzięki temu mimo wielkiego świata zużycie pamięci jest ograniczone do ilości i rozmieszczenia graczy.
Ogólnie aktualnie zmagam się z problemem "knowlist", czy też jak to niektórzy programiści nazywają, "network bubble" czyli generalnie chodzi o to, że gracz X ma rozsyłać swoje pakiety tylko do graczy w określonej odległości bo gracza Y na drugim krańcu mapy guzik obchodzi co X tam robi i szkoda zaśmiecać sieć.
Czytałem, że MMO radzą sobie z tym poprzez "spatial databases", których to jedną z implementacji w Javie jest Quadtree, więc pewnie spróbuję najpierw z tym - stworzę sobie taki Quadtree, który będzie przechowywał pozycje wszystkich klientów i na podstawie odległości oceniał do którego rozsyłać pakiety.
Z wszystkimi grami, które robią coś masowo (czy to ilość graczy czy świat, czy oba) jest problem taki, że stosowane rozwiązania muszą być proste. Jak to mnie uświadomili na gamedev.net "You need to keep things simple unless you want your server to run out of memory at 50 people online".
Zgadzam się z ludźmi z gamedev.net, pierwsza zasada jakiej uczysz się projektując systemy informatyczne to KISS (keep it simple stupid) i... to pierwsza rzecz którą się zapomina zostając przy stupid . To nie tylko domena mmo, w wielu systemach stawia się na prostotę i przejrzystość nad performance. Jeśli coś działa i rozumiesz to - możesz w przyszłości to usprawnić. Jeśli coś działa dobrze, ale nie wiesz lub nie pamiętasz jak - zmiany będą utrudnione jeśli w ogóle możliwe.
Nie chcę ci narzucać nic, bo to Twój projekt, ale ja bym algorytmu A* nie użył do generowania rzek. A* wyszukuje najkrótszą ścieżkę, co przy wzniesieniach ma sens przyjmując wysokość jako wagę pola, ale co z równinami? A* przeleci przez nie bez meandrów co dla mnie byłoby niesatysfakcjonującym wynikiem.
Niestety, nie znam się na programowaniu sieciowym, a w szczególności nie mam doświadczenia z mmo, niemniej to co piszesz o QuadTree ma dla mnie sens.
![[Obrazek: DXVU5Ng.png]](http://i.imgur.com/DXVU5Ng.png)
.
