######################################################################## Martin Manak: 1) Pouziti knihoven tretich stran Pokud je v projektu neco vetsiho, co lze uspesne pokryt jiz existujicimi knihovnami, je dobre to udelat, usetri to spoustu casu a prace, kterou by clovek stravil implementaci. Na druhou stranu, nekdy to spis spoutu prace pridela, kdyz se knihovna nechova tak, jak se od ni ceka, nebo nezvlada to, co chceme. 3D modely pro grafiku a fyziku jsme exportovali z 3DS MAX nebo z Blenderu do vlastniho XML formatu. To s sebou nese radu vyhod (citelnost, prehlednost, upravovatelnost), ale i nevyhod (implementace vlastniho epxporteru, udrzba vlastniho formatu souboru, pomalejsi nacitani z XML). Pritom podobne a lepsi reseni uz davno existovalo, jen jsme jej objevili prilis pozde. Mozna by stalo za to, misto vlastnich veci, pouzit jiz existujici Colladu (.DAE), pro kterou existuji exportery i nejaka DOM knihovna pro praci s .DAE souborem. Podstatnou cast reprezentace sceny a renderingu, kterou jsme udelali sami, by se dala resit napriklad pomoci multiplatformni (Win, Linux) NVSG SDK, coz je knihovna pro scene graph. Pro nacitani obrazku jsme pouzivali SDL_image. Ucel splnilo. Mozna by stalo za to misto SDL_image pouzit DevIL - vypada more powerful. Kdybysme v projektu meli boost library (www.boost.org), mozna by sme par veci vyresili mnohem elegantneji a rychleji. Takhle sme si psali vlastni singleton, vlastni smart pointers a podobne. Ano, je to sice zabava, ale stoji to cas, ktery sel investovat jinam. Pro zpracovani XML sme pouzili tinyXML. Je to fajn knihovna pro MALE XML soubory, jak uz sam nazev napovida. Da se pouzit dobre treba na settings files. Pouziti mnoha knihoven vsak nemaji moc radi koncovi uzivatele linuxove komunity. Resit prilis mnoho zavislosti je proste "nebavi". 2) "TODO" aneb "udelam to jindy" Je dobre nenechavat si prilis mnoho "TODO" komentaru v prubehu implementace. Po case se zacnou hromadit, clovek o nich lehce ztrati prehled a na hodne z nich se ani nedostane. Kdyz uz se implementuje nejaka cast, muze stat za to dokoncit maximum co jde a neodbihat k jinym vecem. 3) dokumentace kodu Dokumentaci snad nepise nikdo rad. Clovek si casto rekne "zdokumentuju tu tridu, az budu mit cas". To neni moc dobry pristup, protoze to "az budu mit cas" nemusi nastat tak brzo, jak by dotycny cekal. Vyplati se okomentovat to hned pri vyvoji, nebo nez se clovek pusti do dalsich veci. Kdyz uz se ma ta trida pouzivat, mela by mit komentar - alespon popis tridy, co dela a popis public metod. Velmi prinosne je rovnez pridat priklad pouziti. Je to jedna z nejrychlejsich pomoci, kdyz uz ji nejaky nestastnik hleda v dokumentaci. Dalsi rychlou pomoci jsou diagramy, ktere ale nastesti umi vygenerovat dany tool pro dokumentaci. Pro dokumentaci kodu jsme pouzili Doxygen. Bez podobneho nastroje by to ani nemelo cenu. 4) Dokumentace programatorska a uzivatelska Neplest si programatorskou dokumentaci s dokumentaci kodu! V nasem pripade nam bylo jasne naznaceno, ze doxygenovska dokumentace kodu jako programatorska dokumentace nestaci. Narozdil od dokumentace kodu, tyto lze psat az pozdeji. Hlavne uzivatelskou. Muzu rozhodne doporucit do programatorske dokumentace vlozit co nejvice UML class diagramu z navrhu a ty pak trochu okomentovat. Nebat se udelat ruzne classes barevne. Prohlednout a pochopit obrazek je mnohem rychlejsi, nez se prokousavat A4 strankou popisu "neceho". Navic, z obrazku jsou na prvni pohled patrne vazby/vztahy. Kdyz si clovek bude listovat dokumentaci, nezaujme ho stranka textu, zaujmou ho obrazky a diagramy. 5) Logovani & settings Pouziti logovani a settings hned ze zacatku se ukazalo jako velka vyhoda. Kdyz uz aplikace nekde padne, lze z logu rychle vycist, kde to bylo. Hodne to pomaha pri testovani release verzi a nebo kdyz si obcas nekdo stahne a vyzkousi posledni release a padne mu to, muze zaslat logy. Settings vyrazne zvysuji konfigurovatelnost aplikace - neni treba ji kvuli malym zmenam nastaveni celou rekompilovat. Muze stat za to si dat pozor na to, aby si do settings file kazdy nesypal, co se mu zlibi, jinak se stane neprehlednym. 6) Profiler Sme nemeli. Skoda. 7) Obhajoba Hra dokaze publikum zaujmout, pobavit a probudit ty, co usnuli pri predchozich prezentacich. Velkou vyhodou je, ze lze ukazat screenshoty a video, pripadne hru predvest nazivo (neni nutne, vyhoda videa a screenshotu je, ze vetsinou nepadaji). Pri prezentaci rozhodne nezabredavat do technickych detailu a class diagramu, ovsem pouzite knihovny a zhruba velmi strucne problemy, kterym se celilo, je dobre uvest. Publikum chce predevsim videt, jak hra vypada a jak se hraje, ne jak funguje uvnitr. ######################################################################## Bernard Lidický: Zkusenosti s projektem BJS. Tema projketu: Jako tema s.p. jsme si vybrali hru. Komise se na moznost delat hru tvarila rozpacite. Komise mivala s hrami spatne zkusenosti - viz. Zavoral: "Bud maji teamy velke oci a trva jim to 3 roky a nebo jsou odevzdavane hry takove shitozni". Doufame, ze po nasi hre se komise bude divat na projekty typu her vice pozitivne :) Doufali jsme, ze projekt typu hra nas bude bavit. Nastesti me vetsinu casu bavil a ja jsem za to rad. Nektere "rady" zkusenosti jsou obecne a nektere asi platne hlavne (pouze) pro hry. Grafika: Jednim ze zasadnich problemu pro hru je kde sehnat obrazky a modely. Pokud mate v teamu modelare/grafika mate vyhrano. Pokud ne, neberte si neco, kde je potreba spousty grafiky jako napriklad adventrura. Na druhou stranu naucit se trochu modelovat a udelat tri tanky, dva stromy a par krabic je i v silach programatora. Vyborne je, kdyz nejakou grafiku generuje program sam - jako v nasem pripade teren. Skladba teamu: Na zacatku - jako asi kazdy ucastnik projektu - jsem si precetl zkusenosti druhych a muzu rici dobrou zpravu. Tou je, ze pri praci na projektu s kamarady o ne prijit nemusite. Je dobre vedet, co lide v teamu umi a hlavne jak jsou ochotni na projektu pracovat. Ve velkem temu se to mozna ztrati, ale ve 4 lidech je hodne znat, kdyz se jeden zacne flakat. Myslel jsem si, ze nam se problem flakace vyhne, ale nevyhnul. Je velice tezke pak lenocha donutit neco delat - lze tak akorat hrozit vyhozenim nebo ruzne jinak vydirat. Takze se pripravte, jak na nej. Ale jak, to bohuzel nevim. Po vzoru Pavla Machka jsme si zavedly alespon interne pokuty - kdyz nekdo neudela, co mel udelat, musi prinest cokoladu a ostatni ji na schuzce snedi. Podpurne utility: Velice se osvedcilo pouziti SVNka - bez nej by to asi nebylo poradne mozne. Zpocatku jsme hlavne vyuzivali, ze mel kazdy svou vlastni vyvojovou vetev a obcas se megovalo do hlavni vetve. V pozdejsi fazi - kdy uz vsechno tak nejak drzelo dohromady - jsme mastili vsechno rovnou do trunku. Vsechno hned do trunku ma zjevny problem, ze trunk je obcas nefunkcni. Ne zamerne, ale obcas se to stane a pak se to musi nejak urychlene opravovat a ostatni mezitim nemuzou skoro nic delat. Na druhou stranu pri mergovani mezi vetvemi v svnku jsme se potykali s neustalymi konflikty a z neznameho duvodu si obcas svnko postavilo hlavu a mergovat nechtelo vubec - tj. merge byly dosti casove nakladne. Pro omezeni konfliktu jsme pouzivali, ze kazdy soubor ma sveho spravce - clovek, ktery je za nej zodpovedny a mel by se o nej starat. To trochu konflikty omezilo. Fyzicky jsme svnko meli na uraxu, ktery je k tomu +- urceny a jde mu to vcelku dobre. Na konci jsme jeste pouzivali statsvn, ktere krasne prozradi, kdo se flaka a kdo neco dela. Zkouseli jsme pouzit wiki, ale nesetkala se s uspechem, protoze jsme info v ni obsazene stejne nepouzivali a nebavilo nas ho aktualizovat. Rozhodne lze doporucit pouzit doxygen. Zabrani to prilisnemu praseni. Precijen kdyz clovek pise do popiskoveho komentare, jak pitome se funkce chova, je jista sance, ze funkci opravi. Ale programatorskou dokumentaci z doxygenu asi nenagenerujete. Asi samozrejma je take emailova konference. Knihovny: Ve hre jsme samozrejme vsechno nepsali, ale snazili se pouzivat jiz hotove knihovny. SDL: Zakladni knihovna pro komunikaci s OS. Je vcelku v pohode. Jen ve windows nezvlada fullscreen na 100%, pokud je startovni panel vlevo a ne dole :) OpenGL: Knihovna pro 3D grafiku - vzhledem k pozadavku na multiplatformnost jasna volba - u pouzivani ruznych extensions se hodi knihovna glew a dejte pozor, ze co bezi na nVidia vubec nemusi na ATI (uz vlastne AMD). Nebo bezi podivne. OpenAL: Knihovna pro 3D zvuk. Vcelku snadna k pouziti a fungujici, ale ma problem s verzemi. V dobe naseho projektu byla verze pro Linux != verze Windows. To zamrzi, ze se v mezicase i zmenilo API, takze jsme ve zdrojacich meli #define na verze. S postupujicim casem bude doufam tento problem out of date. ODE: fyzika. Psat vlastni fyziku jsme vzdali brzy a nedoporucujeme psat si vlastni. ODE je vcelku OK, ale pozor na mnoho zaludnych konstant - jedna udela z tankove strilecky zavody klokanu (hledali jsme ji dva mesice). Dale ODE dela fyziku ala skutecny svet - pro arkadoidni hru je takovy model nevhodny (spatne ohlasy hracu) a fyziku bylo treba nalezite sidit a podstrkovat nerealna cisla, posouvat teziste zcela mimo tank a podobne. CEGUI: Knihovna na GUI. Vyhodou je, ze knihovna ma vlastni vizualni editor (je otresny, ale porad nadhera proti tomu, kdyz to ma clovek rovnou psat v kodu), podporuje mezinaroni znaky, ma velice stabilni vykreslovani (tim mysleno, ze CEGUI se vykreslilo i kdyz zbytek renderovani byl jako rozsypany caj) a umi navrhovat GUI nezavisle na rozliseni. Knihovna se sice chlubi multiplatformnosti, ale prelozit ji na MacOSX je peklo. Na Win a Lin to slo. omniORB: S nim jsem nastesti do styku neprisel, ale programator, co s nim pracoval na to nadaval a tvrdil, ze radeji napise svuj vlastni prenos. Meli jsme tam ruzne problemy jako ze nam zustavalo viset spojni a ze se omniORB obcas odmital vypnout pri ukonceni aplikace - a nebo pro jistotu spadnul. Je docela blbe, kdyz program pada az po navratu z funkce main a to jeste v nejakem divnem vlaknu, ktere si udelal sam orb. tibyxml: velice pekna mala knihovnicka pro praci s XML soubory - pokud nehodlate mit giganticke databazove xml soubory, tak tinyxml je asi dobra volba. Snadno se pouziva. Multiplatformnost? Projekt jsme delali multiplatformni, protoze jsme se nedokazali dohodnout na jednom OS - kazdy mel rad a chtel pracovat v tom svem. Psali jsme na windows, linux i macosx uz od zacatku. Rychle se zjisti, ze kompilatory generuji jine warningy a obcas i errory. To je ale dobre, protoze se diky tomu podarilo odhalit rozlicne chyby. Stoji to nejakou energii, aby hra byla na vice platformach, ale myslim, ze to u hry neni az tolik energie, multiplatformnost se cool do obhajoby a i vysledny kod je lepsi. Myslim, ze jediny vetsi problem byl, ze gcccko a visualko uznavaji templaty trosku jinak, takze to byl chvilku boj, nez se podarilo najit format, ktery zkousnou oba. (slo o nejake specializace templatovych funkci v templatovane tride - ono ani my jsme poradne nevedeli, jak to napsat :-) Ale zase precijen to nejaka prace je, tak zvazte. Jeste jedno doporuceni - explicitne si napiste, ze pocitac Filipa Zavorala neni podporovana platforma. Dejou se na nem veci, nad kterymi cely team krouti hlavou a nikdo netusi. Obhajoba: Myslim, ze obhajovat hru je prijemne - samozrejme, pokud funguje a vypada hezky. Po nezajimavych technickych prezentacich poslucharna doslova lacne hlta vsechny screenshoty a videa :) Hudba & Zvuky: Hlasove ustroji cloveka a jeho schopnost produkovat rozlicne zvuky bohate staci pro produkci zvuku pro sebrani bonusu az po strelbu - staci jen mikrofon a uzijete si s tim skutecne plno zabavy. Pro hudbu muzete zkusit sehnat nejakou malou ceskou kapelnu - budou radi, ze o jejich hudbu ma nekdo zajem - pro ne to je vlastne reklama. Asi tezko budete chodit za kapelou typu Lucie, BBP,.. ale nejaka kapelka kamosu, co jen tak hraji podobny navrh jiste oceni. Opensource? Ne vsem se od zacatku chtelo, ale nakonec hra byla opensource - kdyz ji nebudete chtit prodavat, tak to prinese plno vyhod. Muzete si udelat stranky na sourceforge nebo podobnem serveru a tim ziskate mailing list, bugzillu (tu jsme pak nepouzivali) nejakou homepage a moznost ditribuce. Nam se stalo, ze komunita helpla a udelali nam lokalizace a namodelovali nejake tanky. Take vrele muzu doporucit delat pravidelne release projektu i kdyz jeste neni hotovy. Ono mit uzivatele a nejaky feedback je uzasne motivujici. Clovek ma pocit, ze nedela neco, co se hodi do kose, ale ze to nekdo pouziva. Samozrejme je potreba udelat reklamu na freshmeatu a pro hry se hodi happypenguin. Ono je prijemne mit pri obhajobe 5000 stazeni :) Kdyz delate hru, vzdycky se najdou lidi, co si ji radi zahraji :) Jeste celkove nakonec si myslim, ze projekt je predmet, ktery je dobre, ze na MFF je a rozhodne doporucuji :) Bodovou dotaci bych si umel predstavit vetsi, ale porad lepsi mala, nez zadna. :) ######################################################################## Lukas Marek: Nebudu tu popisovat klady projektu ani obecne zkusenosti s projektem. Zamerim se na jeden z nejvetsich problemu, ktery jsme pri vyvoji meli. Pri vyvoji projektu se jen tezko obejdete jen s prekladacem. Nutnosti je pouzivat cizi knihovny pripadne cely middleware. To byl pro nas kamen urazu. Konkretne middleware pro sitovy prenos - omniOrb. Po tom co jsme zustali jen ctyri bylo pouziti ciziho sitoveho middleware nutnosti. Nakonec jsme se rozhodli pro CORBU(omniOrb). I kdyz architektura a pouzivani CORBY nebylo pro hru nejlepsi, uprednostnili jsme znamy a dlouho vyvijeny projekt. CORBA udela spoustu veci, ale take spoustu veci zastresi a nenecha si na ne sahnout. To bylo castecne limitujici, ale protoze jsme neskakali po hlave do nezname vody a meli castecne rozmysleno dopredu, tak se nam mensi problemy cestou podarilo vyresit. Co se vsak ukazalo jako velky problem byla neodladenost omniOrbu. O to horsi bylo, ze pady se objevovaly dosti nedeterministicky a odladit je bylo temer nemozne. S dalsimi problemy jsme se setkali pri instalaci projektu u oponenta. Neni to prijemny pocit. Pred tim nez se rozhodnete pro nejakou knihovnu, middleware, ...(cizi kod) informujte se ve svem okoli kdo ma s pouzitim zkusenosti. Cim vice zdroju, tim lip. Nemuzu rict ze by jsme vyber podcenili a presto jsem se problemum nevyhnuli. ########################################################################