Module in Spieleprogrammierung?



  • Hallo Ihr,

    ich bin schon seit längerer Zeit dabei ein Spiel zu programmieren und wie das so ist mit der Zeit, wird das Teil sehr groß. Ich hab schon oft von Spieleentwicklern gehört, dass sie Module haben, die dann alle einzeln fertig programmieren und am Ende zu einem Projekt zusammenführen. Das wär genau das, um Ordnung in mein Chaos zu bringen und um einfacher und effektiver Änderungen zu programmieren.
    Hat jemand eine Ahnung, wie man sowas realisieren kann? Mein erster Gedanke war lib's, womit ich mich aber nicht so richtig anfreunden kann. dll's sind ja sowieso schon raus.

    Any suggestions?



  • Zoran schrieb:

    dll's sind ja sowieso schon raus.

    Wieso? nd wieso keine libs? Ist doch beides garnich schlecht.

    Bye, TGGC (Keine Macht den Dummen)


  • Mod

    wenn man von "modulen" spricht, geht es vorrangig um das design der software und nicht so sehr um die physikalische realisierung von "modulen" (was natürlich trotzdem gemach wird)

    Module sind teile der software die für sich ihre spezifikationen haben und standalone sind, sodass man sie woanders verwenden kann.

    ein beispiel wäre z.b. ein mp3 abspieler. den kannst du in deinem spiel dazu benutzen um hintergrundmusik zu spielen. bei schlechtem design, hast du dinge festgecodet wie z.b. den include eines standart headers vom projekt in dem alle möglichen libs eingebunden werden wie z.b. directSound. so ist es dann nicht mehr möglich das modul zum mp3 abspielen zu nutzen, ohne das hauptprojekt mitzubauen, es ist aber auch nicht mehr möglich das hauptprojekt zu bauen ohne das soundmodul.
    sauber wäre es, wenn das "soundmodul" in wenigen zeilen in jede anwendung eingebaut werden könnte und man dann mit z.b.

    CSoundPlayer::Instance().Play("Bla.mp3");
    

    mp3s abspielen würde.

    wenn du das für jedes modul machen kannst wie z.b. imput,sound,resourcemanagement,3ddevice... hast du deine saubere trennung. Es bietet sich auch an module durch namespaces zu kapseln.

    dabei ist es nicht wichtig wie diese module physikalisch vorliegen, ob als *.lib, .dll oder als sourcen-proejekt im cvs. denn diese dinge sind eher dafür zuständig, dass man zur compilezeit unabhängig von implementationen ist (dll), dass man bei einem rebuilt nicht ewig auf den compiler wartet (.lib).

    rapso->greets();



  • Hallo,

    vielen Dank euch beiden für die Hilfe. DLL's bräuchte man ja später für die .exe auch und LIB's nur beim kompilieren, richtig?

    Also sollte ich das grundlegende Spiel in der .exe lassen und nur Sound, Grafik usw. rausnehmen und als Module nutzen?

    Hatte im ersten Moment eher so an Menü und bestimmte Bereiche im Spiel im Spiel zu splitten, keine gute Idee?

    Mit anderen Worten sollte ich das GUI (Menü's, Spiel selber usw.) in dem Hauptprojekt machen und Input, Sound, bla bla in lib's stecken?

    Zoran



  • Also ich denk mal, das ein schönes, erweiterbares und vielseitiges GUI System auch in anderen Projekten Verwendung finden könnte, deswegen würd ichs in ne .dll packen, dann kann ichs einfach nutzen und dass unabhängig vom Spiel 😉 .

    cya WirrWar2850.



  • @WirrWar2850: Wie gesagt, mit 'ner Lib auch.

    Bye, TGGC (Wähle deine Helden)



  • Is klar, aber ich persönlich bevorzuge .dlls 😉 ...

    cya WirrWar2850.


Anmelden zum Antworten