Zápisnica č.

Dátum

Miesto

Čas

17

6. 4. 2009

Softvérové štúdio

11.15

 

Zúčastnení

členovia

Bc. Juraj Ligocký

Bc. Michal Hrubý

Bc. Gabriel Pán

Bc. Ján Hric

Bc. Marek Polák

Pedagóg

Ing. Ivan Kapustík

Zapisovateľ

Bc. Ján Hric

 

Program stretnutia

Cieľom stretnutia bolo dohodnúť sa na postupnej kompletizácii nášho hráča s využitím doterajších odskúšaných nápadov.

  1. Organizačné záležitosti
  2. Diskusia k stavu projektu
  3. Spresnenie úloh

 

Priebeh stretnutia

  1. Organizačné záležitosti

-        MP sa opakovane dostavil neskoro na stretnutie, preto sme sa na návrh GP dohodli na posunutí času začiatku stretnutia o 15 minút. Stretnutie sa bude po zvyšok semestra začínať 11.15. Vyhovuje to GP a MP najmä z hľadiska spojov MHD.

-        Pred začiatkom stretnutia GP a MH diskutovali o posledných nejasnostiach pri používaní systému Maven. Ich úsilie vyústilo do plného pochopenia systému a možnosti naplno ho využiť celým tímom.

