spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

Ich kann mir nicht helfen, aber ich bin bis jetzt noch ganz gut mit den einfachsten strukturen durchgekommen, ohne mich mit den "simplen" Techniken zu beschäftige.....
so far

Einfachsten Strukturen, "simplen" Techniken, wo ist da der Unterschied?

Nutzt du die TB Engine?
Hast du einmal versucht eine eigene Engine zu programmieren oder machst es vielleicht sogar bereits?

Dann wirst du schnell merken, dass du mit simplen Techniken nicht sehr weit kommen wirst.
Dinge wie Memory Management, Profiling, Serialization, Factories, Interfaces, Desgin Patterns, Scripting gehören alle zum Alltag und selbst in eine simple Engine. Soweit ich weiß besitzt die TB keines der eben erwähnten Mechanismen.
Aber für simple Spiele reicht es allemal. Das sieht man ja auch schön an den Spielen, die damit entwickelt werden. Was ich persönlich als definitives Plus für das Buch anrechne. Weil in den meisten Bücher wird mehr abstrakt gearbeitet oder man muss sich konkrete Bücher kaufen. Hier wird versucht alles zusammenzumischen, was bis auf die fehlenden Grundtechniken auch ganz gut gelingt.

Von Heiko habe ich noch kein Buch gelesen, daher kann ich nicht sagen, wie er das Thema anfasst und wie gut er die Themen vermitteln kann.
Vielleicht werde ich mir die 2nd Edition einmal anschauen. Wann soll das Buch herauskommen?

Ich verstehe nicht genau, was ihr an meinem Text nicht verstanden habt und ich bin mir auch nicht sicher welche "Fachwörter" ihr meint?

Ich arbeite selbst erst seit ca. 3 Monaten an einer eigenen Engine und habe schon zum dritten Mal den Kram neu angefangen, weil das Design, für mich, nicht ausreichend war.
Vielleicht übertreiben ich hier ein wenig, sorry.
Es stimmt schon, dass man vielleicht diese Dinge, die ich oben erwähnt habe nicht unbedingt in einer kleinen Engine braucht, wie der TB Engine, aber ihr werdet merken, dass diese Techniken sehr sinnvoll sein werden.

Hier noch mal eine kleine Erklärung der "Fachbegriffe":
Memory Management: Speicherverwaltung, z.B. für das Protokollieren von Allokationen und Deallokationen oder zum Finden von Memory Leaks.
Profiling: Messen des Zeitaufwands, z.B. des Rendern, der AI usw.
Serialization: Laden und Speichern von Savegames oder ich nutze es zum Initialisieren von der Application, Renderer usw.. In meinem Fall mit XML.
Factories (ein Design Pattern): Factories kennen verschiedene Klassen, z.B. verschiedene Game Entities und durch die Factory kann man sich diese erzeugen lassen. Vorteil: Das Spiel muss nur die Factory kennen und nicht jedes Game Entity (Abhängigkeiten sinken) und man kann eine Verwalung der Entites erreichen, wie beim Resource Management.
DesginPatterns: Beispiele: Factory, Singleton (lest das GoF Buch)
Scripting: Zum Beispiel mit Lua, dadurch lassen sich z.B. bestimmte Ereignisse im Spiel triggern.

Wie gesagt, für einfache Spiele wie die Spiele im Buch, brauch man solche Mechanismen nicht zwingend. Aber es macht Sinn, von diesen gehört zu haben. Ich empfehle euch das Buch "C++ for Game Programmers, von Noel Llopis" und die Game Programming Gems Reihe. Die GPG Reihe ist ein absolutes muss und da werdet ihr all diese Mechanismen und noch viel mehr wieder finden.

Ich wollte keinen auf den Schlips treten.
Aber man sollte immer über den Tellerrand hinaus sehen.

Zitat

dass das Design vielleicht ncith den ansprüchen von großen firmen genügt, sondern mache das aus jux und tollerei.

Ich verstehe nicht wo das Problem liegt. Glaubst du den dass die paar Dinge, die ich aufgezählt habe eine so große Sache sind?

Ich will keine Engine programmieren, die mit einer kommerziellen Engine mithalten kann, dafür brauch man auch mehr als nur einen Programmierer. Ich will auch keine Engine programmieren, die mit überhaupt einer Engine mithalten kann. Ich möchte lediglich eine Engine programmieren, die etwas taugt und die ich nicht bei jeder neuen Idee neu programmieren muss oder die am Ende einfach nichts taugt, da ich mich nicht von Anfang an um Dinge wie Speichermanagement und Performance usw. gekümmert habe.

Ich programmiere die Engine als Open Source, daher auch die Motivation, die Engine ein wenig auf Vordermann zu halten. Außerdem kann man die Erfahrung auch im Beruf gebrauchen. Bevor die Frage gleich auftaucht. Es ist noch kein Source verfügbar. Da das Grundsystem noch nicht fertig ist. Aber ich werde einen Link zum Source hier posten, wenn es soweit ist.

Zitat

Naja ich weiß ja nit wieivel Zeit du hast?

Ich habe leider sehr wenig Zeit, da ich den ganzen Tag arbeite und nur Abends für mein Projekt Zeit finde. Und dann auch nur unter der Woche.

Zitat

einigermaßen einfach und bündig hält, kannst du all deine schönen Techniken über Bord schmeißen

Also die Techniken, die ich oben erwähnt habe, laufen wohl keiner Gefahr, dass sie veralten werden.

Zitat

P.S: sry für den Angriff mit Babylon aber mir viel kein synoniem ein..

Also ich fand den Vergleich ganz gut.

Es stimmt schon, dass man nicht gleich mit etwas zu großem Anfangen soll.
Durch meine arbeit sehe ich die Notwendigkeit von z.B. Data Driven Design (bedeutet, dass so wenig wie möglich fest programmiert wird, sondern Daten aus Dateien gelesen wird.)

Da fällt mir auch ein guter Vergleich ein:
" Viele Wege führen nach Rom "
Und so ist es auch.
Jeder hat einen anderen Weg, hat andere Vorstellungen von einer Engine.
Und es macht wahrscheinlich auch wenig Sinn, ohne Erfahrung ein Monsterprojekt zu starten.

Von daher, sollte jeder das machen, was er auch kann.

Mir ist nur aufgefallen, dass viele sich so auf die TB Beschränken und glauben das ist alles was man machen kann.
Aber OK, dass soll am Ende auch jeder für sich Endscheiden.