Java/C++/C# als Werkzeuge der Spieleprogrammierung

xaoC

Danke für die Links!

Spielekonsolen miteinzubeziehen halte ich für etwas zu viel verlangt. Gerade im Hinblick auf die XBOX wäre XNA vielleicht der bessere Ansatz.

Playstation und Nintendo dürften zu speziell sein. Bleibt nicht mehr viel übrig.
Ich denke die 3 Kernplattformen Mac, Unix/Linux und Win dürften mehr als anspruchsvoll genug sein.

tim3d

Hallo xaoC,
nach meinen Recherchen setzen bereits eine ganze Reihe professioneller Spielestudios auf eine Kombination von C++ mit Python. Ein Beispiel für den kommerziellen Einsatz ist das MMORG Eve Online, das vollständig in Python gemixt mit C++ entwickelt wurde. Die Highend-3D-Grafik-Engine ist in C++ implementiert, während alles andere mit Python gecodet wurde. Die Entwicklungsgeschwindigkeit ist entsprechend höher. Python bietet den Vorteil, dass man die kritischen Spielbestandteile, die enormen Rechenaufwand verursachen, vergleichsweise problemlos in Module auslagern kann, die dann rein mit C oder C++ arbeiten. Weitere Beispiele für Python + C++ in der Spieleentwicklung: Civilization IV und Toontown.

Für kleinere Projekte und den Einstieg in die Spieleprogrammierung insgesamt ist der SDL-Wrapper Pygame auch ideal, der sehr einfach mit OpenGL/PyOpenGL kombiniert werden kann.

Im Blick auf C# kann man schon an den vielen neuen Buchveröffentlichungen in den USA ablesen, dass Managed DirectX mit C# sicher sehr an Bedeutung gewinnen wird, hinzu kommt die Aufmerksamkeit, die das XNA SpieleSDK von Microsoft bereits vor der eigentlichen Veröffentlichung auf sich zieht. Allerdings schätze ich es so ein, dass noch auf Jahre hinaus C++ die wichtigste Entwicklungssprache bleiben wird. Ergänzt mit einer guten Highlevel-Sprache wie Python, Lua, Ruby bleiben C++ (und C) die vorherrschenden Sprachen.

rapso

heutzutage setzt man meistens auf 3 komponenten

guter core (meist in c++)
data driven (vieles z.b. mit xml configurierbar)
highlevel languages/scriptsprachen bei denen unerfahrene wenig bis nichts falsch machen koennen (in bezug auf stabilitaet des systems)

scriptsprachen die oft verwendet werden sind lua(z.b.farcry,homeworld), python, JavaScript,und HLL sind java, C#(z.b. reality engine)/VB.Net

in diesem hinblick kann man XNA/managedDX auch ein wenig als den 'core' sehen den MS schon liefert, mit dem man dann wenig fehleranfaellig arbeiten kann.

also um deine frage "Die Frage ist: Ist Java/C# wirklich eine ECHTE Alternative zu C++?" zu beantworten: Nein, diese sprachen sind keine konkurierenden alternativen, sondern sich gut ergaenzende komponenten, und entsprechend gibt es leute, die auf einfache weise ein spiel scripten/coden wollen und es gibt leute die nur den core coden wollen ohne mit HLL gameplay schreiben zu muessen.

rapso schrieb:

in diesem hinblick kann man XNA/managedDX auch ein wenig als den 'core' sehen den MS schon liefert, mit dem man dann wenig fehleranfaellig arbeiten kann.

Dieser 'core' ist allerdings in C# geschrieben und damit in deinem Sinne als Alternative zu C++ verwendet worden.

hellihjb

es ist noch nicht sehr lange her als es undenkbar war, den "core" eines spiels nicht in assembler zu schreiben.
heute ist die situation etwas anders.
solang man den grafiktreiber einigermassen performant mit daten fuettert, kann man dazu eine beliebige hochsprache benutzen.
es ist relativ egal ob man dabei die haelfte aller cpu-taktzyklen verpulvert - hauptsache man verkuerzt die entwicklungszeit und steigert damit den gewinn.

