Multe fac chestia asta. Nytro face chestia asta (motorul lui Nek). Ideea mea e cam pe dos. Sa fac un engine semi-modular dar si stabil si compact in acelasi timp. Si performant .

pai prin asta se poate face si un engine performant si stabil... numai ca anumite procese trebuiesc uploadate in memorie din start, nu in runtime

Am incercat si eu ideia cu dll'uri separate pt fiecare componenta. Partea buna este ca atunci cand vrei sa o iei de la zero sa testezi lucruri noi, este mai usor pt ca folosesti numai dll'urile care iti trebuie, GUI, input, sunet, etc. Problema e ca atunci cand faci jocuri 90% din timp il petreci lucrand la codul proiectului in faza sa avansata adica cu mii/zeci de mii de linii de code deja scrise. Daca iti pusca enginul si cauza e intr'un dll o sa ai bataie de cap mare sa faci debuggingul. In practica cand lucrezi la un proiect adaugi functionalitati noi la clasele/bibiliotecile initiale permanent, cand adaugi functionalitati noi adaugi si buguri noi =]. Daca ai un milion de dll'uri nu ajungi nicaieri. Daca totul e la un loc vezi imediat in cod unde e problema.

Din cauza asta eu prefer sa tin totul la un loc si sa pastrez un nr minim de dll'uri

pai nu neaparat...
practic... daca vad ca ceva nu functioneaza corect, ma uit la ultimul dll adaugat...
dar corect... cred ca mai bine ma limitez la un numar modest de dll... ceva in genul graphics, audio, net, input, physics

Mie mi-a placut ideea celor de la iD. DLLul este defapt game code-ul, iar enginul il trateaza ca pe un plugin.

e ceva... dar nu prea vad utilitatea

Intru'un proiect care trece dincolo de banal lucrurile nu 'functioneaza corect' de mii de ori



ma uit asta inseamna sa incerci sa reproduci bugul adica sa recreezi conditiile in care s'a produs bugul. Daca nu era dll debuggerul ti'ar arata direct unde e problema.
sa utilizezi dll'uri pt fiecare chichita e ok pt distractie/ proiecte mici. Nu este o sulutie foarte practica pt proiecte serioase. Singurul engine care are mai mult de 20 de dll'uri e Open Scene Graph dar ala nu e chiar engine de joc.

da... corect si asta... am cam renuntat la idee oricum.. .dar probabil o sa incerc ceva similar pe viitor ca sa vad ce iese

In primul rand pentru cei care spun ca e mai greu sa faci debug intr-un dll, eu zic ca se inseala, poti sa faci debug in orice dll daca ai sursele (trebuie doar sa incarci proiectul in workspaceul curent)

In al doilea rand dll-urile sunt bune doar daca ai cu adevarat nevoie de linkare la runtime, adica daca vrei sa alegi un modul dintre mai multe disponibile, sau daca vrei sa dai bucati de cod care sa foloseasca exact dll-ul cu care ai facut tu release la un moment dat.
In schimb daca vrei doar sa modularizezi treaba, poti sa faci si lib-uri linkate static.

dapz.. se poate face si cu statice...
dar e mult mai flexibil cu dinamice... mai ales daca engine-ul este sub gpl/lgpl


deci ceva in sensul unei sfere

rendering pipeline    physics pipeline
                    /
        [CORE]

si se ramifica foarte mult... dar ar iesi prea multe dlluri... si nu prea ar fi rentabil...
probabil o sa incerc abordarea mai putin modulara

Eu zic ca cel care se inseala esti tu. Sa folosesti/faci debugging la un dll e mai greu (chiar daca poti folosi aplicatia care foloseste dll'ul pt a face debuggingul)

de ce?

d c e greu? asta fac in fiecare zi la munca si mi se pare la fel ca cu un exe... ai libu ai info de debug... care-i diferenta? (singura chestie e ca tre sa te atasezi (ctrl-alt-p)

PS: ideea mi se pare buna, oricum documenteaza-te vezi cum sunt facute alte engineuri inainte fa-ti un plan bine stabilit (eu nu am facut asta la inceput si a trebui s-o fac dupa aceea )

Eu zic ca e greu daca esti total pe dinafara. Altfel nu conteaza in ce fel s-a incarcat codul pe care-l debugezi. Iar e un moment in care ar fi bine sa iei de bun ce spun aia care au mai programat chestii in loc sa citezi din "experienta" ta.

Apoi, lasind la o parte opiniile programatorilor experimentati care fac Editoare pardon jocuri anulate in C#: in ce fel se poate considera thread-ul asta un articol? Cum ne lumineaza autorul asupra unei probleme din programarea jocurilor?

In al treilea rind argumentul cu "DLL-urile sint cool" e bun pentru propovaduirea in fata oglinzii si cam atit. Cind faci un engine open source dai sursele si cui nu-i convine ceva schimba in surse. Cind faci un engine closed source nu vrei sa schimbe lumea DLL-urile. Cind esti intre, ca idsoftware, faci DLL partea care vrei sa fie plugin (game code-ul, in cazul lor). Nu faci normal mapping-ul un DLL, ceea ce oricum e o aberatie. Gamebryo de exemplu are un sistem de plug-in-uri pentru shadere, da' trebuie sa le faci DLL-uri doar pentru editor, jocului i le dai ca lib-uri sau le incluzi direct, si oricum nu-i vorba de normal mapping. Acum as putea sa aduc in discutie si faptul ca pe console nu exista DLL-uri, da' presupun ca nu e cazul.

Ca sa raspund "pe scurt" la intrebarea din finalul post-ului original: cum iti structurezi proiectul in VC si cum iti incarci codul nu-i o idee de engine. Altele sint problemele intr-un engine, de exemplu in 3D: cum faci management la shadere, cum determini vizibilitatea obiectelor, cum se redau animatiile si cum blenduiesti intre ele, cum se compreseaza animatiile, cum iti compresezi geometria, cum le dai artistilor parametri editabili pentru shadere (sau shadere editabile ca-n UE3 daca ti se pare ca te tine), cum rezolvi cu iluminarea indirecta, ce fel de umbre vrei sa bagi, cum faci light linking, cum impaci mai multe efecte screen-space deodata etc. Sau cum iti faci codul de collision sau ce fel de integrare folosesti in ala de fizica. Sau cum faci in game code seturi de proprietati pentru entitati, expunere catre scripting, serializare si versionare pentru load/save, cum faci state management si tranzitii intre stari, cum expui asta intr-un tool catre designeri. Chestii d-astea cu DLL vs. LIB vs. the world au relevanta 0.

Pai eu nu am simtit nicio diferenta daca linkez un proiect static sau dinamic. Totul e sa-i spun la debug sa incarce dll-ul pentru debug ... in rest e absolut la fel.