Magic The Gathering

[Gurthfin]

Zdravim,
som tu novy...(len upozornujem, ze to so mnou bude asi blbe)

Uz dlho sa chystam/rozbehavam projekt Magic The Gathering. (Myslim, ze tato kartova hra by vacsine mala byt znama, preto dalej nebudem vysvetlovat. )V podstate prvy zaciatok bol na strednej, kde som na maturite odprezentoval tento projekt urobeni v C a OpenGL (hra bez schopnosti a kuziel, len boj a vyvolanie kreatur). Nanestastie som sa do grafiky vela nepustal, vacsinu urobil spoluziak a ja som prepisal len C-ckovu cast a umiestnenie kariet v OpenGL. (Aj tak to bolo len vytvorenie stvorca a nahranie donho textury). Po maturite som si povedal, ze MtG nejako sprovoznim. Presiel som na C++ a asi 3x som znovu zacal a zase skoncil s tymto projektom. Prvy raz kvoli absencii poznatkov nacitania zo suborov, druhy raz kvoli navrhu programu pre schopnosti a treti raz kvoli grafickemu oknu - to bolo naposledy, vtedy som skusal DarkGDK, co mi nevyslo. Teraz by som chcel zacat znova.


A preto moja otazka. V com by som mal zacat robit graficke okno? S programovanim v C++ si nejako poradim, ale s grafikou mam problemy. Uz pri prvom MtG s OpenGL som mal problem, ze cely kod (funkcie atd) som napisal do "void drawGlScene ()" (tusim tak nejako to bolo). V skole nas ucili len pisat do "int main()" , takze uz len toto mi sposobovalo v hlave galimatias (nehovoriac o to, ze program nemohol mat nijake cakanie na nacitanie, alebo ze sa hlavna funkcia stale opakovala, takze kazda zmena hodnoty premennej musela byt peclivo osetrovana). Uz vtedy som sa s grafikou nepohodol a to sa opakovalo s DarkGDK (hlavne kvoli absencii nejakeho poriadneho tutorialu).

Tak prosim poradte mi, na aku graf. kniznicu/program sa mam zamerat a nejaku jednoduchu teoriu okolo toho, ako sa pise program spolu s grafikou, aby som mal aku taku predstavu od niekoho, kto uz nieco urobil, alebo sa v tychto veciach vyzna lepsie ako ja.

Dakujem.

[Vilem Otte]

Grafickou knihovnu můžeš klidně použít OpenGL. Já spíše vidím problém v organizaci projektu, psát vše do main nebo DrawGLScene (fuj ... NeHe) je prasárna! Zkus vše strukturovat trošku více logicky.

Projekt by měl být logicky dělený, např. grafické hlavičky a zdrojáky si hoď do složky gfx, herní do game a samotné okno do window ... vše pak volej elegantně z mainu. (a jsou lidé co napíšou i na toto dělení fuj, každému dle jeho gusta ... resp. dle gusta project leadera).
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[perry]

Spíše doporučuji používat třídy než hromady funkcí a rozbít projekt na malé části.. rozhodně nepsat všechno do jedné funkce

Jinak Otte doporučuje OpenGL... já jsem zase zastáncem DirectX Nicméně je s ním asi více práce než s OpenGL.. hlavně v začátcích je relativně složité (naštěstí to vyvažuje dle mého názoru perfektní dokumentace a hromady samplů)
_________________
Perry.cz

[FrantaTomanu]

Nuže, klidně bych se nebál použití OpenGL, GLUT. Každopádně aplikace je třeba řádně rozdělit a trochu se naučit hlouběji C++. OOP ti pomůže .

http://sokoban3d.frantatoman.cz

Tady najdeš zdrojáky mého projektu, co jsem nedávno dělal do školy, třeba tě trochu inspirují.

[VladR]

Nehe stale zije

1. "Teach yourself C++ in 21 days" - http://www.angelfire.com/art2/ebooks/teachyourselfcplusplusin21days.pdf

2. Neveril by som, ze take nieco niekedy napisem (nikdy nehovor nikdy), ale v tvojom pripade je uplne idealna stranka http://nehe.gamedev.net/