-        JL sa spojil s druhým tímom vo veci používanej verzie servra. Snažil sa najmä zistiť, či by bol problém použiť na turnaji staršiu verziu (9.3.6 alebo 9.4.5), pod ktorou hrá náš hráč výrazne lepšie než pod najnovšou (13.0.#). Členovia druhého tímu vyjadrili plnú spokojnosť so staršou verziou, novšiu dokonca ani neskúšali pre podozrenie z veľkej chybovosti.

-        V tejto súvislosti IK poznamenal, že minuloročný turnaj sa tiež odohral s verziou 9. Snahou fakulty je držať sa svetových trendov, no kým je použitešnosť značne nízka, nový server sa nepoužije. Porozpráva sa ML, aké stanovisko by sa malo zaujať.

 

  1. Diskusia k stavu projektu

-        JH oboznámil tím so spoluprácou nášho hráča so servrom verzie 13. Na minulom stretnutí už hráč bol schopný so servrom komunikovať, no jeho herný výkon bol veľmi slabý. Najmä postup a prihrávky dopredu hráči často ignorujú. JH sa snažil prísť na koreň veci. S týmto cieľom odchytával komunikáciu smerom od servra k hráčovi. Porovnal správy zo servra 13 so správami zo servra 10, pod ktorým hra prebieha v poriadku. Nespozoroval žiadne rozdiely vo formáte prijímaných správ. Zistil, že kouč ráce s možnosťou pridelenia každého heterotypu až trom hráčom, pričom server 13 má štandardne nastavený maximálny počet na 1. Daktorým hráčom preto kouč nebol schopný priradiť heterotyp. Odstránením tejto chyby sa však hra nezlepšila. JH ďalej skúsil použiť konfiguračný súbor servra 10 pre server 13. Sú tam iné hodnoty parametrov hry (napr. maximálna výdrž 4000, nie 8000). Hra sa mierne zlepšila, no stále bola na nedostatočnej úrovni. JH vidí možnosť odstránenia problému len komplexným testovaním a porovnaním udržiavania vnútorného sveta hráčov pri oboch servroch. Pre časovú náročnosť takejto úlohy radí pozastaviť snahu o sfunkčnenie hráča pod servrom 13. V prípade zvýšenia času v nej bude pokračovať na konci semestra alebo až pred turnajom.

-        MH ukázal zápas nášho hráča proti Jahodovým princom. V tomto zápase bolo stále vidno kmitanie hráčov pred vykopávaním po góle. Nepodarilo sa mu kmitanie doma odstrániť. Za zdržianie v plnení úlohy považuje najmä nedôsledné použitie systému SVN iným členom tímu, ktorý vložil do kódu množstvo pomocných výpisov. Dohodli sme sa, že takéto veci musíme riešiť ináč a na SVN pôjde len ,čistý' kód. MH si však priamo na stretnutí uvedomil, že nefunknčosť odstránenia kmitania, ktorú riešil, môže byť byť spôsobená nesprávne definovanými režimami hry v konfiguračnom súbore hráčov - pomýlil si režim BeforeKickOff s režimom Goal. Chybu opravil a po spustení zápasu už hráči nekmitali.

-        MH a GP upozornili tím na nevypínanie sa hráča po skončení zápasu, pričom iné fakultné tímy sa po vypnutí servra automaticky ukončia. Navrhli riešenie skončenia programu po dlhšom čase neprijatia správ od servra. JH oponoval, že takto to v hráčovi riešené aj je a problém musí byť inde. Zároveň označil túto chybu za nepodstatnú.

-        JL analyzoval správanie hráča pri štandardných situáciách (aut, roh). V kóde sa tieto situácie vôbec neriešia. Navrhuje vytvoriť novú taktiku špecializovanú na vykopávanie pri štandardných situáciách. MH položil otázku, či hráč pozná všetky potrebné režimy hry. Po nazretí do kódu sme usúdili, že požadované režimy hry sú definované. MH ukázal, ktoré režimy má JL pri vykopávaní brať do úvahy. Myslí si, že asi bude vhodné pre každú situáciu vytvoriť osobitnú taktiku. GP oponoval myšlienkou vytvorenia univerzálnej taktiky.

-        MP sa venoval zameriavaniu sa na zvukové správy od konkrétneho hráča (akcia AttentionTo). Vytvoril novú taktiku rozširujúcu SearchBallState. Pôvodne sa hráč v každom takte zameriava na jedného spoluhráča. Pamätá si, ktorého spoluhráča začul naposledy, aby sa mohol zamerať na ďalšieho. MP zmenil spôsob počúvania takto:

o       Ak má náš tím loptu a vzdialenosť od hráča s loptou je pod 15 metrov, hráč si vytvorí zoznam hráčov pri lopte, vezme prvého a naňho sa zameria.

o       Ak je zoznam prázdny, vezme hráča najrýchlejšieho k lopte.

o       Hráč, ktorý je najbližšie k lopte, sa riadi pôvodnou metódou (zameranie sa na ďalšieho spoluhráča v poradí).

o       Ak náš tím nemá loptu alebo lopta je od najbližšieho hráča vzdialená nad 15 metrov, hráči sa riadia pôvodnou metódou.

-        MP pri testovaní zistil rozdiely v rýchlosti rozpoznania potreby zamerať sa na konkrétneho hráča. Daktorým hráčom trvalo mnoho taktov, kým sa zamerali na správneho hráča. MP vyjadril obavy z užitočnosti tohto postupu. JH upozornil na možnosť nepresných informácií vo vnútornom svete jednotlivých hráčov. Potom ho napadla pravdepodobnejšia príčina: Keďže kód zameriavania sa na hráča sa vykonáva len v potomkovi taktiky SearchBallState, hráč ho využíva, len keď nevykonáva inú činnosť (beh za loptou, driblovanie a pod.). Načim, aby sa vykonával v každom takte, preto je vhodné dať ho do každej taktiky. JL poukázal na výhodnosť vložiť ho do taktiky AbstractState - rodičovskej triedy všetkých taktík.

-        JH poznačil, že hráči si posielajú zakódované správy dĺžky 5 znakov (zbadal to pri sledovaní komunikácie), no Jahodoví princovia posielajú správy dĺžky 10 znakov. Zdalo sa mu to divné, lebo GP na minulom stretnutí spomínal, že dĺžka zakódovanej správy s informáciou o objekte (lopte alebo hráčovi) je 10. GP teraz objasnil formát správy - v jednej správe možno poslať informácie až o dvoch objektoch.

-        GP poznamenal, že čakanie na správu od servra blokuje hráča, čiže nič sa vtedy nevykonáva. To nám vyhovuje, lebo nie sú problémy so súbežným kódom.

-        Výber vhodnej taktiky prebieha až po prijatí obrazovej informácie. Kvôli otestovaniu možností komunikácie GP pridal do hráča vyhodnocovanie taktík aj po prijatí zvukovej informácie. Sledoval tým ošetrenie prípadu, keď zvuková informácia obohacujúca vnútorný svet hráča príde až po obrazovej, čím môže ovplyvniť vhodnosť jendotlivých taktík. Testovanie ukázalo neschopnosť hráčov včas reagovať. Vzrástla výpočtová zložitosť a stroj to nestíhal. Podľa komentára od tvorcov tímu DAInamite sa prijatie zvukovej správy za obrazovou nestáva často. Aj preto GP navrhuje nechať pôvodný spôsob. Po prijatí zvukovej správy sa len obnoví vnútorný svet hráča a použije sa až v ďalšom takte. GP uistil tím, že ak za zvukovou správou príde obrazová, neprepíše úplne model sveta, pretože informácie zo zvukovej správy majú vyššiu prioritu. To nás len viac pobáda dokončiť navrhovaný mechanizmus komunikácie.

 

  1. Spresnenie úloh

-        IK naznačil vhodnosť otestovania poradia prijímania obrazovej a zvukovej správy. Dá nám to istotu pri realizácii komunikácie. Ak sa správy prijímajú vždy (alebo skoro vždy) v tom istom poradí (napr. prv zvuková, potom obrazová), môže to byť výhoda. Úlohu si vzal na svedomie GP.

-        MP a GP sa venovali každý jednej časti zvukovej komunikácie, preto to spoločne dokončia.

-        JL a JH vytvoria taktiku na spracovanie štandardných situácií (aut, roh). JL navrhol postupovať ako pri formáciách - prevziať správanie z Jahodových princov.

-        JH si dal za úlohu odskúšať nášho hráča na servri verzie 9 a 12, lebo tieto verzie neskúšal. Tak isto skúsi použiť server pre OS Windows, keďže dosiaľ testoval len v Linuxe.

-        MH sa povenuje doladeniu formácií, prípadne zakomponuje do presunu hráča na svoju pozíciu manažment výdrže. Bolo by vhodné navrhnúť viac formácií, než sú súčasné dve. Možno by sa mal zmeniť aj spôsob výpočtu vhodnej pozície hráčov, lebo kód prevzatý z Jahodových princov výrazne narúša definované formácie. Upravuje ich totiž podľa pozície lopty.

 

 

Plnenie úloh z predchádzajúcich stretnutí

Id

Opis

Zodpovedný

Termín

Stav

12.4

Upraviť hráča DAInamite na spoluprácu so serverom verzie 13.

Hric, Hrubý

13. 4. 2009

Zrušená

16.1

Zistenie príčiny kmitania hráčov, dopad kmitania na výdrž. Odstránenie kmitania.

Hric, Hrubý

6. 4. 2009

Splnená

16.2

Implementovať správanie, v ktorom sa hráči zamerajú na zvukové správy od hráča s loptou (AttentionToAction).

Polák

6. 4. 2009

Splnená

16.3

Implementácia výberu taktiky a vhodnej akcie na základe počutej informácie - analýza vhodnosti prístupu, dopadov na hru.

Pán

13. 4. 2009

17.1, 17.2

16.4

Kontaktovať konkurenčný tím s cieľom zjednotiť verzie servera.

Ligocký

6. 4. 2009

Splnená

16.5

Identifikovať a opraviť príčinu neschopnosti rozohrávania hráčov pri autovom vhadzovaní.

Ligocký

6. 4. 2009

17.3

 

Nové úlohy

Id

Opis

Zodpovedný

Termín

17.1

Vyhodnotiť poradie prijímania obrazovej a zvukovej správy v takte.

Pán

20. 4. 2009

17.2

Dokončiť zvukovú komunikáciu (posielanie informácie o prihrávke).

Polák, Pán

20. 4. 2009

17.3

Prevziať správanie sa pri štandardných situáciách z Jahodových princov

Ligocký, Hric

20. 4. 2009

17.4

Odskúšať hráča so servrom verzie 9 a 12 aj pod OS Windows

Hric

20. 4. 2009

17.5

Vytvoriť viac formácií, prípadne upraviť súčasné. Prezrieť algoritmus výpočtu pozície vo formácií v závislosti od pozície lopty.

Hrubý

20. 4. 2009

 

Použité skratky:

 

JL        Bc. Juraj Ligocký    

MH      Bc. Michal Hrubý

GP       Bc. Gabriel Pán

JH        Bc. Ján Hric

MP      Bc. Marek Polák

IK        Ing. Ivan Kapustík

ML      Ing. Marián Lekavý (vedúci druhého tímu)