Moin Moin!

Nach dem Pointerfiasko gestern frage ich mich, wie man ein Spiel von der Struktur her am geeignetsten aufzieht, um der objektorientierten Programmierung gerecht zu werden...

Ich hab bis jetzt anfangs immer drauslosgeschrieben und alles in eien Unit gepackt, weil ich schnell Ergebnisse sehen wollte. Bis es dann irgendwann zu unübersichtlich wurde... also hab ich angefangen, alles mögliche auszugliedern. Ein eigenes TGame Objekt, welches sich dann "Unterobjekte" erzeugt. Ein TMap, ein TCamera, TEventHandler und so weiter...
Wenn ich aber dann im EventHandler, als Reaktion auf nen Tastendruck, beispielsweise die Position der Kamera verändern wollte, kam ich schon in Schwierigkeiten, weil die beiden Objekte sich ja nicht kannten.
Also hab ich jedem Unterobjekt von meinem TGame-Oberobjekt eine TObject Variable Owner gegeben. Dann konnte ich im EventHandler sagen TGame(Owner).myCamera.X := ... (Gestern hab ichs aus Jux und Dollerei mal mit Pointern statt TObject versucht - es war schrecklich)

Hat jemand Anregungen, wie man das eleganter macht?

Wie funktioniert das eigentlich in dem BombermanTutorial2?
Da steht ja nirgends Soundsystem := TSoundsystem.create;
Ich denke, das wird mit der einen Variabe in der Soundsystem-Unit gemacht, aber ich versteh die Vorgehensweise nicht.
Ich hab bis jetzt in zusätzlichen Units halt immer nur Klassen definiert und die im Hauptprogramm instanziiert...


Und ein letztes noch: Ich habe ein kleines Netzwerkspiel mit SDL geschrieben. Besteht daran Interesse für die Seite? So in der Art Demo-Sourcecode oder so?
Also es ist vielleicht nicht "schön" programmiert, aber es funktioniert

Netzwerkspiel mit SDL? Ich würd sagen, immer her damit. Demos und Beispiele sind doch immer gern gesehen.

Was die Struktur betrifft:
So zentrale sachen wie EventHandler und Kamera würde ich garnicht mal auslagern, vorallem wenn man mit SDL arbeitet, ist es nicht sehr sinnvoll, den EventHandler in ne extra klasse zu legen.

Grundsätzlich kann ich nur empfehlen, vor beginn eines Projektes erstmal grob (oder besser fein, aber dazu ist man ja meistens zu faul) zu planen, welche klassen man braucht und wie diese miteinander in Verbindung stehen. Dabei sollte man große Klassen wie zum Beispiel einen Partikelmanager nicht unbedingt mit der Soundengine verknüpfen. Das macht einfach nicht viel sinn.
Eher schon eine Zentrale Klasse, die auf Ereignisse und änderungen in der Spielwelt reagiert und die dann auf die anderen großen Klassen verteilt.
Also die größeren Klassen sollten nicht direkt miteinander in Verbindung stehen, also möglichst modular sein.

Wenn du interesse hast, kann ich ja mal versuchen, nen Diagramm zu erstellen, wie in meinem aktuellen Projekt die Klassen in relation stehen.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Okay, dann werd ich mir erstmal gründlicher überlegen, was ich auslager...
Aber ne ausgelagerte Kamera ist doch nicht verkehrt, dann muss ich beim nächsten Projekt nicht wieder ne Neue schreiben.

Und was hat es mit dem BomberManTut auf sich? Wieso werden da so Sachen wie der SoundManager nicht instanziiert?
Ich versteh nicht, wie das von der Delphi-Sprach-Logik her funktioniert, was da gemacht wird...

Und die Map ist da beispielsweise TMap = object - aber in der Hilfe steht, das man das nicht mehr nutzen soll.
Wär es dann richtiger/sinnvoller TMap als Klasse zu definieren?



So und hier das SDL-Netzwerkspiel: Panzerschwein
Habe ich größtenteils während einer recht langweiligen Vorlesung im Wintersemester 07/08 geschrieben.
Einfach, um ein bisschen mit SDL und vor allem SDL_Net herumzudoktorn.

