Sper ca e ok aici topic-ul, daca nu mutati-l.

Asadar, dupa multe zile de gandire, m-am gandit sa fac si eu un motor de joc ca sa invatz sa programez anumite aspecte de care nu te poti lovi niciodata daca programezi jocuri folosind motoarele altora.

Dupa vreo doua saptamani de research si bataie de cap cu design-ul, am ajuns la concluzia ca nu pot face design la ceva atat de generic, si am nevoie de un joc pentru care sa fac engine-ul in prima faza, un proiect cu feature-uri clar definite si use case-uri clar definite.

In concluzie, acum lucrez la specificatiile jocului, din care mai apoi sper sa pot identifica si proiecta toate componentele engine-ului (de fapt singura diferenta fatza de un joc "fara engine" e ca voi incerca sa proiectez componentele pentru a putea fi reutilizate).

Un alt obiectiv este ca acest engine sa fie pregatit pentru portarea pe alte platforme, chiar daca initial va rula doar pe windows folosind DX in mare parte.

O alta decizie (in scopul invatarii, ca deadline nu am) este de a integra cat de putine 3rd party libraries si de a implementa cat pot de mult de unul singur (fara sa imi pierd motivatia sper ).

Am postat aici pentru ca am vazut ca exista cativa care s-au apropiat de final cu un astfel de task gigant (de a face un game engine) si vroiam sa va rog sa imi dati orice sfaturi legate de proiectarea unui astfel de motor. Ce metodologii ati folosit, ce probleme ati intampinat, etc....

Merci.

vrei sa faci engin de fizica?, de grafica, de networking, de sunet, de AI, etc..

da, iti recomand sa utilizezi totusi 3rdparty, daca vrei sa il termini secolul asta.
E foarte bine ca ai ales sa faci un joc intai si apoi engine, lucrul la un engine generic te poate duce spre zari in care te pierzi, fara un tel anume.

@nekitu

Pai pentru ca e gandit modular, oricand o sa pot folosi 3rd party intr-un loc sau altul, dar pe cat posibil as vrea sa fac cat de mult pot de unul singur . Ma gandeam ca probabil o sa folosesc un motor de fizica existent, probabil SDL pentru input, ceva pentru sound, dar nu stiu daca exista free, din astea, dar partea de grafica vreau sa o fac singur, la fel si editorul si alea alea. Stiu ca ar fi mai usor sa folosesc direct Ogre3d, dar vreau musai sa invat eu cum se face . O alta parte pe care vreau neaparat sa o fac singur este cea de networking.

Un alt drum pe care as putea sa il iau este sa integrez tot ce gasesc (cum face de ex yake si alte engine-uri comerciale care de fapt se bazeaza pe o tona de librarii free), dar integrarea sa se faca folosind un set de interfete, iar mai apoi sa inlocuiesc modul cu modul pe masura ce avansez.

Tu ce 3rd party ai folosit in al tau?

@pin46

Nu de toate, doar ce are nevoie jocul. In cazul asta nu are nevoie de fizica, doar simple collision detection, nu are nevoie de AI, dar are nevoie de networking (ca e multiplayer), randarea va fi initial in DX (9 probabil, PS 2.0), iar apoi probabil a fi si un opengl in viitor.

Cel mai complicat mi se pare de facut scene graph-ul si terrain engine-ul, dar probabil pentru ca inca nu am incercat niciodata sa fac asa ceva.

O alta mare nelamurire este daca sa folosesc sau nu D3DX pentru partea de matematica. Stiu ca daca va fi sa il portez pe alte platforme o sa trebuiasca sa imi fac propria librarie, da ma gandeam ca initial o sa fie o interfata de functii matematice generice, vectori, matrici, etc, iar in spate D3DX, si pe urma si o implementare proprie, cu timpul.

Vezi ca s-ar putea sa n-ai nevoie de asa ceva (unii fac apoplexie doar cind aud termenul). Fiecare intelege ce vrea prin "scene graph", dar probabil iti va fi mai simplu sa ai mai multe structuri de date cu informatii despre scena, nu una. Cum zice si Forsyth acolo, daca incerci sa folosesti acelasi graf si pentru occlusion culling, si pentru collision, si pentru separat in pasi de randare, si pentru state changes, si pentru animatie, o sa-ti iasa un dezastru. Am vazut scene graph-uri care contineau scheletele personajelor, sau grafuri care contin noduri de materiale si texturi, care-s folosite si pentru frustum culling. Era groaznic.