Zacni pekne od tutorialu 01 a zhruba okolo 05ky by si mal prist k tomu co uz teraz mas nakodene.

3. Potom si precitaj nieco o triedach v C++. Vykasli sa na polymorfizmus a dedicnost. Ignoruj Overriding.
Tebe bude v prvom kroku bohate stacit ak budes mat kod rozbity do tried, teda ze vsetky premenne a funkcie vztahujuce sa ke nejakemu logickemu segmentu hry budu pekne pokope v jednej triede.
Nezabudni premenne inicializovat v konstruktore.
Kedze s triedami robis uplne po prvy krat, tak by som doporucil ignorovat private sekciu triedy a vsetko nadrbat ako public a az bude vsetko bezat, potom zacat refaktoring a snazit sa oddelit private a public premenne a funkcie. To samo o sebe ti na dlhsiu dobu znepojazdni kod

Uvidis, ako ti triedy ulahcia orientaciu, hladanie bugov a celkovo to zrychli vyvoj.

4. Az ked budes mat kod rozbity do tried, zacni triedy oddelovat do suborov. Vygoogluj si "C++ include guards", ze ako sa to presne robi.
Potom ti nastane problem, ako maju triedy medzi sebou komunikovat, ale toto tu teraz rozpisovat nebudem, lebo kym sa dostanes tam, budes mat kod dlhsiu dobu nepojazdny.

5. Konstantam (const int MaxEnemies = 137) sa zatial vyhni, kedze zatial detailne nerozumies tomu ako C++ kompiler funguje, tak ti extern bude robit zbytocne problemy pri linkovani.

6. Neskor, az bude kod znova pojazdny, mozes zacat nahradzovat vsetky #define konstantami v triedach - ci uz cez static, alebo constructor-initialization. No, asi by som doporucil ten static na zaciatok, syntax c-tor init by bola zrejme zbytocne matuca.

7. Vyser sa na C++/OGL kombo a prejdi rovno do C#/XNA a nic z vyssie uvedeneho nebudes musiet riesit, lebo Visualko to vsetko spravi za teba (este aj tie konstanty si pekne nadefinujes rovno v triede ). A ako bonus odchytis vsetky memory leaky u seba uz pocas vyvoja (kedze .NET framework je tak proste nadizajnovany).
S C++/OGL sa natrapis jak hovado, potom to niekde uploadnes a zistis ze to nikomu nebezi Najprv zistis, ze musis riesit debug/release.
Potom, ked konecne najdes zdroj mem leaku, tak po dalsom uploade to znova spadne niekde uplne inde A tak dalej - toto ti treba ku stastiu ?

[Ladis]

Poznámka k NeHe: Starší verze přeložená do češtiny viz odkaz v horní liště na tomto fóru: http://nehe.ceske-hry.cz/
_________________
Award-winning game developer

[perry]

[nou]

[VladR]

Nic nie je tazke ak to uz vies.

Preco mu potom rovno neodporucite, aby si precital nejaku knihu od Alexandrescu o generickom programovani a potom to napisal pomocou templatov ?

Nech si rovno utriedi, kde pouzije Singelton pattern, kde pouzije Adapter. Observer, Composite, ci Strategy Pattern ?

Nech ma dopredu rozmyslene, kde pouzije public inheritance a odovodnene vynimky private inheritance (s dopredu stanovenymi spublikovanymi metodami).

Samozrejme, k tomu uz sa hodia STL standardne sekvencne/asociativne kontajnery a nech nezabudne na <algorithm> kniznicu operujucu na iteratoroch.
Nestadardne STL kontajnery by som ale nevylucoval takisto.

S pointermi radsej nech ani nerobi a rovno skoci na <auto_ptr>, ze ?

Pravdaze, bolo by mrhanie casom sa babrat v takychto prachsprostych zakladoch C++, takze radsej nech si pred navrhom vyskusa aktualny release Boostu, nech vie, ci sa uchylit len k STL kontajnerom, alebo ci mu nepomoze znalost o Boost::dynamic_bitset, boost::array, boost::multi_array. Nezavrhoval by som ani boost::tuple a boost::tribool sa casto tiez hodi.

Pri praci s filesystemom nech zacne s boost::filesystem, vsak ?

