spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Genau. Ein Weltraumshooter ist schön einfach, weil es wenige Objekte gibt. Es gibt praktisch nur die Raumschiffe, Sterne, Raketen und Laserstrahlen. Und wie Du sehen wirst, ist das schon ein riesiger Aufwand. Der wäre bei einem First-Person-Shooter noch viel größer, und das wäre nicht mehr unbedingt für einen Einsteiger geeignet.
Stefan Zerbst hat jetzt schon drei Bücher, und First-Person-Shooter beschreibt er auch erst in seinem dritten Buch. Aus gutem Grund, weil solche Spiele eben viel komplizierter sind als Weltraumshooter oder Breakanoid-Klone.

Natürlich währe es mal eine Abwechslung wenn man mal ein Buch in der Hand hält wo "Spieleprogrammierung" drauf steht und auch drin ist. Meist wird jedoch nur DirectX oder eine andere API besprochen. Soweit muss ich dir recht geben Maverick.
Speziel bei David's Buch kann ich sagen, das dort mehr über Game Developement drin steht als bei allen anderen Büchern die ich bis jetzt gelesen habe und das sind nicht nur 2

Aber wie genau würdest Du denn ein Buch über Game Development aufbauen, Maverick. Welche Themen würdest Du behandeln? Natürlich müssen Themen wie BSP- oder Octreerendering enthalten sein. Aber allein eine vernünftige Abhandlung des BSP-Trees würde gute 60 bis 100 Seiten in anspruch nehmen. Wenn dann noch Themen wie Scene-Management oder Game-AI hinzukommen, wird das Buch wohl Bibelstärke erreichen. Ein Problem ist das man nicht das gesamte Game Developement in ein Buch bekommt. Da es sich sonst wohl keiner kaufen kann, da es bei über 2000 Seiten mehr als 80€ Kosten würde

Ein weiteres Problem ist, wie hält man Themen wie z.B. das Scene Managment so Allgemein das es für alle Spiele gleichermasen gilt? Es gibt schon einen erheblichen Unterschied, ob man nun einen Scene Manager für einen Space-Shooter hat, oder ob man einen für ein RPG hat. Das gilt für viele Themenbereiche.

Eine Scriptsprache kann man schon etwas Allgemeiner halten. Jedoch ist es nicht grad so einfach sich mal eben eine eigene Scriptsprache zu basteln. Zudem ist hier auch nicht unbedingt ein Buch erforderlich, das eine Scriptsprache Speziell für Game Development bespricht. Was eine Scriptsprache macht dürfte wohl jedem klar sein, da bereits jeder schon mal mit einer gearbeitet hat Hier ist eine einfache Abhandlung über den Strukturellen Aufbau der Sprache sowie die des Übersetzers und dessen Implementierung nötig. Und dafür gibt es schon Bücher. Wie die Sprache dann genauer aussieht hängt eh vom jeweiligen Game ab. Das reicht von der einfachen Steuerung für die Initialisierung bis hin zu einer Kompletten Sprache wie UnrealScript.

Aber wenn Du ein paar Tutorials schreibst, dann werd ich sie gerne auf meiner Page veröffentlichen und bin sehr gespannt wie sie denn aussehen werden, und welche Themen du besprechen wirst.

Ist HTML eine Scriptsprache?
Wenn NICHT, dann weiss ich nicht was eine ist und wofür man die überhaupt in Spieln benutzen soll.

Hehe, nein, HTML ist keine Scriptsprache!
Eine Scriptsprache ist sozusagen eine "Untersprache", die speziell an das Spiel angepasst ist. Sie ist also auf einer viel höheren Ebene als C++.
Scripts kontrollieren bestimmte Abläufe in einem Spiel. Z.B. könnte ein Script dafür sorgen, dass ein Gegner erscheint, wenn der Spieler irgendetwas spezielles tut. Oder dass wenn er einen Hebel bedient, irgendwo eine Tür aufgeht.
Bei Weltraum-Shootern, die auf richtigen Missionen basieren, sind Scripts auch unerlässlich. Ein Script könnte da so aussehen:

if(FeindlichesMutterschiff.Zerstoert)
{
SendeFunkspruchAnAlle("So einfach werdet Ihr uns nicht besiegen!");
NeuesSchiff = SchiffErzeugen("Borg Kubus");
NeuesSchiff.SetzeZiel(Spieler);
}

