Denník

August 2012 Zaciatok programovania. Zakladne prazdne triedy, testy, utility package. (2000 riadkov kodu)

September 2012 Pridal som klienta pre UDP protocol, napisal som testy a zda sa, ze vsetko funguje. ( 3000 riadkov kodu)

Oktober 2012Nastudoval som si problematiku riesenia synchronizacia stavu klienta a servera. Posielat vzdy vsetko je blbost, posielat zmeny jednom je prilis komplikovane na kod a prilis vela malych paketov. Najviac sa mi paci, nedafinovat entitam, ktore atributy maju byt synchronizovane a ich zmeni prebiehaju cez jednotne rozhranie, ktore si zapamata co sa zmenilo a to sa v najblizsom update cykle skomprimuje a posle. (5000 riadkov kodu)

November 2012Studoval som kniznicu netty ohladom threading modelu, ale kniznica sa ukazuje nevhodna pre aplikacie vyzadujuce maximalny vykon. Je skor vhodna pre biznis logiku, kde udrzuje fixny pocet spojeni a pod. Nakoniec som sa rozhodol pre vlastne jednoduche riesenie: thread pe kazdeho klienta. (6000 riadkov kodu)

December 2012Precital som si prezentacie a knizky o umelej inteligenicii, najviac sa mi pozdava "Ian_Millington_Artificial_Intelligence_for_Games". Vybral som si behavioralne stormy, ale rozhodol som sa ze nad nimi bude este vrstva s automatmi, aby som mohol medzi jednotlivymi stormami lahko prepinat. Napisal som prazdne triedy. ( 7000 riadkov kodu)

4.1.2013 Zacal som kodit okienkovy editor. Nasiel som pekny look&feel aj super layout manager ( zakladne swingove su jeden horsi nez druhy ). Pre editaciu stromov a automatov som vybral kniznicu jgraphX.

5.1.2013 Prestudoval som dokumentaciu k jgraphx ( priserna, pisana raz k java verzii, raz k javascript verzii ), robil jednoduchy editor stromovch struktur, co ale nebolo jednoduche, lebo jgraphx nepozna generika a tak su skoro vsetky parametre aj navratove hodnoty "object" a ked neni dokumentacia, clovek moze akurat debugerom zistovat, co to vlastne vracia a pokus-omyl zistovat co sa ma posielat.

7.1.2013K jgraphx pridany save load do xml, vyrieseny problem s "bonusovou" funkcionalitou jgraphx, ktoru sa konecne podarilo vypnut, pridany algortimus na zarovnanvanie stromov.

9.1.2013 Pridana moznost editacie zdrojakov v editore pre jednotlive "tasky" vo vrcholoch behavioralnych stromov. ( 8000 riadkov kodu )

11.1.2013 Studujem manualy k hibernate, vyzera to ako lepsia volba na prepojenie s databazou. Moje 1. riesenie bolo rucne mapovanie, 2.bolo mapovanie reflexiou, ale vyzera, ze hibernate sa aj tak nevyhnem, ked budem riesit versioning.

13.1.2013Do editora som pripojil 3D opengl canvas, vyskytol sa bug. Horne menu sa vykreslovalo az za canvasom. Vyriesene "magic" funciou.

17.1.2013 Dalsi bug, resizovania okna spolu so specialnym layout managerom a 3d canvasom nejdu dokopy. Vyriesene "magic" volanim setMinimumSize(10,10); ( 9000 riadkov kodu )

20.1.2013 Zacal som pracovat na terene do hry, aby bolo kde testovat AI. Nastudoval som hill generation algorithm a diamond square algorithm. Implementoval som image-terrain pipleline: 1) zober pokojne aj rukou nakresleny a naskenovany obrazok->spriemeruj farby (odstrani to sum) 2) vyrob indexovane farby (tipy krajiny) 3) vyrob alpha mapy 4) aplikuj hill generation s parametrami kopca podla farby bodu v strede kopca. 5) Aplikuj textury pouzitim alpha map (10 000 riadkov) Implementovany aj dialog, otestovane

28.1.2013Niesom spokojny s image-terrain pipeline, teren nie je dost realisticky. Studujem ine algoritmi tvorby krajiny. Zaujalo ma praca o vyhladavani vzorov krajiny v dtabaze realnych objektov.