Pravdaze, bolo by zverstvo navrhovat engine bez toho, aby podporoval multithreading (uz by som nechal na koderovi, nech si zvazi ci pojde do OpenMP, pthreads, boost::Thread, ci inu alternativu).



A inak ste kompletni

[Gurthfin]

s tym, ze C++ nejako zvladnem som myslel uz to, ze sa v C++ ako tak vyznam... system OOP viem, ale nemam odskusany. Navrhnut triedu, zakladnu pracu s konstruktormi zvladam v pohode (2x som precital Mistrovstvi v C++, a ked si niecim nie som isty, tak v tej knihe hladam vzor). Pouzit viac suborov tiez ako tak viem, ale prekvapilo ma pouzit na kazdu triedu zvlast subor...
Osobne si myslim, ze ak by bola hra len o cislach, dokazal by som ju ako tak naprogramovat, len komu by sa to chcelo hrat v commande a namiesto karticiek by videl len cisla...

Najvacsi problem mi robi pochopenie toho, ako logicku cast (kuzla, boj, vykladanie) spojit s grafikou. Kde tam je hlavna cast programu (nieco ako main() ), ako osetrit jednotlive premenne (nemozem si len tak dat hocikam do grafickeho kodu i++ z logiky, lebo pri kazdom refreshy by sa i++ vykonalo)...

[Deluxe]

Vetsinou se toto resi tak, ze logiku hry pocitas jen jednou kazdych X snimku. Kde X si spocitas tak aby aby byla doba mezi updaty logiky porad stejna.
viz treba tady: http://gafferongames.com/game-physics/fix-your-timestep/
No a ve vysledku pak kreslis X snimku to stejny, nebo interpolujes mezi dvema poslednimy kroky simulace logiky (kde to jde).
Kazdopadne by logika a jeji stav mnel byt oddelenej od grafiky. Asi by to mnelo fungovat tak, ze pri vykreslovani mrknes na stav entity, kterou kreslis a podle toho ji vykreslis.

Ja bych si asi reprezentoval herni objekty jako tridy, kazda by mnela metodu Simulate(step_time); a Render(); a pak bych Simulate voval v pravidelnych intervalech a Render, kazdej snimek.

Jina moznost (a lepsi) by byla, ze by herni objekt nekreslil sam sebe, ale jen by obsahoval informace potrebny ke kresleni a mnel by jsi pak tridu ktera by obsahovala pole vsech objektu a starala se o jejich vykresleni.

Tak nejak jak bych na to pro zacatek sel ja, ale snad se k tomu vyjadri i nekdo zkusenejsi.

[VladR]

[VladR]

Jo a toto tu este spomenute nebolo, ale nez zacnes cokolvek animovat, najdi si na NeHe tutorial, ktory ti vykresli text na obrazovku a pred tym, nez vobec zacnes animaciu riesit, spojazdni to u seba v kode, aby si si mohol vypisovat debug informaciu priamo na obrazovku - nejakou jednoduchou funkciou - napr. DrawText (ScreenXP,ScreenYP, float Value).

Ono sa totiz _dost_ debilne debuguju procesy, ktore trvaju len par framov, ale pol sekundy, lebo debugger zapnes za tu dobu len raz a pri druhom priechode tym istym breakpointom uz proces davno skoncil.

Iste, slo by to aj cez logovanie do suboru, ale to zase prinasa ine problemy (ak zabudnes flsuhnut file po kazdom zapise) a nie je to bohvieako interaktivne.

Skratka, vypis kritickych premennych (napr. aktualna pozicia objektu, percento casu stravene od zaciatku animacie a vobec hodnoty TimeStart/TimeEnd/TimeLength) realtime na obrazovku je absolutne nevyhnutny, ak nechces polku casu len hutat, ze preco to zrazu prestalo ist, ked to doteraz islo.
Vsetky debug vypisy si daj do jednej metody a jednoduchym bool flagom zlinkovanym na nejaku klavesu budes urcovat ci sa to vypisuje alebo nie.

Bez vyssie uvedeneho zabijes uplne zbytocne kopec casu hutanim, ze preco nejaky proces bezi/nebezi.

[FrantaTomanu]

[Gurthfin]