Green Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 Joh...lange nix mehr gepostet, aber jetzt bin ich ja wieder da. Das Thema ist etwas heikel. Ich würde gerne Spiele programmieren, und ich würde gerne wissen wie realistisch das ist, oder wie unrealistisch meinetwegen. Vielleicht hat ja schon mal ein Spiel programmiert. Ich fänds toll Kontakt zu jemandem zu schließen der mir in dieser Richtung vielleicht etwas beibringen möchte. Bis dahin, der Green, der !! Zitieren
lpd Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 Hmmm... ich kannte da mal jemanden, vielleicht finde ich seine Adresse noch.... Spieleprogrammierung ist so schwierig nicht. Solange du nicht auch noch die Grafiken entwirfst.. Zitieren
Topf Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 Mich würde dazu noch interessieren in welcher Sprache man am besten spiele programmieren kann..? ich nehme an C++?? Zitieren
CtrlAltEnt Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von littlepunkdog: <STRONG>Hmmm... ich kannte da mal jemanden, vielleicht finde ich seine Adresse noch.... Spieleprogrammierung ist so schwierig nicht. Solange du nicht auch noch die Grafiken entwirfst..</STRONG> Zitieren
Green Geschrieben 12. Oktober 2001 Autor Geschrieben 12. Oktober 2001 Also was die Grafik Engine angeht, da gibr es einige die Open Source sind, und totally free. Beispielsweise Genesis3D .. die fand ich ganz passabel. Ich habe heute eine Menge gelesen, weil mich das Thema reizt muss ich zugeben. Allerdings .....ich kann zwar programmieren ( naja ) aber deswegen weiß ich noch nicht wie ein Spiel programmiert wird. Es muss ja nicht DER Oberknaller sein....aber auch kein 4 gewinnt oder so... Der Green, der !! Zitieren
Green Geschrieben 12. Oktober 2001 Autor Geschrieben 12. Oktober 2001 <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von Topf: <STRONG>Mich würde dazu noch interessieren in welcher Sprache man am besten spiele programmieren kann..? ich nehme an C++??</STRONG> Zitieren
dirk12345 Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 jupp gibt auch welche die meinen es sei mit VB möglich(ist es vielleicht sogar keinplan...) Zitieren
Green Geschrieben 12. Oktober 2001 Autor Geschrieben 12. Oktober 2001 Möchte vielleicht noch jemand etwas zu diesem Thema schreiben??? Zitieren
CtrlAltEnt Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 rein theoretisch kannste auch mit java nen ego-shooter programmieren, das problem ist nur mit C++ ist es viel schneller. (also nicht das programmieren an sich, aber die engine) Zitieren
Crush Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 Ich habe gelesen, daß die ersten Java-3D-Classes schon im entstehen sind. Allerdings läßt die Geschwindigkeit wohl sehr stark zu wünschen übrig. Also gleich C/C++ -> darauf basiert fast alles was im 3D-Bereich gehandhabt wird. Ich habe aber schon ganz gute Spielchen in Blitzbasic gesehen -> auch hierfür gibt es schon eine 3D-Version (und die ist gar nicht mal langsam). Jedenfalls die Blitzbasic-Mario-3D-Version flutscht flüssig vor sich hin und man kann auch mal in, um und über die Burg spazieren gehen. Für 2D ist eigentlich alles ausreichend, was es auf dem Markt gibt. Ich empfehle C/C++. Zitieren
backdraft Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 Wie ist das eigentlich generell? Mal angenommen ich möchte jetz ein Spiel proggen. Ne Idee hab ich auch schon, C++ kann ich einigermaßen und dann? Wie läuft das ab, mit Grafik, 3D Engine und so??????? :confused: :confused: :confused: :confused: :confused: :confused: :confused: :confused: Gibt's speziell dafür ein gutes Buch? backdraft Zitieren
lpd Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von Green: <STRONG>Ich habe auch in meiner Recherche bemerkt das einige Delphi programmierer der Meinung sind, mit Delphi wäre das genauso möglich.</STRONG> Zitieren
lpd Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica, sans-serif">Zitat:</font><HR>Original erstellt von backdraft: <STRONG>Wie ist das eigentlich generell? Mal angenommen ich möchte jetz ein Spiel proggen. Ne Idee hab ich auch schon, C++ kann ich einigermaßen und dann? Wie läuft das ab, mit Grafik, 3D Engine und so??????? Gibt's speziell dafür ein gutes Buch? backdraft</STRONG> Zitieren
Rohde Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 Da Du nichts über Deine Programmierkenntnisse schreibst, fällt es schwer, Dir eine entsprechende Antwort zu geben. Aber hier ein paar Links zum Thema: http://www.games-net.de/ http://www.usf.de/start_d.shtml http://www.untergrund-spiele.de http://www.geocities.com/SiliconValley/Vista/6774/ http://www.game-developers.net/ Zitieren
Crush Geschrieben 12. Oktober 2001 Geschrieben 12. Oktober 2001 Also es ist wesentlich einfacher mit BMPs zu arbeiten, da hier die Daten unkomprimiert als DIBs in einfachen Format vorliegen und somit ganz leicht einzulesen sind (das braucht man auch für die Texturen der Polygone bei 3D). Du mußt bei 3D-Programmierung erst mal wissen, wie das gemacht wird. Das ist sooooo einfach wirklich nicht ... aber auch mit der heutigen Technik und Unterstützung durch die Grafikkarten auch nicht mehr soooooo kompliziert. Früher mußte man noch wie wild die Flächen sortieren, Objekte Sortieren, überhaupt alles sortieren. Heute reicht es aus einigermaßen zu wissen, welche Objekte sich im Viewing Frustum befinden (das ist der Bereich zwischen der Far Clipping und der Near Clipping Plane - halt dem sichtbaren Bereich der vom Monitor in den Raum "hineinragt"). Dann einfach alles reinzeichnen lassen und Z- oder W-Buffer erledigen das selber, was sichtbar ist und was nicht. Genauso ist ein Clipping von Linien am Bildschirm nicht mehr von Hand notwendig (es ist eben alles auch einfacher geworden). OK, abgewandte Flächen müssen nicht unbedingt gezeichnet werden (Flächen-Normale zeigt vom Betrachter weg), aber ich sehe das bei heutiger CPU- & GFX-Power eher als Optimierung an. Das Berechnen der Punkte im Raum ist so einfach, das man sich krümmen könnte vor Lachen. Die Leute sagen, daß die Mathematik so kompliziert ist und vergessen dabei, daß man das Rad ja nicht 1000 mal neu erfinden muß. Das bedeutet: Die Formeln hierzu sind (eigentlich) IMMER gleich, also schreib ich das Grundlegende halt kurz auf: Der Mittelpunkt liegt bei (0|0|0) Das Objekt wird um seinen Mittelpunkt gedreht. 3 Rotationen: Rotationen nur dann durchführen, wenn auch die Winkel von 0 abweichen. Winkel=a,b,c Koordinaten des 3D-Punkts: x,y,z 1) Rotation um die x-Achse = x-bleibt also gleich y = y*cos(a) + z*sin(a) z = z*cos(a) - y*sin(a) 2) Rotation um die y-Achse = y-bleibt also gleich x = x*cos( - z*sin( z = z*cos( - x*sin( 3) Rotation um die z-Achse = z-bleibt also gleich x = y*cos© + x*sin© y = x.cos© - y*sin© Vergrößern/Verkleinern ist jetzt ganz einfach machbar: x=x*Faktorx ; y=y*Faktory ; z=z*Faktorz Verschieben = Raumpositionen x,y,z zu Raumpunktxyz dazuaddieren oder subtrahieren Wenn vom Objekt gesprochen wird, wird nochmal auf das gesamte Objekt eine Rotation, Verschiebung, Skalierung und Transformation durchgeführt. Die Beobachterposition ist erneut eine Welt-rotation, -verschiebung, -skalierung & -transformation (puh). Also muß man immer vom Maßstab und der Betrachtungsweise beim gesamten ausgehen. Soll das Objekt nun um einen Punkt im Raum rotiert werden (R1), so muß man von den Objekt-Koordinaten x,y,z einfach R1(x,y,z) abziehen, die Rotationen wie oben durchführen und wieder R1(x,y,z) dazuaddieren. Das ist auch innerhalb eines Objekte die Methode, mit der z.B. Finger animiert werden. Jedes Gelenk ist halt ein R. Hier muß man sich vom Gelenkansatz bis zum Endgelenk mehrfach durcharbeitet und alle in der Hierarchie darunter liegenden Punkte und Gelenkpositionen mit verschieben und rotieren. ACHTUNG: Erst drehen und dann verschieben ergibt ein komplett anderes Ergebnis als verschieben und dann drehen, am Besten ausprobieren. Ob ein Dreieck sichtbar ist, muß anhand der 3 Punkte berechnet werden. Wichtig ist dabei, daß die Punkt im Uhrzeigersinn a(x1,y1), b(x2,y2), c(x3,y3) angeordnet sind, sonst wird das Ergebnis negiert. V(isible)=(x2-x1)*(y3-y1) - (x3-x1)*(y2-y1) V=Positiv -> sichtbar, ansonsten unsichtbar, erst gar nicht zeichnen lassen. Zentralprojektion für perspektivische Verzerrungen: P(x,y) = Bildschirmkoordinaten Q(x,y,z) = Koordinaten des zu projizierenden Punktes Z(x,y,z) = Zentrum der Projektion Px = (Zx*Qz-Qx*Zz)/(Qz-Zz) Py = (Zy*Qz-Qy*Zz)/(Qz-Zz) Px & Py sind nun zeichenbare Bildschirmkoordinaten! Das reicht schon vollkommen aus um ein richtiges 3D-Demo oder gar 3D-Spielchen zu machen. Jetzt fehlen natürlich noch Routinen für Kollisionen, die Texturen richtig drüberzulegen, Objekt-Bewegungen, eine Physik-Engine (Steiner fallen nicht nach oben), eine Partikel-Engine (damit Feuer und Staub oder auch Max´s Pistolenkugeln korrekt durch die gegen fliegen), Pathfinder, bzw. KI- oder AI-Funktionen, damit sich auch die beweglichen Objekte korrekt bewegen und Scipt-Engines, damit Aktionen auch Zeitgerecht ausgeführt werden und auch bestimmte Handlungen nur in bestimmten Situationen ausführbar sind. Natürlich wird jetzt nicht von irgendwelchen Optimierungen wie BSP-Trees, Octrees oder den Unterschied zwischen Indoor & Outdoor-Engines gesprochen, aber wenn Du das oben drauf hast kannst Du dich da ganz problemlos ranwagen. Mir sind aber auch ein paar Tricks von Demo-Codern bekannt, die ich in noch keinem Tutorial sonstwo gesehen habe (hehe). Komischerweise aber auch in (fast) noch keinem Demo! Fast alle Formeln oben sind schwer vereinfachbar, allerdings auf Kosten von Genauigkeit und Flexibilität, aber wenn´s keiner optisch merkt :-> Vielleicht sind auch ein paar Errungenschaften durch die Bequemlichkeit einer schnellen CPU in Vergessenheit geraten. Aber wenn man ein wenig nachdenkt findet man hunderte von Beschleunigungsmethoden allein für die o.g. Dinge ... Man darf aber auch nicht vergessen, daß es fast noch mehr Aufwand ist das ganze mit OpenGL oder DirectX umzusetzen, weil hier noch unheimlich mit zig Funktionen und Strukturen gearbeitet werden muß. (Vor allem bei DirectX muß man sehr viel mehr Hand anlegen, kann dadurch aber die Ergebnisse prima optimieren - OpenGL ist für den Einstieg wesentlich einfacher zu handhaben und ist leichter portierbar auf andere Rechner). Man sollte aber auch nicht vergessen, daß bestimmte Konvertierungstools erstellt werden müssen, damit die Objekt- und Welt-Daten schnell ins Programm eingelesen werden können, bzw. wie man seine Weltdaten im Programm verwaltet. Das ist auch noch mal ein Thema für sich, genauso wie Editoren für alles mögliche (z.B. die Scripts. Stichwort: Hot-Spots setzen). Achso, die Sound-Engine, Joystick-Abfragen und Menüs für Optionen, etc. darf man natürlich auch nicht vergessen. Auf jeden Fall solltest Du jetzt einen kleinen Vorgeschmack auf 3D-Programmierung bekommen haben und kannst Dir auch überlegen, ob es was für Dich ist oder nicht. Spieleprogrammierung ist heute auf jeden Fall ein hartes Stück Arbeit geworden und der Aufwand hierfür übertrifft locker viele sog. industrielle, bzw. kommerzielle Anwendungen und kann somit als Creme-de-la-Creme der Programmierung betrachtet werden. (Es gibt auch kaum etwas Flexibleres) <FONT COLOR="#a62a2a" SIZE="1">[ 12. Oktober 2001 22:46: Beitrag 4 mal editiert, zuletzt von Crush ]</font> Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.