TL;DR: założyłem repozytorium, zorganizowałem porządną strukturę projektu, zrobiłem IDE i będę robił build system.
Na początek wypada przedstawić jak wygląda sytuacja zastana, bo niektórzy mogą o tym nie wiedzieć, a inni nie wiedzieć czy to źle.
Jak dotąd mody do Gothica są tworzone w bardzo amatorski sposób.
1. Przechowywanie i wymiana kodu
Zazwyczaj nie ma żadnego repozytorium z kodem źródłowym, jest to raczej wymiana plików z kodem przez generyczne serwisy do współdzielenia plików (jak Dropbox, Google Drive itd). W połączeniu z brakiem build systemu, efektywnie "składa" projekt tylko jedna osoba na raz.
2. Środowisko programistyczne
Kod jest tworzony w edytorach tekstowych jak Notepad++ czy Gothic Sourcer. Nie istnieje IDE które w trakcie pisania wykrywałoby błędy składniowe, niepoprawne referencje, pozwalało na nawigację przez kod czy chociaż najprostsze refactoringi (jak zmiana nazwy funkcji). Żeby dowiedzieć się czy kod jest poprawny, modderzy muszą uruchomić grę lub edytor lokacji (oba włączają się dość długo) i przeczekać powolny proces kompilacji. Kompilacja jest przerywana po wystąpieniu już pierwszego błędu, którym zazwyczaj jest brakujący średnik lub literówka w referencji.
3. Build system
Nie istnieje build system - modderzy ręcznie uruchamiają "reparsowanie" skryptów (kompilacja kodu źródłowego Daedalusa do kodu bajtowego maszyny wirtualnej Zengina w pliku .dat), następnie tworzą paczkę z modem (archiwum VDF), a na koniec instalator (.exe w oparciu o jakiś framework).
To złożona, żmudna i niepotrzebnie ręczna robota. Dałoby się to w pełni zautomatyzować i w profesjonalnych projektach takie rzeczy zawsze się automatyzuje.
4. Zawartość projektów
Projekty zwykle składają się z kopii GMDK na którą powprowadzano zmiany. Jest więc to całkowicie nieprzejrzysta mieszanina kodu Piranha Bytes i zespołu, przy czym i jeden i drugi jest zazwyczaj miernej jakości.
Jak to powinno wyglądać profesjonalnie i do jakiego stanu chcę doprowadzić w Dziejach Khorinis:
1. Przechowywanie i wymiana kodu
Repozytorium Git na GitHub.com. Na razie dostęp tylko dla członków grupy, docelowo mam nadzieję otwartoźródłowe.
Przy tym podejściu, równolegle nad modem może pracować bardzo duża osób jednocześnie, na bieżąco dostając w grze swoje zmiany czy samemu jednym kliknięciem tworząc gotowe instalatory dla testerów.
2. Środowisko programistyczne
Napisałem wtyczkę dodającą wsparcie Daedalusa do platformy IDE IntelliJ.
W trakcie pisania na żywo podkreśla błędy składniowe, niepoprawne referencje, pozwala na nawigację przez kod i proste refactoringi (jak zmiana nazw funkcji). Jeśli kod nie jest "czerwony" w edytorze, jest właściwie pewne że skompiluje się poprawnie.
Wydałem to otwartoźródłowo - każdy może jej używać i brać udział w jej rozbudowie o nowe funkcjonalności (
https://github.com/Avallach7/daedalus-intellij). Wymagana jest znajomość języka Java.
3. Build system
Będzie skrypt, który jednym kliknięciem będzie odpalał moda lub w pełni automatycznie budował wersję releasową (kompilacja skryptów + kompilacja innych assetów + złożenie paczki VDF + zbudowanie instalatora).
4. Zawartość projektu
W repozytorium nasze skrypty i assety będą całkowicie oddzielone od GMDK. Sprawi to że praca nad modem będzie dużo bardziej przejrzysta i będzie łatwiej zauważać bezsensowne / niepotrzebne elementy. Wspomniany przed chwilą build system będzie to składał w całość z GMDK przed odpaleniem / budowaniem.
W skryptach GMDK będziemy mieli jedynie te zmiany w implementacji których nie dało się wprowadzić przez umieszczenie kodu w nowych plikach. Te sytuacje powinny być jednak bardzo rzadkie.
Być może napiszę też narzędzie które będzie automatycznie weryfikowało czy ktoś nie popełnił w skryptach jakiegoś syfu (np dodanie całkiem nowej rzeczy w katalogu od GMDK, stosowanie złych konwencji nazewnictwa, mylących struktur w kodzie, czy umieszczanie kodu w innych folderach/katalogach niż podają nasze wewnętrzne wytyczne).