Scuze de hijack Bobos...
Nu, nu fac nici un efect... Poate am noroc si dispare de la sine cum a si aparut. (nu era de la inceput)
Btw, demo e ala cu fire exit ?
Da.
Deci sa-l folosesc pe engin sau nu? Mentionez ca mi-ar placea cand tremin facultatea sau dupa cativa ani dupa ce o termin sa ma angajez macar ca programator junior la o firma de gamedev (deci sa zicem peste 4-5 ani maxim). Pana atunci is multumit unde lucrez.
Pai trage singur concluziile; dar m-am gandit putin, si uite ce recomand eu: nu folosi un engine, si
nici nu te apuca sa faci unul.
Uite o chestie care sa petrecut alaltaieri: jocul nostru (ultimul demo la care lucrez acu) e un fel de "cross-breed" de sidescroller cu grafica 3D, in care lumea nu e fixa pe o axa, ci e definita de un 'spline'. Cand ne-am apucat sa implementam, ne-am trezit ca oFusion nu ne lasa sa exportam spline-uri, in varianta sa gratis, si nu aveam $700 deocamdata sa aruncam aiurea doar pentru un exportor, pt ca bugetul si asa strans a fost deja stabilit pentru tot anul. (ar fi ridicol oricum, ca si asa tot cam pe atat am dat pe licenta de Max, acu platim aceasi suma pt un
exportor...
)
Asa ca ne-am apucat, eu si colegul meu Richard, sa gasim un hack prin care sa ne salvam buzunarele. Prima data am venit eu cu idea ca ar merge sa transformam in Max spline-ul intr-un mesh, si in joc luam vertecsii la rand si reconstruim un spline din alea. Desigur, sa pus problema: daca nu exporteaza vertecsii in ordine? Dupa un scurt test am aflat ca oFusion defapt nu exporteaza deloc vertecsi care nu apartin unui triunghi (ceea ce e un lucru bun)... deci idea a cazut.
Apoi ne-am gandit la un hack si mai si: oFusion asta stie sa exporteze animatii keyframe, asa ca am pus un obiect pe acel spline in Max, si i-am zis sa se plimbe de la un cap la altul al spline-ului (keyframe animation sau asa ceva, nu sunt sigur). Am setat numarul de frame-uri la ceva mai mare (1000), si ce sa exportat sunt defapt 1000 de sample-uri de-a lungul spline-ului.
Totul se duce in XML, asa ca a fost relativ usor sa reconstruim un spline in joc din acele sample-uri, si a mers de minune!
(Toate astea s-au intamplat pt ca ne-am decis ca nu avem timp sa terminam editorul ala C++/CLI la care am lucrat eu 3 saptamani)
Acum, morala e ca noi am stat ore in sir discutand ca prostii tot felul de teorii, cand defapt problema sa rezolvat de la sine in 10 minute o data ce ne-am apucat sa lucram la ea. Sa rezolvat deoarece solutia sa definit din limitarile impuse, nu din zecile noastre de teorii. A, si in joc, a constat in sub 200 de linii scrise in vre-o ora, cu pauza de rigoare pt o tigara, ca deh is lenes din fire. (cu tot cu o implementare de spline proprie, nu dobitocenia aia care vine cu Ogre)
By the way, daca in loc sa ne fi dat in filozofii de cum sa construim editorul (atat tehnic cat si estetic), ne-am fi prins de la inceput ca tot ce ne trebuia puteam sa facem si noi ca un layer peste Max. (Max te lasa sa pui optiuni text per obiecte, de ex sa scrii in proprietatile obiectului:
whatever=x
foobar=y
Si asta ar fi ghidat un exportor propriu.)
Asa ca nu te intreba "ce pot sa fac", "ce posibilitati am" (am mai avut noi si vre-o alte 20 de variante cum sa pacalim oFusion), pt ca o sa te tina ocupat pana la Craciunu' viitor, ci "care imi sunt limitarile?" si "care imi e scopul?".
Nu sta cu Ogre ca e o gluma de prost gust. Si nu te apuca sa faci un engine 3D pt ca... nu iti trebuie! Te gandesti la ce vrei sa-ti iasa, (faci o schita a jocului cum ar veni) si
rezolvi probleme care te tin sa-ti atingi scopul ala.
Primele sunt alea tipice: ca sa rendezi ceva iti trebuie o fereastra, bun, intrii pe directxtutorial.com si gasesti imediat un snippet cum sa creezi o fereastra in Win32. Apoi initializezi Direct3D. Prima chestie care o vrei este sa ai un model 3D in lumea ta. Incepi cu cel mai simplu caz: iti trebuie un vertex si un index buffer. Definesti nistre structuri/clase apoi dai o fuga pe blender.org, descarci Blender si iti scrii un exportor. Eu primul meu exportor care l-am scris a fost in Blender, cu Python, si a fost FOARTE usor si placut de scris. In 2 ore a fost gata. Paremi-se ca gasesti screenshot-uri pe undeva pe forum, posibil la unul din devlog-uril mele mai vechi.
Observi o diferenta? In Ogre, un 'engine', ai tot felul de balarii: VertexDeclaration, BufferBindings, si alte minunatii care tie efectiv
nu iti trebuie. Nu acum cel putin. O sa ti le scrii cand o sa ai nevoie de ele, si cand o sa ai nevoie de ele,
atunci o sa (iti) fie clar si simplu cum sa le faci.
De aici in colo, ce faci depinde de jocul in cauza.
Eu nu am reusit sa scriu un shader timp de un an cat am avut calculator modern pana nu a venit cineva la mine si mi-a zis sa fac ceva precis. Si na ca in 2 zile am avut primu meu shader. Nu perfect, dar merge.
Can't stress this enough: nu incerca sa faci un engine, tu/eu vrei sa faci un joc, asa ca fa un joc si gata
A fost putin dezamagitor tot procesu, apropo, pt ca nu e deloc cum ma asteptam sa fie: nici o tehnica smechera sau nimic "magic" - pur si simplu totul a fost 'straight-forward', si nu a fost problema care nu sa putut rezolva in mai putin de o zi.
Intelegi unde merg cu idea?
Oricum e evident: nici unul din noi nu e experimentat cu 3Du', asa ca e cam ridicol sa ne dam in teorii cum sa ne construim enginu', nu?
Mai bine lasam cerintele si problemele sa ne ghideze, ca pana acum au facut o treaba a naibii de buna pt mine
Ca sa scap de termenul de 'engine', o sa ii zic 'codul'; ei bine, codul nu trebuie sa fie un Framework, Mare, si Oficial, cum ti-l serveste Ogre spre exemplu. Trebuie sa mearga bine, si atat! Chiar nu e tocmai critic sa treci prin 7 clase si un extra DLL ca sa initializezi o fereastra. Spre exemplu, pana sa ajungi la o fereastra neagra D3D, Ogre trebuie sa treaca prin clase ca RenderWindow, RenderSystem (+implementare), Camera si Viewport, fara sa mai pui la socoteala un SceneManager din care face parte acel Camera. Faci pariu ca sunt doar layere peste layere la EXACT acelasi cod care il gasesti pe directxtutorial.com? Doar ca Ogre, daca te uiti la codul sursa, trebuie sa se ingrijoreze si de bietele cazuri in care calculatorul nu suporta hardware vertex processing, sau nu suporta un stencil buffer de 8biti. Noi ne permitem sa fim nesimtiti si sa zicem "don't use your grandma's computer", si ne-am spalat pe maini. Cum poti sa spui ca asemenea chestii sunt "critical features" pt un DEMO?
Aceasi chestie cu texturile... nu trebuie sa fie o subclasa a clasei Resource care e copilu' lui ResourceManager, si care apartine unei anumite grupe din ResourceGroupManager. Si nici nu trebuie sa ai un scene graph, si nici nu trebuie sa dai un nume la fiecare entitate care o creezi.
Si cea mai banala chestie care e utila intr-un joc: logging. Pana si asta trebuie sa para complicat in Ogre. Ei trebuie neaparat sa aibe un LogManager, o clasa Log, LogListener, si alte minunatii.
Da-i mai in jos un pic la codul care il folosesc eu pt un side-project in C, si te asigur ca face exact aceasi chestie, cu exceptia timestamp-ului care oricum nu ma incalzeste cu nimic.
Ohhh, 15 linii sau asa ceva. Clar, munca de amator!
Din vre-un motiv ciudat nu am simtit nici o motivatie sa scriu de 10 ori pe atat pentru acelasi rezultat... Si daca vreodata o sa am nevoie de un listener pt log... o sa scriu
atunci acele 4-5 linii in plus. Pana atunci eu chiar dorm linistit noaptea, cand vine vorba de proiectul asta secundar.
Deci sfatul meu personal e, nu mai pierde vremea cu "engine-uri", scrie
jocul, si gandeste-te la chestiile legate de 3D doar ca la un "inconvenient" de care nu poti sa scapi
Lasa jocul sa dicteze ce trebuie sa faci, nu invers. (enginul)
Alea (3D stuff) sunt una din chestiile care iti opresc ideea de joc sa se materializeze. Scrie-ti jocul cate un feature pe rand, si sa vezi cum creste intr-o zi cat 10 MMO-uri intr-un an. (apropo, dupa 8 ani in development, au lansat Demo-ul 3 al
PlaneShift... heh)
Anyway, ca un fel de personal note de incheiere, am trait mult si bine, pana de curand, cu impresia ca daca imi construiesc Cel Mai Fabulos Engine, (incluzand editor si toate cele), atunci jocul meu o sa se scrie de la sine. Ah, si e pe fix pe invers...
Cum curg cerintele jocului pe masa mea, asa se scrie engine-ul jocului meu de la sine. (pt ca dupa cum am spus, Ogre e doar un layer nesimtit peste D3D/GL, si tot ajungi in pozitia in care trebuie sa faci tu, fericitul utilizator Ogre3D, orice e util in joc)
Putine sunt adevaratele chestii utile din Ogre. Spre exemplu, codul care optimizeaza ordinea vertecsilor dintr-un mesh ce foloseste index buffers astfel incat sa 'dea' in cache cat mai des. Ultima data cand m-am uitat, bucata aia de cod nu trecea prin nici un framework magic... Ce chestie, huh?
Anyway, cu "un feature pe rand" (eu chiar am un 'policy' de un feature nou pe zi, altfel, er, imi iau o zi libera pt ca
evident nu sunt in forma de nu programez destul de bine
) ai tot ce iti doresti: jocul creste vazand cu ochii, deci moralul e sus-sus, (ma intrebam eu de ce am ratat chiar atatea proiecte... nu era pt ca eram eu un programator prost... ci ca eram un programator naiv), si ca bonus, 'engine'ul se scrie de la sine.
Apropo, cat despre partea comerciala a engine-urilor, am auzit de pe la conferinte ca majoritatea prefera (cel putin aici in Australia) sa-si scrie singuri chestiile principale, ie: enginu 3D.
In plus, renderingul nu e tocmai singura ta grija cand scrii un joc, mai ai fizica, AI, integrare, scripting si altele, deci lasa engine-u sa fie 'scurt si la obiect' si ocupa-te de chestiile cu adevarat importante intr-un joc.
Ptiu, cata' rant'u...
PS: scuzi eventualele greseli gramaticale, la mine sa facut deja cam tarziu.. Si sunt sigur ca am vrut sa spun ceva dar am uitat sa zic....
. Bine, cu cod cate de cat structurat ..
