Witam, otworzę nowy wątek żeby było bardziej przejrzyście. Mianowicie mam pytanie, który z projektów odpowiada za obsługę AI:
StupidAI czy VCAI? czy może to są 2 niezależne projekty do AI? Przydałoby się jakieś info jak wykorzystywać informacje pochodzące z mapy: jak odczytać ile jest potworów lub ile armii ma wróg, co znajduje się w mieście itp. Można też byłoby zrobić osobną klasę odpowiedzialną za pośrednictwo pomiędzy mechaniką mapy a AI. Tak by móc pobrać informacje o mapie z tej klasy(jak już wyżej wymieniłem o przeciwnikach ale także bardziej pomocnicze funkcję jak wyszukanie najkrótszej drogi, informacjami o danym kaflu mapy itp.), w naszej klasie AI ją przetworzyć i na podstawie tego wykonać odpowiednią interakcję w grze( przykład funkcji: goTO(position) z uwzględnieniem celu wskazanej drogi, czyli ma iść do skarbu to podchodzi do niego i podnosi jak normalny gracz, rekrutacja jednostek w zamku i innych budowlach itp.) Poza tym dodać jakąś klasę odpowiedzialną za komunikowanie eventów zachodzących na mapie(np.: utrata naszego zamku, utrata zamku przez sojusznika, wygrana bitwa, przegrana bitwa, utrata kopalni, zdobycie kopalni itp.) - taka jakby baza wydarzeń przez którą moglibyśmy analizować jak miałby wyglądać ruch AI.
Później pewnie łatwiej byłoby dodać do tego możliwość oskryptowania. Ktoś kto chce zrobić swoje AI siada i piszę mając gotowe do tego celu funkcje, kolejna zaleta to zapewne kontrola co algorytm AI mógłby odczytać z informacji o mapie. Czy miałby to być wszechwiedzący komputer czy musiałby analizować swoje poczynania wraz z poszerzaniem obszaru widzialnego. Ograniczyłoby to także zakres wiedzy jaki powinien posiadać ktoś kto zajmuję się tym projektem, odpadła by cała znajomość mechaniki.
To mniej więcej tyle co sądzę na temat implementacji modułu AI:)
StupidAI odpowiada za bitwy, VCAI - za akcje na mapie przygody.
Wszystkie informacje o grze, które są dostępne dla gracza, można odczytać za pomocą rodziny klas Callback (obiekty cb, myCb). Docelowo wszystkie one powinny być odczytywane TYLKO za pomocą bezpiecznych metod tej klasy, ale wiele informacji jest jawnie dostępnych dla uproszczenia - na przykład możemy poznać wszystkie właściwości obiektu, na który trzymamy wskaźnik *obj - są one publiczne.
AI jest informowana o wszystkich zdarzeniach przeznaczonych dla klienta (packForClient, aplyCL). VCAI przeciąża wszystkie metody tych paczek i na podstawie ich wywołań może poznać bieżący stan gry.
Zbieranie informacji o grze przez jakąś pośrednią klasę to ciekawy pomysł, ale niekoniecznie celowy. Żeby z tych informacji był jakiś użytek, ktoś musi je odebrać - więc tak czy inaczej moduł AI musi oczekiwać i obsługiwać konkretne informacje, a nie jakieś potencjalnie przydatne ogólniki.
Nie widzę tu miejsca na oskryptowanie. Choć oczywiście jest to istotny element, który prędzej czy później należy przemyśleć i zrealizować.
Gdyby wszystko było gotowe, to zamiast pisać grę moglibyśmy po prostu w nią grać 
możliwe że nie powinien mieć on aż tak dużego priorytetu, nie mniej do bardziej skomplikowanych ai napewno by znalazł zastosowanie. Chociażby te pobieżne informowanie o działaniach. Dodatkowo można byłoby go wykorzystać jak w Civilization żeby później móc na osi czasu prześledzić replay rozgrywki itp. ale to już raczej bajer do już działającej, pełni funkcjonalnej wersji.
To już zależałoby od konkretnej budowy AI. Czemu by nie zastosować modułu odpowiedzialnego za działania na mapie przygody(tu i teraz) połączonego z modułem strategii(ewentualnych podbojów itp). I tak na przykład informacja o tym że sojusznik stracił zamek, może oznaczać że strategicznie potrzebuje wsparcia i moduł przygody podejmuje odpowiednie akcję żeby mu tego wsparcia dostarczyć.
Oczywiście czysty kod c++ byłby szybszy niż język skryptowy, nie mniej utworzenie klasy obsługującej skrypty ułatwiała by szybkie ich rozpowszechnianie, chociaż nie uważam że dużo osób podejmowałoby się prób tworzenia ich własnych AI:)
No dobrze, ale w jaki sposób chcesz wyznaczyć granice pomiędzy działaniami “tu i teraz” a planowaniem długofalowym? Według jakich kryteriów moduły mają zostać podzielone i jak będą się ze sobą komunikować?
AI widzi przecież wszystko to, co widzi sojusznik, więc nie potrzebuje dodatkowego alarmowania o bardzo specyficznych zdarzeniach. Inna sprawa, jakie istotnie nowe informacje dostarcza wiadomość, że sojusznik stracił zamek? I jakiego wsparcia może mu udzielić AI? Wysłać surowce?
Jest oczywiste, że podczas gry z sojusznikiem przeciwko wrogowi należy dążyć do pokonania ostatniego, między innymi atakując jego zamki. Niezależnie od tego, kto był ich właścicielem przed chwilą.
Wydaje mi się, że nie tędy droga. AI z założenia nie jest pasywne, lecz aktywne. Zamiast reagować na zdarzenia, samo kreuje strategię na podstawie całej posiadanej wiedzy o stanie gry. Dzięki temu jest faktycznie inteligentne i nieźle sobie radzi pomimo licznych braków. System pasywny może doprowadzić do nadużyć ze strony graczy.
Własne AI ze skryptów? Wątpię. Niestety gra jest diabelnie skomplikowana i obsługa wszelkich jej niuansów to praca na lata. Na tym właśnie należałoby się skupić - na uzupełnieniu tego, czego AI nie rozumie lub nie potrafi wykonać. Możliwe jest też połączenie istniejących elementów (np. budowy miast) w zgrabną całość.
Może źle się wyraziłem ze słowem długofalowe, co też mogło ciebie zmylić z pasywnym AI, chodziło mi o ogólne założenia. Ten moduł aktualizowałby się co jakieś krytyczne(ważne programowo) wydarzenia albo co parę tur domyślnie co turę(w zależności od obciążenia tą czynnością) i powiedzmy w sytuacji w której gracz AI traci zamek, następuje reorganizacja ogólnych punktów celów np. ze zdobywania kopalń, czy zdobycia zamku x, na odbicie przejętego zamku y(tudzież znalezienia innego słabiej bronionego) gdy gracz nie ma już innego albo był to najlepiej rozwinięty zamek/ kluczowy strategicznie i armia AI jest w stanie pokonać jego nowych obrońców.
W tedy część odpowiedzialna za mapę przygody dostaję informacje o aktualnym celu i bohater z najlepszą armią/najbliżej położony rusza wykonać misję.
Tak w teorii oczywiście, bo o dokładnej mechanice nie mam co się na razie rozpisywać(nie lubię zresztą debatować za dużo, o czymś czego nawet nie potrafię, na chwilę obecną, ugryźć od strony programowej - ale jak już opękam c++ to wrócę do tej dyskusji).
Ogólnie chciałem uzyskać opinię o tych klasach “interfejsu” AI i co do jakiego modułu AI należy(dzięki za wyjaśnienie tej kwestii)
Na tym poziomie ogólności bardzo łatwo jest snuć plany i udzielać dobrych rad. Cała jednak trudność polega właśnie na przekuciu tych idei w konkretny kod, który sensownie pokryje wszystkie przypadki i faktycznie przyniesie poprawę działania AI.
Zachęcam Cię, byś spróbował podłubać w VCAI. Jeśli słabo znasz C++ tym bardziej — nawet jeśli z AI nie wyjdzie, to się przynajmniej języka poduczysz. Sam się nauczyłem jako-tako C++ próbując poprawić istniejące AI w projekcie open-source (TA Spring). To właśnie analizując istniejącą implementację i użyte w niej konstrukcje, uczymy się najszybciej (a przynajmniej tak było ze mną). Wzorzec ładnego kodu to nie jest, ale za to bardzo ciekawy przykład C+±a czasu przejściowego.
Uruchom VCMI w debugerze, postaw breakpointa w metodzie VCAI::makeTurnInternal i śledź działanie. Spróbuj coś tam podziubać. Nie jest to wszystko łatwe bynajmniej — ale jaka radość, gdy bohater się w końcu ruszy i zrobi, to co mu zaplanowaliśmy! 
A, i sprawdź PW.
może ktoś podesłać na mojego e-mail`a pliki z katalogu data/
./Data/H3ab_ahd.vid doesn’t contain needed data!
./Data/H3ab_bmp.lod doesn’t store anything!
ponieważ moje coś nie za bardzo chcą być czytane. Poza tym myślę że wiąże się z tym taki problem że jak chcę uruchomić debug to klient nie chce się uruchomić,błąd w instrukcji:
SDL_FillRect(screen,NULL,0);natomiast odpalenie przez zwykłe .exe działa
oto log z odpalenia exe:
log Client
VCMI_Client_log.txt (15.2 KB)
Radomiej bo instalowałeś WoGa na SoD a nie na Gold/Complete - tzn w chwili instalacji WoGa nie mialeś tych plików (pochodzą z AB) - Instalator WoG dodał pliki o tej samej nazwie ale puste - aby generowanie map losowych i dziewiąte miasto działały w WoG i SoD (BTW ERA nie wymaga tych plików do działania).
Jeśli instalowałeś na Gold/Complete albo SoD instalowałeś na AB to oznacza że dalej te pliki są “puste” ale tym razem w związku z zainstalowaniem błędnego pliku WOG (do pliku WOG trzeba dodać instrukcje zainstaluj “nic” w H3ab_ahd.vid i H3ab_bmp.lod, inaczej H3update.exe psuje te pliki - autor jednej paczki instalowanej przez ciebie mógł zapomnieć o tym)
Możliwe jest też (aczkolwiek mało prawdopodobne) że masz jakąś dziwną wersję Hirka w której te pliki nazywają się jakoś inaczej (ktoś znalazł dziwną wersję językową która crashuje VCMI ale nie podał jaką, a VCMI działa z polskimi, angielskimi i (?)ruskimi wersjami językowymi bez większych problemów - instalacja zangielszczenia mu pomogła).
Zignoruj te ostrzeżenia, te archiwa nie są aż tak niezbędne. Kampanie z AB mogą Ci nie działać, na normalną grę nie ma to wpływu.
Jeżeli odpalenie przez exe działa, a debug nie, to praktycznie na pewno masz źle ustawiony katalog roboczy w debuggerze. wiki.vcmi.eu/index.php?title=How … I_from_IDE
Przy poprawnej konfiguracji IDE uruchomienie z debuggerem musi dawać ten sam efekt co uruchomienie przez dwuklik na exeku. To przecież ten sam plik.
Ponoć z polska nie działało, choć nie udało mi się zreprodukować. Masz może jakieś pełne spolszczenie gry lub pliki językowe z w pełni polskiej wersji? To by trzeba wytestować kiedyś porządnie do końca.
Ja mam heroes3 złotą edycje + wog + VCMI i mi działa z polską wersją językową bez większych problemów. A menu opcji jest spolszczone.
ok jak będę miał chwilkę to pobawię się z tym debugerem:)
niestety nie wiem jaką miałem edycje herosa(możliwe że z gazety, albo jeszcze inną z nie pamiętnych czasów:P)
wersję mam spolszczoną