Spellcross - tvorba grafiky

Toto ohliadnutie sa spat na vyvoj hry Spellcross sluzi hlavne pre zacinajucich gamedeveloperov, ktori maju skvele napady na vytvorenie hier zalozenych na sprajtovej grafike. V dnesnej dobe nie je vacsi problem vytvorit zlozito posobiace 3d hry, sprajtova grafika ma vsak stale svoje caro a budeme sa s nou stretavat pravdepodobne este niekolko desatroci. Preto dufam ze tento text nebude v tejto dobe posobit staromodne :-)

Kapitola 01 - Uvod

Zaciatok grafickych prac na hre predchadzala intenzivna previzualizacia. Bolo nutne zvolit spravny pohlad kamery, rozhodnut sa pre perspektivu medzi axonometriou, isometriou, dimetriou a trimetriou. Na tento ucel bola vytvorena testovacia 3d scena vyrenderovana v roznych pohladoch. Nakoniec sa vysledne obrazky nechali posudzovat nezavisle viacerymi ludmi. Bola vybrana perspektiva ktora bola ludmi najlepsie hodnotena. Tymto padom sa zabezpecil dolezity faktor kladneho vnimania neskor vytvaranej grafiky. Vyber bol oslobodeny od technickych limitacii vyroby a editacie grafiky. Na rad prisli testovacie animacie ktore simulovali pohyb vozidiel v terene. Uz od zaciatku sme uvazovali o pseudo-3D terene v ktorom sa nachadzaju vyskove rozdiely. Teren aj pohyb vyzeral slubne takze dala sa zelena na vyrobu grafiky. Tento proces rozhodovania trval zhruba tyzden a bolo velmi dobre pozriet si dane veci na druhy den, kedy mal clovek triezvy pohlad na vec. Na rad prisla dolezita otazka "Ako to do pekla teraz urobime?"

Kapitola 02 - Prostredie

Bolo jasne ze bojova mapa sa do pamate nezmesti ako jeden velky obrazok (nebolo by to ani elegantne). Preto sme od zaciatku uvazovali o jednoduchej grafickej skladacke, pomocou ktorej vytvorime cely herny teren. Moznych policok pre vytvorenie terenu bolo 13. Pekne male cislo na zaciatok.

V naslednych testovacich vizualizaciach boli simulovane prostredia vyskladavane v grafickom 2d programe. Bolo zbytocne programovat editor ked neboli ujasnene zakladne otazky vytvarania grafiky. Vsetka grafika terenu sa vytvarala v programe 3D Studio. Bolo to najlepsie riesenie ako dosiahnut vyzor pseudoterenu v rozumnom case. Dospelo sa k zaveru ze teren nebude moct byt vyskladavany iba z maleho poctu policok. Problemy nastavali v tvrdosti hran medzi jednotlivymi sklonmi terenu. Grafika posobila velmi tvrdo a pocitacovo. V tomto pripade pomohli spominane previzualizacie. Chceli sme sa za kazdu cenu priblizit k renderom ktore boli vytvorene ako prve. Cielom bolo vytvorit pekne zaoblenu grafiku terenu. Zatial sa k tomu grafika moc nepriblizovala. Ked to uz vyzeralo, ze graficky to nebude mozne vytvorit, prisli sme na riesenie. Najprv sme vytvorili vsetky zakladne kombinacie terenu, ktore mohli v hre vzniknut. Bolo ich 32.

Po case testovani sme si vsimli urcite pravidla makkosti prechodov medzi jednotlivymi sklonmi terenu. Vytvorili sme testovacie martice na vyrobu terenu a urcili si vztahy jednotlivych policok medzi sebou. Hned prve testovacie skladanie terenu dopadlo mimoriadne dobre. Princip spocival v tom, ze kazdy sklon terenu musel na seba viazat dalsich 8 policok ktore graficky spolu suviseli. Zla sprava bola ta, ze pocet nutnych policok na level nam rychlo narastal.

Mysliet na dostupnu pamat pri vytvarani grafiky je pre hru priam klucove. Vzdy treba navrhnut taky princip grafiky aby vyzerala co najlepsie a do pamate este vliezla. To plati pre kazdu hru. V tomto pripade bolo jasne kolko zozerie zakladna grafika terenu. Zostatok bol urceny pre postavicky a vozidla (tych taktiez nebolo malo). Pre aditivnu grafiku (domy, cesty, stromy) zostalo zalostne malo miesta. Preto boli navrhnute aditivne grafiky ktore najlepsie obohacovali priestor a nezaberali vela miesta v pamati. Od zaciatku bolo jasne ze chceme ponuknut co najvacsiu hernu plochu. Kombinacie stromov a domov boli uplne postacujuce.
Nasledne obrazky popisuju vsetky policka, ktore su nutne pri modelovani pseudoterenu. Kazde policko ma svoj zmysel. Pokial sa v scheme nachadzaju policka s rovnakou funkcnostou, nabeton su pouzite ako vzajomne variacie.

Policka maju svoju funkcnost zakodovanu v svojom nazve. Ide hlavne o typ policka popisujuceho sklon v terene, vysku v pseudoterene, vztah na ostatne policka, obtiaznost prejazdu (mociar, trava, cesta) a vyska samotneho policka pri zistovani viditelnosti v terene (pouzite pri budovach). Potrebnych policok pre editaciu mapy bolo okolo 2500. Pricom kazde muselo byt ulozene pod specifickym nazvom...bez preklepu. Tu bola na mieste trpezlivost. List adresara vyzeral asi takto.

Dokladny popis policok bol vyvazeny genialnym editorom v ktorom sa spominane grafiky mimoriadne lahko editovali.
Pri navrhovani prostredia boli iba dve moznosti. A) grafika bude kompletne kreslena pixel za pixelom B) grafika bude modelavana v 3d programe a nasledne retusovana a pixlovana. Vyhrala moznost B. Bola najrychlejsia. Pre zaciatok bolo nutne vytvorit material ktory by umoznoval vytvorit strukturu terenu. Mapovania roznych textur nepriniesli dobre vysledky. Material musel byt univerzalny pre vsetky sklony pseudoterenu a musel byt tilovatelny v kazdej kombinacii policok. Toto splnal iba spravne farebne vyvazeny sum. Pre vytvorenie spravneho sumu boli pouzite proceduralne textury v 3D Studio MAX. V kombinacii so spravnym bumpom a svetlom v scene vytvoril pozadovany efekt. Material vyzeral asi takto. Uplne postacoval.

