Spieleprogrammierung

[Whiz-zarD]

Will man jedoch sich richtig ernsthaft mit der Materie befassen, reicht C# alleine nicht aus. Zumindest nicht auf Dauer. Will man die ganzen Hintergrundabläufe kennen lernen und auch verstehen ist ein Weg über C++ unumgänglich.

Und warum?
Nur weil der Programmierer unter C# nicht mit Zeigern jonglieren muss?

Ich sehe da nicht wirklich einen Grund, wieso man bei Spieleentwicklung unbedingt auf C++ greifen muss. Es ist ein Mythos, der immer noch seine Runden dreht, aber C# ist auch performant genug, um damit Spiele zu entwickeln. Die Entwicklung der XBox Spiele läuft ausschliesslich unter C#.

Den sog. Game Loop, muss er sowieso implementieren. Da ist es egal, obs C, C++ oder C# ist. Selbst mit dem XNA Framework muss er noch den Loop implementieren. Wenn auch in einer einfacheren Art und Weise.

 

[antred]

Es soll wohl sogar Spiele geben, die in noch 'langsameren' Sprachen wie z.B. Python entwickelt worden sind. Ich denke auch, daß C++ heute für die Spieleentwicklung nicht mehr zwingend notwendig ist.

 

[CrazyIwan]

@Whiz-zard
Das mit der XBox und C# stimmt überhaupt nicht! Nur weil du als "Indie" bei XBox auf XNA zurückgreifen musst, wird auf XBox sonst nichts ausschließlich mit C# entwickelt. Du kannst nicht mal ohne weiteres dein Spiel, egal wie gut es ist und sogar auch wenn du einen Publisher hinter dir hast, in XBLA platzieren wenn es mit XNA entwickelt wurde! Da ist von Microsoft nicht mal richtig vorgesehen. Die mesten Spiele auf XBLA sind C++ Spiele.

Außerdem, Zeiger sind nicht das einzige was C++ ausmacht. Allein schon GarbageCollector unter C#, auch wenn der gut ist, ist nicht immer kontrollierbar und kann dir mächtig Performance-Einbrüche bescheren.

@antred
Wie bereits gesagt, man kann auch Spiele in absoluter High-Level Sprache entwickeln, aber es bleibt Oberfläche und der TE will in die Materie gehen.

 

[Whiz-zarD]

Bei den heutigen Maschinen fällt der Garbage Collector kaum noch ins Gewicht.
Selbst das oft zitierte "Java ist sooo langsam" stimmt nicht. In der Schule hatten wir C Code nach Java portiert und die Rechenzeit gemessen. Java war nur geringfügig langsamer als C.

Bei C++ musst du dich aber dann mit Speicherlecks rumplagen, wenn du dann nur eine Kleinigkeit vergisst und diese Fehler zu korrigieren, kosten Zeit und Geld. Dann nehm ich lieber eine Sprache, mit einem Cargabe Collector, der vielleicht ein wenig mehr Performance frisst, aber dafür meinen Speicher sauber hält.

 

[CrazyIwan]

Das mit Speicherlecks stimmt, aber dennoch halte ich den Weg zu Spielen mit C++ als sehr sinnvoll. Genau aus dem Grund, dass man vieles falsch machen kann ist es das beste Weg um zu lernen.

Ob Java nur geringfügig langsamer war/ist als C sei man dahingestellt. Ich will hier kein Programmiersprachekrieg entfachen. Dafür gibt es im Internet genug Foren, Themen, Blogs und Chats.

Mir geht es auch nicht um Geschwindigkeit, nicht um Pointer und dem GarbageCollector an sich. Mir geht es darum, das man in die Spieleentwicklung, und ich meine damit wirklich die tiefe Materie, hauptsächlich über C++ findet. Nicht weil es die beste oder die schnellste Sprache ist, sondern weil man noch selbst auf sehr viel achten muss und damit sehr viel lernt. Im Gegenzug erhält man die Kontrolle, über die man sonst in keiner bzw. weniger Sprachen verfügt.

Kein Engine, kein Framework, oder Blackbox wird dem TE das leren, was er durch Erfahrung und eigenständigem Aufwand sich selbst beibringen kann. Und glaub mir, wenn man schon fähig ist ein simples 2D Spiel zu erstellen, ist der Zugang zu allen anderen Sprachen um einiges leichter.
Beherrscht man die Grundlagen. sollte man auf das umsteigen was einem Spaß macht, oder zumindest was einem näher liegt. Sei es XNA, nur C#, Jaba, Python, Unity mit UnityScript oder gar Assembler

 

[antred]

Speicher und andere Resourcenleaks sind in C++, wenn man sich strikt an RAII hält, eigentlich gar kein Problem mehr. Wer davon nichts hält und sich lieber mit explizitem Managment von Resourcen herumplagt, der hat das Problem natürlich nach wie vor. Das trifft aber auf Java genau so zu, denn Garbage Collection kümmert sich nur um Speicher - es gibt aber jede Menge anderer Resourcen, die man eventuell auch in irgend einer Form freigeben / releasen / unlocken / was auch immer möchte (und dann bist du in Java sogar schlechter dran als in C++, denn Java kennt kein RAII). Wollte ich nur mal am Rande anmerken.

 

