Design der Gameengine

Sylence · **Verfasst:** 17.04.2007, 18:53

Das Problem wÃ¤re dann aber wieder, dass wir sehr stark an eine Irrlicht version gebunden wÃ¤ren. Bei jedem neuen release von irrlicht mÃ¼sste sich dann jemand hinsetzen und den erweitertete interface wieder mit dem neuen scenegraphen kombinieren.

Wenn wir dann nicht vor version 2.0 fertig werden (wovon ich mal ausgehe, denn ich denk mal version 2.0 kommt noch dieses jahr), dann haben wir ein richtiges problem, da wie ich gehÃ¶rt hab sich einiges im scenegraph mit 2.0 Ã¤ndern wird.

Oder hattest du irgendwie daran gedacht das interface zu erweitern ohne den eigentlichen source anzufassen, also quasi ISceneNode ableiten und IGameSceneNode draus machen?

frodenius · **Verfasst:** 17.04.2007, 19:32

jup genau
also mein grundgedanke ist das wir abstrakte interfaces machen wie in irrlicht auch, und dann klassen die diese interfaces implementieren und eben von ISceneNode erben. dass der scenegraph geÃ¤ndert werden soll kÃ¶nnte fÃ¼r uns problematisch werden wenn wir auf funktionen des bestehenden systems zurÃ¼ckgreifen die geÃ¤ndert werden.. das wÃ¼rde dann aber jeden betreffen, wie das zb mit dem OnPreRender + OnPostRender war.. dann gibts ja aber refactoring.

beispiele:
IAttachable - alles was man irgendwo dranhÃ¤ngen kann
IWearable - alles was man tragen kann
IStorable - alles was in
IContainer - geht, zb inventar, kiste etc
IResource - holz, metall, etc .. evtl nochmal spezialisieren in Natural und Artificial wenn etwas aus mehreren NaturalResources zusammengefÃ¼gt eine neue substanz gibt (zb trÃ¤nke, munition etc)
IUsable - selbsterklÃ¤rend
IWeapon
ITool
usw usf

Sylence · **Verfasst:** 17.04.2007, 19:46

die dann wiederum von IGameSceneNode abgeleitet werden, die von ISceneNode erbt.
Dadurch wÃ¤r dann nur eine weiter klasse fÃ¼r die scenenodes nÃ¶tigt, nÃ¤mlich IGameNodeFactory.

Durch diese aufteilung wÃ¤re es dann auch einfacher zum beispiel neue waffen in das spiel einzufÃ¼gen.
Man hÃ¤lt IWeapon dann einfach so weit abstrakt, dass es mÃ¶glich wÃ¤re die attribute der waffe (z.b. schaden) aus einer datei zu laden. So mÃ¼sste nicht fÃ¼r jede Waffe eine neue ableitung von IWeapon erstellt werden

frodenius · **Verfasst:** 17.04.2007, 19:48

genau

wir verstehn uns

[edit]
ich les grad einen artikel Ã¼ber fsm's fÃ¼r die ki.. mir kam sponten die idee das Ã¼ber scripts zu lÃ¶sen, so kÃ¶nnten wir das doch auch mit waffen zb machen: jedes entity kann ein oder mehrere scripts angehÃ¤ngt bekommen, die dann bei bestimmten events ausgefÃ¼hrt werden..

Sudi · **Registriert:** 12.04.2007, 11:47 **Beiträge:** 108

Schlechte idee!!!!
nicht von ISceneNode ableiten!!!
hab ich gemacht und bin bÃ¶se auf die nase gefallen. das was ihr da anfasst ist die rendering pipline...warum heiÃŸt die wohl so???da wird gerendert nichts anderes!!!!!Ãœberlegt mal ihr hÃ¤ttet eine scenenode die eine scenenode erstellt damit sie sich graphisch dartsellen kann...und wenn ihr dann noch extras wollt mÃ¼sst ihr ne reference zu dem pointer wieder irgendwo speichern und nochmal durchlaufen lassen. es ist echt nicht schwer mal eben nen eigenes entity system zu schreiben! seht euch mein spiel spacefighters an. das nutzt ein interface system und ist im prinzip eine fertige spielengine die nur erweitert werden muss. wÃ¼rde sogar fÃ¼r euer spiel passen. seht euch den source code einfach mal an.

Sylence · **Verfasst:** 17.04.2007, 21:01

ich wollte mir mal spacefighters angucken, aber irgendwie funktioniert der link zum download nicht...

gibts noch eine mÃ¶glichkeit den source zu laden als von gdlib.net ?

Sudi · **Registriert:** 12.04.2007, 11:47 **Beiträge:** 108

verdammt is die seite immer noch offline...hmmm
ok hier habs ichs mal eben hingepackt. normaler weise ist da meine website aber da ich auch gerade das andere spiel entwickel liegen da immoment nur binaries. hab mal eben spacefighters bin und source hingepackt.

http://daniel.game-host.org

Sylence · **Verfasst:** 17.04.2007, 21:21

Ok habs mir mal gezogen und werd mir das mal morgen angucken. thx

frodenius · **Verfasst:** 17.04.2007, 22:32

argghh natÃ¼rlich, der haken..
ich fand es halt nur irgendwie etwas unsinnig komplett zwei scenegraphs zu haben, einen fÃ¼r die spiellogik und einen fÃ¼rs rendern... naja wenns nicht anders geht..
[edit]
@sudi
was ist denn schiefgelaufen?

Sylence · **Verfasst:** 18.04.2007, 01:09

Wahrscheinlich die performance und die wartbarkeit des codes

frodenius · **Verfasst:** 18.04.2007, 08:15

wartbarkeit ok, aber performance? ist doch theoretisch gleich, das mehr an code kommt ja trotzdem dazu.

Sudi · **Registriert:** 12.04.2007, 11:47 **Beiträge:** 108

Ã¼berleg doch mal....du wÃ¼rdest code wÃ¤hrend des renderns ausfÃ¼hren der dort garnicht hingehÃ¶rt. das ist erst einmal schlechtes design, warum gibt es wohl klassen in c++. zweitens wie ich schon gesagt habe brauchst du eine reference des objects bestimmt noch einmal an anderer stelle fÃ¼r statistische werte oder sonst was. das wÃ¼rde heiÃŸen einmal der scenemanager hat einen pointer und an dieser anderen stelle liegt noch einer und du mÃ¼sstest beide lÃ¶schen wenn das entity zerstÃ¶rt wird....schon mal ein schÃ¶ner punkt fÃ¼r einen fehler....auÃŸerdem wirst du an der anderen stelle auch Ã¶fters mal durch die entities laufen weil du ihnen bestimmte befehle zum ausfÃ¼hren geben mÃ¶chtet z.B. das resultiert dann darin das du zweimal durch die entities lÃ¤ufst.einfacher wÃ¤re es da gleich nur an der anderen stelle zu speichern. ich kÃ¶nnte dir zeigen was ich meine wenn ich den source code fÃ¼r shootirr nicht gelÃ¶scht hÃ¤tte....da hab ich mir nÃ¤mlich auch gedacht auch ich nehm einfach iscenenode. und ich bin dann schnell an die grenzen gestoÃŸen.

[edit:]
zu anfang sieht es nicht so aus als brÃ¤uchte man eine extra methode aber spÃ¤ter wenn das ganze komplexer wird fÃ¤llt es doch schon auf.

Design der Gameengine

Wer ist online?