Irgendwie sowas halt. Eben solche Sachen, die man nicht direkt in den Quellcode des Spiels einbauen würde, sondern die spezifisch für einen Level bzw. für eine Mission sind. Scripts können natürlich auf die Variablen des Spiels zugreifen.
Wenn Du selbst eine Scriptsprache erstellen willst, ist das garnicht so einfach. Du musst dann vieles von dem programmieren, was man auch für einen Compiler programmieren müsste.

Für dein Code Beispiel braucht man aber keine Scriptsprache.
Man kann das genau so gut mit einer Verketettenliste machen!
Oder nicht?

Nur die harten kommen in den Garten, oder wie war das noch mal? Mein erstes Richtiges Game war ein 3D Shoter a la Quake 3, für damalige Zeit mit fantastischerer Grafik. Davor habe ich auch das ein oder andere Billig Game gemacht. Dagegen sagt ja auch keiner was, nur denn weg den du grade beschreist mit dem „Indor“ und „Outdor“ sind grund verschieden, muss ich erheblich wiedersprechen, wenn man uralt Techniken wie BSB oder ROAM benutzt JA. Aber wer macht das noch? Für dein zweites Buch, würde ich z.B. einen Simplen Szene Graphen verwenden, mit dem kann man jegliche art von Spiel realisieren.

So jetzt brauche ich erst mal eine Kippe.

Die Engine würde ich nach dem Lego Prinzip aufbauen, ein steck system aus Modulen, was man jederzeit erweitern kann, so das die Leute viel damit experimentieren können. Zum Rendern eines 3D Objektes gibt es dann z.B. ein PlugIn welches in den Graphen gehangen wird, im Prinzip muss die Engine nicht viel mehr können als deine jetzige, nur fehlt ein einfacher Editor. Wenn man das hat, hat man ein sehr Mächtiges Framework, auf dem die Leute dann aufbauen können. Eine weitere schöne Sache wäre es z.B. Wenn es ein Kapitel über Bone Animationen gibt, aber nur die Grundlagen, so das man selber weiterarbeiten kann, den Leuten etwas vorzuwerfen „hier friss das“ ist keine so gute Idee. Eines der größten Mankos der Zerbst Bücher ist es einfach, dass dort nur Schrott produziert wird, ich habe mich tierisch auf sein zweites Buch gefreut, wurde aber wieder total enttäuscht. Die, oder das Spiel sollte schon auf der Höhe der Zeit sein. In seinem dritten Buch geht er jetzt im Indor bereich, aber man merkt es einfach, das er sich noch nie Unreal II angeschaut hat. Alle loben DOOM3 aber im Prinzip wird dort auch nicht gezaubert, ein bisschen Bump mapping ein paar stencil shaows, mehr ist das auch nicht, nur das verstehen die Leute nicht. Ich kann mich noch gut an die Geforce4 Präsentation erinnern, wo wir die Demo mit den Echtzeit Grass hatten, wo jeder „wow“ gesagt hat, dabei ist es auch nicht mehr als ein Decal mit einem vertex shader. Das wichtigste, was ein Buch vermitteln muss ist, Geht nicht, gibt es nicht! Mann kann komplexe Probleme immer in mehrer kleine zerlegen, die dann machbar sind. Die Jungs von Piranha Bytes sind zu viert angefangen und haben eins der Besten Spiele Serien, die es gibt erschaffen.

Zurück zu dem Buch, ich weiß nicht, ob es zu viel wäre, aber Elementare dinge wie Path finding, oder wie eine Rakete ein Objekt verfolgt sollten schon enthalten sein. Ein kurzer abriss über Physik und wie man sie in dem Graphen einbindet. Key Frame Animation, dazu muss man je nur den Node bewegen. Ein Trigger PlugIn wäre auch eine feine Sache, das könnte man dann immer mit den vorherigen dingen kombinieren. Z.B. das ein Männchen auf den Trigger zu geht, ihn auslöst, und er ein Stein, der ein RigidBody Physik PlugIn enthält, auf die Nuss bekommt.

Um Prinzip müsste man dann so vorgehen, Erklärung der Grundlage, Schreiben des Engine PlugIn’s, schreiben des Editor Wrappers, Anwendung anhand einer Demo, welche mit dem Editor erstellt wurde zeigen. So ähnlich würde ich mir das vorstellen.