30.1.2013Rozhodol som sa pre realnu krajinu, hladam dobre heightmapy. Tie v googli su prilis male. Z google earth sa da exportovat len po velmi malych kuskoch.

1.2.2013Nasiel som data zo satelitov, kde je naskenovana elevacia v USA, snazim sa to vyuzit v praci. Problem 1) ake detaily? Ukazuje sa najlepsie rozlisenie 30metrov, ostatne subory su uz privelke a neviem ich spracuvat. Problem 2) kde je v USA nejaka zaujimava krajina? Vybrany ladovcovi park v Montane Problem 3) Data su prilis ostre, height mapa je zubata. Vyriesene prblurovanim mapy vo photoshope. Problem 4) Mierka je teraz prilis velka, tj krajina je mala, ked ju nafuknem je to skarede, zubate. Vyriesene zvacsenim heightmap vo phostopshope. Zvolenych 192 stvrcov, pokryvajucich realne uzemie asi 200 x 200 km. Problem 5) Stale je to zubate... Pouzity smooth algoritmus. Stale torcha zubate. Este raz smooth. Uz je to dobre.

4.2.2013 Ako tie heightmapy loadovat postupne? Naraz to do pamate nevojde a grafika tiez nezvlada, najdeny streamovaci engine. FPS super, detaily velmi nie, ale da sa to. Problem, heightmapy k sebe po smooth-e nepasuju. Treba upravit smoothovaci algoritmus. Napisany maly skript. ( 11 000 riadkov )

6.2.2013Problem s texturami, shader berie len tri rozne textury pre blendovanie podla vysky, napisal som vlastny shader, ktory ich berie 5 a viem to rozsirit na lubovolne ( hoci zdroje uvadzaju, ze limit na gpu je 14 textur na mesh). S terenom som nateraz spokojny.

11.2.2013 Nasiel som open java particle system, po zhladnuti systemu v akcii som sa rozhodol, ze v praci ho chcem pouzit. Tento system je ale navrhnuty pre uplne iny 3d engine, musim napisat plugin, ktory ho nacita. Dokumentacia neexistuje, v kode su komentare po francuzsky (?).

13.2.2013 Plugin napisany, FPS uzasne, ale 2 bugy, castice neumieraju kedze neviem efektivne zmensit vertex buffer a blbnu mi niektore textury, zle sa mapuju. (12 000 riadkov)

16.2.2013 Bug 2 vyrieseny, bolo treba upravit texture wrap na borderclamp v nasteveniach materialov aj pre zvyslu os.

17.2.2013 Bug 1 vyrieseny, nakoniec stacilo vyuzit bytebuffery a limit(). Novy velky bug, nejdu pouzivat textfieldy, 3d canvas nepusti focus.

18.2.2013 Bug s focusom brzi pracu, nedari sa mi zistit preco to nejde.

19.2.2013 Bug s focusom vyrieseny po priserne dlhom debugovani. Chyba priamo v jave7, najdeny patch pre nativne kniznice lwjgl. Riesenie poslane aj na fora enginu, pochvala od autorov.

20.2.2013 Z polovice napisany gui editor pre casticove systemy. (13 000 riadkov)

21.2.2013 Konzultacia so skolitelom. Mam sa teraz sustredit hlavne na umelu inteligenciu. Napisany system pre dynamicke loadovanie a complivanie tried zo zdrojakov. (14 000 riadkov)

24.2.2013 Pridane algoritmi pohybu pre AI. Sledovanie ciela, vybybanie sa prekazkam, vzajomne sa vyhybanie. (15 000 riadkov)

26.2.2013 Implementovany steering pipleline, ako nizsia vrstva pathfindingu. Ak pathfinding vrati cestu, ktoru medzitym nieco zabklokuje, alebo ak pathfinding nepocita s drobnymi prekazkami, steeringpipeline zabezpeci, ze do nich AI nevrazi. Pridane ukazkove video. (16 000 riadkov)

1.3.2013 Rozhodol som sa pre implementaciu strednej vrsty pathfingu pomocou navigation meshov. Na nich bude bezat najvyssia vrstva - aStar. Podarilo sa mi pomerne rychlo vygenerovat slusny mesh pre cast terenu. Tiez napisany algoritmus, ktory prevedie navigation mesh na klasicky graph pre aStar. Velky doraz som kladol na casovu zlozitost. Myslim, ze to bude bezat velmi slusne, horny odhad niekde na urovni O(N*m), kde m je priemerny pocet polygonov majuci spolocny vrchol. (17 000 riadkov)

