Weltraumshooter (Parsec) Sourcecode

[Demirug]

http://openparsec.sourceforge.net/

[Persönliche Meinung]
Nichts ist wirklich unbrauchbar. Es kann immer noch als schlechtes Beispiel eingesetzt werden.

C ist irgendwie nicht mehr zeitgemäss auch die verwendung von Abstrakten Datentypen (ADT) macht es nicht wirklich besser

Wer baut heute noch Glide support in eine Engine?

Die "3D Engine" und die Gameengie sind viel zu sehr miteinader verbunden. Da läst sich das eine ohne das andere kaum verwenden. Wiederverwendbarkeit was ist das?
[/Persönliche Meinung]

[Nasenbaer]

Sowas (einen WingCommander Clon) will ich auch in nächster Zeit zusammen mit einem Freund programmieren.
Auf was sollte man denn beim Design achten? Als Sprache will C++ (eingetlich nur die Möglichkeit von Klassen) und DirectX nutzen.

Mfg Nasenbaer

[Demirug]

Der Universaltipp dabei ist "Funktionale Trennung". Lasse die einzelnen Teile des Games nur zuviel voneinander wissen wie unbedingt notwending.

Das heist in diesem Fall. Eure Klasse welche ein Raumschiff verwaltet sollte sich nicht mit Detail der Grafik-API herumschlagen müssen. Im Gegenzug sollte es eurem Grafikteil aber auch vollkommen egal sein was er da gerade rendert.

Über das Thema kann man aber sehr lange Abhandlungen schreiben. ;)

[Nasenbaer]

Jo ich befasse mich gerade mit OOP am Beispiel einer verketteten Liste für einen größeren Vortrag und ich bin erstaunt wie stark man die einzelnen Teile voneinander trennen kann.
Insgesamt sind es 3 Klassen geworden. Eine für die GUI (vom C++ Builder die Form halt), einen für einen Knoten und dann eine für die Liste selbst. Und noch eine Struktur um die Liste nicht um die anderen beiden Klassen vom Inhalt eines Datensatzes unabhängig zu machen. :)

Mfg Nasenbaer

[Unregistered]

Originally posted by Nasenbaer
Sowas (einen WingCommander Clon) will ich auch in nächster Zeit zusammen mit einem Freund programmieren.
Auf was sollte man denn beim Design achten? Als Sprache will C++ (eingetlich nur die Möglichkeit von Klassen) und DirectX nutzen.


Wenn ihr euch noch nicht richtig mit Objektorientierter Programmierung auskennt, lest euch mal etwas Literatur drüber durch und versucht mal mit kleinen Progrämmchen euch klarzumachen wir Objekte in komplexerem Zusammenhang miteinander funktionieren.
Mir hilft es unheimlich zuerst ein paar UML-Diagramme zur Übersicht zu zaubern ;) Ist auch perfekt um den anderen zu erklären was man vorhat (man programmeriert ja selten allein).
Und dann testet die Grundfunktionen die ihr von DirectX braucht vorher wieder in kleinen Programmen (nicht unbedingt Objektorientiert). Sonst isses beim ersten Projekt, dass man so angeht schwierig fehler zu finden, da man nicht weiss an was der auftretende Fehler genau liegt.
Und vorallem plant eurer Klassendesign vorher sorgfältig.
Ich find nix schlimmer wie tagelange Arbeit über den Haufen schmeissen zu müssen, weil man zu faul war ne halbe Stunde länger in die Planung zu stecken.
Ansonsten was Demirug gemeint hat auch strikt einhalten. Trennt alle Bereiche soweit wie sinnvoll (sinnvoll in dem Zusammenhang ist ne eigene Wissenschaft) und haltet alles möglichst erweiterbar (am Anfang sollte alles eh nur mit den notwendigsten Funktionen laufen, der Rest kommt später). Ein Spielobjekt sollte nicht die kompletten Grafikroutinen enthalten. Die gehören woanders hin. :)
Im Idealfall sollte zb die Grafikengine komplett unabhängig von Spiel sein und jederzeit für ein anderes Spiel einsetzbar sein.