Spieleprogrammierer Buch
-
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.