3.3.2013 Napisal som aStar pre navigation mesh. Ako sa ukazalo, aStar generuje pomerne zubatu cestu (pre velke polygony v navigation meshi), preto som musel napisat Funnel algoritmus, ktory z cesty vyhadze nepotrebne body na zakladne konvexnosti pospajanych trojuholnikov. Taktiez som napisal vysledny Pathfinding service, uz rozdelujuci requesty do threadov, vyuzivajuc Cached Thread Pools. (18 000 riadkov)

5.3.2013 S navigation meshmi je problem, ze na generovanie potrebuju vela cpu a vela pamate, preto ich musim generovat postupne. Velky problem je ale tieto navmeshe spojit. Podarilo sa mi na to napisat alg, ktory to realtivne slusne spravi (slusne geometricky a slusne casovo). Dalsi problem bolo ukladanie navmeshov a grafov do suboru, defaultny serialization mechanizmus v jave takto velke grafy nezvladal, musel som to upravit. Save a load teraz trva dlho (pol minuty), ale vzhladom na velkost grafu (1200 000 vrcholov a priblizne 2500 000 hran) to pokladam za dostatocne. Pre potreby debugovania som napisal alg, ktory navmeshe vykresli do 2d obrazka. Uz teraz mi to zachranilo hodiny a hodiny s roznymi mikro bugmi Tiez som napisal vlastny quad tree, ziadna s dostupnych implementacii nebola pre moje pouzitie vhodna. Otestovany pre 10 000 objektov.. Vygenerovany javadoc. (19 000 riadkov)

7.3.2013 Opravene mnozstvo drobnych bugov od funnel algoritmu az po steering pipleline, napisany debugger pre vysledne vygenerovane cesty z pathfindingu a ich export do obrazkov. Steering pipeline naucena pozuivat cestu z pathfindingu. Pridane video. (20 000 riadkov)

8.3.2013 Pridany editor konecnych automatov, ktore obsahuju v kazdom stave behavioralny strom. Pridany save/load do xml, vratane stromov. Prechod medzi stavmi mozny na zaklade podmienok, ktore su programovatelne v groovy. Behavioralne stromy posunute pod konecne automaty. Upravy UI. (21 000 riadkov)

9.3.2013 Synchronizacia behavioralnych stromov so stavom sveta sa ukazala ako tazsi oriesok, nez sa to zdalo na prvy pohlad. Povodny plan bol pouzit thread na kazdy strom, v pripade paralelnych vetiev pridat dalsie thready. Avsak odborna literatura toto nedoporucujue, lebo privela threadov ( nad 100, pricom potrebujem radovo tisicky ), vraj nie je efektovnych. Neviem si predstavit ako je mozne zastavit beh kodu a potom sa k nemu vratit, bez komplikovaneho ukladania stavu, co by ale zabilo princip user friendly editora. Skusal som sa hrat s closures v groovy, ale ani to neprinieslo user-friendly vysledok. Ine scriptovacie jazyky su prilis pomale. Napisal som teda benchmarky pre thready ci je to naozaj az take zle. Pri 2 sekundovom sleepe a 1000 threadoch padlo 0.7 sekundy na ich prepinanie. To uz je vyznamna strata, po skusani roznych alternativ som vybral single threaded locking, kde sa vetvy stromu navzajom uzamikaju pred a po vstupe roznymi zamkami, cim efektivne simuluju cakanie jednej vetvy na druhu. Tm by mala byt dokoncena AI architektura a presuvam sa na 3D editor sceny a jej hierarchiu.

10.3.2013 Nakreslil som niekolko diagramov: diagram1, diagram2, diagram3. Po ich prezreti som im prisposobil objektovy model a vymazal nadbytocne triedy a upravil vztahy. (22 000 riadkov)

11.3.2013 Hotovy zaklad 3D editora (loadovanie modelov, skalovanie, posuvanie, rotacie, zakladne renderovacie vlastnosti - transparency, culling, texture filtering) + automaticka vyska podla terenu. (23 000 riadkov)