this-*gt*that

Wie programmiert man eigentlich ein Spiel für ne Konsole wie Wii oder PS3? Benutzt man da nen Standard-API wie OpenGL bzw. ne propritäre API und kompiliert das mit nem Nintendo/Sony SDK Compiler?

hellihjb

Benutzt man da nen Standard-API wie OpenGL bzw. ne propritäre API und kompiliert das mit nem Nintendo/Sony SDK Compiler?

kurz gesagt: ja.

rapso

Optimizer schrieb:

rapso schrieb:

in diesem hinblick kann man XNA/managedDX auch ein wenig als den 'core' sehen den MS schon liefert, mit dem man dann wenig fehleranfaellig arbeiten kann.

Dieser 'core' ist allerdings in C# geschrieben und damit in deinem Sinne als Alternative zu C++ verwendet worden.

afaik sollte der managed dx 10 'core' in c++/cli sein, zu den davor weiss ich das nicht.

hellihjb schrieb:

es ist noch nicht sehr lange her als es undenkbar war, den "core" eines spiels nicht in assembler zu schreiben.

ja, vor knapp 20jahren

heute ist die situation etwas anders.
solang man den grafiktreiber einigermassen performant mit daten fuettert, kann man dazu eine beliebige hochsprache benutzen.
es ist relativ egal ob man dabei die haelfte aller cpu-taktzyklen verpulvert - hauptsache man verkuerzt die entwicklungszeit und steigert damit den gewinn.

und das kann man besonders gut inden man einen guten core nutzt. deswegen geben soviele ne million aus fuer ne engine.

xaoC

Ich hab mir mal ein paar Sachen angesehen. Ich kann Python zwar nicht, aber interessiert hat es mich eh schon seit langem.

Ich schliesse Java als Möglichkeit jetzt mal vorrübergehend aus. Mein Anliegen im Bezug auf eine Spiele-Framework muss folgendes erfüllen:

- Plattformunabhängigkeit für folgende Systeme: Mac, Linux, Windows

- Einfache Implementation von Standardaufgaben (File-IO, Textprocessing etc.)

- Sehr gute XML Implementation, da ich Gamecontent nach XML auslagern möchte. Dazu gehört ebenfalls die Darstellung von Klassen. Spieleobjekte werden also in XML abgebildet und auf entsprechende C++ Klassen gemappt.

- Als Engine würde ich gerne eine eher einfache OpenSource Engine wie Irrlicht benutzen, für meine Vorhaben mehr als ausreichend und Plattformunabhängig.

- NetzwerkLibs (bei Bedarf), SoundLibs (z.b. OpenAL) werden mehr als wahrscheinlich in C++ implementiert.

- Ich würde Scripting ersteinmal außen vor lassen. Um Spieleobjekte zu scripten ist Lua wahrscheinlich eher die bessere Wahl.

Am wichtigsten ist mir, so wenig wie möglich mit Betriebssystemspezifischen in Kontakt zu kommen. Ich habe wenig Lust mich mit Grundsatzimplementationen rumzuärgern die schon tausendmal besser implementiert worden sind.

Im großen und ganzen würde ich zeitliche Effektivität und Fehlertoleranz einem Höchstmaß an Geschwindigkeit vorziehen.

Möglicherweise bietet Python hier einen guten Ansatz, wobei ich mir da folgende Fragen stelle:

- Wäre die Anbindung entsprechender Engines in einen Python Grafikkontext unproblematisch? Das werde ich wohl mal ausprobieren...

@tim3D
Was meinst du mit "[...] während alles andere mit Python gecodet wurde"? Den 3D Teil größtenteils in C++ zu realisieren ist einleuchtend, aber ich denke Sound und (Realtime)Metzwerk z.B. rein über Python laufen zu lassen ist eher unwahrscheinlich...Wobei ich da nicht genug zu sagen kann eigentlich.

