mod byłby plikiem tar (szybkie wypakowanie) z rozszerzeniem .vcmi
mógłby zawierać:
-LODy VIDy SNDy i zwykłe (7z/zip) paczki zasobów
-lużne pliki danych
-pliki konfiguracyjne vcmi
-łatki na pliki konfiguracyjne vcmi
-skrypty instalacji
-główny skrypt instalacji
-zasoby tekstowe ukryte przed menedżerem modów
katalog MODS zawierał by pliki vcmi i foldery z nazwami odpowiadającymi plikom modu (.DIR zamiast .VCMI), dodatkowy katalog current.dir na pliki zatwierdzane przez mod, zaczynałby od wypełnienia plikami konfiguracyjnymi z głównego katalogu (nie-modowego),
a podczas zatwierdzania modu wypakowywałby główny skrypt instalacji do nazwamodu.dir i uruchamiał
polecenia skryptu instalacji:
-ARCH (z aliasami SND, LOD, VID, ZIP, PACK) - dodawałby archiwum o nazwie wskazanej argumentem do archiwów obsługiwanych przez vcmi (bez kopiowania)
-FILE - wypakowywałby plik podany argumentem do folderu current.dir jeśli nie istnieje lub do nazwamodu.dir
-forcefile - jw. ale nadpisywałby zawartość celu
-PATCHLOCAL, PATCHGLOBAL (alias PATCH) - zastosowywałby plik patcha do pliku konfiguracyjnego lub tekstowego odpowiednio w katalogu modu/current.dir
-TOUCH - wypakowywałby plik tekstowy/konfiguracyjny do nazwamodu.dir lub tworzyłby nowy gdy źródło nie istnieje
-EXEC - uruchamiałby skrypt instalacyjny z nazwamodu.dir (musiałby być touch-nięty)
plik patch byłby także plikiem skryptu instalacji ale by korzystał głównie z innych poleceń
-PATCHING - zmiana pliku bierząco patchowanego (przydatne gdy chce się patchować bezpośrednio z skryptu instalacji), wywoływany automatycznie po użyciu patch(local/global) zamiast exec
-APPEND - dokleja wskazany plik na koniec pliku bierząco patchowanego
-Prepend - jw tylko na początek pliku
-INSERT - wkleja zawartość wskazanego pliku bezpośrednio po znaczniku wskazanym drugim argumentem (znacznik wygląda :arg )
-VAR - doklejałby resztę linii polecenia do pliku VARIABLES w katalogu modu (docelowo $nazwazmiennej=zawartość)
-CALC - wykonywałby na podanych zmiennych (w pliku variables) obliczenia (w tym konkatencja stringów) i wynik zapisywałby w następnej linii pliku variables przyporządkowany zmiennej będącej pierwszym argumentem
CONST - podmieniałby nazwę wskazanej zmiennej w bierząco patchowanym pliku zgodnie z zawartością pliku VARIABLES
reguły nazwy zmiennej:
$zmienna - zwykła zmienna zamieniana we wszystkich konfiguracyjnych i tekstowych plikach ruszonych przez mody i z katalogu current.dir pod koniec wykonywania skryptów instalacyjnych (ostatni wpis zmiennej z ostatniego modu ma znaczenie)
$$zmienna - zmienna specjalna - po podmienieniu wszystkich zwykłych zmiennych zamieniana na nazwę zmiennej w formacie odpowiadającym rozszerzeniu pliku (lub nie zamieniana) (przydatne gdy chce się używać tej zmiennej bezposrednio w skrypcie i chce się wyłączyć podstawianie)
$@nazwamodu:nazwazmiennej - zwykła zmienna zakresowa pochodząca z pliku VARIABLES z innego modu
występowałyby pliki SAFE i UNSAFE przesyłane przez serwer z listami wyrażeń regularnych dozwolonych / zakazanych poleceń w skryptach instalacyjnych - jeśli polecenie znajduje się w liście SAFE i nie znajduje w UNSAFE i serwer jest w zwykłym trybie bezpieczeństwa polecenie jest wykonywane normalnie, jeśli podczas ładowania serwer byłby ustawiony na tryb RISK wystarczy że polecenie nie jest w UNSAFE by wykonało się normalnie, jeśli serwer jest w trybie UNSAFE, każde polecenie jest wykonywane normalnie, w przeciwnym wypadku polecenie jest pomijane
po zaakceptowaniu modów i podmianie zmiennych dokonywane jest usunięcie wszystkich etykiet :nazwa z plików w których takie etykiety są niedozwolone (wszystkie nie-skrypty)
Super, jeszcze tylko skryptów instalacji nam brakowało… znakomity pomysł na to, aby fani zaczęli się zachwycać wsparciem dla modów w WoGu. Czy istnieje jakakolwiek zaleta systemu z modami nadpisującymi inne pliki? I czy instalacja dawałaby coś poza irytacją graczy, modderów i deweloperów?
skrypt mógłby być generowany automatycznie przez menedżer modów, geekowie by poprawiali bardziej
zalety:
-można pozostać przy bierzącej formie plików konfiguracyjnych
-bardziej elastyczny mechanizm niż przy przypisywaniu feauturów konkretnemu numerkowi (można insertować przy każdej etykiecie)
-pliki konfiguracyjne dostarczone silnikowi pozbawione by były konieczności obsługi zmiennych, przy zachowaniu zalet używania zmiennych
-wysoki wpółczynnnik zgodności modów wpływających na ten sam feature (w “inteligentnym” systemie byłoby to o wiele trudniejsze)
-możliwość rekonfiguracji modów bazowych przez jeden maluśki mod na końcu kolejki
-mozliwość instalacji materiałów dodatkowych bez ingerencji w podstawowy zestaw danych
-prostota od strony programistycznej
-możliwość łatwego odfiltrowania zmian przez obsługującego serwer
zapomniałem wspomnieć że te skrypty instalacyjne zajmowałyby się zaakceptowaniem modu a nie tylko jego instalacją - to znaczy że format obsługiwany przy otwieraniu moda byłby taki sam jak przy publikacji
poza tym zapominacie że najprostsza zawartość skryptu instalacyjnego to zaledwie kilka linijek typu
przy czym pliki miasta.txt i jednostki.txt to w najprostszym wypadku seria poleceń insert lub jedno polecenie append, których argumentem jest fragment pliku konfiguracyjnego w postaci takiej jak bierzące pliki konfiguracyjne
@warmonger
buahaaha oczywiście że jest format tekstowy - to dzięki niemu w linuksie możesz zwykłym edytorem tekstu zmienić drażliwy element konfiguracji gdy pod windowsem potrzebny jest wyspecjalizowany program który na dodatek nie wspiera jakichś rzadszych przypadków
to co proponuje to jest prosty plik typu batch - czytelny i łatwy w implementacji, a wszystko to byłoby zaszyte w paczce przez co użytkownik nie musiał by się tym martwić, a dla moddera to nie większy zachód niż napisanie pliku *.cmd *.bat lub *.sh który by przestawiał pojedyńczy feature lub po prostu instalował bardziej skomplikowany mod
wystrzegałem się przy tym niejasnych dwuliterowych komend i starałem się nadać im znaczenie a także aliasy np. plik heroesplus.lod mozemy załadować polceniem LOD i nie musimy pamiętać że to to samo co arch (archive)
@tow dragon
a zaleta katalogu current.dir?
taka jak każdego rozwiązania z katalogiem tymczasowym plus zalety sandboxa
czyli brak konieczności sprzątania po zabugowanym instalatorze, brak możliwości naruszenia rdzenia gry, a także możliwość czystego startu przy każdym uruchomieniu i prostota systemu pozwalająca uniknąć nieoczywistych błędów
każdy “inteligentny” system modów w grze jaki znam miał jakieś wady których ominięcie powodowało sporo zachodu (przy zamkniętym żródle)
a to powodowało by problemy ze zgodnością wstecz przy otwartym źródle i chęci wyeliminowania problemu
ale to tylko szkic rozwiązania które może być w szczegółach inne i na pewno nie jedyny słuszny
Mógłbyś krócej i jaśniej? Przeczytałem kilka fragmentów twojego posta i z niektórymi się nie zgadzam, a niektóre przypominają mi lekturę rozdziału o algebrze homologicznej ze “Wstępu do topologii” (coś między uczuciami “aha”, “WTF” i “a na co to komu”). Przy czym algebra homologiczna zdaje się mieć jakieś zastosowania, więc zamierzam jeszcze do niej wrócić.
O ile łatwiejsze w obsłudze byłoby użycie języka skryptowego wywołującego odpowiednie funkcje programu głównego. Znajdujemy w folderze modu odpowiedni plik Pythona i go wykonujemy, co powoduje dodanie do listy obiektów gry nowych stworzeń, artefaktów i miast tudzież modyfikację już istniejących. Tak czy inaczej, należy napisać obsługę tych funkcji bezpośrednio w kodzie gry, niech więc lepiej będą jak najprostsze.
Naprawdę nie trzeba do tego zaprzęgać kolejnego języka - sam silnik jest pisany w C++, skrypty w Pythonie lub Lui, do tego dochodzi ERM, którym prędzej czy później trzeba będzie się zająć. A Ty chcesz jeszcze dorzucać basha?
Z obsługą ‘bardziej skomplikowanych modów’ poczekajmy, aż uda się zmodyfikować cokolwiek. I nie, nie potrzebujemy plików instalacyjnych - skoro H5 działa na zasadzie drag&drop, VCMI też może. Dzięki temu tą grą zajmują się zupełnie normalni ludzie, a nie tylko stwory z mrocznych czeluści serwerowni.
przepraszam ale mnie nie zrozumiałeś
przez “skrypty instalacyjne” miałem na myśli skrypty uruchamiane przy dodaniu nowego moda, którego zwykła instalacja przebiegałaby przez wgranie paczki
chodzi o to by nie tworzyć heurystyk zgodności tylko żeby każda paczka miałła prosty zbiór poleceń co jak połączyć
głównie chodzi mi o to żeby pliki konfiguracyjne można było łączyć a nie tylko zamieniać
oczywiście nic nie przeszkadza aby mieć zwykły język typu python a te polecenia były funkcjami bibliotecznymi - w sumie w pythonie można zrobić bardziej zaawansowane funkcje konsolidacji modów niż w zaprezentowanym skrypcie którego parser zająłby nie więcej niż jedną stronę kodu
mi chodziło o koncepcję modów patchujących a nie o konkretny język skryptowy
A jak modder sobie coś pomyli i się źle połączy, to i wszyscy będą narzekali na silnik… a jeśli skrypty nie są widoczne dla moddera, to są detalem implementacyjnym i nie ma co się nimi zajmować w oderwaniu od ogólnej koncepcji (do której się nie odniosłeś).
Kilkanaście komend, z aliasami i zmiennymi ma się zmieścić na jednej stronie? No to ciekawe…
No to jak chodzi ci o koncepcję, to może napisz o zaletach tej koncepcji w stosunku do propozycji mikromodów i rulesetów zamiast wypisywać nikomu obecnie nie potrzebną listę potencjalnych komend.
@heurystyki zgodności
jeśli mody są w postaci bazodanowej (jak w h5 czy TES) to przy potencjalnej niezgodności są trzy wyjścia 1) nie pozwolić na działanie 2) ułożyć zasadę co zamienia co wedle kolejności (first wins/last wins) 3) zbadać heurystycznie zgodność i na tej podstawie ratować co się da
@niewidoczne dla modera
ma być niewidoczne dla modera-lamera a jak najbardziej widoczne dla tych co są pro-moderami (przynajmniej dla tych co to stwierdzą)
@lista niepotrzebnych komend
może opisałem to zbyt szczegółowo jeśli chodzi o implementację ale chodzi mi głównie o funkcjonalności
@koncepcja
chodzi o to by nagłówek modu był wykonywalny (plik wsadowy, skrypt itp)
żeby wspierał zmienne, żeby pliki można było patchować a nie tylko zamieniać
także o to by twórca modu sam zadbał o zgodność z innymi (autorstwo zobowiązuje)
także miałem na myśli by móc ustalić przez serwer które polecenia/dane są dozwolone a które nie i by pozwalał na dopuszczalne nawet jeśli są różne niż na serwerze (np inna grafika czerwonego smoka)
także o to by mody były sparametryzowane i żeby nazwany parametr można było zmienić innym modem
także o to by plik z serwera był jako tako zgodny z plikiem modu, był zobowiązujący i niewielki
także chodzi mi o to by każdy mod miał swój własny katalog tymczasowy jak i był katalog tymczasowy globalny dla bieżącej gry
PS: pliki *.wog też są instalowane przez skrypt wewnątrz który jest wcale nie prostszy niż moja propozycja
jeszcze raz mówię że to mają być skrypty z nagłówka
a skrypty z gry mogą być od tego niezależne
@heurystyki
z bardzo gęsto powiązanymi modami nie da się wszystkiego sprawdzić rozsądnie
jak się próbuje wszystko sprawdzić to albo zajmie to z godzinę, albo analizator się powiesi np. na zapętlonych zależnościach, albo stwierdzi że mody są niezgodne jak są cześciowo zgodne i pewne niezgodności można zaniedbać
EDIT: moja koncepcja jest prosta może nawet zbyt prosta, a ja ją niestety zamąciłem podając szczegóły realizacji, poza tym przedstawiłem cele a nie wszystkie zalety, bo kilka podstawowych celów może implikować mnóstwo zalet, oczywiście sysem można rozbudować/poprawić/cokolwiek po prostu stwierdziłem że wpadłem na genialny choć prosty pomysł i chciałem się nim podzielić tak jak się pojawił w mojej głowie, przez co oczywiście jest niedopracowany i po mojej stronie wystarczałuy domysły których po waszej nie ma
implementacja może być dowolna - chodzi tu o cele które upraszczają sposób dotarcia do głównego celu a nie o konkretną implementację - na przykład nie wpadłem na to by zaprząść do tego gotowy parser skryptów i dodać polecenia jako funkcje - widać jest wiele do dopracowania - czemu nie zaprzeczę
To jest twoja osobista opinia czy wypowiedź kogoś kto robił mod support do jakiejś gry? Nie wydaje mi się, aby jakakolwiek gra dawała możliwość zagmatwania zależności modów aż tak bardzo… oczywiście wykluczam sprawdzanie sensowności współdziałania skryptów zmieniających stan gry w czasie jej trwania - ja bym tego nie sprawdzał w ogóle, a odnośnie konfliktów w ustawieniach początkowych - naprawdę, nie widzę co tu można zagmatwać. Jeśli mody wpływają tylko na różne ustawienia początkowe - jest ok, jeśli na te same - to musimy wybrać, który mod będzie “ważniejszy”. Nie widzę tu żadnych poważnych problemów.
Cele powinny być efektem analizy potrzeb i możliwości ich zaspokojenia. Radzę ci opisywać propozycje w taki sposób:
wskazanie podstawowych potrzeb graczy / modderów / deweloperów (tych, do których się odnosisz w propozycji - np. gracz potrzebuje łatwo uruchamiać różne mody i w miarę łatwo je łączyć, modder potrzebuje rozbudowanych możliwości i prostego tworzenia, deweloper prostoty implementacji)
wskazanie możliwości ich realizacji wraz z uzasadnieniem, w jaki sposób te potrzeby są zaspokajane (np. skrypt uruchamiany przy włączaniu moda będzie niewidoczny dla gracza a zapewni pewne możliwości modderowi (jakie? da się je zaspokoić inaczej czy byłby z tym problem? - to są istotne pytania)); w tym punkcie dobrze jest też odnieść się do innych, proponowanych wcześniej rozwiązań zadań wymienionych w punkcie 1
szczegóły implementacyjne (np. zmienne w plikach uruchamianych przy uruchamianiu moda dałyby dodatkowe możliwości); ten punkt może zostać pominięty na rzecz większego rozbudowania punktu 2
Taki szyk moim zdaniem pozwoli na łatwiejsze połapanie się w propozycji i ułatwi polemikę.
Moim zdaniem taki szyk łatwo pozwoli każdemu odnaleźć się w twojej propozycji, a także ułatwi polemikę.
nagmatwane mody? nie widziałeś The Elder Scrolls 3-4 (morrowind i oblivion)?
żeby różne mody działały razem moderzy muszą się (nie)zdrowo nagimnastykować i jeszcze zazwyczaj to i tak wymaga zewnętrznego fanowskiego narzędzia które trzeba dobrze skonfigurować pod dany zestaw modów a owe narzędzie jest pełnowymiarową aplikacją same w sobie… naprawdę nie wiesz jak to się potrafi skomplikować
@cele
ja uważąm za dobrą strategię wyznaczanie sobie celów pośrednich które ułatwią te docelowe
prostota działania mechanizmu przy jego wysokiej kofiguralności jest podstawowym prawdziwym sposobem na wsparcie modów i przede wszystkim moderów
wysoka konfigurowalność przy niezbyt utrudnionej reszcie może być postawione za cel bez zastanowienia gdyż prawie zawsze się sprawdzi i to często tam gdzie się nie spodziewamy
forma wykonywalna nagłówka modu daje duży wpływ modera na integracje jego modu z innymi i sposób odbierania jego przez silnik gry przy niewielkim utrudnieniu dla mniej zaawansowanych moderów
jednym z najbardziej sprawdzonych celów pośrednich ogólnie w eksploatacji programów jest utrzymanie plików konfiguracji w formie tekstowej - zobaczcie jak się różni tweakowanie linuksa i windowsa
moja ulubiona cecha celów pośrednich są zalety długoterminowe które są nie do przewidzenia startując od zera
@mój największy błąd
moim największym błędem była niespójność prezentacji i praktycznie odwrotny sposób jej realizacji za co bardzo przepraszam i co sporo utrudniło zrozumienie - zgadzam się że uporządkowanie wypowiedzi według tych trzech punktów jest dużo lepsze
@nadzieja
mam nadzieję że zrozumieliście już treść mojego przekazu i wykorzystacie to co najlepsze wwaszym vcmi
Nie, nie widziałem tych gier. Tak w ogóle - czy te gry mają mod support producenta czy też fani postanowili to modować na własną rękę? Jeśli to drugie, to twój przykład jest trochę chybiony. I drugie pytanie: jeśli producent dał możliwość modowania, to czy choć minimalnie przewidział chęć mieszania modów czy po prostu jest zasada “jeden mod na raz” (nawiasem mówiąc, ucinająca wszelkie problemy z łączeniem modów - przynajmniej dla deweloperów). Uściślając moją wypowiedź: chodziło mi o sytuację, w której producent gry daje możliwość łączenia modów. Choć w sumie… może ci chodziło o to, że w sytuacjach konfliktu modów losujemy który mod wprowadzi daną zmianę i ewentualnie jakoś grupujemy konfliktowe opcje - np. jak mod A zamienia jednostkę na inną i mod B też chce, to jak wybierzemy jeden z modów do wykonania zmiany to usiłujemy tą decyzję sensownie propagować…
No to mógłby być jakiś cel, ale moim zdaniem mechanizm plików konfiguracyjnych jest prostszy od skryptów… i mógłbyś opisać jakiś konkretny scenariusz, w którym istotnie rośnie konfigurowalność?
TESy mają Construction Set : dzięki niemu można np.dodawać nowe budynki czy postacie. Głównym plikiem modu jest plik z rozszerzeniem .esp w których są główne informacje ( resztę plików np.grafikę wrzuca się do folderu Data Files przez co robi się bałagan) . Dlatego podoba mi się reguła “Wszystko w Jednym Pliku”.
hej mam odświeżony pomysł co do wsparcia modów, ponieważ tamten niedomagał trochę
głównym elementem konfiguracji moda byłyby skrypty (najlepiej w Pythonie)
zmianę treści dowolnego pliku konfiguracyjnego odbywała się na wywołaniu skryptu z tym plikiem jako parametrem, prze podanie pliku wprost można dodawać tylko nowe pliki
zastosowanie wirtualnego systemu plików - wszystkie pliki poniżej 64kb nie będące DEF-ami będą w czasie ładowania modów przechowywane w pamięci, przez co ograniczy się operacje dyskowe - przyspieszy proces ładowania i ubezpieczy dając pewność nie nadpisania ważnych plików
bazą virtualnego systemu plików będzie ten realny (realny pozostaje nie zmieniony podczas ładowania modów i odpowiada za początkowy stan VFS)
kolejność wykonywania skryptów modyfikujących zawartość VFS zależy od konfiguracji gry (kolejność modów) oraz konfiguracji wewnętrznej moda (plik wsadowy)
cały mod byłby paczką tar zawierającą
6.1 folder VFS zawierający nowe pliki do VFS oraz skrypty edycji które też byłyby ładowane przez VFS
6.2 dowolną ilość archiwów - archiwa mogą zawierać dane multimedialne (defy, dźwięki, grafiki, filmy itp), oraz folder VFS obsługiwany jak ten z 6.1
6.3 plik wsadowy startowy, oraz opcjonalnie inne pliki wsadowe
plik wsadowy nic by nie robił poza wykonywaniem skryptów edycji (tych w pythonie), przekazaniem do nich parametrów, oraz wywoływaniem innych plików wsadowych
7.1 parametrem przesłanymi do skryptu edycji musi być jako pierwszy ‘edytowany’ plik (z vfs)
7.2 parametrami przesłanymi do skryptu edycji mogą być inne pliki pomocnicze (Read/Only) i/lub stringi przekazywane dosłownie
7.3 przy wywoływaniu pliku wsadowego można przekazać parametry (stringi, pliki) które ten może przekazać dalej
skrypt edycji byłby uruchamiany z zainicjowanymi parametrami (plik-> zawartość, string- jak leci)
skrypt edycji wysyła na standardowe wyjście przetworzoną zawartość pliku
VFS oprócz plików przechowywałby zestaw wszystkich ścieżek do plików które nie wchodzą w jego skład
plik reguł byłby podobny do pliku będącego modem przy czym:
11.1) nie może zawierać plików spoza VFS (grafik itp)
11.2) plik wsadowy miałby dodatkowo opcje załadowania modu (plik startowy modu byłby wywoływany z parametrami przekazanymi tu)
11.3) pliki które mają być przekazane jako parametry do plików startowych modu muszą być w tym tarze tej paczce zawarte, lub zawarte w paczce modu
W ogólnych zarysach zaczyna to przypominać system, który zaproponowałem wcześniej - a nawet, jeśli nie zaproponowałem, to miałem na myśli
Coś ty się uparł na te pliki wsadowe? O ile w pewnych sytuacjach znajdują zastosowanie, to odpalanie jednocześnie kilkudziesięciu takich wydaje się dość kontrowersyjne. Wystarczy w każdym modzie wyznaczyć plik główny (o sugestywnej nazwie header.py, main.py, mod.py czy co tam jeszcze), który będzie zbierał do kupy zawartość folderu z modem. W takiej sytuacji każdy mod żyłby sobie w oddzielnym folderze.
Plik taki zawiera funkcje w rodzaju NewArtifact(nazwa), które dodają nowe obiekty do listy i zwracają ich indeks, oraz wszelkie wywołania parserów plików tekstowych, konfiguracyjnych, .def i innych. Działają one dokłądnie tak samo (i są tymi samymi), jak dotychczas istniejące funkcje VCMI odpowiedzialne za wczytywanie plików gry.
pliki wsadowe są odpowiednikiem makefile - można łatwo zamienić kolejność zmian bez konieczności edycji skryptu jako takiego
co do skryptów edycji, to mogą korzystać z jakich bibliotek chcą, w szczególności tych opracowanych przez team vcmi
można będzie korzystać z technik wysokoobiektowych, a także z tych prostszych… oczywiście zalecanym wariantem może być korzystanie z konkretnych bibliotek, jednak nie ograniczenie do takowych zwiększa kontrolę nad integracją moda
pliki konfiguracyjne byłyby wirtualnymi plikami tekstowymi które skrypty edycji mogą zmieniać w DOWOLNY sposób: np dopisywać treść w uprzednio zamienionym miejscu, zamieniać teksty namierzone wyrażeniem regularnym na własne itp.
dobrą cechą pełnego egzekutywizmu jest dobra obsługa sytuacji wyjątkowych tzn. skrypt może się zorientować że czegoś brakuje i załatać wymagającą tej brakującej części opcję używając prostszych danych (“aha brakuje zasobów zamku heaven to zróbmy wzmocnioną wersję castle na istniejących zasobach”) i wiele rzeczy o których nie przypuszczamy że mogą wystąpić… oczywiście skrypty edycji mogą się w szczególnym przypadku ograniczyć do “dodaj to to i to zgodnie z zaleceniami” ale nie muszą
głównym zadaniem plików wsadowych jest proste przekazywanie parametrów (np możesz przesłać listę zmiennych jako plik z zewnątrz modu przez główny plik wsadowy gry)
za to skrypty WEWNĄTRZ gry byłyby traktowane jako zwykłe pliki konfiguracyjne co umożliwiłoby metaprogramowanie ich z poziomu sekcji instalacyjnej modu
AHA i jeszcze bym zapomniał: klient mógłby przechowywać cache dla konkretnej konfiguracji (po prostu po ukończeniu inicjalizacji wszystkich modów zapisałby stan VFS-u wraz z elememntem na podstawie którego można sprawdzić czy w bieżącej konfiguracji chodzi dokładnie o tą samą konfigurację)
EDIT: pliki konfiguracyjne z VFS-u trafiałyby do silnika dopiero po zakończeniu inicjalizacji, więc dzięki temu jest możliwa obróbka wstępna nieograniczona silnikiem
Widzę, że cały koncentrujesz się na tym, jak przeprowadzić modyfikacje, natomiast chciałbym wiedzieć, CO tak naprawdę chcesz modyfikować. Najpierw cele, potem środki. Inaczej całość staje się niemożliwa do ogarnięcia.
Jako pierwszy cel realizowalny w przewidywalnej przyszłości i decydujący o faktycznym powodzeniu projektu określiłbym możliwość dodawania (ew. modyfikowania) obiektów gry, takich jak stwory i artefakty oraz lokacje na mapie.
Aby tego dokonać, proponuję wyeksportować kilka podstawowych klas opisujących te obiekty do Pythona, wraz kilkoma funkcjami pozwalającymi na ich modyfikację (dodaj zdolność, podmień opis etc). Wówczas wystarczy stworzyć nowy obiekt poprzez dziedziczenie i/lub te funkcje, określić jego właściwości, podpiąć jakąś grafikę i dodać do listy obiektów występujących w grze. Voila, losowe potwory i artefakty zaczną pojawiać się na mapie.
Wparcie dla bardzie zaawansowanych modów, jak zaklęcia i interface (a zatem również miasta) może wymagać większego nakładu pracy oraz dobrze przemyślanego udostępnienia graczom modyfikowalnych elementów gry, oddzielonych od stabilnego i spójnego silnika. Nie łudźmy się, że moderzy będą w stanie swobodnie grzebać w najciemniejszych zakamarkach kodu i np. podmieniać funkcje biblioteczne na własne
Przykładzik w postaci Pythonowego pseudokodu:
id = CreateArtifact(
'CrystalOrb', #nazwa referencyjna
'Crystal Orb', #nazwa w grze
ART_RELIC, #rarity
ART_HERO, #sa niby jeszcze artefakty dowódców / oddziałów
ARTPOS_MISC #slot
)
id.AddBonus (SIGHT_RADIOUS,+12)
id.price = 8000
id.AIValue = 12000
id.description = ParseTextFile ('.\CrystalOrb.txt')
SetArtifactDef ('CrystalOrb','.\lodfile\orb.def')
ArtHandler.SetArtAvaliable ('CrystalOrb')
moim zamiarem byłoby danie nieograniczonych możliwości skryptowych,
zaś zapis utrzymać w prostocie
więc medium byłyby tekstowe pliki konfiguracyjne (takie jak dotychczasowe pliki konfiguracyjne heroesa, jak dodatkowe pliki tekstowe vcmi, jak bazy danych mysql, jak arkusze xml) - medium byłoby prosto określone
za to dowolność w operacjach (podmiany, inserty, haszowanie, dublowanie i co dusza zapragnie)
cały pomysł w tym żeby skrypty wyedytowały pliki konfiguracyjne przed startem growej części silnika, a nie opierały się wyłacznie na eksportach silnika
biblioteki z eksportami w moim pomyśle, zawierałyby tylko uproszczone obsługi pliku tekstowego (znajdź-zamień, sprawdź-dodaj itp) opakowane w ładny interfejs obiektowy, za to skrypt mógłby korzystać z (prawie) każdej biblioteki czy to matematycznej czy plikowej, czy to generatora losowego czy co tam modder zapragnie - standardem by było skrypt dostaje plik z VFS od preloadera z silnika, przetwarza go, zwraca preloaderowi a ten uaktualnia go w VFS
oczywiście nie jestem przeciwko edytowaniu zasobów gry w czasie wykonania (skrypty edycji tj. kompilują środowisko) ale to powinno być jako oddzielna opcja już wewnątrz właściwej części silnika, zwłaszcza że takie runtime-script-y miały by mniejsze możliwości
zapewne runtimy miały by ciekawe właściwości typu dynamiczna allokacja itp ale powinny być (jeśli będą) oddzielnie od surowej części loadera
gdyby zostawić tylko interfejs obiektowy mielibyśmy sytuacje odwrotną do oczekiwanej w moim pomyśle - czyli binarno-klasowy nośnik i ograniczone funkcjonalnie skrypty
cały sęk w tym że gdy się sztywno ustawi granice co może być modyfikowane prędzej czy później nastąpi potrzeba ich przekroczenia - więc lepiej wyposażyć moddera w bardziej skomplikowane narzędzie, które bez problemu załatwi wszystkie podstawowe potrzeby, a zostawi (prawie) nieograniczone pole do zaawansowanych modderów/skrypterów