12.3.2013 Uprava 3D editora, pridany copy, delete, radius. Pridana moznost generovat viacero roznych scen (zaklad pre interiery), napisane jadro script systemu. (24 000 riadkov)

13.3.2013 Prezentácia na seminár [.pptx] [.pdf]

17.3.2013 Pridavanie portalov medzi scenami v editore, pridavanie prvych scriptov v editore (video scripty). (25 000 riadkov)

23.3.2013 Dokonceny editor vsetkych typov scriptov + save/load pre tento editor, pridavanie scriptov do sceny. (26 000 riadkov)

26.3.2013 Particle system editor, stav 75%, refaktorizacia. (27 000 riadkov)

28.3.2013 Particle system editor, stav 90%, chyba save/load do xml a jops + premenovavanie komponentov. (28 000 riadkov)

29.3.2013 Pridany save do praticle systemu, upravy editora behavioralnych stromov, podpora pre rozne typy uzlov a listov.

1.4.2013 Export XML suborov pre server: sceny, skripty, fsm+bt, portaly, particle systemy. (29 000 riadkov)

15.4.2013 Z dovodu zdravotnych komplikacii neprislo pocas uplynuleho obdobia v praci k ziadnemu vyznamenjsiemu pokroku

19.4.2013 Pripravena kostra databazoveho modelu pre server. Pregenerovana dokumentacia.

20.4.2013 Template triedy pre databazove tabulky. Nakodeny editor predmetov na 75% - Chyba par tlacidiel a save, mozno filter. Napojenie na hibernate. (32 000 riadkov)
Zostavajuce casti

  • Prepojit navmeshe a urobit UI ku generatoru - jeden az dva dni prace
  • Napisat load sceny pre editor aj server - den prace
  • Dokoncit editor predmetov - den prace
  • Napisat editor surovin - den prace
  • Napisat editor npc - den prace
  • Dokoncit persistanciu servera cez hibernate - dva az tri dni prace
  • Klient - tyzden prace
  • Naplnit framework datami - tyzden az dva prace

26.4.2013 Dokonceny editor predmetov a editor npc. Refaktorizacia. (33 000 riadkov)

27.4.2013 Zaklad editora surovin. (34 000 riadkov)

28.4.2013 Urobena vacsia cast editora surovin. Kod doplneny o relacne anotacie pre hibernate. Pomerne dost problemov s lazy vs eager fetch. Snazil som sa o jednoduchy ale efektivny interface. Rozne benchmarky ukazali, ze sa oplati eager fatch cez multi select, kedze mi nevadi jednorazove zatazenie pri starte servera, a data musim tak ci tak drzat v pamati, lazy load som nechal len data klientov, kde to jedine dava zmysel, kedze ich je vela, ale sucasne v pamati treba drzat len zlomok. (35 000 riadkov)

29.4.2013 Dokonceny editor surovin, refaktorizacia. Nacaty stat editor, problem s dynamickym mappingom v hibernate. Myslienka znie, ze uzivatel si bude moc nadefinovat, kolko a akych statov bude. Problem je ako to reprezentovat v databazovej scheme. Idealny a normalny stav by bol mat N enitit a M statov a vytvorit medzi nimi N:M relaciu, kde by sme v relacnej tabulke ukladali este akutalny stav statu, pripade ine informacie. Problemy s tymto riesenim su,
1) negarantuje, ze enita bude mat definovane vsetky staty
2) DML operacie budu strasne pomale, N:M tabulky budu obrovske.
3) bude treba N:M pre kazdy typ enitity (predmet, npc, user).

Kedze chcem pre kazdy entitu vsetky zaznamy vzdy a na servery sa ich pocet uz nebude menit, ovela efektivnejsie je definovat staty ako stlpce v tabulke dynamicky vytvorenej editorom. Toto riesenie ma vsak problem s tym, ako potom dynamicky namapovat tieto data na servery, kedze anotacie ktore pouzivam generovat dynamicky nejde.

30.4.2013 Niekolko pokusov presvedcit hibernate aby mapoval viacero stlcov do jednej kolekcie. Podla vsetkeho sa to naozaj neda. Musim vymysliet ine riesenie.