tim3d

xaoC,
Deine Anforderungen könnten auch auf folgende Kombination passen:
ClanLib (Server unter www.clanlib.org wird gerade umgebaut, daher vorübergehend: hier) plus das nette Monster Ogre. Mit Clanlib hast Du alles rund um die Grafik-Engine herum: vom Sound über Ressourcenverwaltung, GUI-Bibliothek bis hin zur Netzwerkunterstützung. Es ist ein feines Spiele SDK, das Objektorientierung groß schreibt und nicht trivial ist. Zeit und C++ Enthusiasmus sollten allerdings genügend zur Verfügung stehen.

Bei Eve Online ist massiv Stackless Python zum Einsatz gekommmen: siehe Präsentation von der PyCon2006 von den Entwicklern des Spieles CCP Games inc.. Ich finde es übrigens cool, dass die in Island zu Hause sind :). Die Eve Grafik-Engine basiert auf DirectX9.

Python verkürzt die Entwicklungszeit enorm. Das wird natürlich umso wichtiger, je größer das Projekt angesiedelt ist. Ich habe vor kurzem auf gamedev.net folgenden Vorschlag über die Entwicklung eines Multiplayer-Games gelesen:

1. Alles in Python + TwistedMatrix grob coden (prototypen)
2. Geschwindigkeit der Module testen
3. Psyco/Pyrex einsetzen und nochmal die Geschwindigkeit testen
4a. Wenn die Ziele bei 2000-3000 Spielern pro Server erzielt werden, prima!
4b. Wenn die Ziele nicht erreicht werden: Code von Python & TwistedMatrix zu C++ and ACE-Framework migrieren.
5. Profit!!!

Twisted ist ein Netzwerk-Frameworkd für Python
Psyco/Pyrex sind Softwaremodule, die den Python-Code schneller machen. Pyrex ist ein Brückenschlag zwischen Python und C. (Pyrex is Python with C data types.)

Übrigens: Warum hast Du Dich gegen Java entschieden? Auch dafür existieren x-gute Möglichkeiten. Wenn Du bereits exzellent in Java programmieren kannst und evtl. gar keine "Hochgeschwindigkeitsanwendung" umsetzen willst, dann könnte Deine Praxis als erfahrener Java-Programmierer wichtiger sein als die paar Prozent, die C++ oftmals tatsächlich bringt.

Wenn Du die Zeit-effektivste Methode suchst, um ansprechende 3D-Spiele zu realisieren, warum dann nicht gleich Panda3D, eine "erwachsene" Engine die C++ und Python mixt?

xaoC

tim,

erstmal danke für den Post, SEHR interessant alles.

Zu Java:
Ich habe mich prinzipiell nicht dagegen entschieden, aber grade dein letzter Post stupst mich etwas weiter in Richtung Python. Ich kann sowohl Java als auch C++, zwar nicht Meisterhaft, aber es sollte mittlerweile ausreichend sein.

Wie schon gesagt möchte ich nicht unbedingt eine komplett fertige Engine nehmen, jedenfalls nicht wirklich eine der gängigen OpenSource Lösungen, aus folgenden Gründen:

- KEINE Engine deckt den vollen Bereich ab. Meistens mangelt es an Sound- oder Netzwerkunterstützung, oder die Lösungen sind nicht Plattformunabhängig (im Sinne meiner vorherigen Posts).

- Viele Engines setzen das Handling von Objekten über Scriptsprachen voraus, oftmals Eigenentwicklungen. Ich bin ja gerne bereit mir auch auf dem Bereich nochwas anzulernen, aber dann reicht es auch. Properität kommt da eigentlihc nicht in Frage. Außerdem würde ich vorerst am liebsten komplett auf Scriptlogik als Schnittstelle zu Objekten verzichten, sondern erstmal eine XML basierte Lösung bevorzugen. Da schreib ich gleich nochwas dazu.

