radekmie / h3mapgen Goto Github PK

We should choose a licence for our software and add the adequate file.

Między MultiLML a fazą układania zon na mapie (MDS+Voronoi) dla map dwupoziomowych dobrze byłoby mieć algorytm który wywala część zon z powierzchni do podziemi.
Zwłaszcza będzie on ważny jeśli tych zon będzie dużo, a więc będą generowały konflikty.

Można iteracyjnie przerzucać można zony które:

• wszystkich swoich sąsiadów mają na powierzchni i ci sąsiedzi są blisko siebie (w domyśle mają krawędzie)
• wszystkich swoich sąsiadów mają już w podziemiach.

Pytanie czy ograniczamy się do zon buforowych, czy (zwłaszcza jeśli zamek jest 'zły') przerzucamy tam też strefy lokalne spełniające powyższe warunki.

Nie wiem też na ile 'greedy' stosowanie powyższych reguł doprowadzi do konfliktów terenowych w podziemiach, na pewno potrzebujemy jakich constraints typu liczba zon w podziemiach musi być nie większa niż na powierzchni, albo coś.

Napisać pierwszy (a tak naprawdę drugi, ale pierwszy dotykający bezpośrednio h3pgm) fragment chaina na początku całego procesu, czyli: user + config -> userParams -> concreteParams

Wstępnie, userParams (czyli do co jest wyklikiwalne w GUI bez zakładki 'advanced') zostały zdefiniowane tu
IMG1, IMG2
Teraz będziemy je chcieli sobie dodefiniować.

concrete Params powinno być ukonkretnieniem wartości z userParams, i chyba tyle. Ewentualnie ten zbiór być jeszcze rozszerzymy o jakie bardziej pośrednie wartości wynikające z parametrów i reużywane przez wiele różnych kroków generatora, ale to na razie nie wiadomo.

Issue tworzy nowy komponent, propozycje nazwy: parameters , generationParameters, ...?
W tym samym komponencie, potem będziemy kodować #18.

Plik Auxiliary/Serialization wymaga globala CONFIG. Powinien dać sobie radę bez.

Poprawki tekstu: deadline 01.06.

Dopisać doca w którym będzie:

• specyfikacja wejścia
• specyfikacja wyjścia
• szczegółowo opis wszystkich możliwych własności wierzchołków i co one oznaczają
• jak jest zapisana gramatyka i jak ją edytować
• jakie są reguły gramatyki

It should either accept the filenames as command line parameters or use stdin and stdout.

Co?

Napisać wrapper, który będzie pozwalał wywoływać MDS bezpośrednio (tj. bez pośrednich jawnych plików) z poziomu Lua.

Dlaczego?

By zapewnić pełną wymienność modułów, każda z części powinna mieć takie samo API - na spotkaniu 2017-11-15 zdecydowaliśmy, że będzie to h3pgm -> h3pgm (Lua).

Komponent działałby post-voronoi i do jego zadań należałoby:

• stawianie zamków¹ (rozpoczęte w #27)
• stawianie kopalni
• wyznaczanie superbiałych ścieżek, w tym superbiałych bram między obszarami

Dotychczasowy kod w generate.lua trochę się rozrósł, dobrze byłoby go wydzielić już do osobnego komponentu. Trzeba pomyśleć na algorytmem rozstawiającym wyżej wymienione heavy features tak aby (z pewnym szacowaniem dokładności) zapewnić 'fairness'.

¹typy zamków fajnie byłoby konkretyzować jak najpóźniej, ze względu na możliwość modyfikacji parametrów przez usera

OK, mamy już od jakiegoś czasu fajne wyniki dzięki https://github.com/maciek16180/h3-fight-sim

Co by się przydało:

• upublicznić gdzieś GUI żeby ludzie mogli sobie sami coś wyklikać (co jest potrzebne na hosting?)
• zrobić na temat tego jakieś statystki, tzn. porównanie z wartościami domyślnymi gry
• zrobić krótki opis na ArXiv żeby dało się do tego odnosić w pracy
• wrzucić na jakieś fora herosów (ciekawe jak ludzie się do tego odniosą).

File src/cellular/board.hpp contains declarations of Board type and related functions. The Voronoi generator uses different representation. Having in mind that we are to join all the parts into a monolitic cpp application unifying the data representation is worth considering.

For both C/C++ and Lua. Suggestions?

Get the bmp-drawing tool from the cellular-terrain repo.

Brakuje:

1. Ustawiania graczy jako ludzkich (na razie wszystkich, potem zależy to od ustawień w parametrach mapy).
2. Dodania każdemu graczowi zamku startowego (na razie dowolnego, wstępnie ustaliliśmy, że potem będzie to zakodowane w LMLu).

1. Brakuje wpisania tytułu mapy
2. W opisie fajnie byłoby coś w stylu "generated by XXX, ver. 0.666, with Parameters p1=a, p2=b, ..." (do zrobienia po #18 )

Jak zostało ustalone w #27 odpowiadając na kwestię

... czy byłoby problemem, w każdej strefie (w losowym miejscu, lewym górnym rogu, gdziekolwiek) umieścić tabliczkę z danymi?
(Local player / buffer players, numer strefy multi, numer strefy single, może też lista features, ...)

No i zostałem zaproszony do zabawy ;-)

Wydaje mi się, że testując nie generowało mi takich samych map jeśli kopiowałem i wklejałem seeda z paramsGeneral.

Jak rozumiem, chcielibyśmy żeby system generował dokładnie tę samą mapę jeśli:

• ten sam seed został przeklejony do paramsDetailedUser (nie do paramsDetailed!)
• pozostałe wartości w paramsGeneral nie uległy zmianie.

Czy tak?

Co?

Napisać wrapper, który będzie pozwalał wywoływać Voronoi ("moduł Piotrka") bezpośrednio (tj. bez pośrednich jawnych plików) z poziomu Lua.

Dlaczego?

By zapewnić pełną wymienność modułów, każda z części powinna mieć takie samo API - na spotkaniu 2017-11-15 zdecydowaliśmy, że będzie to h3pgm -> h3pgm (Lua).

Zaobserwowano dwa błędy:

• kończenie LML z 1 krawędzią przez co MultiLML jest niespójny
• przerzucanie bufora za local bez outera - co sprawia, że z logicznego układu mapy staje się on localem.

Po skończeniu #17, można będzie na nowo wrócić do MultiLML'a. Dotychczas było zrobione na szybko i o ile pamiętam, nie wszystkie rzeczy działają jeszcze tak jak ostatecznie byśmy tego chcieli.

Oczywiście komponent powinien być również porządnie udokumentowany, podobnie jak bazowy LML.

Edit: Notka żeby pamiętać skoro wprowadzamy teamy: symetryczność Multi'LMLa powinna być tak naprawdę wyznaczona przez obroty względem teamów nie graczy.

Abstract trzeba wysłać do 01.03.
(powiązane z #54 )

Przed fazą SFP dodać faktyczne losowanie zamków i kopalni, korzystając z tabel prawdopodobieństw które już są w detailedParams.

Jakaś dodatkowa struktura na to?

Na masterze:

maciek@maciek-L560:~/Desktop/h3/h3mapgen$ git submodule update --init --recursive
maciek@maciek-L560:~/Desktop/h3/h3mapgen$ make

make -C libs/homm3lua
make[1]: Entering directory '/home/maciek/Desktop/h3/h3mapgen/libs/homm3lua'
cc homm3lua/homm3lua_constants.c -c -I/usr/include/lua5.3 -W -Wall -Wextra -O3 -fPIC -shared -std=c99 -I homm3tools/h3m/h3mlib -I homm3tools/3rdparty/uthash/src -o dist/homm3lua_constants.o
homm3lua/homm3lua_constants.c: In function ‘h3mlua_constants’:
homm3lua/homm3lua_constants.c:57:38: error: ‘H3M_HERO_CONFLUX’ undeclared (first use in this function)
constant("HERO_CONFLUX", H3M_HERO_CONFLUX);
^
homm3lua/homm3lua_constants.c:5:22: note: in definition of macro ‘constant’
lua_pushinteger(L, value);
^
homm3lua/homm3lua_constants.c:57:38: note: each undeclared identifier is reported only once for each function it appears in
constant("HERO_CONFLUX", H3M_HERO_CONFLUX);
^
homm3lua/homm3lua_constants.c:5:22: note: in definition of macro ‘constant’
lua_pushinteger(L, value);
^
homm3lua/homm3lua_constants.c:65:38: error: ‘H3M_HERO_DARKSTORN’ undeclared (first use in this function)
constant("HERO_DARKSTORN", H3M_HERO_DARKSTORN);
^
homm3lua/homm3lua_constants.c:5:22: note: in definition of macro ‘constant’
lua_pushinteger(L, value);
^
Makefile:34: recipe for target 'dist/homm3lua_constants.o' failed
make[1]: *** [dist/homm3lua_constants.o] Error 1
make[1]: Leaving directory '/home/maciek/Desktop/h3/h3mapgen/libs/homm3lua'
Makefile:25: recipe for target 'homm3lua' failed
make: *** [homm3lua] Error 2

Próbowałem to zbudować, żeby sprawdzić, czy działa, no i nie działa. Błędy stałych w homm3lua, nie ma takiego herosa DARKSTORN, jest DARKSTORM (w h3m_hero.h). HERO_CONFLUX też wygląda dość podejrzanie.

Such as "Repo tree" section etc.

Przy stawianiu zamków/kopalń/czegokolwiek, chcemy mieć jakąś sprawiedliwość w odległościach. Do tego będziemy potrzebować funkcji w stylu:

local d = distance(map, {x1, y1}, {x2, y2})

Póki co musi uwzględniać tylko teren, z czasem także budynki, rzeki, drogi i (najważniejsze?) potwory.

EDIT:

local d = distance(map, {x1, y1, z1}, {x2, y2, z2})

Póki co: z1 == z2.

MultiLML mówi, że istnieją jakieś zony, natomiast na mapie ich nie ma.

Przykład: dumps.zip

MLML_graph ma 30 zon (od 1 do 30), natomiast w world występują jedynie zony 7 ,8 ,2 ,5 ,6 ,14,20,18,3 ,26,9 ,4 ,28,30,22.
Brakujące zony, to wszystkie te dla których wstawianie zamków daje FAILED TO PLACE A TOWN IN ZONE.

Ponieważ w world znajdują się takie cuda jak 0 72 0 = { cell= { 8, }, zone=-97, }, i patrząc na dziwną zawartość mapText.txt podejrzewam, że coś jest z tym głupim przerzucaniem na znaczki...

Somebody should write a short description of the project.

Więc do napisania są dwie rzeczy. Pierwsza (CheckFairness), najważniejsza, to dla podanego grafu dla wielu graczy napisać funkcję sprawdzającą czy jest on fair i symetryczny z punktu widzenia każdego z graczy. Druga (MultiplyLML) to generowanie takich grafów wiedząc jak wygląda pojedynczy wierzchołek i wychodzące z niej krawędzie (tzn. strefa single dla jednego gracza).

Jako, że zawartość components/mlml idzie do przepisania, proponuję sobie spokojnie pisać np. w tests/mlml.

Przykład grafu który oczywiście nie jest fair i nawet nie ma sensu, ale będzie nam służył do wizualizacji struktur.

Funkcja MultiplyLML powinna brać dwie rzeczy: informację o wierzchołku oraz liczbę graczy. Informację o wierzchołku proponuję zakodować po prostu jako tablicę krawędzi, gdzie każda krawędź to tablica zawierająca id strefy łączącej, typ strefy oraz jej poziom. Ostatnie dwa parametry wynikają z pierwszego ale wygodniej będzie (przynajmniej w danych wejściowych) mieć je podane explicite.
Tak więc kodowanie wierzchołków P1/P3 wygląda w takim formacie następująco:

{ {11, 'BUFFER', 5}, {12, 'LOCAL', 2}, {13, 'LOCAL', 3} }

Dla tak zadanego wierzchołka (+ liczby graczy) funkcja zwraca zmultiplikowany graf. Jeśli ma Pan dobry pomysł na format może Pan użyć swojego, ja bym proponował mapę z id graczy (1 do n) w listę połączeń rozumianą jako trójkę (eid1, eid2, pid2), gdzie eid1 to id krawędzi wychodzącej z wierzchołka, zaś eid2 to id krawędzi wchodzącej do wierzchołka pid2. Dla grafu na obrazku wyglądałoby to tak:

{
   { {11,11,2}, {12, 13, 3}, {13, 12, 3} }, -- P1
   { {11,11,1}, {12,11,3} },                -- P2
   { {11,12,2}, {13,12,1}, {12,13,1} }      -- P3
}

Funkcja CheckFairness powinna brać już zmultiplikowany graf (taki jak na rysunku, w wybranym formacie) i zwracać true/false w zależności czy jest fair.

Ogólnie nie wiem czy będzie pomocne ale fragment ogólnej procedury której te funkcje są częścią został kiedyś spisany w docu na stronie 7.

Wracając jeszcze do generowania, wykluczamy łączenie dwóch krawędzi które nie są LOCAL i mają inny typ lub inny poziom. (czyli dopuszczamy łączenie non-locali tylko jeśli mają ten sam poziom i ten sam typ: BUFFER, TELEPORT, itd)

Mam nadzieję, że opisałem w miarę jasno - jak coś to proszę pytać i doszczegóławiać.

Po ustaleniu zestawu początkowych parametrów (see #37), napisać GUI w którym będzie możliwość tworzenia nowej mapy ustawiając parametry generatora.

Bardziej zaawansowane użycie zakłada możliwość modyfikacji bardziej szczegółowych parametrów (concrete i/lub config).

Ostatecznie chcielibyśmy też mieć opcję loadH3PGM, pozwalającą regenerować poszczególne kroki (see #38).

Ah no i oczywiście 'post-opcje': minimapa, otwórz w edytorze, wklej do folderu z grą, itd.

OK, z tego co dzisiaj ustaliliśmy, o generowaniu dowolnego elementu decydują trzy zbiory ustawień: config, userParams i concreteParams - nazwijmy je roboczo settings.

Standardowe działanie programu polega na wczytaniu tych rzeczy (np. przez GUI) i wygenerowaniu mapy. Voila i do domu.

Natomiast chcielibyśmy umożliwić użytkownikom wczytanie istniejącego h3pgm'a i regernerowanie niektórych etapów. "Regenerowanie" nie tylko w postaci, zrób mi inne potwory na tych samych ustawieniach, ale także np. zrób mi inne potwory. Albo ustaw inne zamki.

Pomysł jest więc taki, że do h3pgm'a możemy dodać wiele settingów, każdy musi być związany z jakimś etapem. I teraz w momencie gdy chcemy jakąś wartość X na etapie powiedzmy "monsters", to wyszukujemy setting który został położony najpóźniej na liście etapów poprzedzających "monsters".

Krótko mówiąc trzeba dopisać interfejs który będzie to obsługiwał od strony kodu. Kawałek liba który na zawołanie w stylu state.userParams("monsters") odpowiednio przeszuka h3pgm i zwróci pożądaną wartość. (a równocześnie byłbym za tym, żeby w samym h3pgm wyglądało to jakoś przejrzyście. no i wymaga to żebyśmy też mieli gdzieś w kodzie zapisany ordering całości wraz z nazwami kodowymi poszczególnych faz).

blocked by #37

Do zrobienia sketch papieru w odpowiednim formatowaniu i od razu z planem sekcji do późniejszego uzupełniania.

Na razie żeby ten komponent po prostu istniał, będzie działał jako tako sensownie pewnie tylko dla pewnego podzbioru parametrów. Ale w szczególności powinno być też info z:

• listą i opisem parametrów jaką chcemy uwzględniać (docelowo) oraz jak ideologicznie powinny one wpływać na mapę (przepisać, uładzić i ponownie przemyśleć z doca)
• listą parametrów które uwzględniamy teraz

To co jeszcze potrzebujemy to ustalić jak powinien wyglądać ten absolutny początek toolchaina czyli jak parametry są podawane.

• rozsądny wydaje się plik .cfg w którym są podane parametry oraz seedy - tu też kwestia do omówienia jak będziemy rozwiązywali przekazywanie seedów do poszczególnych komponentów (wtedy trzymamy na dysku kilka konfigów i zmieniamy parametrem toolchaina jak chcemy wygenerować inny typ mapy)
• trzeba będzie też w toolchainie podawać nazwę jaką chcemy żeby miała wygenerowana mapa (plik .h3pgm oraz wszystkie .h3m-y).

Powrzucać do folderu z dokumentacją historyczne zdjęcia tablic żeby było tematycznie w jednym miejscu bez potrzeby przekopywania się przez tonę maili.

Co?

Napisać wrapper, który będzie pozwalał wywoływać CA bezpośrednio (tj. bez pośrednich jawnych plików) z poziomu Lua.

Dlaczego?

By zapewnić pełną wymienność modułów, każda z części powinna mieć takie samo API - na spotkaniu 2017-11-15 zdecydowaliśmy, że będzie to h3pgm -> h3pgm (Lua).