1.5.2013 Hibernate je mozne nastavit, aby data nemapoval pouzitim anotacii, alebo mapovacih suborov, ale aby skutocne pouzival mapu pre jednotlive stplce. Nanestastie, ani jeden z prikladov v oficilanej dokumentacii nefunguje. V prvom rade preto, ze priklady su zastarale, takze bolo nutne ich preportovanie do novej verzie Hibernate a v druhom rade preto, ze jednoducho absolutne nefungovali, kedze API na niektore svoje nastavenia proste uplne kasle. Po preskumani niekolkych for plnych nezodpovedanych prispevkov, preco to nefunguje a ako to opravit (hanba hiberante), som sa docital, ze kedysi to predsa len fungovalo. A v skutku, septembrova verzia Hiberante 3 sa ukazala este funkcna. Problem vyrieseny.

2.5.2013 Hoci hibernate riesenie fungovalo, z viacerych hladisk sa ukazalo ako nedostatocne preto som sa rozhodol vyuzivat mix hibernate a zakladneho java.sql API. Vyzadovalo to pomerne velke mnozstvo kodu, aby sa rozhranie navonok stale javilo jednoduche, hoci na pozadi sa musia synchronizovat tieto dve persistantne moznosti. Navyse bolo treba implementovat jednak cachovanie a jednak optimalizacie, ked bude k datam pristupovat server, kedze tam sa nemoze stat, ze sa zmeni databazova schema pocas behu aplikacie, ako u editora, kde je tym padom potrebne kontrolovat information_schemu. Tym padom som urobil editor vlastnosti. (36 000 riadkov)

3.5.2013 Nove ikony v aplikacii, vyzera ovela lepsie. Integracia vsetkych hotovych editorov. Optimalizacie pri ich prepinani. Najdeny a vyrieseny deadlock v LWJGL, cez zamykanie EDT. Rozpracovane pridanie postav a surovin do sceny na zaklade sablon z databazy. (37 000 riadkov)

4.5.2013 Dokonceny editor sceny pre portaly, suroviny, postavy.

5.5.2013 Synchronizacia modelov napriec editormi, pridanych viacero cachovacich systemov, komplet export a import sceny do XML. (38 000 riadkov)

6.5.2013 Dokonceny editor, vyriesene posledne bugy a doplneny export script. (39 000 riadkov)

7.5.2013 Praca na prezentacnom videu

8.5.2013 Vyhodene po novom nepotrebne triedy zo servera, pridane sifrovacia vrstva, pouzite hibernate pri nacitani hraca, zrychlenie systemu udpatov, prerobene kompletne na packetovu architektutu, celkova kontrola ako novembrovy kod spolupracuje s teraz dopisanym editorom. Dalsia prezentacia na seminar, tentoraz trosku o sieti [.pptx] a [.pdf]

13.5.2013 Napisanych 38 stran prace.

16.5.2013 Stretnutie so skolitelov, predebatovany text prace.

19.5.2013 Dokoncenie textu prace z mojej strany, cakam na pripomeniky od skolitela.

19.5.2013 Inicializacny script servera na nacitanie dat z editora prostrednictvom xml / sql. Spravil som to ako moznost naloadovat default stav z xml alebo naloadovat uz ulozeny stav z sql. (40 000 riadkov)

20.5.2013 Finalizacie textu prace.

21.5.2013 Napisana sietova vrstva klienta + zaklad datovej vrstvy. (41 000 riadkov)

22.5.2013 Napisana prezentacna vrstva klienta + dokoncena datova vrstva. (42 000 riadkov)
Do zavrsenia este potrebujem este nasledovne detaily
- procesor scriptov v scene
- odosielanie paketov klienta o aktualnej polohe
- procesovanie chat paketov

23.5.2013 Dorobeny procesor scriptov scene, odosielanie polohy klienta.(43 000 riadkov)

24.5.2013 Rozne bug fixy v konkurentnom programovani, najdeny a praveny maly bug v editore, funkcny chat, upravy textu prace, pridana prikladova cast.(44 000 riadkov)

25.5.2013 Finalizacia textu prace.

26.5.2013 Opraveny bug v cryptografickej vrstve, dokoncenie testovania.

27.5.2013 Vytlacenie prace.

28.5.2013 Vycistenie projektu, rozclenenie na samostatne aplikacie, odoslanie elektronickej verzie prace.

30.5.2013 Odovzdanie tlacenej verzie.