- Core Tasks wie Rendering will ich nicht selbst implementieren, genausowenig wie Plattform-spezifische Implementation etc.

Die eierlegende Wollmichsau gibt es nicht, aber Engines zwingen mich u.U. in ein enges Korsett (ja, OpenSource könnte ich erweitern/ändern, aber das ist nicht unbedingt meine Absicht).

Was ich benötige ist eigentlich ein selbstgeschriebenes Framwork, das exakt meinen Anforderungen entspricht und über sinnvolle Patterns änderbar ist. Das Managerkonzept ist ja ebenfalls in vielen Engines implementiert und das würde ich ähnlich implementieren. So könnte man hinter einen Soundmanager verschiedene Implementationen verstecken, die entweder über OpenAL o.a. laufen, so hätte ich größte Auswahl und Kontrolle, ohne Details implementieren zu müssen.

Das Entwickeln entsprechender Objektklassen wird natürlich knifflig, da diese direkt von den Libs abhängen, aber das sollte auch gehen (hoffe ich).

Ich würde Klassen vorgeben, und die Objekte in XML definieren. Über XML wären Objekte dann frei konfigurierbar. NATÜRLICH ist dieser Ansatz wesentlich weniger konfigurierbarer seitens des Nutzers, der keinen Code schreiben will als eine Scriptsprache, aber es geht darum , ein Spiel schnell pflegen zu können ohne zu kompilieren. Der Ansatz reicht mir vorläufig.

Dieses XML wäre mein Metadata-Container der Objekteigenschaften und Fähigkeiten definiert. Allerdings ist es blödsinn Levelformate oder Modelformate ebenfalls neu erfinden zu wollen. Also müssen die Metadaten auf Fremdformate verweisen. Formate wie Collada würden sich da anbieten. Bis auf Photoshop möchte ich soviel wie möglich Freeware nutzen, z.B. Renderware.

Kurz zur Geschwindigkeit:
Meiner Meinung ist das für Hobby bis Indieentwickler doch kaum ein Argument. Es macht sicherlich kaum Sinn Spiele komplett in Python zu entwickeln (jedenfalls finde ich das gebotene in diesem Bereich etwas lahm, kommt auch drauf an), aber im Hinblick auf 80/20 sinnvoll. Gerade das starke String-Handling z.B. in Interpretern und High-Level Integrität sind IMO Ideal dafür. Frameabhängige Implementation auslagern nach C++, und es sollte wenigstens in der Theorie klappen.

Das wäre auch ein (zugegegebenermaßen weicher) Grund gegen Java:
- Der Interpreter ist (noch) stäker in High-Level Processing
- C++ ist performancekritisch stärker und es gibt Massenhaft Tuts und Libs, wo in Java eher noch weniger Auswahl herrscht (Physiklibs). Klar kann man auch JNI nutzen oder Native kompilieren, aber das finde ich ... naja.

Letztendlich stellt sich wieder die Frage nach der Nutzung. Ich will und kann keinen 3DShooter entwickeln. Aber ich würde gerne klein anfangen und mich in Libs reinsteigern, ohne mich auf eine ungewisse properitäre Lösung festzulegen.

Würde ich Plattformunabghängikeit völlig aussen vor lassen, wäre .NET + XNA vielleicht tatsächlich spannend. Gerade im Bezug auf XBOX. Aber ich kann mir nicht helfen, Linux wird nach und nach salonfähig im Multimediabereich, Mac seit der Umstellung auf Intel Cores sicherlich auch nicht schlechter. Will sagen: Auf Microsoft zu setzen ist vielleicht ein Fehler im Indie Bereich.

Ich würds so ausdrücken wollen:

- Produktivität statt Effektivität
- Implementation statt Grundlagenforschung

Aber um auf deinen Post zurückzukommen:
Ogre kann Rendern, mehr fast nicht, und es ist mir schon beinahe zu Überladen.
Panda3D kannte ich noch garnicht, dass schaue ich mir auf jeden Fall mal an.
Dickes THX!