Diskussion:Enginepfad
Der Artikel scheint verfrüht zu sein. Die meisten verlinkten Artikel existieren noch nicht, gerade das soll bei Trampelpfaden vermieden werden.
Außerdem klingt der Text noch nicht sehr ausgegohren. Wichtige Informationen wie das erstellen von Managern/Tools wurden nicht erwähnt. Um ganz ehrlich zu sein, der Autor scheint selbst recht wenig Erfahrung mit großen Projekten bzw. einer ausgefeilten Planung zu haben (was aber im nichtkomerziellen Sektor nicht überrascht). Im Forum bei DGL gab es diverse Threads die sich mit der Planung genauer beschäftigen. Wir sollten deshalb unbedingt die Informationen noch zusammen tragen. Der Momentane Artikel kann bei "echten Programmierern" schnell als schlechter Scherz aufgefasst werden, da z.B. die aufgeführten Module nicht zwingen aussagekräftig sind.
Sorry, dass das vielleicht hart klingt aber ich hoffe Kritik wird nicht als perönlicher Angriff verstanden. --149.225.150.153 23:25, 30. Mai 2005 (CEST)
Keine Panik auf der Titanic, Wasser ist für alle da!
Mal ehrlich, ich hab doch gestern nur den Trampelpfad gelegt, die Textüberarbeitung sowie hinzufügen der einzelnen Module kommt noch. Das ist ein so grosses Thema das ich erstmal nur den Umriss machen konnte und in folgenden Tagen es um einiges erweitern werde. Man kann doch nicht alles mit einal erstellen.
Mein Augenmerk liegt erstmal auf die vorbereitung eines Projektes, in nachhinein werde ich auch Möglichkeiten der entwicklung einzelner Module zur Engine niederschreiben hoffe aber das sich da andere noch darum kümmern werden. Als Basis zur erklärung werde ich meine neue und noch in entwicklung befindene Engine verwenden.
Der Anschein, dass der Autor keine Ahnung vom Thema hat ist mir schleierhaft :( (als Beleidigung fass ich das auch nicht auf). Ich versicher dir, ich habe Erfahrung in diesem Gebiet unter DarkBasic,Delphi,FreePascal und teilweise auch C++ angeeignet. Auch mein Wissen über Plannung von Projekten erstreckt sich über zig bücher ,Tuts und Praxiserfahrung.
Der Artikel ist vieleicht wirklich verfrüht, da ich erst in 2 Tagen wirklich Zeit habe mich intensiv damit auseinander zu setzen.
MfG TAK2004
Die Frage die sich mir gestellt hat war, ob es wirklich notwendig ist von Grund auf anzufangen. Also ist es beispielsweise notwendig jemanden darauf aufmerksam zu machen dass es unterschiedliche Programmiersprachen gibt. Hier würde ich nur auf den Einsteigerpfad und vielleicht auch auf den Technik-Pfad verweisen.
Ganz am Anfang wäre mal eine kurzer Hinweis angebracht wofür man eine Engine braucht und was eine Engine überhaupt ist (wobei letzteres wohl etwas unklar definiert ist :-) ). Also salopp gesagt, dass die Engine nach der (möglichst einfachen) Initialisierung die gesamte Szenenverwaltung übernimmt und du nur noch auf Ereignisse wie Tastatur- oder Netzwerk- Eingaben, Kollisionen und dergleichen reagieren musst.
Bei den APIs würde ich ebenfalls nur kurz etwas in der Art schreiben: "Welche Sound/Render/Input API du verwendest bleibt dir überlassen, im Idealfall solltest du sie so weit abstrahieren können dass du später auch mehrere unterschiedliche APIs unterstützen könntest". Vielleicht bei der Render API noch etwas ins Detail gehen wie man diese abstrahieren könnte.
Danach sollte man denk ich gleich mal mit allgemeinen Szenengraphen beginnen, wozu man vielleicht sogar noch nen eigenen Artikel verfassen könnte.
Für die Dateiformate vielleicht noch ein paar Hinweise wie beispielsweise:
- Sollen alle Models die selben Kollisionsinformationen besitzen (der typische Multiplayer Shooter)
- Wie kann ich eine dynamisch nachladbare Welt abspeichern
- Was könnte ich alles bei den Shaderen/Materialeigenschaften gebrauchen
- Und ggf. auch welche bestehenden Dateiformate könnte ich in welchen Fällen gut einsetzen (vor allem bei Levels wichtig)
Nun noch ein paar Entscheidungshilfen für die Algorithmen die man verwendet. Beispielsweise ich will rein Indoor, was sind die Möglichkeiten die ich hier so habe, also:
- Kollisionsabfragen und Raumunterteilungstechniken (Octree(s), BSP-Baum, ...)
- Sichtbarkeitsabfragen (PVS, dPVS)
- und ggf. Pathfinding Möglichkeiten (Navigation meshes, Wegpunkte, ...)
Und das würde ich wirklich nur an einigen Beispielen erläutern, also eventuell auch auf bestehende Engines eingehen und deren Stärken und Schwächen etwas beleuchten.
Gegen Ende vielleicht noch ein paar Dinge erwähnen die man ebenfalls früher oder später beachten sollte, also beispielsweise:
- Wie sollte ich meine Lichter verwalten?
- In welcher Reihenfolge soll ich meine Objekte rendern, auf was muss ich dabei achten und wie kann ich das überhaupt geschickt lösen (könnte jedoch zu einem größeren Teil auch beim Szenengraphen behandelt werden)?
- Wie gehe ich vor wenn ich eine Extension optional verfügbar machen möchte? Also Stichwort Rendering Path, worauf man bei der Render API-Abstraktion schon eingehen könnte.
- Wie gehe ich vor wenn ich die Szene aus 2 Ansichten rendern möchte (der typische 2 Spieler Modus)?
Die Haupt-Frage die sich mir hier noch stellt ist in wie weit man auf Themen eingehen soll die mit einer Game-Engine zusammen hängen (also eine Engine die zB auch Netzwerk, Sound und dergleichen verwaltet), oder ob sich der Artikel ausschließlich oder großteils auf 3D-Engines spezialisieren soll. Auf die eigentliche Projekt Planung aus Softwareentwicklungstechnischer sicht würde ich jedoch eher weniger eingehen, denn wenn jemand aus den Informationen rund herum (was er alles beachten muss) ein Projekt nicht planen kann, dann kann man es ihm wohl kaum mit 2-3 Seiten Text beibringen. Die Planung könnte man zwar erleichtern indem man etwas konkretere Vorschläge macht wie man zB eine gscheit abstrahierte Render API gestaltet, oder indem man ein paar Schlagworte (wichtige Design Patterns und dergleichen) hin schmeisst.
Und nun wart ich mal auf ein paar Kritiken zu einem derartigen Aufbau bevor ich mir einen konkreteren Text überlege :-).
--Lyr 15:31, 31. Mai 2005 (CEST)
Mein Aufbau ist sicherlich nicht das Endprodukt und bedarf einiger änderungen. Aufgrund von Zeitproblemen habe ich gestern nur angefangen den Trampelpfad zu erstellen. Dinge wie Softwarecycle soll man nicht als A und O halten aber man sollte mindestens zeigen wie sowas in etwa aussehen kann und was so alles drin sein könnte. Noch ist zu sagen das ich mich erst an die Möglichkeit von verschachtelungen durch links gewöhnen muss, denn ich bin eine statische Folge noch gewohnt.
Ich dachte mir den Aufbau wie folgt:
- Erklärung des Begriffs
- wie baut sich eine Engine auf
- Planung einer Engine
- entwicklung einzelner Module
- forführende texte
- Links
dies soll wie ein kleintext lesbar sein und dann nach Wissensgrad in die einzelnen Module tiefer einsteigen indem man die Links verwendet. So wollte ich dinge wie einzelne Libaries in ein extra Text packen aber fand keine Möglichkeit diesen intern zu verlinken wobei der Link aus meheren Wörtern bestehen sollte. Mitlerweile weiss ich das ich das mit ein externen Link machen kann ^^ --TAK2004 16:36, 31. Mai 2005 (CEST)
