spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ein eifaches 2d-Spiel zu programmieren ist nicht besonders schwierig. Wenn du dich mal in die Materie eingearbeitet hast und alle Punkte des Buches gut verstehst, kannst du mal versuchen das Spiel aus Kapitel 12 zu erweitern oder ein Männchen auf dem Bildschirm per pfeiltasten herumgehen lassen etc. So hab ich angefangen, das war sofort nachdem ich das Buch durch hatte.

//Edit: Praxis bekommst du, indem du Programmierst Lass dir was einfallen. Ein einfaches Konsolenspiel oder eine Anwendung die dir bei der Arbeit hilft oder einfach nur eine Spielerei etc.

Naja neido schon sagte. Praxist im Programmieren bekommst du nur durchs Programmieren. Mach kleine Schritte überlege dir kleine Erweiterungen für den Code aus dem Buch, lese weitere Bücher. Und programmieren, programmieren, programmieren.

Natürlich kann man ein Spiel auch komplett ohne Klassen schreiben. Doch wenn du das Klassenkonzept noch nicht verstanden hast, solltest du vielleicht ein bischen länger an den Grundlagen arbeiten bevor du ein 2D Spiel beginnst.

Wie die anderen schon gesagt ham Praxis bekommt man durch üben und was auch zum teil hilft ist wenn wann sich den Qellcode von anderen Programmierern anschaut und versucht ihn zu verstehen.

Oder andere hatten ein ähnliches Problem.

Die ham ein Problem vielleicht anderes gelöst und so kennst du noch einen Lösungsweg.

Ich hab mich durch die Tribase-Engine gekämpft und den großteil verstanden. David hat sich viel überlegt wie er die geschrieben hat, und manchmal hab ich mir gedacht: "Wau der hat das genial gelöst :idea: " Manchmal klapts nicht auf anhieb, aber das ist ja nicht so schlimm.

Oder zB. beim Wordcount hat mein Lehrer auch nen interessanten anzatz gehabt.

Ich möchte aber nicht stupides copy and paste fördern, man sollte nur dann kopieren wenn man genau versteht was der Code macht.

Gruß Raimund .

Mein erstes Spiel (VB.NET & DirectX :oops: ) bestand nur aus einer riesigen Schleife. Kopiert im Sinne von Copy & Paste habe ich damals nichts, ich hab mir die Infos zur initialisierung und zum blitten etc. aber auf einer damals schon uralten Seite besorgt.

So hab ich zumindest grob begriffen, wie es bei der Spieleprogrammierung läuft. Mein zweites Spiel hab ich dann in C++ & SDL geschrieben, mit vi als Entwicklungsumgebung. Das war dann schon was ganz anderes. Habe dann direkt alles auf Klassen ausgelegt und soweit möglich Vererbung etc. benutzt.

Was ich damit sagen will, wenn du die ersten 2 oder 3 Versuche codetechnisch totalen Murks produzierst wird dir keiner böse sein, aber du solltest dir einen guten Stil zulegen. Wichtig ist, dass du praktisch in das Thema reinfindest. Ich weiß nicht wie das mit den Spieleprogrammierer-Büchern ist (ich hab keins), aber bis jetzt hab ich am schnellsten gelernt wenn ich einfach irgendwas sinnloses zusammengehackt und damit rumgespielt habe.

Um einen guten Programmierstil zu entwickeln, empfehle ich dir ein gutes Buch, das sich nicht unbedingt (nur) der Spieleentwicklung widmet. Ich benutz für C++ z.B. O'reilly-Bücher, die mich wirklich sehr viel weiter gebracht haben.

Zum kopieren, ich würde das nur bedingt gutheißen. Die Kontrollstrukturen bei einer Programmiersprache sind meist gleich, der Rest ist denken. Und das solltest du schon bei banalen Problemen üben, sonst kommst du bei den richtig dicken Dingern nicht weiter. Wenn du dann nix zum kopieren hast sieht es düster aus.

Zielsuchende Geschosse haben mir damals die eine oder andere Nacht geraubt, aber als es lief war ich umso froher

Noch ein kleiner Tipp am Rande:
Ein meiner Meinung nach unheimlich wichtiges Werkzeug um deine Programme zu verstehen ist der Debugger.
Auch wenn der eigentliche Zweck ein anderer ist, um zu verstehen wie dein Programm abläuft gibt es nichts praktischeres als das Programm Schritt für Schritt durchrechnen zu lassen.
Das wird meiner Meinung nach ziemlich unterschätzt. Die meisten der Anfängerfragen hier im Forum würden sich klären wenn der Fragende sein Programm mal Schritt für Schritt im Debugger nachvollzogen hat.

Zitat von »"xardias"«

Auch wenn der eigentliche Zweck ein anderer ist, um zu verstehen wie dein Programm abläuft gibt es nichts praktischeres als das Programm Schritt für Schritt durchrechnen zu lassen.

Verstehe ich das richtig, du schreibst dein Programm und dann erst versuchst du es zu verstehen? :-)

Ich würde eher sagen, man schreibt ein Programm (so wie es funktionieren soll) und wenns dann nicht klappt schaut man mit dem Debugger wie es wirklich funktioniert

Also sogesehn schreibt man erst und versucht dann (den Fehler) zu verstehn

Zitat von »"knivil"«

Zitat von »"xardias"«

Auch wenn der eigentliche Zweck ein anderer ist, um zu verstehen wie dein Programm abläuft gibt es nichts praktischeres als das Programm Schritt für Schritt durchrechnen zu lassen.

Verstehe ich das richtig, du schreibst dein Programm und dann erst versuchst du es zu verstehen? :-)

Ich nicht. Aber viele Anfänger kopieren sich Quelltext zusammen und haben nicht ganz verstanden was welche Anweisungen/Konstrukte bewirken und benutzen diese unter diesen falschen Annahmen.
Dort ist es eben verdammt hilfreich sich das vom PC mehr oder weniger vorrechnen zu lassen