Pictatul terenului pe ecran este o treaba destul de simpla in principiu. Exista niste gotchas daca te arunci la smecherii gen megatexture, proiectii neuniforme sau blenduit brush-uri in shader in loc de pictat multipass, dar nu-s insurmontabile. La editatul terenului o sa ai mai mult de munca, dar la nivel de baza e doar inginerie si UI. Daca vrei sa incluzi si generare si alte mizerii d-astea, o sa fie mai complex. Daca vrei sa-i faci si streaming, in principiu e iar usor, in practica poate deveni delicat daca ai foarte multe date de streamuit (cum se intimpla la megatexture, de exemplu).



Nu prea vad cum ai putea sa faci o interfata generica pentru vectori si matrici. O biblioteca minimala care sa adune vectori si sa-i inmulteasca cu matrici se scrie in 10 minute. Dupa aia iti mai ia 10 minute sa copiezi de pe net niste cod pentru quaternioni si inversat matrici si gata. In 20 de minute ai scapat de durerea de cap cauzata de implementarea unui wrapper peste D3DX, plus aia cauzata de reimplementarea wrapper-ului pe alte platforme (unde n-o sa se potriveasca, deoarece vei descoperi ca wrapper-ul generic nu era suficient de generic).

Se intimpla foarte rar ca biblioteca de mate sa fie un bottleneck, asa ca nu prea conteaza ca D3DXMatrixMultiply() foloseste SSE593 iar operatorul scris de tine nu. Daca totusi devine o problema, iti ia inca 10 minute sa cauti pe net o versiune optimizata si s-o bagi acolo. La fel si pentru diverse functii mai ezoterice de care ai putea avea nevoie la un moment dat. In orice caz, nu cistigi mai nimic optimizind adunarile de vectori cu SSE, chestiile astea se fac altfel (in schimb pierzi destule chestii daca incerci, de exemplu faptul ca trebuie sa aliniezi totul la 16 bytes inseamna ca n-o sa poti sa scrii in fisiere vectori d-aia cu care opereaza biblioteca de mate).

In plus, daca scrii o biblioteca de mate a ta poti sa folosesti conventii de oameni, nu de animale (cum ar fi faptul ca vectorii sint coloane si se inmultesc la dreapta matricilor, nu fix pe dos ca-n D3DX).

Sa sti ca ai dreptate la partea asta. Ma gandeam eu ca trebuie sa fie ceva alternativa. Am citit de curand o carte, 3D Game Engine Architecture, pe care a scris-o un tip despre ceva engine free pe care l-a facut el. A scris 3 carti si 3 vesiuni ale engine-ului (WildMagic sau asa ceva). Si la partea cu scene graph-ul totul a fost ok (parcurgem de la radacina la varfuri pentru transformari si state-uri, parcurgem de la varfuri la radacina pentru frustum culling, etc), pana a ajuns tipul la includerea terenului si a animatiilor (scheletelor) in graph. De acolo incepand a fost strutzo-camila, si eu am inceput sa nu mai inteleg mare branza.

Ideea de a avea un sistem de structuri care permit tot felul de parcurgeri si de grupari mi se pare foarte interesanta, si cred ca o sa ma gandesc la un sistem in genul asta, mai degraba decat la strutzo-camila .




La teren o sa vreau ceva simplu, bazat pe heightmaps, fara alte artificii, cel putin initial, nici macar streaming in prima faza, dar o sa-l proiectez astfel incat sa se poata adauga astfel de features ulterior.


La partea cu matematica, cred ca ai dreptate, asa o sa fac. Am observat si eu anomaliile cu ordinea inmultirii, si am mai observat ca math-ul din D3DX e si dubios cu privire la organizare, in sensul in care are o gramada de functii si cateva structuri, nu prea e object-oriented, iar eu asa as dori sa il am, mi se pare mai elegant si mai usor de folosit.

Legat de SSE chiar vroiam sa intreb asta, dar vad ca m-ai lamurit "in avans", merci.


