Niepojęty pozostaje dla mnie opór, z jakim dyskutujecie nieistotne w ostatecznym rozrachunku detale implementacyjne. Ich omawianie nie jest naturalnie niczym złym, ale w oderwaniu od nadrzędnych zagadnień jest po prostu… daremne. A kwestie prawdziwie ważkie, kluczowe wydają mi się kompletnie pominięte.
W angielskim wątku o skryptach wskazałem przykład takiej, nie spotkało się to z konkretnym odzewem, więc pozwoliłem dyskusji toczyć swoim torem - co chyba mogło być opacznie poczytane za moją aprobatę. Tutaj widzę to samo, ale język bliższy (nienawidzę mojej koślawej angielszczyzny) więc raz jeszcze się wtrącę.
Pierwszy pomysł Majaczka jako całość jest dla mnie trudny do ogarnięcia. Przeczytałem jeden post, potem jeszcze raz, potem myślałem, że kolejne rozjaśnią całość, ale nic z tego. “Im bardziej Puchatek zaglądał do środka, tym bardziej Prosiaczka tam nie było.” Mimo to zrozumiałem dostatecznie dużo, by mnie ciarki przeszły. Kolejne wersje różnią się detalami implementacyjnymi, ale ta straszliwa myśl, stojąca za nimi wszystkimi, trwa niezmieniona.
Po moim trupie! [albo twoim forku 
]
Ten pomysł jest tak aberracyjny, że nawet nie potrafię wymyślić porównania, które by to dobrze ukazało.
Dlaczego?
W skrócie - zawodne, obłędnie pracochłonne, mało możliwości, nierozwijalne.
W szczególe:
-
Pliki konfiguracyjne reprezentujące identyczną logikę mogą mieć w H3 różną postać tekstową. (Wersje językowe dla przykładu)
-
Długa i kręta droga by cokolwiek zrobić. Aby skrypter mógł zaimplementowac daną funkcjonalność, to:
a) Implementuje ją w języku skryptowym. Aby to było możliwe, język skrytpowy musi udostępniać jakiś interfejs umożliwiający interakcję z mechaniką gry.
b) Biblioteka skryptu tłumaczy to co modder napisał na odpowiadającą temu postać tekstową i odpowiednio modyfikuje pliki konfiguracyjne.
c) VCMI parsuje plik konfiguracyjny, odczytując z niego informacje o logice gry.
Każdy element logiki musi być tak naprawdę w czterech miejscach naniesiony: raz - wykonanie logiki przez sam silnik; dwa - dodanie logiki to formatu pliku konfiguracyjnego i parsowanie jej przez VCMI; trzy - odwrotne parsowanie (logika -> tekst) po stronie biblioteki skryptu; cztery - udostępnienie elementu i powiązanych struktur w interfejsie skryptowym dla moddera (i w końcu pięć - użycie tego wszystkiego przez moddera). Szaleńcze, jeśli za alternatywę weźmiemy udostępnienie pewnego interfejsu (zbioru funkcji i powiązanych z nimi struktur danych) bezpośrednio skryptom. (Raz - robimy funkcję realizującą logikę w VCMI; dwa - biblioteka skryptu udostępnia to modderowi).
-
Ograniczona funkcjonalność. Można tylko modyfikować pliki konfiguracyjne. To może i pozwoli na dodawanie nowej treści wizualnej, ale niewiele więcej. Nie można na tym zrealizować interaktywnych skryptów, nie można pisać złożonej logiki. Wszystko jest wszak wykonywane przed rozpoczęciem rozgrywki, więc siłą rzeczy te skrypty będą statyczne.
No chyba, że przez bogactwo możliwości rozumiemy, że będzie można napisać skrypt podający VCMI wszystkie pliki wspak albo pokemonizujący komunikaty w grze.
-
Niemożliwe do rozwoju. Dodanie jakiegoś nowego elementu do pliku konfiguracyjnego spowodowałoby, że wszystkie dotychczasowe skrypty wykonujące operacje tekstowe na pliku (dokonując tym samym założeń odnośnie jego kształtu) pogubiłyby się. Dowolna zmiana czegokolwiek w formacie wymagałyby dużych zmian w parserze VCMI i parserach wszystkich bibliotek skryptowych. Wskaż mi dewelopera, który by to robił. Ja na pewno nie.
To tylko najbardziej cisnące się na usta (palce?) uwagi.
Nie czuj się proszę dotknięty tą krytyką - naprawdę podziwiam twój zapał i cieszę się, że przedstawiasz swoje pomysły - po prostu ta konkretna idea jest w moich oczach nietrafiona.
A kto zrobi? Na razie wciąż brak nam rąk do pracy, by odtworzyć funkcjonalności oryginalnego Heroesa…
To o czym pisze Warmonger jest generalnie słuszne. Niestety jest zbyt generalne, by coś wynikało. Udostępnienie językom skryptowym (Python, nie Python - to nieistotne) odpowiedniego zbioru funkcji umożliwiających modyfikację logiki i interakcje z nią jest oczywistym i najwidoczniej jedynym słusznym sposobem realizacji skryptów. Nic lepszego chyba nie wymyślono. [No, jeszcze jest uproszczony wariant pod tytułem handler skryptów bezpośrednio dziubie w silniku, ale tego nie chcemy.]
Trafna jest uwaga, że najpierw należny określić cele do osiągnięcia, a dopiero następnie dobierać odpowiednie “środki implementacyjne”. Natomiast zanim zaczniemy się bawić w jakiekolwiek skrypty, musimy mieć ideę całości ich systemu. Najpierw cele i wymogi względem ogólnej całości, potem dopiero można wypełniać ją jakąś szczegółową treścią. Dodawanie nowych potworów czy artefaktów jest tu właśnie szczegółem - jakimś małym wycinkiem całości, niespecjalnie fascynującym z jakiejkolwiek perspektywy. (Dzięki mojemu systemowi bonusów nie powinno tu być problemów 
)
Podstawowy cel, jaki ma nasz projekt, to odtworzenie funkcjonalności Heroesa z WoG-iem. WoG ma swój język skryptów - ERM. Nasz system więc zasadniczo powinien oferować przynajmniej te możliwości, jakie ma ERM. To można sobie przyjąć za cel pierwszy - bo jest zgodne z założeniami projektu, oczekiwaniami fanów i dostatecznie komplikuje zagadnienia. Żeby było weselej, niech skrypty działają w trybie multiplayer należycie; muszą być przy tym bezpieczne (nie stwarzające możliwości oszustwa) lub reaktywne (nie robiące “lagów” w mechanice lub GUI). Piszę “lub” - bo jednego z drugim połączyć się nie da. Pamiętajcie, że gra VCMI to jeden serwer i do ośmiu klientów. Pamiętajcie, że ERM umożliwia reagowanie zarówno na koknretne zdarzenia w logice gry (bohater odwiedza pole, nowy dzień) jak i zdarzenia w GUI (gracz kliknął myszą).
A, jeszcze fajnie by było, gdyby funkcjonalności dodane przez skrypty mogły być wspierane przez AI.
W ogóle zagadnienia modów i skryptów to trochę co innego. Dużo łatwiej zmodyfikować ( / sparametryzować) istniejącą logikę w silniku, niż dodać ją gdzieś “poza”.
W skrócie:
- bezpieczeństwo skryptów (co zrobić, żeby mogły być używane w rozgrywkach MP bez obawy oszustw)
- niezawodność i reaktywnośc skryptów (żeby mogły by ć używane w MP i nie prowadziły do lagów lub błędów desynchronizacji)
- skrypty a AI
W ogóle, to zanim poważnie będziemy dyskutować o dodaniu skryptów, VCMI musi mieć działający tryb multiplayer w dwóch wariantach (reaktywny, bezpieczny). To ciągle długa perspektywa. Traktujcie mój post jako wrzucenie problemu do niezobowiązującej dyskusji - która jednak jak najbardziej może wpłynąć na kształtowanie się mojej końcowej idei systemu skryptów / modów.
Szeroko rozumiane modyfikacje gry muszą być ostatnią dużą funkcjonalnością, jaką zaimplementujemy. (No, może poza AI, które do niczego nie jest konieczne, a może być od nich zależne.)
