Das Lernen von C++ | Spieleprogrammierung |
-
Guten Tag,
ich erlerne aktuell die Programmiersprache "C++" mithilfe eines Lehrbuchs autodidaktisch. Erfahrung in der Programmierung habe ich grundlagenbasierend mit C#/.NET gesammelt. Das heißt, die Grundlagen bis hin zur Objektorientierung sind mir bekannt.Mein Ziel ist es, später mit fundierte Kenntnisse in die Spieleprogrammierung zu gehen. Hierzu wurde mir unter anderem geraten, die Sprache C++ zu wählen. Hier stechen bei mir sowohl 2D als auch 3D-Programmierung in's Auge. In diesen Bereichen habe ich kein Wissen. In C# hat man einen guten Leitfaden. Es gibt XNA und damit schon eine integrierte Möglichkeit, die Lernphase fortzusetzen. Wie kann ich aber effektiv mit C++ zu diesem Ziel kommen?
Es gibt diverse (2D-)Bibliotheken wie z.B. SDL/SFML. Ebenso gibt es auf 3D-Basis DirectX sowie OpenGL. Andererseits gibt es, soweit ich weiß, sogar eine Grafikengine mit Namen "Ogre 3D". Mir fehlt nach Erlernen der C++ Syntax und Unterschiede der rote Faden.
Wie sollte ich, nach Durcharbeiten des Lehrbuchs, am besten fortfahren? Welche Wege sind sowohl zukunftsorientiert als auch für Lernzwecken geeignet?
Grüße,
IchiNi
-
Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x, bzw. C++11) 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.
-
Schnapp dir SFML und schreib kleine Spiele. Fang mit etwas einfachem wie Tic Tac Toe und Pong an und arbeite dich langsam über Tetris in Richtung eines kleinen Sidescrollers vor. Das dürfte fürs Erste genug Beschäftigung sein
-
dot schrieb:
Schnapp dir SFML und schreib kleine Spiele. Fang mit etwas einfachem wie Tic Tac Toe und Pong an und arbeite dich langsam über Tetris in Richtung eines kleinen Sidescrollers vor. Das dürfte fürs Erste genug Beschäftigung sein
Guten Tag,
danke für deine Antwort!
Erlernt man denn mit SFML irgendetwas, das einem später weiterhilft? Selbstverständlich bietet SFML viel Praxisbezug und dementsprechend sammelt
man auch ausreichend viel Erfahrung. Was genau bietet SFML einem aber beim Erlernen von spieleprogrammierspezifischen Aspekten?Frohe Weinachten!
Gruß,
IchiNi
-
Wenn du SFML benutzt, dann brauchst du dich erstmal nicht um die details der grafik sachen und sowas wie fensteröffnen machen. Du kannst dann erstmal lernen, wie man die Logik eines Spiels umsetzt.
Wenn du das irgendwann gut drauf hast, dann kannst du dich ja immer noch in opengl / directx einarbeiten.
Ich mache das zumindest auch so, dass ich erstmal mit highlevel bibliotheken arbeite und damit was bastle.
Falls ich irgendwann ganz viel zeit finden sollte, dann werd ich mir vll auch einen eigenen ersatz schreiben.Ich finde es aber mindestens genausowichtig, dass man weiß, wie man die logik eines spiels programmiert, als das man über jedes detail von opengl und winapi bescheid weiß.
Für den Anfang ist es auch viel motivierender mit SFML zu arbeiten, da man da schnell erfolge erzielt.
-
IchiNi schrieb:
Erlernt man denn mit SFML irgendetwas, das einem später weiterhilft? Selbstverständlich bietet SFML viel Praxisbezug und dementsprechend sammelt
man auch ausreichend viel Erfahrung. Was genau bietet SFML einem aber beim Erlernen von spieleprogrammierspezifischen Aspekten?Eine einfache Umgebung um das Wichtigste lernen zu können: Spieledesign. Was macht Spaß? Was nicht? Wo sind die großen Schwierigkeiten? SFML kümmert sich um viele technische Details wie zum Beispiel 2D-Grafik. So kannst du dich auf das wesentliche konzentrieren.
-
Beim Spieleprogrammieren stecken vll. 5% der Arbeit im Programmieren der Grafikschnittstelle, der Netzwerkschnittstelle, oder dem ganzen anderen Low-level Zeug. Bei 2D-Spielen sinds eher 1%, wenn überhaupt. Dieses Low-level Zeug solltest du deshalb erstmal auslassen und durch Libs wie SFML ersetzen, damit du zu den wichtigeren Sachen kommst:
Wenn du grade anfängst, dann verschlingt die meiste Zeit das Lernen von gängigen Algorithmen und Verfahren, die du auch für einen simplen Mario-Klon brauchst. Beispielsweise Kollisionserkennung und -auflösung (Physik), einfache AI (Wegfindung aka der heilige Gral der Spieleprogrammierung "A*" und State-Machines für Verhalten), Interpolationsmechanismen, sogar recht triviale Dinge wie zeitunabhängige Aktualisierungen oder ordentliches Gamestate-Management werden dir am Anfang gar nicht in den Sinn kommen und dann, sobald Probleme auftreten, die ein oder andere Stunde abverlangen weil du das Prinzip verstehen und dann den alten Code abändern musst.
Wenn du dann den Anfang hinter dir hast und ein "größeres" Spieleprojekt angehen willst,dann ist das, was dich als lernenden am längsten aufhalten wird auch wieder Dinge, die wenig mit Grafik zu tun haben (solang dein Projekt nicht wie bei vielen eine Engine ist die bessere Grafik produziert als Crysis) und die sich auf einer viel höheren und abstrakteren Ebene befinden. Dein World/Entity-System, deine Level oder Maprepräsentation inkl. Ablauflogik für Scripte, vll. Cutscenes, evtl. zufallserstelltes Terrain... die Liste ist extrem lange. Dazu kommt dann noch spielspezifische Ablauflogik (z.B. Kampf und Dialogsystem, etc.). Das ganze will dann auch noch von der Festplatte geladen und drauf gespeichert werden... Und am Ende merkst du, dass du 90% davon 90% simpler hättest machen können und in 10% der Zeit. Ganz zu schweigen davon, dass du die hälfte deines Frameworks noch nie benutzt hast...
Auch das gehört dazu, denn sowas lernt man beim Programmieren normalerweise nicht im Voraus, sondern hat die Erkenntnis erst danach.
Und das sind dann erstmal die technischen Dinge. Das, was dich am Ende mit Abstand die meiste Zeit kosten wird ist das Game-Design. Testen, merken dass es deinen Punkt nicht gut rüberbringt odre keinen Spaßmacht und ändern.
Dann überhaupt das allgemeine Erstellen der ganzen Assets (Levels, einfache Bitmapgrafiken, aussuchen der Musik im Internet oder wenn du es kannst und die Zeit hast gar selbst komponieren), um das du nie rumkommen wirst wenn du nicht grade komplett mit Programmer-Art (prozedural erzeugtes Zeug) auskommen kannst, wirst du selten rum kommen. Selbst wenns nur Vierecke mit paar Punkten drin sind, kostet dich das die ein oder andere Stunde.
Da kannst du OpenGL oder DirectX erstmal weit hinten stehen lassen. Früher oder später packt dich das Interesse daran aber trotzdem und du wirst es dir anschauen (so funktioneren Gehirne von Programmierern einfach), aber zur Vollständigkeit rate ich dir trotzdem: Schreib Spiele, keine Grafikengines.
-
travisg_off schrieb:
[...] aber zur Vollständigkeit rate ich dir trotzdem: Schreib Spiele, keine Grafikengines.
Genau.
Zusatz: schreib kleine Spiele, die du auch fertig bekommst. Und mach sie auch fertig. Nicht mitten drin fallen lassen und das nächste Projekt anfangen.Die Engine/Library die du für das erste Projekt verwendest ist dabei eher nebensächlich. Wenn du im Bereich Spieleprogrammierung tätig werden willst, solltest du dich schonmal darauf einstellen, dass du ständig dazulernen/umlernen musst. Ein grosser Teil der Techniken/Engines/Libraries die 2011 "state of the art" sind, werden spätestens 2014 wieder veraltet sein. Und 3 Jahre heisst im professionellen Bereich 1-3 Spiele (je nach "Grösse" des Spiels).
Und die Dinge die gleich bleiben, sind eben Engine-unabhängig.
-
Guten Tag,
ich bedanke mich noch einmal für eure Antworten und
wünsche euch noch einen guten Rutsch in's neue Jahr!MfG