[Tumbleweed]

Nur der Vollständigkeit halber sei erwähnt, dass ein garbage collector kein Allheilmittel für memory leaks ist. Wenn der Coder trieft, dann kann es durchaus memory leaks geben, weil noch Referenzen bestehen, auch wenn Objekte nicht mehr aktiv benutzt werden.

Ich hatte nur einen relativ kurzen Ausflug zu C++ und muss sagen, es hat mir sehr geholfen das Speichermanagement besser zu verstehen. Wenn man sich von Anfang an auf den GC verlässt und vielleicht im schlimmsten Fall sogar gelehrt bekommt "damit brauchst du dich um nichts mehr kümmern", dann hat man vermutlich nicht mal Ahnung wo der Unterschied zwischen heap und stack ist.

Dass C++ in der Spieleprogrammierung so etabliert ist, hat sicher auch in gewissem Maße historische Gründe. In die Sprache sind einfach viele Programmierer hineingewachsen und da Spiele für lange Zeit Projekte kleinster Entwicklerteams waren, wurden Punkte wie Wartbarkeit eher weniger gewertet als heute, wo riesige Teams an einigen Spielen arbeiten.
Für Spiele kleineren Umfangs wie z.B. im Mobile-Bereich ist Java doch auch sehr gut vertreten und Objective-C (würg) als Konkurrenz haben wir nur Apple zu verdanken.

Theoretisch kann man ja in Java (und vermutlich auch in C#) problemlos für OpenGL entwickeln. Das setzt sich aber bisher nicht wirklich durch. Ich war enttäuscht, als ich nach einer vernünftigen 3D API für Java gesucht habe. Java3D scheint tot und reines OpenGL in Java ist mir zu low level.
Das braucht Java aber auch nicht zwangsweise. Es glänzt dafür im server backend Bereich. C# dafür bei GUI-lastigen Tools, usw. Daher sollte man sich (wie schon erwähnt) nicht auf eine bestimmte Sprache versteifen.

 

[Xetoxyc]

und wieder sind wir wie schon sooo oft zu dem entschluss gekommen es gibt keine "perfekte" sprache die für alles das beste is
der eine macht gern was mit C# und es ist perfekt für seine anwendung
der andere kommt mit C# nicht in schuss da is unbrauchbar für seine anwendung is

und wenn man ehrlich is an die performance von c++ kommt einfach nichts ran
und das speichermanagment mag "schwierig" erscheinen
mit dem nötigen wissen aber nicht
und sagn wir mal so
wer c++ kann kann den rest schon lang ;P
deswegen würd ich mal sagen das c++ eine super wahl is weil einfach alles damit offen steht
würd dir auch das buch C++ für Spieleprogrammierer empfehlen is meiner ansicht nach eins der besten fachlektüren überhaupt

 

[Marco01_809]

Eine "perfekte" gibt es vielleicht nicht, aber die mit den meisten Vorteilen für 3D-Spiele-Programmierung gibt es, man kann das nur nicht richtig ausdiskutieren weil i.d.R. in jedem Forum davor immer 'nen Admin den Thread dichtmacht

C++ hat mittlerweile schon viele Jahre auf dem Buckel, durch die Abwärtskompatibilität gibt es auch viele "Unschönheiten" in der Sprache. C++ ist aber ein wenig schneller als andere Sprachen und es gibt die meisten 3D-Engines dafür. Für einen einzelnen ist C++ für 3D aber garantiert nicht so gut, da lieber auf C#+XNA oder Java+JME

und wenn man ehrlich is an die performance von c++ kommt einfach nichts ran

Assembler ist schneller, allerdings nicht OOP und auch viele andere Sprachen kommen schon an C++ ran, überholen es allerdings nicht.

 

[Mike Lowrey]

Der größte Vorteil von C# ist das Alter. Die Sprache ist relativ jung, hat aber quasi alles an Inspiration mitgenommen was zur Verfügung stand.

Das C++ schneller sein kann ist unbestreitbar, dass man aber bei unmanaged Code auch viele Probleme haben kann ist wenig verwunderlich.

Letztlich ist entscheidend was Ziel und Basis ist. Klar ist managed Code ist die Zukunft(spätestens mit mehre Hardware Erweiterungen die selbigen beschleunigen), da überwiegen einfach die Nachteile von unmanaged Code.
Zugleich muss man aber auch festhalten, dass insbesondere .Net der Inbegriff davon ist Hintergründe vor dem Programmierer zu verstecken.
Das ist Vorteil wie Nachteil. Man muss sich beispielsweise bei der SyndicateFeed Klasse nicht mehr um Basics des rss feed parsing kümmern. Hat dafür aber eben auch weniger Einfluss auf das Ergebnis.