Si acum o intrebare noua: Am nevoie de memory manager custom sau nu? Din cate am citit, fragmentarea memoriei nu e o asa mare problema pe sisteme cu management de memorie virtuala bun, dar este o problema pe alte platforme, cum ar fi telefoanele mobile si consolele. Alocarea in sine iarasi am inteles ca e o operatie costisitoare, dar nu stiu daca se merita doar pentru atata, avand in vedere ca natura jocului presupune ca majoritatea instantelor de obiecte sunt create la inceput si distruse la sfarsit, doar putine sunt create real time.

Am citit destul de mult despre cum se face memory managementul, si am o idee generala despre asta, dar nu stiu daca este un bottleneck sau nu intr-un joc FP multiplayer cum este acesta.

Ala e Eberly, care a fost sef pe la NetImmerse si Gamebryo. Nu-i deloc un habarnist, dar cartile alea vin din alta era. Intre timp lucrurile s-au mai schimbat. Am citit si eu una din editii (a treia, parca) si mi s-a parut destul de irelevanta pentru mileniul curent.



Vezi ca in practica n-o sa ai nevoie de un sistem flexibil pentru asta. Probabil o sa ai nevoie de o structura specializata pentru fiecare chestie majora si atit. Nu te apuca sa gindesti sistemul "in general" inainte sa vezi ce trebuie sa faci de fapt cu el.



Nu cred ca o sa reusesti. Cred ca va fi mai simplu sa-l refaci cu streaming sau ce o sa vrei sa pui in el cind va fi cazul, decit sa te apuci acum sa-l faci extensibil. Daca n-ai mai facut asa ceva, e foarte probabil sa-ti scape chestii cind il faci prima data si sa observi ca extensibilitatea pe care ai proiectat-o nu te lasa sa extinzi ce-ti trebuie de fapt.



Nu fragmentarea e marea problema, ci cit dureaza sa faci alocari. E adevarat ca daca scrii cod disciplinat n-ar trebui sa ajungi sa ai multe alocari per frame, dar depinde cit de dinamic e environment-ul tau. In Quake 3 se fac zero alocari per frame pentru ca n-ai ce sa aloci in afara de citeva sprite-uri, proiectile si gib-uri, care traiesc foarte putin si deci se pot face dintr-un pool prealocat. Intr-un MMO o sa aloci chestii, ca tot apar si dispar personaje, elemente de GUI, vraji etc. Un sistem de streaming iar o sa-ti faca alocari la runtime.

Nici la load time nu e bine sa ai multe alocari, ca o sa dureze 100 de ani sa se incarce un nivel. Am vazut personal doua jocuri carora le-a scazut drastic timpul de incarcare dupa ce s-a facut curat in alocari (unul din ele nu trecea de TRC altfel).

Acestea fiind spuse, alocarile se pot tine totusi sub control si atunci n-o sa vezi un mare beneficiu de la un alocator custom. Un alocator custom e in general o solutie cost-effective de a stoarce niste performanta cind ai o groaza de cod scris cu picioarele, pentru ca e mai ieftin decit sa repari codul. Nu-ti bate capul de la inceput, pentru ca ar fi cam "early optimization". Mai bine ai grija cum si ce aloci (genul "bun" de "early optimization"), iar daca ai totusi o problema, poti baga un alocator custom mai incolo fara prea mare efort.

Unii isi fac propriile functii de alocat memorie nu din motive de performanta, ci pentru debugging si profiling. Poti de exemplu sa obligi pe toata lumea sa aloce memorie cu o functie careia ii spui si la ce iti trebuie memoria aia, iar la runtime sa desenezi bare de utilizare pe ecran, spre bucuria tuturor. Pe de alta parte, poti obtine acelasi lucru oferind o interfata separata spre un modul de statistici, mai ales ca barele importante vor apartine citorva sisteme in care alocarile se fac din putine locuri (mesh-uri, texturi si sunete, de exemplu), deci nu e mare code bloat sa mai adaugi cite un apel la AddMemoryUsage() in locurile esentiale.

