3D Game Studio
De vreo luna tot citesc documentatie de la 3D Game Studio al Conitec. La inceput mi-a placut fiindca nu am inceput cu manualul ci cu o serie de tutoriale foarte simple (liteC.chm), explicite, din care intelegeai tot fara efort, natural. Apropo, au fost scrise de George Pirvu - un colaborator al Conitec. Apoi am trecut la manual (nu este scris de el). Aici au inceput perii albi sa-mi iasa. Scris anbiguu, ce referiri la notiuni neexplicate anterior sau neacoperite in intregime. Plus ca daca intampini o exceptie de la regula, o bagi la cap si treci peste. Apoi vine alta si alta si vrei sa le scrii undeva. Dar apoi realizezi ca un sfert din manual reprezinta exceptiile de genul daca flagul 1 este setat dar nu si flagul 3, atunci flagul 4 trebuie resetat caci nu merge combinat cu umbrele dinamice cand bbox-ul nu este definit. Ce ati inteles voi am inteles si eu. Ei, am dat un exemplu fictiv. Tot notezi si notezi pana te saturi. Plus se vede ca s-au grabit cu manualul. Sunt greseli MULTE de tipar si iti scade increderea si cheful de a mai citi (I HATE TYPOS BTW, unde nu este nici Dumnezeu nu cere dar la programatori am pretentii). Daca iti aduni energie sa mai continui, daca te mai lovesti si de greseli in snippet-urile exemple, chiar ca citesti cu indoiala ca nu cumva sa inveti gresit.
Alt minus ar fi limbajul lite-C. In opinia mea, limbajul a fost gresit conceput. Este f. asemanator cu C si C++ numai ca "vine in intampinarea" userului cu niste "facilitati" de genul:
- enginul detecteaza singur daca intr-o expresie un operand este variabila sau un pointer catre ea. Deci nu trebuie sa mai folosesti &. Va dati seama ce sursa de bug-uri cand folosesti ca argument un pointer intr-o functie care ar trebui sa lucreze cu o copie a variabilei.
- o variabila, de ex. 'pan' poate fi passed ca argument unde se asteapta un vector (struct - grup de 3 variabile).
- si ca sa fie si mai... challenging, in anumite cazuri trebuie sa respecti regula de a face distinctie intre pointer si variabila fiindca altfel - crash!
A, si poti initializa in declaratie doar variabilele. Arrays nu, structs nu stiu dar struct pointers nu, daca sunt locale.
Lista poate continua.
Partea buna e ca (zic eu) au facut rabat la claritate si workflow pentru a castiga performanta. Aici nu pot sa ma plang. 9 view-uri cu zeci de mii de instances in 30 FPS e... ce ma mai tine cu gandul la 3D Game Studio. Dar e crima, fratilor. Plus ca e cam odios, fata de

Torque 3D
Are interfete prietenoase ca editoarele wysiwyg, in care bifezi niste check-uri, si gata ai materialul. In 3DGS scrii la cod... si asta fara sa vezi rezultatul. Ma gandeam sa trec pe Torque. Toate bune si frumoase dar are probleme cu librariile de functii gen 'move to mouse clicked position'; nu prea... exista. Am inteles de pe un forum ca a fost conceput cu FPS in minte si ca pt. a crea un RTS (ce vreau eu) trebuie sa modifici enginul. Acuma, eu sunt incepator in programare, vroiam sa folosesc functiile built-in de manipulare a mousului, pozitiei, instantelor etc. Am gasit pe un alt site un snippet de zeci si zeci de randuri numai pt. 'move to mouse clicked position'. Freakin.
Partea buna e ca suporta HDR si SSAO ceea ce nu am vazut la 3DGS.

Acum, alta intrebare, de fapt cea mai importanta si va rog sa-mi raspundeti daca folositi Torque sau aveti idee:
"More importantly, nearly all of your game play programming will be written in TorqueScript: inventory systems, win/lose scenarios, AI, weapon functionality, collision response, game flow." TorqueScript este un limbaj high level interpretat la run time. Nu e nevoie sa recompilezi dupa o modificare. Thanks but no, thanks. Nu vreau sa invat un limbaj nou cel putin daca nu e la fel de rapid ca un cod nativ C++. Si acum intrebarea propriu-zisa: de cate (zeci de) ori este mai lent un limbaj de scripting fata de unul pre-compilat (C++)? Eu tin f. mult la viteza din simplul motiv ca la un limbaj rapid pot incarca procesorul mai mult la acelas pret cu un script. Si cum prefer jocurile s u p e r - complexe...

Pentru a-ti raspunde la intrebare iti recomand capitolul 4 din aceasta carte:

http://books.google.ro/books?id=W_ChoAN4AboC&pg=PA97&lpg=PA97&dq=is+torque+script+slower&source=bl&ots=WYveIIs6AD&sig=BtU7yfuToVy0fjNs8WxEn2XRLRw&hl=ro&ei=R5EFTK3ZI5CCONrmjYYF&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBQQ6AEwAA#v=onepage&q&f=false