Po vyrenderovani zakladneho podkladu sa naniesli na grafiku charakreristicke pomocne ciary, ktore zvyraznovali jednotlive policka. Pre zakladnu rovnu plochu v terene sa kombinovali iba 4 policka. Pri vacsich rovnych plochach by vsak teren posobil nudne. Preto boli vytvorene takzvane "celky grafik". V nich boli ulozene vsetky dalsie "spestrenia" prostredia.
Svetlo v scene taktiez hra velmi dolezitu ulohu. Kazda cast exterieru by mala byt nasvietena rovnakym svetlom. V tomto pripade vsak rovnake svetlo na prostredie a objekty vyzeralo dost zle. Pre prostredie vyznievalo lepsie svetlo smerujuce od pohladu kamery. Na objekty sa viac hodilo svetlo umiestnene vlavo od kamery. Preto teren a objekty sa renderovali s rozdielnym osvetlenim. Paradoxne aj ked sa pridali pod objekty tiene, tento fakt vobec nevadil. Svojim sposobom nerealne nasvetlena scena posobila na divaka omnoho atraktivnejsie a prehladnejsie.
Vytvaranie celkov grafik uz postupovalo podla klasickych pravidiel. Taky domcek bol najprv namodelovany tak, aby sa presne zmestil na pozadovane policka. Vsetky okrajove casti policka museli byt zaplnene, preto vsade po okrajoch sa nachadzaju muriky, stromy alebo kamene. Vysledne male rozlisenie grafiky umoznovalo modelovat objekty velmi nahrubo. Vacsinou sa nic netexturovalo. Pouzivali sa iba ciste materialy, pripadne sem tam proceduralna textura. Zasadne zmeny sa uz udiali pri retusovani grafiky. Kde-tu bolo idealne zvyraznit svetla/tiene, doplnit prirodzenu patinu a zmakcit prechod medzi objektom a prostredim. Cely tento proces bolo rychlejsie riesit pomocou retuse ako dokonalou 3D scenou.

Kvoli dostupnej pamati v prostredi mohli byt umiestnene iba niektore celky grafik. Preto niektore uzemia su charakteristicke budovami, ine prirodnymi prekazkami a dalsie zmenami v prostredi. Dalsou vecou ako si ulahcit tvorbu grafiky je vytvorenie si masiek na prechody medzi jednotlivymi prostrediami. Prechod v prostredi spocival napriklad medzi svetlou a tmavou travou. Grafik na potrebne vytvorenie prechodu bolo viacero, takze pre usporu casu sa recyklovali aj v inych prostrediach ako pust/zem/devastovana trava. Iba pripomeniem ze v tej dobe Photoshop nepoznal funkciu vrstiev. Spominane masky boli vytvarane v 3D prostredi, lahsie sa robili nadpojenia medzi polickami. Vyzerali asi takto:

Povodne vsetky stromy boli vytvorene do jedneho policka a jednotky nemohli pozane chodit. Takto naeditovane prostredie nevyzeralo zle, avsak lesu sa to vobec nepodobalo. Vizualne strom dosahoval vysky postavicky a celkovy zmysel grafiky posobil dost rozpacite. Preto boli vyvynute specialne grafiky ktore mohli mat vysku policka a pol. Boli pouzite pri stromoch a vyssich hradbach. Kedze v tej dobe pocitace neboli moc rychle, vykreslovaci engine musel optimalne vykreslovat len to najnutnejsie aby hra bola rychla aj vo vysokom rozliseni. V praxi to zmanenalo nepouzivat vela stromov v terene. Dost spomalovali. Tento obrazok z prveho levelu potvrdzuje toto pravidlo.

Stromy dodali prostrediu dalsi netuseny rozmer. Ich vyzoru bolo nutne venovat viac pozornosti. Vsetky boli namodelovane pomocou 3D programu. Stacila iba zakladna geometria bez textur. Stromy bolo nutne pred renderingom specialne osvetlovat. Rendering bol nakoniec realizovany na kontrastnej ploche (nejlepsia je fialova) s vypnutym antialiasingom. Nasledne v 2D programe bol pridany mierny sharpen a retusou zvyraznene svetla a tiene. Tym padom ked sa stromy nachadzali husto za sebou, nesplyvali do jednej zelenej masy a boli stale krasne citatelne. Tien stromu bol spociatku presne renderovany, avsak neposobil v grafike prirodzene. Pod stromami sa skor ma nachadzat velmi makky tien nez raytracovana kopia. Preto boli realne tiene nahradene retusou.

Kapitola 03 - Farby

Kedze cela hra prebiehala v 256-farebnom mode, bolo mimoriadne dolezite rozvrhnutie farieb v prostrediach. Grafika nesmela byt prilis roznofarebna. Cim viac farieb pouzitych v grafike, znamenalo menej odtienov farieb v palete. Potom by pri nizkom rozliseni bol vidiet masivny dithering, co by nebolo moc pekne. V palete bolo vyhradenych prvych 128 farieb pre prostredia. Dalsich 88 farieb bolo vyhradenych na jednotky a zvysok bol urceny pre menu a systemove farby. Paleta vyhradena pre menu a jednotky sa pocas levelov nemenila a bola stala. Aby sa farby vyuzili co najefektivnejsie, bol zvoleny nasledovny postup. Najprv sa na jeden obrazok umiestnili vsetky jednotky v truecolore. Ich farby boli zredukovane na 88. Dalsi obrazok bol vyplneny charakteristickou grafikou levelu. Farebna paleta levelovej grafiky bola zredukovana na 128 farieb, pricom sa prihliadalo na 88 uz vygenerovanych farieb pre jednotky. Takze nakoniec levelova grafika vyuzivala plnych 216 farieb.

Vyhodou paletizovanej grafiky je umoznenie cyklovaniu casti paliet, pricom takto sa daju dosiahnut zaujimave efekty uplne zadarmo. Toto bolo vyuzite pri grafike tecucej vody v riekach.

Pri vytvarani farieb pre jednotky, bol problem s farbami pre jednotky Aliancie. Prirodzene vozidla v zelenom terene pouzivaju zelene maskovanie. Avsak pri takejto farbe sa dobre v hre maskuju pred samotnym hracom. Preto bolo dobre pouzit prijemnu kontrastnu farbu. Idealna bola okrova. Avsak v pustnom prostredi jednotky zacali tiez zanikat. Preto niektore prostredia boli farebne upravovane tak, aby vyhovovali ako spravny kontrastny podklad pod jednotky. Nakoniec sa podarilo najst tie najlepsie kombinacie pre farby v jednotlivych prostrediach.

Kapitola 04 - Praca s grafikou