Es ist ein Spiel für bis zu 4 Spieler über's Netzwerk.
Jeder Spieler spielt ein Schwein und man versucht, die anderen Schweine mit Raketen zu treffen.
Bäume kann man kaputt schießen, Felsen nicht. Über Wiese kann man laufen, über Wasser nicht.
Mit den Cursortasten bewegt man sein Schwein, mit Space schießt man eine Rakete.

Damit man nicht jedesmal beim Client den Namen oder die IP des Servers eintippen muss, verbindet sich der Server beim Starten mit einem PHP-Skript im Internet und lässt seinen Namen in eine Datei schreiben.
Wenn die Clients gestartet werden, versuchen sie, diesen Namen aus dem Internet abzufragen.
Aber manuell geht das natürlich auch.

Das Spiel funktioniert soweit, aber es ist sicherlich nicht sauber gecoded und wahrscheinlich auch nicht stabil, wenn man es drauf anlegt, es aus dem Konzept zu bringen.

Kommentiert ist es auch nicht sonderlich... aber bei Bedarf kann ich das ja nachholen =)

Generell würde ich sagen, leg mehere Ordner an wie Lib(externe Bibliotheken,externe Units wie Sascha sein TFrustumClass),Wrapper wenn genutzt(z.B. eigene Klassenkapseung von Fenstern über SDL,GDI,XLib oder ähnliches) und Code(eigener code). Dein Projektcode, also der Spieleanteil sollte im obersten Ordner liegen oder in ein 4. Ordner(z.B. game). Es lohnt sich alles in Module zu unterteilen, z.B. Netzwerk in Socket,Chat,Session, Sound in OpenAL,OggVorbis,Alut, Grafik in GL/DX,SceneGraph,Model,Level,GUI. Viele Klassen sind okey aber man sollte alles in maßen genießen und vorallem methoden. In der Mainloop sollten möglichst wenig Methodenaufrufe drin sein, da gerade Delphi für eine Methode viele prüfungen auf gültigkeit macht(im vergleich zu FPC) und dieser mehraufwand sich dann schnell in der FPS zubuche schlägt.
Vermeide möglichst units mit initialization drin, dies ist ganz böse(nur in seltenen fällen gutes Foo(singleton),Entwickler können sowas leicht übersehen). Es kann sich sehr lohnen, das designpatter Singleton einzubauen, da dieses einmalige Ressourcen(Texturmanager, SceneGraph, SoundManager, GUI, Fontmanager) besser handhabbar macht. Bau dein Spiel in einer Statemachine auf, z.B. Konstanten für LoadGame, Menu, Gameloop, MenuGraphic, MenuSound,.... und dann über ne case State of ... den passenden Code rein. Ich verwende noch dazu Klassen wie AuthScreen, MenuScreen, GameScreen und packe alle Sachen die ich dort brauche rein und lade sie im Create und gebe sie im Destroy frei. Die restlichen Ressourcen wie Fenster,SceneGraph sind Global definiert, wenn diese aber von Singleton abgeleitet sind auch die ....Screen klassen gepackt werden. So entsteht am Ende ein sauberer Code.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich hab jetzt den Teil mit dem Soundmanager nicht im Kopf, aber ich glaube das sich der TextureManager genauso verhält.
Die Antwort dafür ist einfach: Du findest im Code der Unit einen Abschnitt initialization udn einen Abschnitt finalization

Die Wörter sind selbsterklärend - der erste Abschnitt wird beim Start aufgerufen, der andere beim beenden. In der Unit für den TextureManager gibt es eine globale Variable names TextureManager der Klasse TTExtureManager. Diese wird initialization-Teil erstellt und im finalization-Teil wieder freigegeben.
Und da alle Units die auf die Klasse TextureManager zugreifen die Unit eingebunden haben, können sie einfach darauf zugreifen

Ob das guter Stil ist muss allerdings jemand anderes beurteilen. Ich denke eher nicht, aber wenns um guten Stil geht bin ich lieber ruhig