La fel ca si la SSE pentru biblioteca de mate, uneori exista oportunitati mai mari de optimizare cind privesti toata problema, decit incercind sa optimizezi la nivelul cel mai de jos, adica in functia de adunat vectori, respectiv in aia de alocat memorie. De exemplu exista cazuri cind alocarile excesive se fac din cauza unui format de fisier prost care nu-i permite codului de incarcare sa aloce de la inceput tot ce-i trebuie si ajugi sa redimensionezi vectori, sa folosesti liste sau mai stiu eu ce. Un alocator custom va rezolva o parte din problema daca face alocarile mai rapide, dar e mult mai eficient sa repari formatul de fisier, astfel incit sa se faca un singur malloc() si sa se bage totul acolo. Asta poate parea un caz trivial, dar sint destule sisteme in care trebuie sa incarci o resursa ca sa afli ce dependinte are (cum ar fi un model care spune ce texturi foloseste) si atunci ajungi exact in cazul asta. Te va ajuta mai tare sa preprocesezi nivelele offline si sa ai la runtime o lista cu tot ce trebuie sa incarci.

Eu ti-as recomanda DX10+ pentru rendering dar daca te-ai apucat de DX9 deja continua asa. The sooner you get results, the better . Faza e ca mi se pare aiurea sa te gandesti sa faci ceva pentru PS2.0 in secolul asta. Pana vei termina ce ai inceput probabil o sa apara DX12 anyway, iar referitor la portabilitate, cred ca e mai satisfacator sa ai un demo mai reusit pe o singura platforma decat unul slab pe 5 platforme.

Referitor la teren si editor, trebuie sa te gandesti daca merita sa investesti timp in ele. In loc de editor de teren poti scrie un shader cu cateva texturi de blend intre layere pe care le editezi in photoshop. Iar editor, well, am facut la editoare pana acuma de m-am saturat si am ajuns la concluzia ca n-are sens sa te apuci de un editor daca ai un engine incomplet si inca nu ai nimic playable. Doar cand te incurca faptul ca tre sa faci totul manual ar trebui sa te apuci de editor, parerea mea.

Aici e discutabil, vezi tu, tehnologia de la blizzard pe care e bazat starcraft 2 (si viitorul diablo 3), e DX9. Tehnologia din spatele World of Warcraft (care a fost folosita si pentru Warcraft 3) era DX8.1 (acum cred ca au ajuns si cu aia la 9).

In general daca vrei sa faci un joc pe care sa-l poata juca cat mai multa lume, trebuie sa te gandesti ca majoritatea inca nu au nici macar placi video pt DX10, sau calculatoare pe care sa ruleze bine Vista sau Win7 (ca fara ele n-ai DX10 anyway).

Imi amintesc ca la un moment dat am citit un interviu cu producatorul Mount&Blade, un joc indie foarte fun (dp meu de vedere), dar caracterizat de toti ca avand o grafica execrabila. Cand a fost intrebat daca o sa upgradeze grafica, a raspuns ca nici vorba de asa ceva, pentru ca o gramada de oameni din fan base-ul lor nu ar mai putea juca jocul.

Asadar cred ca initial o sa incep cu DX9, si apoi cu timpul o sa mai vad si altceva.



Parerea ta e ok, atata timp cat scopul este sa termini un joc si sa-l scoti pe piata. In cazul meu insa, scopul este sa invatz sa fac un engine, impreuna cu tot cu tool-uri, deci eu vad dezvoltarea editorului ca o oportunitate sa invatz ceva, nu ca o corvoada care ma impiedica sa termin jocul mai repede. Bineinteles, ca si date de test o sa incep cu photoshop, dar pana la urma vreau sa termin editorul inainte sa lucrez propriu zis la hartile jocului.

Merci de comentarii si sfaturi, o sa mai revin cu intrebari din cand in cand, deocamdata scriu use case-uri la greu pentru joc.

De ce nu incerci sa folosesti Api-ul DX11 ? Poti rula aplicatiile pe orice hardware de la Dx9 pana la Dx11. Singura problema ar fi ca trebuie rulat jocul pe Vista sau Windows 7 dar eu momentan am Windows 7 pe un PC vechi ( pe care a trebuit sa il curat de rugina inainte sa il bag in priza ) si merge fara probleme...

XP are inca 31% din piata in survey-ul lu' Valve, deci nu-i bine sa-i dai cu piciorul. Ce v-a facut DX9 de va grabiti sa scapati de el?