Das ist ja alles schön und gut.
Nur kann man jetzt sowieso nix mehr ändern weil das Buch bereits gedruckt wird. Villeicht macht das DAvid in seinem 2 Buch.
Aber Pathfinding ist drin oder David?

@lukuku: Richtiges Path-Finding nicht. Aber Du lernst schon, wie eine Rakete ihr Ziel verfolgt.

@Maverick: Gute Ideen sind das! Ich habe mir auch mal Gedanken über eine 100% erweiterbare Engine gemacht. Da könnte man mit Modifikatoren arbeiten. Ich glaube, das ist auch das, was Du meinst. So in der Art hier:



LoadFromFile, BoneTransform und Renderer wären dann Modifikatorklassen. Der erste Parameter des Konstruktors ist immer der Name, den man diesem Modifikator gibt. So kann man ihn später per Object::FindModificator wiederfinden und seine Parameter ändern. Z.B. beim BoneTransform-Modifikator würde man ihm den aktuellen Zeitindex geben. Oder Renderer würde die Transformationsmatrix erwarten.

Sobald man einen Parameter eines Modifikators verändert, müssen alle untergeordneten ihre Arbeit neu erledigen.

-> LoadFromFile
|--> BoneTransform
|---> Renderer

Wenn ich jetzt bei LoadFromFile z.B. den Dateinamen ändere, dann müssen BoneTransform und Renderer neu ausgeführt werden, beim nächsten Durchlauf der Hierarchie (also beim Rendern).

Ja, so ein "Rigid Body Physics"-PlugIn wäre toll. Dem könnte man dann einen Kraftvektor übergeben und es würde dann die Geschwindigkeit und das Drehmoment des Objekts verändern.

Was würdest Du von dem Prinzip halten, Maverick (ich glaube, genau das meintest Du)? Vielleicht wäre das was für ein eventuelles zweites Buch.
Diese PlugIns, sollten die in einer DLL vorliegen?
Jedes PlugIn, also jeder Modifikator, könnte definieren, welche Daten es als Eingabe braucht, und welche es verändert.

Ich muss sagen: Es macht Spaß, sich so eine feine Architektur auszudenken Nur die Implementierung wird sicher nicht ganz ohne werden...

Ich hatte an sowas auch schon beim ersten Buch gedacht, aber letzten Endes mich doch für ein viel einfacheres, weniger modulares Modell entschieden. Das modulare Modell ist zwar sehr elegant, und wenn man einmal die Grundlagen hat, dann ist es wohl recht einfach, es noch zu erweitern - aber ein Einsteiger würde wahrscheinlich dann das Buch zuklappen und denken: "Was soll der ganze umständliche Scheiß? Ich will doch nur ein paar einfache Objekte darstellen!".

Du kannst dich mal kaputt lachen, selbst die Vulpine Vision basiert nicht auf einem PlugIn System, traurig aber deutsche Realität. Klar braucht man einige zeit dafür, bis das PlugIn system ausgereift ist, und man die Admin Klasseen zusammen hat, aber die arbeit lohnt sich. Bevor man etwas anfängt sollte man erst mal evaluieren.

Schau dir das mal an:

http://www.marcospoerl.de/de/projekte/ik/index.html

Was sollen die Bone Animationen (PlugIn’s) können, nur für Charaktere, oder für jegliche art von Objekten? Eventuell, sollte man soweit gehen können, das man Node’s mit Gelenken verbinden kann, die winkelbeschräkugen haben für technische Objekte, wie kann man dazu eine grundlange schaffen, die beliebig erweiterbar ist? Das eigentliche Rendern ist nicht das Problem. Denk mal nicht an die altmodische art, sondern, wie würde dies in einem Graphen aussehen?

Klar würde ich dir bei deinem 2ten Buch helfen, wenn dies erwünscht ist. Aber das können wir mal über ICQ bequatschen. #125088463

mfg

Maverick

Nätürlich könnte man alles auch fest in C++ einbinden. Aber dann könnte man nicht einfach mal eben schnell ein neues Level dazupacken. De Leveleditor müste dann den Code des Games neu Kompilieren.

Der Vorteil in einer Scriptsprache liegt ja grad darin, das man das nicht brauch, und abläufe verändern, löschen oder hinzufügen kann, ohne dabei das Game neu Kompilieren zu müssen.