Spieleprogrammierer Buch
-
Nein, ich möchte auch eigene Spiele programmieren.
Aber wie soll ich ohne jegliches Vorwissen Spiele programmieren? Einpaar Beispiele wären für dne Anfang schon nicht schlecht.
Oder kennst du irgendein Spiel das nur aus Variablendeklarationen besteht?
-
Guck mal auf www.zfx.info . Das ist die Seite von Stefan Zerbst, der hat schon einige gute Bücher über Spieleprogrammierung geschrieben...
-
das erinnert mich an den CPC.. da konnte man Seitenweise Basic Code abtippen und man hatte sein Spiel
-
@personenkult: aber so konnte man sehr viel lernen, ich halte von dieser Vorgehensweise immer noch viel, leider sind die Quelltexte einfach zu groß geworden. Und einfach von CD laden? Naja, da entfällt ja das wesentliche...
Trotzdem kommt das Buch von Riker der Sache schon relativ nahe:
Man bekommt ein fertiges Spiel zum Buch... hat gewisse Vorteile im Gegensatz zu Büchern, wo man nur einfach sich durch Codebeispiele ohne Zusammenhang quält.
Für 2D ist dieses hier ähnlich:
-
Du hast recht wenn der Quellcode nicht zu lang ist und der Code in einer Sprache ist die man leicher verstehen und anwenden kann als C/C++
Heute ist es um einiges schwerer geworden. Der C64 hatte noch Sprite und die 2D Programmierung ist einfacher zu verstehen als die 3D PRogrammierung.
Also erfordert es eine Menge an Vorwissen um den Code zu verstehen.
- C/C++ beherschen
- WinAPI beherschen
- DirectX oder OpenGL beherschen
- eines der vielen 2D/3D Enginen beherschen oder eine eigene schreibenJa und das beste zum Schluss. Damals gab es ein System. z.B den C64 oder einen Amiga. Heute wissen wir gar nicht mehr für was wir entwickeln. Ist es ein Pentium oder ein AMD. Ist es ein ATI oder ein nVidia. Hat er 1024MB Ram oder weniger. Kann die Grafikkarte das oder kann sie es nicht etc...
-
ZuluAlphaTangoBravo schrieb:
Ja und das beste zum Schluss. Damals gab es ein System. z.B den C64 oder einen Amiga. Heute wissen wir gar nicht mehr für was wir entwickeln. Ist es ein Pentium oder ein AMD. Ist es ein ATI oder ein nVidia. Hat er 1024MB Ram oder weniger. Kann die Grafikkarte das oder kann sie es nicht etc...
Am Anfang muss man sich darum aber keine Sorgen machen...
-
Was ich nicht empfehlen kann ist:
- Tricks of the bla bla von La Mothe
- Die zfx-BücherDas Einzige Buch was bisher recht gut war war "Jetzt lerne ich DirectX 9.0 und C++", der Titel klingt zwar scheisse (ich hab auch die C++ Kapitel übersprungen) aber das ist das einzige Buch wo einem der Autor freie Hand lässt, bei allen anderen wird erstmal irgendwas tolles entwickelt oder standardmäßig die eigene tolle Engine verwendet ohne das man weiß wieso etc. Er benutzt nur standard C++, da lernt man dann weit mehr.
-
Ich würd sagen erstmal die Grundlagen lernen und dann mit der SDL einfache 2D Spiele Programmieren.Die SDL scheint mir jedenfalls einfacher zu sein als z.B. Direct X.
-
Dieser Thread wurde von Moderator/in kingruedi aus dem Forum Rund um die Programmierung in das Forum Spiele-/Grafikprogrammierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Ich würde wenn überhaupt ein "richtiges Programmierbuch" kaufen, auf keinen Fall so Pseudozeugs von Zerbst o.ä. Spiele programmieren ist am Ende halt auch "nur" Programmieren, also sollte man vornehmlich dies können.
Bye, TGGC (Wähle deine Helden)
-
Ich habe mir aus didaktischem Interesse auch schon einige Bücher zur Spiele-Programmierung in C/C++ angeschaut. Das Problem für einen Einsteiger in diese Materie besteht vor allem darin, dass er bei raschem Vorgehen (wer will das nicht?) bei 3D-Engines irgendwann nicht mehr weiß, an welchen Stellen in dem h/cpp-Verhau wirklich die für ihn relevante "Musik" spielt. Vieles ist ja für den Anwender zu Beginn "nur" Grundlage für die "Engine".
Ganz schlimm sind solche Autoren, die ihre Leser kapitelweise mit purer Vektor- und Matrizen-Mathematik erschlagen, ohne dass sich auch nur das Geringste am Bildschirm bewegt. Für Praktiker nahezu unerträglich.
Ja, was kann man denn überhaupt noch empfehlen?
Ned's Turkey Farm in dem Buch von Ian Purberry, "Learn Computer Game Programming with DirectX 7.0" ist für die 2D-Programmierumng echt lustig aufgezogen. Klasse Grafik, Musik und Sprüche. Da in kleinen Schritten vorwärts gegangen wird, kommt man auch als Anfänger mit. Der Spaß-Faktor erhält die Motivation.
http://www.amazon.com/exec/obidos/tg/sim-explorer/explore-items/-/1556227418/0/101/1/none/purchase/ref%3Dpd_sxp_r0/002-1711144-4000842Didaktisch erträglich ist auch das Buch von Ulrich Kaiser, "Spieleprogrammierung in C++" http://www.buecher.de/verteiler.asp?site=artikel.asp&artikelnummer=000001273661&wea=1100652
Sein 2D-Ultris-Beispiel ist zwar leider "staubstrocken", aber recht gut erklärt. Aus den verschiedenen Stadien abgeleitet kann man recht schnell eigene Ideen realisieren.
Für die 3D-Programmierung kenne ich bisher kein didaktisch gutes Beispiel, nur das berühmte Nehe-Tutorial, aber das ist OpenGL, nicht DX, also nicht empfehlenswert.
Vielleicht sollte man einfach mit Game Studio beginnen.
-
Ganz schlimm sind solche Autoren, die ihre Leser kapitelweise mit purer Vektor- und Matrizen-Mathematik erschlagen, ohne dass sich auch nur das Geringste am Bildschirm bewegt. Für Praktiker nahezu unerträglich.
leider läuft die 3d programmierung nicht ohne solide vorkenntnisse. wer nicht weis, was ein mathematischer vector ist, kann auch nichts auf dem bildschirm bewegen lassen geschweige denn anzeigen.
-
leider läuft die 3d programmierung nicht ohne solide vorkenntnisse. wer nicht weis, was ein mathematischer vector ist, kann auch nichts auf dem bildschirm bewegen lassen geschweige denn anzeigen.
Da wäre ich mir in der didaktischen Reihenfolge nicht so sicher. Man kann erst etwas auf einer höheren Verständnisebene "bewegen" und später verstehen, wieso das in einer bestimmten Weise realisiert ist. Die Mathematik ist zumeist allerdings nicht das Problem, sondern die Unterscheidung zwischen wichtigen (dort, wo man etwas programmieren kann) und "unwichtigen" (Basismodule, die man unverändert lassen sollte) Modulen (h/cpp bzw. h/lib).
Ich kenne allerdings nicht alle 3D-Bücher. Vielleicht gibt es doch ein lustiges, praxisnahes und verständliches Werk/Tutorial.
-
Da wäre ich mir in der didaktischen Reihenfolge nicht so sicher. Man kann erst etwas auf einer höheren Verständnisebene "bewegen" und später verstehen, wieso das in einer bestimmten Weise realisiert ist.
Schüler in einer Klasse schalten sofort ab, wenn sie was nicht verstehen.(oder friemeln sich irgendwas komisches zusammen) Das halt ich also nicht für didaktisch sinnvoll.
Die Mathematik ist zumeist allerdings nicht das Problem, sondern die Unterscheidung zwischen wichtigen (dort, wo man etwas programmieren kann) und "unwichtigen" (Basismodule, die man unverändert lassen sollte) Modulen (h/cpp bzw. h/lib).
damit implizierst du ja direkt, dass der user 3D programmierung anhand einer engine erlernen soll. Meiner meinung nach der falsche weg. Erst sollte der user wissen was er tut, bevor er damit arbeitet, und dafür braucht man basis mathematikwissen(das macht der Scherfgen meiner meinung nach gut, erst lehrt er die grundlagen mathematik/directX und stellt dann seine Engine vor, mit der mann dann weiter arbeiten kann).
-
otze schrieb:
Da wäre ich mir in der didaktischen Reihenfolge nicht so sicher. Man kann erst etwas auf einer höheren Verständnisebene "bewegen" und später verstehen, wieso das in einer bestimmten Weise realisiert ist.
Schüler in einer Klasse schalten sofort ab, wenn sie was nicht verstehen.(oder friemeln sich irgendwas komisches zusammen) Das halt ich also nicht für didaktisch sinnvoll.
damit bestätigst du ihn aber
wer erstmal mit unverständlicher mathematik erschlagen wird, schaltet wohl wesentlich eher ab, als jemand, der mit hilfe einer einfachen 3D engine erstmal ein bisschen experimentieren kann.aber letztendlich sind das 2 absolut gegensätzliche didaktische modelle.
sich vom trockenen basiswisen hocharbeiten oder gleich oben einsteigen und stück für stück lernen, was da tatsächlich passiert - "bottom-up" und "top down".
ich bevorzuge auch letzteres und glaube ersteres ist der grund, warum es gerade bei den hobby-spieleentwicklern nicht wirklich voran geht.
jeder newb, der mal ein bisschen reinschnuppern will, bekommt gleich an den kopf geknallt, dass er erstmal ein paar jahre C++ lernen muss (und womöglich auch noch ohne IDE anfangen sollte). fertige libraries und engines sind auch nicht gut, oft wird gar von der standard (!) lib abgeraten.
imho sollte jeder neuling ruhig erstmal eine gute, einfach engine nehmen, mit der man schnell gute ergebnisse bekommt. und nicht unbedingt C++, es gibt auch ne menge weniger unfreundliche sprachen. selbst wenns einer der diversen basic-dialekte ist.
sein wissen vertiefen kann man immernoch, wenn man tatsächlich mehr als tetris und snake programmieren will. aber soweit muss man auch erstmal kommen.
-
Es kann ja für manche der richtige Weg sein, sozusagen bottom up. Es gibt aber auch Personen, die wollen erst wissen, was sie mit dem Endprodukt anfangen können und ob sie selbst damit genügend Freiheitsgrade besitzen, um eigene Ideen zu realisieren. Wichtig sind Wechsel von DirectX n auf DirectX n+1, Importmöglichkeiten für alle möglichen Filetypen wie x, 3ds, etc. Wenn solche Dinge nicht einfach möglich sind, dann macht das Ganze z.B. von Anfang an keinen Sinn, bzw. man muss mit Substitutes nacharbeiten.
Ich halte den Weg, erst das Auto (die "game engine") zu fahren und dann unter die Motorhaube zu schauen für den einfacheren und praktischeren Zugang.
Damit ich nicht missverstanden werde: selbstverständlich muss man nach einiger Zeit die Grundlagen möglichst gut verstehen, aber m.E. nicht alles auf einmal am Anfang.
-
maximAL schrieb:
imho sollte jeder neuling ruhig erstmal eine gute, einfach engine nehmen, mit der man schnell gute ergebnisse bekommt.
Und das sind dann genau diejenigen, die dann nicht wissen, was der Datentyp "Texture" bedeutet, wie man 'nen Sternenhimmel macht oder Texturen auf einen Würfel legt.
Bye, TGGC (Wähle deine Helden)
-
TGGC schrieb:
maximAL schrieb:
imho sollte jeder neuling ruhig erstmal eine gute, einfach engine nehmen, mit der man schnell gute ergebnisse bekommt.
Und das sind dann genau diejenigen, die dann nicht wissen, was der Datentyp "Texture" bedeutet, wie man 'nen Sternenhimmel macht oder Texturen auf einen Würfel legt.
und die anderen wissen zwar, wie es geht, bekommen damit aber kein projekt zustande
-
Die Diskussion ist sicher nicht neu. Es gibt sozusagen einen bottom-up und einen top-down Weg. Der erste führt zu vertieftem Verständnis, der zweite zu praktischen Ergebnissen. Bücher mit dem bottom-up-Ansatz gibt es viele. Kennt jemand ein Buch, in dem der zweite Ansatz hervorragend gelöst ist, ohne dass das Grundverständnis verloren geht?
Nachtrag: Das Buch von David Schergen ist sehr gut, aber ebenfalls bottom-up und führt zu einer Engine (Tribase), die vor allem als Vorbild (oder was auch immer) für eine eigene Engine dienen kann. Nach seiner eigenen Aussage ist sie nicht für größere Projekte tauglich.