PS: totusi, nici sa te limitezi la SM 2.0 nu-i tocmai bine. Nu cred ca mai sint multi cu GF5 si Radeon 9, iar SM 2.0 te va stringe destul de repede cu limita de instructiuni, lipsa de arbitrary swizzle si asa mai departe. Nici Radeon 10 nu prea mai are lumea, deci poti tinti linistit spre SM 3.0.

Merci de sfat Dark, sa sti ca ai dreptate, cand am zis PS 2.0 nu m-am gandit pe ce placi exact ruleaza, dar daca stau sa ma gandesc cand am avut eu asa placa, au trecut muulti ani de atunci.

Eu nu sunt prea priceput cu shaderii inca, m-am jucat de cateva ori cu programe gen Render Monkey sau Fx Composer (cu ultimul am facut si eu un geometry shader, ca vroiam sa inteleg ce si cum), am mai citit despre diverse ecuatii si formule pentru iluminare de-a lungul vremii, dar per ansamblu am foarte multe de invatat despre ei, si am impresia ca a fi musai sa ii invatz inainte sa proiectez restul cumponentelor ajutatoare (de managemet al scenei etc), pentru ca mie mi se pare ca input-ul shaderilor si pasii acestora determina de fapt structurile respective si nu invers. Dar pana ma hotarasc de ce feature-uri grafice o sa aiba nevoie jocul, nu pot sa ma gandesc la shaderi.

Uite, ca tot vb de shader, mai am o intrebare:

Am vazut ca unele engine-uri (C4, Unreal) au software pentru constructie grafica de shaderi. Adica ai mai multe efecte, texturi, etc, si faci un graph frumos cu ele in care compui respectivele efecte, le pui ca input la altele si asa mai departe, pentru ca in final sa obtii efectul pe care il doresti. Are rost sa fac asa ceva? Si daca da, cam cum se face?

Ca sa se inteleaga la ce ma refer, un exemplu aici.