Kedze pocas vytvarania grafiky dochadzalo k roznym optimalizaciam, zmenam a opravam, grafika musela byt pre testovanie neustale ukladana do jednotlivych policok ktore engine dokazal nacitat. To znamenalo menit stovky suborov. Aby tento proces bol co najrychlejsi, bol vyvynuta metoda automatickeho vysekavania a ukladania grafiky. Kazdy obrazok s hernou grafikou mal vytvorenu paletizovanu masku s definicnym suborom jednotlivych policok. V praxi to vyzeralo asi takto.

Rychlost prace s grafikou sa nakoniec ukazala ako dost podstatna. Vdaka tomu mohlo byt vyskusanych mnozstvo grafik a vychytanych kopec chyb v pomerne kratkom case.
Podobna automatizacia musela byt vytvorena aj pri konverzii grafiky jednotiek do enginu. Ked uvazime ze motorova jednotka mohla stat na osmich rozne natocenych rovinach v 16-tich smeroch so samostatne otocnou pripadnou vezou. A motorovych jednotiek bolo okolo 40, Dostaneme sa zhruba k cislu 10 000 sprajtov. Presnejsie pocet sprajtov jednotiek dosahoval 23 255!!! Pricom kazdy sprajt musel byt postprodukcne po renderovani upraveny (sharpnuty iba v obsahu alphamasky + doplneny o tien) a pripadne vyretusovany. Rychlost spracovania tu bola na mieste.

Celkovo velka pozornost sa davala na detail modelovanych jednotiek. Ich mnozstvo bolo vsak prilis vysoke a to zial sposobilo prilis dlhy cas ich vyroby. V konecnom dosledku detailna grafika samotnej hre moc nepomohla. Detailne modely boli pouzite iba v informacnych obrazovkach a animaciach. Pre rendering do hry sa muselo vela jednotiek zjdenodusovat, optimalizovat a colorovat do viditelnejsich farebnych kombinacii. V tomto pripade sa urcite oplatilo spominany cas investovat do grafiky prostredia. Asi by hra vyzerala omnoho omnoho lepsie. To ale az snad az v pokracovani...

MaxMan

Tvorba listnatého stromu - sprite v 3DS MAX

Ak ste niekedy vyvíjali hru, v ktorej ste sa rozhodli používať sprity, určite vás napadlo, či je lepšie kresliť ich pomocou jedného z mnohých 2D programov, alebo či siahnuť po 3D programe, ako je napríklad 3Ds max alebo MAYA.
Tento tutoriál je práve pre tých, ktorí sa buď ešte nerozhodli alebo si vybrali jeden z mnohých 3D programov.
V krátkosti ukážem, ako jednoducho vytvoriť celkom pekný strom v 3Ds max a ako ho exportovať tak, aby sa dal použiť ako sprite v hre.

Tvorba základu

Ako prvý krok treba samozrejme vytvoriť kmeň, na ktorý sa neskôr pripoja vetvy. Je to jednoduché. Keďže ho v konečnom dôsledku ani príliš vidno nebude, netreba sa s ním príliš trápiť. Asi najjednoduchší spôsob je použiť loft, pričom na vrchu by mal byť kmeň tenký a spodok naopak hrubý.

Všimnite si, že som zvolil väčší počet vertikálnych segmentov, ako by bolo na prvý pohľad treba. To preto, aby nebol problém vytvoriť na spodku stromu malú nepravidelnosť, ktorá dodá celkovému vzhľadu o niečo plastickejší ráz.
Pre dosiahnutie tohto efektu stačí pomocou poly select vybrať spodné vertexy kmeňa a aplikovať na ne noise. Asi takto:

Konáre

V ďalšom kroku vytvoríme konáre. Tu je znova dôležité si uvedomiť, že v konečnom dôsledku ich takmer celé prekryjú listy. Stačí teda celú korunu formovať tak, aby sme dostali aspoň približný tvar reálneho stromu. Taktiež treba mať na mysli skutočnosť, že listy sa budú zoskupovať okolo konárov, takže ak chceme mať strom pekne hustý, treba zahustiť aj konáre.
Tak a poďme na samotnú tvorbu.
Ako prvý krok si vytvoríme akési samply, čiže viacero jednoduchých konárov, ktoré budeme neskôr spájať do komplexnejších celkov.

Sú to jednoduché objekty, ktoré je asi najjednoduchšie vytvoriť ako lofty a neskôr na ne aplikovať noise. Dá sa to však vytvoriť aj z boxu postupným upravovaním vertexov. Ako vyrobiť tieto jednoduché objekty je už len na vás.
Ďalej tieto samply pospájame do konárov, ako je napríklad tento:

Všimnite si, že čím bližšie ku koncu, malé konáriky sa zmenšujú.
Ak máme pár konárov hotových, môžeme ich "poukladať" na strom asi takto.

Snažte sa vytvoriť vami požadovaný tvar, pretože ako ho vytvarujete teraz, približne tak aj ostane po pridaní listov.
Celé je to trocha pracný proces a vyžaduje si trpezlivosť, ale nikto nám nezakáže, aby sme aj trocha podvádzali. Vzhľadom na to, že konárov je veľké množstvo, celkom často sa môžu opakovať. Netreba sa teda trápiť s vytváraním tisícou samplov. Postačí pár, ktoré po zmene veľkosti a otočení vlastne vyzerajú úplne rozdielne.

Listy

Listy spravíme pomocou scatter.
Ako prvý krok treba spojiť korunu do jedného celku. To dosiahneme prevedením jedného z konárov na editable poly. Pomocou attach k nemu pripojíme aj ostatné konáre, až nakoniec vznikne z koruny jeden objekt.
Potom vytvoríme plane vo veľkosti jedného listu. Bude slúžiť ako referencia pre všetky ostatné. Aplikujeme na neho scatter (create->geometry->compound objects->scatter). Ako distribution object dáme našu korunu.
Podrobnejšie nastavenia sú zobrazené tu (odporúčam sa s tým ale pohrať pre dosiahnutie presného požadovaného výsledku):

Textúra

Detailnosť textúry samozrejme závisí od vzdialenosti kamery. Ak je váš želaný náhľad podobný tomu môjmu vyššie, postačí vám celkom jednoduchá textúra.
Na kmeň som použil mapu dreva z "3dsmax/maps/wood/ASHSEN_2.GIF". Na listy mi postačila jednoduchá zelená farba s nastaveným specular level a glossiness na 20.

Export