Chiar la inceput se abordeaza intrebarea: "to script or not to script?"

Am citit. Sincer, in afara a doua chestii cu care de altfel Torque recupereaza, sunt foarte reticent; ma asteptam la mai mult
Pe site nu prea gasesti despre ce stie Torque sa faca in materie de fizica sau game mechanics. Bad advertizing sau nu are ce sa arate? Mie imi plac lucrurile clare si sistematizate. Uite o descriere a lui C4 Engine, care din prima mi-a incantat sufletul si care m-a scutit si de pierdere de timp: http://www.terathon.com/c4engine/features.php , dar la care totusi nu m-am oprit. De ce? Pt. ca mi s-a parut lent. Singurul motiv. Torque tot da inainte cu *suportul* pentru 3rd party PhysX dar si asa, NVidia ocupa cel mult sa spunem 60% din piata video cardurilor. Sa spunem ca trec peste si imi fac motorul de fizica si celelalte, singur. Dar ce fac cu TorqueScript? este type insensitive?! case insensitive?!
Gandul ca trebuie sa-l folosesc in masura de 80% ma sperie.
OK. Hai si cu cele doua chestii bune de la inceput:
1. Poti face jocul chiar 100% in C++. Asta e un mare "whew" pt. mine. Nu ca as sti prea bine C++, ca nu stiu, dar scap de obligativitatea scriptingului. Ma repet, tin enorm la viteza de executie. M-as casatori cu ea dar am deja pe cineva.
2. Accesul la codul sursa.
Deci marele atu al Torque este posibilitatile nelimitate. Marele dezavantaj este ca trebuie sa cam pui osu' la treaba si la chestii simple cum ar fi "move to mouse click". Caile de realizare a unui joc in Torque mi se par a fi doua: una usoara (si nu prea) prin script si alta f. grea prin modificarea enginului. Mai, e bine ca sunt doua, nu?

Dar intrebarea (retorica) este: as putea sa compar d.p.d.v. al performantei doua jocuri similare, unul facut in Torque, celalalt in 3D Game Studio?

Fiecare engine are partile lui bune si rele. In cele din urma se ajunge la preferinte. Incearca-le pe amandoua. Arhitectura carui engine ti se potriveste? Care ti se pare mai programmer-friendly? Dar cu mai multa libertate pentru developeri? Apoi compara experienta generala pe care ai avut-o cu fiecare in parte. Din pacate e singura solutie, pentru ca daca o sa ii intrebi pe altii ce prefera, de cele mai multe ori o sa devi si mai confuz.

3d Game Studio e "cam" invechit.
L-am vazut prima oara acum app 6-7 ani si i-am mai urmarit evolutia de cateva ori pe an pana acum.
Primul contact cu el a fost un esec total. Al doi-lea contact tot un esec dar am inceput sa inteleg de face engiul si editorul. Am renuntat total. Si nici nu are versiune Free for non commercial.
Un engine indie ff "smecher" este NeoAxis.
Minusuri:
-updat-uri la engine cam micute pt ca este dezvoltat de o manuta de oameni cu un singur programator.
- poate faptul ca sdk-ul este in C#
Plusuri:
- Ogre + PhysX + DirectSound
- Editor ff intuitiv cu modificari realtime.
- Cod complet pt tot gameplay-ul care ti-l ofera enginul chiar si pt ver free for non comercial
- Codul si enginul este explicit gandit si scris pt game-play = eform extrem de mic pt a face un joc functional fata de alte engine-uri (la acest capitol sta mult mai bine ca UDK-ul)

Acum folosesc UDK-ul:
Minusuri:
- iti ia mult timp sa te obisnuiesti cu Unreal Script-ingul
- fiind fff complex iti ia destul timp sa te deprinzi cu el si sa ajungi la punctul in care poti zice: da pot face asta doar necesita timp
Plusuri:
- engine si editor f puternic
- stabil
- update-uri constante
- pot face debug in Visual Studio pe codul scris in unreal script cu ultima versiune de nFringe (configurata corect )
- licenta actuala e ff incurajatoare pt independenti (cost initial de $99 si 25% royalty daca/cand proiectul depaseste $50,000)

A nu se uita Unity, care desi nu are flexibilitatea lui UDK, e mai usor de lucrat cu el, si as zice ca e mai bun ca torque. Unity, ca si UDK, e mai aproape de ce ai numi "authoring tool", ceea ce e bine pentru echipe foarte mici care vor sa faca un joc repede. Daca vrei sa programezi in cod nativ exista multe alternative. Eu de exemplu am o licenta de C4, dar sincer nu m-as apuca de facut un joc in el de unu singur, sau cu o echipa de doi oameni, ar fi prea mult de lucru.