In orice engine din era noastra, shader-ul este elementul central al procesului de desenare. Nu mai exista fixed function, adica nu mai faci din API SetLight(), SetTransform() sau cine stie ce altceva. Ca sa pictezi un obiect, bindezi geometria, bindezi shader-ul, bindezi texturile de care are nevoie shader-ul si-i trimiti shader-ului constantele care ii povestesc ce si unde sa faca (eventual mai setezi si niste state-uri, da' ma rog). Asta e partea cea mai de jos a engine-ului si eu cu ea as incepe.

Chestiile alea in care editezi shadere conectind noduri dau bine, dar nu toata lumea e de acord cu ele. De facut se fac simplu: fiecare nod e o functie in HLSL/GLSL/Cg/whatever care primeste niste parametri si scoate niste valori intr-o structura. Cind conectezi noduri, de fapt generezi cod care cheama functiile alea si trimite valori scoase de unele ca parametri la altele. Daca vrei sa fii smecher poti sa faci pe compilatoru' si sa optimizezi ce iese, dar compilatorul de HLSL deja face asta mai bine decit tine, deci e un efort academic.

Un sistem d-asta va aduce cu sine o groaza de munca de management: cum se reprezinta un shading network d-ala in engine, cum se stocheaza parametrii introdusi de artist, cum ajung ei la codul care face SetVertexShaderConstant(), cum te asiguri ca vertex shader-ul pune ce-i trebuie pixel shader-ului in interpolatori etc. Daca nu ai grija te trezesti ca trebuie sa asamblezi si sa compilezi shadere la fiecare model incarcat, ceea ce va dura milenii. Un sistem d-asta e bun ca lasa artistii sa experimenteze, dar in productie mai peste tot vine un technical artist care face o mina de materiale pe care le foloseste dupa aia toata lumea, tocmai ca sa nu ajungi sa ai mai multe shadere decit vetecsi. Din cauza asta unii spun ca oricum ajungi la un ubershader, asa ca mai bine nu-ti bati capul si faci un ubershader de la inceput. Un ubershader e o chestie cu toti parametrii imaginabili si o groaza de checkbox-uri care specifica ce feature-uri se folosesc (cu fog sau fara, cu skinning cu 4 oase sau cu 1 os, cu SH pentru ambient sau cu ambient constant, cu normal map, cu parallax, cu shadowmap, cu iluminare per pixel sau per vertex si asa mai departe).

Chiar si cu un ubershader, nu scapi de problema ca vei avea multe shadere la runtime. Fiecare combinatie de flag-uri din ubershader genereaza un alt HLSL, adica un alt shader in engine. Poti ajunge usor sa ai mii de instante individuale (fiecare flag dubleaza numarul de shadere), si atunci incep intrebarile: le generezi dinamic ca sa mearga prost, sau le generezi offline si le pui pe DVD, ca sa-ti ia 10 ani sa recompilezi jocul?

Avind in vedere ca tu vrei sa inveti, poti incerca sa faci un sistem d-ala de conectat noduri, dar vezi sa nu te plictisesti doar scriind la editorul lui, inainte sa apuci sa scrii ceva la engine. Exista unele chestii gata facute, cum ar fi mental mill, dar nu stiu daca-ti poti scoate chestii din el intr-un mod decent (GLSL-ul pe care il genereaza e atroce, poate se poate scoate doar graful). Poti de asemenea sa faci un plug-in de Maya care genereaza noduri si te lasa sa le conectezi in Hypershade, dar e destul mult de scris, si nu-i la fel de misto ca mental mill. In orice caz, dupa ce termini distractia cu authoring-ul vei da peste o noua distractie la implementarea in engine, mai ales cind vei descoperi ca ai nevoie de versionare, ca o sa adaugi un parametru la un nod sau la un network dupa ce l-ai folosit in 50 de locuri, si va rezulta dezastru daca n-ai un sistem decent de atribute. Sint chestii banale, ingineresti, dar trebuie sa le prevezi. De exemplu, din toate soft-urile de 3D pe care le-am vazut, unul singur s-a prins cum se face, si tot nu e perfect (Maya). Restul sint de aratat cu degetul si ris.

Am facut asa ceva, dar doar in OpenGL, si pentru niste shaderi foarte simpli, dar am priceput ce sunt alea atribute si cum se "incarca" registrii cu ele, ce sunt alea constante (uniforms) si cum se incarca si ele, despre limitarile in numarul de registrii, cum se trimite output-ul de la vertex fragment la pixel fragment si asa mai departe. Doar chestii de baza, dar am o idee.


Despre sistemul cu noduri, am mai facut asa ceva cand eram student, ca si proiect la ceva materie, folosind MFC parca. In schimb nu avea nimic cu shaderii, utilizatorul putea sa specifice niste module in Lua (cu atentie la specificarea parametrilor de intrare si iesire) iar apoi programul incarca blocurile astea si puteai sa le adaugi pe suprafata de lucru, sa desenezi linii intre ele (drepte, nu curbe frumoase cum erau in poza de mai sus) si no, era un fel de "programare vizuala", cum s-a exprimat laborantul. Totusi, ca sa stiu sa il fac pe asta, tre sa incep cu studiul vreunui limbaj de shading.

Apropo, daca in timp ma gandesc sa merg si pe un renderer in opengl, merita sa folosesc Cg de la nvida? Sau o sa am probleme cu el?

Cg e mana cereasca daca vrei sa suporti si OpenGL, pentru ca e practic acelasi limbaj ca HLSL. Daca alegi GLSL trebuie sa rescrii toate shaderele, ceea ce nu e tocmai frumos. Pe linga asta, GLSL e o abominatie cu tot felul de limitari idioate si drivere scrise cu picioarele, deci iti vei blestema zilele daca incerci sa faci un joc cu el.

Daca scrii in HLSL (d-ala de DX9, evident) si nu te aventurezi in colturile minuscule in care difera fata de Cg (unu-doua keyword-uri in plus), poti sa compilezi exact acelasi cod cu Cg si sa scoti ASM de arb_vertex/fragment_program sau chiar GLSL din el. Unreal de exemplu asa procedeaza ca sa nu rescrie toate shaderele pentru PS3, ceea ce in cazul lor ar fi fost pur si simplu imposibil.

LE: evident poti compila si pentru DirectX cu Cg, dar compilatorul de la Microsoft e mai bun in unele cazuri, asa ca eu as recomanda sa compilezi cu HLSL pentru DX9 si Cg pentru OpenGL.