Základom renderovania, keď hovoríme o spritoch, je zapnutie možnosti Don`t Antialias Against Background (customize->preferences->rendering->...). Takto zamedzíme problému s nepekným ružovým okrajom okolo celého stromu.
Listy však stále nie sú v poriadku:

Sú až príliš rozmazané. Preto treba ísť do rendering->render->renderer a v sekcii antialiasing prepnúť filter na soften (filter size = 1,0). S týmto sa tiež dá pohrať pre presný požadovaný výsledok.
Takto upravený strom vyzerá takto:

Tento strom vyzerá už trocha lepšie. (V skutočnosti vyzerá ale trocha inakšie, pretože tento obrázok je jpg. Teda tu je antialiasovaný s okolím.)

Výhoda je, že z jedného takéhoto stromu je možné vytvoriť viac. Stačí ich len natáčať a meniť farby listov i kmeňa.
Takisto, keď sa vám zdá, že je váš strom príliš riedky, stačí vybrať celú korunu, alebo jej časť, skopírovať ju a pootočiť. Toto vám môže značne ušetriť čas a nervy.

Attachment	Size
Strom.jpg	12.7 KB
Kmen.jpg	9.83 KB
KmenDole.jpg	8.19 KB
Vetvy.jpg	16.13 KB
Vetva.jpg	24.23 KB
Stromy-vetvy.jpg	94.04 KB
Scatter.jpg	207.01 KB
Area.jpg	8.14 KB
Soften.jpg	9.15 KB

Aký Programovací Jazyk Mám Použiť?

Toto je otázka, ktorá patrí do každej FAQ o programovaní hier. Zdá sa, že je často kladená na game developerských fórach niekoľko krát za týždeň. I keď je to dobrá otázka, ťažko sa na ňu hľadá odpoveď. Existujú programovacie jazyky, ktoré sa viac hodia pre niektoré aplikácie než iné. Tu je zoznam hlavných programovacích jazykov používaných na písanie hier aj s popismi, výhodami a nevýhodami. Dúfam, že vám tento zoznam pomože pri rozhodovaní.

C

Ak boli FORTRAN A COBOL prvými kompilovanými vyššími jazykmi, potom C je ich vnuk. Vytvoril ho Dennis Ritchie v 70. rokoch ako užší a súdržnejší následovník ALGOLu, čo bol štruktorovaný následovník COBOLu a FORTRANu. Bol navrhnutý tak, aby bol menšou a jednoduchšou verziou svojich predchodcov, vhodný pre písanie programov vyššej úrovne, ako operačné systémy. Do vtedy boli operačné systémy kódované ručne v assembleri a neboli prenosné. C bol prvý programovací jazyk ktorý urobil z prenosnosi pre systémový kód realitu.

C je jazyk, ktorý podporuje štrukturované programovanie. Teda môžme povedať, že C programy sú napísané ako zbierka nespojených funkčných volaní, ktoré sa spracovávajú od hora dolu a nie jednotný monolitický blok kódu s riadenim behu programu pomocou príkazov GOTO. Z toho dôvodu sú C programy všeobecne lepšie čitateľné než monolitický kód FORTRANu a COBOLu pripomínajúci špagety. V skutočnosti C stále má príkaz GOTO, ale jeho funkčnosť je limitovaná a doporučuje sa iba ako posledná voľba v prípade, že sú štrukturované riešenia o mnoho zložitejšie.

Vzhľadom na svoje korene v systémovom programovaní, je dosť jednoduché použiť C s jazykmi assembleru. Rozhranie funkčného volania je veľmi jednoduché a inštrukcie assemblera je možné vnoriť do C kódu, takže spájanie v odlišných moduloch assembleru nie je potrebné.

Výhody: Vhodný pre písanie malých rýchlych programov. Jednoducho kombinovateľný s assemblerom. Veľmi štandardizovaný, takže verzie na iných platformách sú podobné.

Nevýhody: Neľahko podporuje objektovo orientované techniky. Syntax môže byť zložitý a ťažko narábateľný.

Prenosnosť: Zatiaľ čo jadro jazyka a funkčné volania ANSI sú veľmi prenosné, sú limitované len na riadenie behu programu, spravu pamäte a jednoduchú prácu so súbormi. Všetko ostatné závisí od platfomy. Napríklad vytvorenie programu, ktorý je prenosný medzi Windowsom a Macom, vyžaduje, aby časti užívateľského rozhrania používali funkčné volania toho-ktorého systému.

Hry napísané v C: Veľa preveľa.

Zdroje: Klasická kniha venovaná C je The C Programming Language. Prešla niekoľkými zmenami a jej veľkosť sa rozšírila asi trojnásobne, ale je to stále dobrý úvod do jazyka. Výborným tutoriálom jeThe Waite Group's C Primer Plus.

C++

C++ je objektovo orientovaný nástupca C. Objektovo orientované, alebo OO, programy predstavujú ďalší krok ďalej za štrukturovaným programovaním. OO programy sú zostavené z objektov, ktoré sú balíčkami dát a funkcíí zozbieraných do diskrétnych jednotiek. Je dostupných mnoho knižníc objektov, ktoré robia písanie programov jednoduchým ako skladanie zbierky "stavebných blokov" programu (prinajmenšom teoreticky). Napríklad, existuje mnoho GUI a databázových knižníc, ktoré sú implementované ako zbierky objektov.

C++ je predmetom kontroverzie, hlavne v komunite game developmentu. C++ má také črty, ako virtuálne funkcie, ktoré pridávajú extra vrstvu pri rozhodovaní o funkčných volaniach a kritici rýchlo poukazujú na to, že C++ programy môžu byť väčšími a pomalšími než ich C náprotivky. Obhájcovia C++ ale poukázali na to, že nakódovať ekvivalenciu virtuálnej funkcie v C vyžaduje to isté. Je to prebiehajúca debata, o ktorej sa tak ľahko v dohľadnej dobe nerozhodne.

Podľa môjho názoru, C++ má navrch v tom, že je jednoducho cenou, ktorú platíte za lepší jazyk. Táto istá debata sa viedla v 60. rokoch minulého storočia, keď vyššie programovacie jazyky ako COBOL a FORTRAN začali nahrádzať ručne kódovaný assembler ako jazyk voľby. Kritici správne poukázali na to, že programy písané vo vyšších programovacíh jazykoch boli podstatne pomalšie než ručne ladený assembler a vždy budú. Obhájcovia vyšších programovacích jazykov ale poukázali na to, že mierny pokles výkonu bol toho hodný, pretože COBOL a FORTRAN programy bolo možné o mnoho ľahšie napísať a spravovať.

Výhody: O mnoho lepšie než C pre organizáciu veľkých programov. Výborne podporuje objektovo orientovanú paradigmu. Knižnice bežných dátových štruktúr, ako spájané zoznamy a zväčšovateľné polia, môžu odstrániť bremeno zaoberania sa s detailami nižšej úrovne.

Nevýhody: Veľmi veľké a komplikované. Podobne ako C, ťažko narábateľný syntax. Môže byť pomalšie než C. Nie veľa kompilátorov implementuje celý jazyk správne.

Prenosnosť: Lepšia než u C, ale stále žiadna sláva. I keď zdieľa rovnaké nevýhody ako C, väčšina prenosných knižních užívateľského rozhrania je implementovaných ako zbierky C++ objektov.

Hry napísané v C++: Veľa preveľa. Takmer všetky komerčné hry sú napísané v C alebo C++.

Zdroje: Najnovšia verzia The C++ Programming Language je výborná. Čo sa týka tutoriálov, sú dva tábory: jeden predpokladá, že viete C a druhý nie. Doposiaľ najlepšie zozbierané C++ tutoriály sú Who's Afraid of C++ a Who's Afraid of More C++. Ak už viete C, skúste Teach Yourself C++.

Mal by som sa učiť C++ alebo by som mal začať s C?

Myslel som si, že toto stálo za zmienku, pretože je to druhá najbežnejšie pýtana otázka po "Ktorý programovací jazyk by som mal používať?"

Naneštastie, odpoveď nie je čiernobiela. Mohli by ste si ušetriť kopu času učením sa iba C-éčka a písaním aplikácii, ale tento postoj ma aj dve nevýhody.

- Bude vám chýbať niečo, čo je pravdepodobne o mnoho efektívnejší spôsob modelovania dát vo vašej hre.
- Ak sa nezačnete učiť OO hneď zo začiatku, mohli by ste sa naučiť programovacie zlozvyky, ktoré sa budete musieť neskôr odučiť. V tomto mi verte.

Mnoho z najväčších komerčných hier, vrátane väčšiny FPS, sa zaobídu bez C++. Avšak autori týchto programov vždy trvajú na tom, že používajú objektovo orientované techniky aj napriek tomu, že používajú staré dobré C. Ak sa chcete učiť len C, prinajmenšom sa naučte OO programovacie techniky. OO je perfektná metodológia pre simulácie (čítaj: hry) a skutočne sa vám bude ťažko robiť, ak budete učenie OO stále odsúvať.

Assembler

Jazyk assembleru bol prvý programovací jazyk. Jazyk assembleru je vlastne príkazová reprezentácia aktuálnych inštrukcií, ktoré váš počítač spracováva. To znamená, že budete mať do činenia s detailami vášho procesora na nízkej úrovni, ako registre a zásobníky. Ak hľadáte jazyk, ktorý sa podobá angličtine a dokumentuje relatívne sám seba, toto nie je ono!

Podľa definície, čokoľvek, čo dokážete urobiť v hocakom programovacom jazyku, dokážete aj v assembleri, iba nie tak jednoducho --samozrejme, je to to isté, keď poviem, že všade tam, kde sa dokážete dostať na aute, môžete aj pešo, ale nie tak jednoducho. Zatiaľčo toto tvrdenie môže byť pravdivé, novšie technológie umožnili veci používať jednoduchšie.

Vo všeobecnosti sa assembler sám o sebe na hry nepoužíva. Hry, ktoré využívajú assembler, ho využívajú len po kúskoch tam, kde sa môže zlepšiť výkon. Napríklad, DOOM je celý napísaný v C s niekoľkými vykresľovacími rutinami ručne nakódovanými v assembleri. Nie sú to rutiny volané niekoľko tisíc krát za sekundu, takže udržanie rutiny uhľadnou skutočne pomohla výkonu hry. Je celkom jednoduché napísať funkciu v assembléri, ktorá je volateľná z C, takže použitie oboch jazykov nebol problém.

Špeciálna poznámka: Názov jazyka je "assembly". Názov nástroja, ktorý konvertuje jazyk assembleru do čisto strojového kódu sa volá "assembler". Je bežné volať tento jazyk "assembler", takže vykročte pravou nohou k volaniu jazyka jeho skutočným menom. (V slovenčine sa tento jazyk označuje bežne assembler; pozn. prekladateľa)

Výhody: Je to, podľa definície, najmenší a najrýhlejľí jazyk. Talentovaný programátor dokáže písať programy, ktoré sú rýchlejšie než hocičo iné urobené v iných jazykoch. Budete prvou osobou, ktorá využije výhodu najnovších vlastností procesora, pretože ich môžete použiť priamo.

Nevýhody: Zložitý na učenie, šifrovaný syntax, ťažký na efektivitu, a vyžaduje si o mnoho viac kódu, ktorý bude vôbec niečo robi --nie pre potešenie!

Prenosnosť: Pretože je jazyk navrhnutý pre jeden procesor, z definície je neprenosný. Ak používate rozšírenia špecifické pre istú značku procesora, váš kód nie je dokonca prenosný medzi inými procesormi rovnakého druhu (napr. AMD 3DNow! inštrukcie nie sú prenosné do iných procesorov triedy Pentium).

Hry napísané v Assembleri: Nepoznám žiadnč komerčné hry, ktoré sú celé napísané v assembleri. Avšak niektoré hry majú väčšinu časovo kritických častí urobených v assembleri.

Zdroje: Keď hľadáte dokumentáciu pre assembler, v podstate hľadáte dokumentáciu pre čip. Nejaké online infomácie o svojich procesoroch má Intel, AMD a Motorola. Čo sa týka kníh, Assembly Language: Step-By-Step má dobrú recenziu.

Pascal

Pascal navrhol Nicolas Wirth začiatkom 70. rokov, pretože sa zdesene prihliadal tomu, že FORTRAN a COBOL nepodporovali u študentov prospešnú disciplínu štrukturovaného programovania. "Špagetový kód" sa stával normou a jazyky toho času sa k nemu nestavali odmietavo. Pascal bol navrhnutý od základov na posilnenie praktík štrukturovaného programovania. I keď pôvodný Pascal bol navrhnutý striktne na vyučovacie účely, mal dostatok zastáncov, aby sa mohol prípadne presadiť aj v komerčnom programovaní. Pascal sa nakoniec dostal do pozornosti, keď Borland vydal Turbo Pascal pre IBM PC. Integrovaný editor, blesku-rýchly kompilátor a nízka cena boli veľmi presvedčivou kombináciou, a Pascal sa stal preferovaným jazykom pre písanie malých programov pre MS-DOS.

Avšak netrvalo to dlho. C kompilátory sa stali rýchlejšími a boli obohatené vstavanými editormi a debuggermi. Takmer poslený klinec do rakvi Pascalu bol zabitý v skorých 90. rokoch s nástupom Windowsu a Borland ingnoroval Pascal v prospech C++ pre písanie Windows aplikácii. Turbo Pascal upadol do zabudnutia.

A nakoniec, v roku 1996, Borland vydal svojho "zabijáka na Visual Basic", Delphi. Delphi bol rýchly kompilátor Pascalu spojený s nádherným užívateľským rozhraním. Naproti všetkým vyhliadkam (a Visual Basicu) si získal mnoho fanúšikov.

V celku je Pascal jednoduchší ako C. I keď syntax je podobný, chýba mu mnoho uľahčujúcich operácii, ktoré C má. To aj dobrá vec a aj zlá. Je ťažšie napísať nevyspytateľne "dômyselný" kód, ale operácie nízkej úrovne ako narábanie s bitmi sú zložitejšie.

Výhody: Dá sa ľahko naučiť. Implementácia pre špecifickú platformu (Delphi) je veľmi pekná.

Nevýhody: OO nástupcovia "svetovej triedy" Pascalu (Modula, Oberon) neboli úspešné. Tvorcovia kompilátora sa nedržia jazykových štandardov, patentovo.

Prenosnosť: Mizivá. Vlastnosti jazyka sa menia z platformy na platformu a neexistujú žiadne nástroje prenosnosti, ktoré by sa vysporiadali so znakmi špecifickej platformy.

Hry napísané v Pascale: Zopár. DirectX komponenty pre Delphi posunuli oblať hrania na vyššiu úroveň.

Zdroje: O Delphi sa môžete dozvedieť na stránke Inprise Delphi.

Java

Java bola pôvodne navrhnutá spoločnosťou Sun ako prenosné "malé C++", ktoré sa dalo používať vnorené do aplikácii. Myšlienka spúšťania malých aplikácii vo web stránkach skutočne podmanila ľudskú predstavivosť, takže jazyk sa rýchlo uchytil. Vyšlo na javo, že Java nebola vhodná len pre vnorené animované bannery vo web stránkach --bol to priam fajnový malý jazyk pre pregramovanie aplikácii. Povaha "virtuálneho stroja", zber odpadkov a neprítomné ukazovatele uľahčili tvorbu nepriestrelných aplikácii, ktoré nepadali a nemali žiadne úniky zdrojov.

Zatiaľčo bola neoficiálnym pokračovaním C++, Java si vypožičiava podstatne veľa zo syntaxu C++. Hromadí mnoho zložitejších vlastností C++ a tým odhaľuje dosť kompaktný jazyk, ktorý sa dá ľahko naučiť. Na rozdiel od C++, Java núti k OO železnou rukou. Napísať ne-OO aplikáciu v Jave je zložité asi tak ako písanie špagetového kódu v Pascale.

Výhody: Binárka sú prenosné na iné platformy. Aplikácie môžu bežať vnorené vo web stránkach. Zahrnutá knižnica triedy je primerane štadardizovaná a extrémne robustná. Automtická alokácia a zber odpadkov eliminuje straty zdrojov v aplikáciach. Obrovské množstvo príkladov kódu na webe.

Nevýhody: Používa "virtuálny stroj" na spúšťanie prenosného bajtového kódu namiesto natívneho strojového kódu, takže aplikácie sú pomalšie než skutočné kompilátory. Existujú technológie (ako "Just In Time" kompilátory), ktoré vo veľkej miere zvyšujú rýchlosť Javy, ale rýchlosť bude pravdepodobne vždy zaostávať za riešeniami skutočného strojového kódu. Prvé vlastnosti ako Abstract Windowing Toolkit neboli dobre premyslené a, zatiaľčo boli oficiálne zanechané, museli zaostávať kvôli spätnej kompatibilite. Je veľmi vysokej úrovne, čo robí prácu s akýmikoľvek vlastnosťami stroja nižšej úrovne veľmi zložitou. Sun je podstatne pomalý v prídavaní nových "požehnaných" vlastností do jazyka.

Prenosnosť: Najlepšia z ostatných, ale stále to nie to, čo by malo. Kód nízkej úrovne je veľmi prenosný, ale mnoho z užívateľských rozhraní a novších vlastností je kolísavých na niektorých platformách.

Hry napísané v Jave: Množstvo malých appletov vo web stránkach, ale iba málo komerčných ponúk. Niekoľko komerčných hier využíva Javu ako interný skriptovací jazyk.

Zdroje: Officiálna stránka Javy od Sunu má dobré informácie. IBM má tiež výbornú Java stránku. JavaLobby je najlepšie miesto, kám ísť zháňať novinky o Jave.

Zhrnutie

Možno ste dúfali v lepší záver k dileme "Aký programovací jazyk používam". Nanešťastie, neexistuje riešenie, ktoré je optimálne pre všetky aplikácie. C je vhodné pre rýchle a malé aplikácie, ale dobre nepodporuje OO programovanie. C++ má dokonale kompletnú OO podporu, ale zastrašujúco komplikovaný. Visual Basic a Delphi sa dajú ľahko naučiť, ale sú neprenosné a právom chránené. Java má veľa užitočných vlastností, ale je pomalá. Najlepšie pre vás by bolo, keby ste si uvedomili akú hru píšete a vybrať jazyk, ktorý by najlepšie podporoval vašu hru. Je dobré, že sa ponuka "vyskúšajte to zadarmo za 30 dní" stala normou priemyslu :-)

Programovanie Hier: Sprievodca Začiatočníka

Často sa ma pýtajú ako môže niekto s malou alebo žiadnou programátorskou skúsenosťou začať vo vývoji hier. Až do teraz som sa im snažil pomôcť ako som len mohol každému osobitne. Ale kedže v poslednej dobe počet otázok vzrástol na takmer nezvládnuteľnú úroveň, rozhodol som sa, že nastal čas, aby som všetky moje rady zhrnul do jedného článku slúžiac ako všeobecný zdroj.

Tento článok je určený ľuďom, ktorí chcú robiť svoje vlastné hry, ale majú majú alebo žiadnu skúsenosť s programovaním. Vlastne budem predpokladať, že čitateľ nemá vôbec žiadnu skúsenosť s programovaním. Zameriam sa najmä na programátorsku a dizajnérsku stránku vývoja hier a vynechám tvorbu. V podstate nepokryjem zaangažovanie sa do priemyslu (pretože pre to už existujú rozsiahle zdroje), ale prevediem vás cez veci, ktoré musíte urobiť, aby ste sa dostali do bodu, že budete môcť urobiť vlastné hry. A na koniec, cestu, ktorú vám tu predostrem by ste nemali brať ako jedinú - alebo dokonca najlepšiu - cestu ako sa naučiť programovať hry, ale pre mňa a iných ľudí sa osvedčila.

Výber jazyka

Prvá vec, ktorú budete musieť urobiť je vybrať si jazyk, v ktorom budete programovať. Máte veľa možností, vrátane Basicu, Pascalu, C, C++, Javy, atď. Existuje množstvo debát na tému, ktorý programovací jazyk je najlepší pre začiatočníkov. Pre diskusiu o počte obľúbených jazykov si môžete pozrieť výborný článok od Johna Hattana, Aký Programovací Jazyk Mám Použiť?

Doporučujem začať s C a C++. Niektorí ľudia budú hovoriť, že tieto jazyky sú príliš pokročilé pre ziačiatočníkov, ale pretože ja sám som začal s C++, musím nesúhlasiť. Navyše, C/C++ je dnes najrozšírenejším používaným jazykom, takže nájsť kopu zdrojov a helpov nebude problém. Vôbec nazáleží na tom, či sa najprv naučíte C alebo C++, pretože akonáhle sa naučíte jeden, naučiť sa druhý bude triviálna záležitosť. Avšak, ak sa rozhodnete najprv pre C++, uistite sa, že rozumiete a viete použiť procedurálne programovanie pred tým, než sa pustíte do objektovo orientovaného programovania (napr. neučte sa o triedach do vtedy, kým nedokážete dobre programovať aj bez nich).

Ak začnete s C/C++ a bude sa vám to zdať zložité, nie je nič zlé na tom, že sa rozhodnete učiť jednoduchší jazyk, ako Basic alebo Pascal. Ale ja si myslím, že ak to s ním vydržíte a nájdete si správne zdroje, nemali by ste mať s C/C++ žiadny problém.

Vašou ďalša otázka by mala byť, "Ako sa mám C/C++ naučiť?". Som rád, že sa pýtate. Najlepší spôsob je zapísať sa na kurz. Keď budete mať k dispozícii nejakého inštruktora alebo asistenta, aby vám odpovedali na vaše otázky a pomohli vám ďalej, budete mať veľkú výhodu a programátorské úlohy zaistia, že aplikujete to, čo sa učíte.

Ak zapísanie sa na kurz nie je voľbou pre vás, druhou najlepšou vecou je zohnať si nejaké dobré knihy. Príliš sa nestresujte výberom "dokonalej knihy", pretože nakoniec si kúpite možno niekoľko. Navrhoval by som ísť do miestneho kníhkupectva a stráviť nejaký čas prehrabávaním sa v úvodných C a C++ knihách pokiaľ nenájdete tú, ktorej rozumiete a mýslite si, že sa z nej dokážete učiť. Medzi časom si budete chcieť vybrať pokročilejšie knihy a možno manuál, ale keď už budete mať nejakú znalosť jazyka, budete lepšie vedieť, čo potrebujete.

V tomto bode by som sa chcel pozastaviť a povedať niečo o tom, čo som videl, že predstavuje pre mnoho začínajúcich programátorov problém, hlavne pre tých mladších: nedostatok peňazí na nákup knihy a podobné veci. Tak za prvé, sú dostupné nejaké zdroje zadarmo, vrátane vašej miestnej knižnice (to si snáď robí srandu!; pozn. prekladateľa) a Macmillan Computer Publishing, ktorý má stovky kníh o programovaní online na http://www.mcp.com/personal (už nefunguje; pozn. prekladateľa). Ale za druhé, ak sa naozaj chcete stať dobrým programátorom, musíte rátať s tým, že musíte do toho aj niečo investovať. Využite akýkoľvek (legálny ;) spôsob, ktorým by ste prišli k nejakým drobným.

Množstvo tutoriálov pre učenie C a C++ je tiež dostupných na webe, ale zistil som, že tutoriály su lepšie na doplnenie toho, čo sa učíte z kníh než aby ich použili ako samostatné zdroje.

Výber správneho kompilátora

Program, ktorý píšete, alebo zdrojový kód, sa ukladá ako textový súbor a môžete dokonca použiť aj Notepad na písanie C/C++ programu. Ale niečo musí ten kód zobrať a prekonvertovať ho na spustiteľný súbor. V prípade C a C++, to niečo je kompilátor.

Je dostupný veľký počet kompilátorov, vrátane mnohých, čo sú zadarmo. Je dôležité vybrať si kompilátor, ktorý je pre vás pohodlný a tie zadarmo majú výhodu v tom, že ich môžete všetky vyskúšať a zistiť, ktorý sa vám naviac páči. Napriek tomu, voľne dostupné kompilátory nie sú až tak "nadupané" a podporované ako komerčné. Našťastie väčšina komerčných kompilátorov sa dodáva v demoštračných alebo akademických verziách, ktoré stoja o mnoho menej a zvyčajne majú rovnaké funkcionality ako plné verzie. Jediním obmedzením je, že nemôžete distribuovať programy, ktoré ste pomocou nich vytvorili (čo mimochodom ešte nejaký ten čas robiť nebudete).

Nakoniec kompilátor, ktorý si vyberiete bude závisieť na tom, koľko môžete investovať a pre ktorý operačný systém a platformu budete vyvíjať. Ak budete vyvíjať pre Windows, silno doporučujem Microsoft Visual C++. Má silné vývojové prostredie, ktoré vám uľahčí množstvo vecí a niet pochýb o tom, že žiadný iný kompilátor nie vhodnejší pre vývoj Windows aplikácii. Ak ste študent, môžete získať kópiu za značne zníženú cenu. Ak budete programovať v DOSe, vašou najlepšou stávkou je pravdepodobne DJGPP, ktorý je zadarmo.

Výber Cieľovej Platformy

I keď na koniec budete pravdepodobne vyvíjať pre nejednu platformu, budete si musieť zvoliť jednu, kde sa budete učiť. Zatiaľ čo sa učíte jazyk a pred tým než začnete s akýmkoľvek programovaním zahŕňajúcim grafiku, budete asi chcieť použiť nejaký operačný systém bez GUI, ako DOS alebo UNIX. Týmto sa vyhnete takým veciam ako napr. Windows programovanie a umožnia vám zamerať sa na učenie jazyka.

Akonáhle ste pripravený začať tvoriť hry, mali by ste zvážiť zmenu vašej cieľovej platformy. Pozrime sa na najprominentnejšie voľby.

Windows: Ak prípadne chcete pracovať profesionálne v hernom priemysle, alebo ak len chcete, aby si veľa ľudí mohlo zahrať vašu hru, potom toto je platforma, ktorú si chcete vybrať. Väčšina cieľového obecenstva používa Windows a v najbližšej dobe sa to nezmení. Drvivá väčšina dnešných hier je urobená pre Windows pomocou technológie, o ktorej ste pravdepodobne počuli pod názvom DirectX. DirectX je knižnica, ktorá vám umožňuje pristupovať priamo k hardvéru, čo znamená, že môže písať vysoko výkonné hry.

DOS: DOS bol pre hry dominantnou platformou, ale tie časy sú preč. I keď nejakí nadšenci stále tvoria hry pre DOS, žiadne komerčné hry sa pre DOS nerobia a bude stále na ústupe ako ho Microsoft prestane podporovať. Ak len začínate s tvorbou hier, DOS si nevyberajte, alebo ak aj áno, tak nie na dlho. Poznámka: pretože existuje veľké množstvo kníh o programovaní hier napísaných špeciálne pre DOS, vývoj hier pre DOS môže byť celkom dobrým ospravedlnením počas štúdia týchto kníh. Ale na druhej strane, keďže množstvo kníh pre programovanie hier vo Windowse rastie, tento argument stráca stále viac na váhe.

Linux: Linux je variant UNIXu, ktorý sa stal v poslednej dobe stal veľmi obľúbeným pre množstvo dôvodov vrátane stability, ceny a postoju proti Microsotu. I keď počet užívateľov Linuxu je stále relatívne malý, entuziasmus ktorý ho obklopuje a potenciálny rast trhu z neho činí realizovateľnú voľbu ako cieľovej platformy.

Macintosh: Mac má veľmi oddaných následovníkov v množstve, ktoré nie je zanedbateľné a takmer každý Mac nadšenec, s ktorým som sa rozprával vyjadril túžbu pre viac lepších hier pre Macintosh. Nevidel som až toľko zdrojov pre tvorbu hier pre Mac, ale som si istý, že existujú, takže toto môže tiež byť dobrá voľba.

Konzoly: Trh konzolových (napr. Playstation, N64, Dreamcast, atď.) hier je obrovský a vo vývoji hier pre konzoly je jasná budúcnosť. Avšak vývoj konzolových nier v nekomerčnom prostredí nie je v tomto čase možný, dôvodov je niekoľko. Ak budete vyvíjať pre konzoly, bude to pravdepodobne počas zamestnania v nejakom komerčnom hernom štúdiu.

Poďme na dobré veci!

Teraz čas podiskutovať o tvorbe hier. Pre ziednodušenie, budem predpokladať, že ste si vybrali programovanie v C/C++ pre Windows, i keď vačšina toho, čo budem hovoriť, bude aplikovateľná aj keď ste sa rozhodli inak.

Zo všetkého najskôr, ešte pred tým než budete pomýšlať nad začiatkom tvorby hier, mali by ste dobre rozumieť C a C++. Mali by ste rozumieť pointerom, poliam, štruktúram, funkciám, a možno triedam a mali by ste ich vedieť zbehlo využívať. Ak je tak, ste pripravený začať s tvorbou hier.

* Zožente si jednu alebo viacej kníh. Pre začínajúcich programátorov hier vo Windows, Tricks of the Windows Game Programming Gurus je perfektným miestom pre začiatok. Prečítajte si knihy, vyskúšajte si všetky príklady a prečítajte si znovu časti, ktorým nerozumiete.
* Doplňte si to, čo čítate online tutoriálmi. Ujasňujú veci, ktoré ste čítali, ale aj pokrývajú témy, ktoré nie sú v knihách zahrnuté.
* Požiadajte expertov o pomoc. Ak nedokážete nájsť odpovede na vaše otázky v knihách a tutoriáloch, využite naše fórum. Je veľa ľudí, ktorí vám budú chcieť pomôcť.

Na toto by sa nemalo pozerať ako na postupný proces, ale ako súbežný proces, ktorý sa nepretržite opakuje.

Ale nestačí sa len učiť, musíte tiež aplikovať to, čo ste sa naučili. Začnite s malou hrou a pracujte na nej. Pozrite si článok Geoffa Howlanda, Ako Mám Robiť Hry? Cesta k Vývoju Hier (zatiaľ len v angličtine).

Najskôr plánujte s tým, že budete pracovať sám. Nenáhlite sa do žiadneho tímu, pretože to iba spomalí proces učenia. Akonáhle budete mať na konte niekoľko hier, tým viac môžete prispieť do týmu.

Jedna vec, ktorá sa týka kníh:Budete musieť prečítať viac než len knihy o programovaní hier. Aby ste boli schopní vytvoriť také hry, ktoré vidíte na predajných pultoch, budete sa musieť ponoriť hlbšie do pokročilejších tém než tie, ktoré sú pokryté vo väčšine kníh o programovaní hier. Niečo z toho čo potrebujete sa dá nájsť v tutoriáloch, ale tiež si budete musieť vybrať knihy o grafike, umelej inteligencii, sieťach, fyzike atď. To sa vám veľmi zíde pri snahe o získanie diplomu z informatiky, pretože budete musieť chodiť na prednášky, o ktorých si môžete myslieť, že sa na programovanie hier nevzťahujú, ale opak je pravdou.

Zhrnutie

Niečo málo tipov, ktoré môžu znamenať obrovský rozdiel:

* Vedomosti len nezhŕňajte, použite ich. Nikde nebudete skutočne vedieť alebo rozumieť niečomu, čo ste nepoužili. Urobte malý demo program, ktorý využíva veci, ktoré sa učíte. A robte si cvičenia na konci kapitol v knihách.
* Hrajte veľa hier. Ak tak učiníte, získate nové nápady a pomôže vám to k tvorbe lepších hier. Taktiež si oddýchnete od programovania.
* Pomáhajte iným. Dostanete sa do bodu, kedu budete môcť pomôcť iným a učením iných sa naučíte viac.
* Dokončite to, čo ste začali. Nepodľahnite pasci myslenia "Viem, že dokážem dokončiť túto hru, ale mám nápad na lepšiu, takže radšej sa budem venovať jej." Naučíte sa veľmi veľa ak dokončíte hry, ktoré ste začali a budete mať niečo ako dôkaz, že nie ste len samé reči. Aby ste si to uľahčili, neskúšajte urobiť veľké a zložité hry až kým nenaberiete skúsenosti.

Nech sa páči! Teraz by ste mali byť na dobrej ceste za Quake 5. Nuž, nie celkom, ale prinajmenšom môžete na tej ceste začať a viete kde hľadať viac informácii a s rokmi tvrdej práce to môže byť realita.