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

xaoC

Hoi,

ich habe die Suchfunktion bemüht, aber die Ergebnisse sind etwas spartanisch.
Vielleicht hat sich ja in der Zwischenzeit etwas mehr getan.

Die Frage ist: Ist Java/C# wirklich eine ECHTE Alternative zu C++?

Als Anforderung würde ich folgende "Maßstäbe" anlegen:

Unterstützung gängiger Konzepte:
Sind schon Fremdimplementationen vorhanden, und sind dieses auch NUTZBAR?

Beispiele:

- Netzwerk (NIO brauchbar, 3RD Party Libs?)
- Sound (OpenAL)
- Scenegraphen, OpenSource 3D Frameworks
- Input (JInput? Sind Geräte leicht anzusteuern? 8+ Button Pads etc.)

Wer mit Java programmiert, hat in der Regel auch plattformunabhängigkeit im Kopf. Wie sieht das in der Praxis aus?

Mir geht es vor allen Dingen um den Zeit/Nutzen-Aufwand. Es kommt nicht auf höchste Frameraten an, sondern um die Zeiteffektivste Methode Spiele zu programmieren.

Meiner Meinung nach sind die größten Vorteile von C++ die höchste Verbreitung im Unterhaltungsbereich, zahlreiche OpenSource Projekte und eine dementsprechend hohe Community. Nachteilig sind die durch die Konzeption und Plattformabhängigkeit lange Implementierungszeit von Standardfunktionen (File IO) oder Patchwork_Library Orgien. Ferner kommt hinzu, dass sich C++ schwerer warten läßt (z.T. natürlich durch den Featurebonus).

C# als Sprache ist natürlich auch interessant. Die Anbindung an andere Sprachen, gerade C++ relativ einfach. Allerdings macht mich hier die Bindung an Windows etwas nervös, der Bereich ist in Zukunft sicherlich breiter gestreut.

Gibt es hier auch Erfahrung mit in diesem Bereich eher ungewöhnlichen Ansätzen (Python?)

Mich würde interessieren was ihr davon denkt, welche Sachen ihr getestet habt, ob es kommerzielle Beispiele gibt etc., wenn möglich ohne Flamewar sondern nüchtern betrachtet. Persönlich Erfahrung kann man sich nicht ergoogeln.

-M.

Gregor

Java ist sicherlich keine typische Sprache zur Spieleprogrammierung. Aber es gibt durchaus Leute, die Java für soetwas genutzt haben bzw. nutzen.

Guck Dir zum Beispiel Projekte wie

www.oddlabs.com (Tribal Trouble) oder www.wurmonline.com

an.

Für OGL (wenn Du auf unterschiedliche Plattformen hinaus willst, dann ist wohl OGL angesagt) gibt es diverse Bibliotheken für Java, die das verfügbar machen:

JSR-231 bzw. JOGL oder auch LWJGL

Auch für OpenAL gibt es entsprechende Bibliotheken.

Wenn Du mal Leute fragen möchtest, die ein Spiel in Java wirklich durchgezogen haben, dann geh nach: www.javagaming.org

Ach ja, zu den Java-Implementationen von Dritten. Da gibt es natürlich einiges, die OSS-Varianten hinken allerdings ein ganzes Stück zurück. Zum Status einiger Implementationen: http://www.kaffe.org/~stuart/japi/

Wenn Du auch kommerzielle Javaprodukte mit einbeziehst, dann gibt es da auch welche, die up-to-date sind. Zum Beispiel Excelsior Jet.

Aber wie schon gesagt: Wenn Du Dich da wirklich informieren möchtest, dann ist www.javagaming.org sicherlich der bessere Ort, um das zu tun. Die Leute da haben auch mehr Ahnung von den Problemen, die Java in diesem Zusammenhang macht. ...wenn Deine Plattformunabhängigkeit die Playstation einbeziehen soll, dann kannst Du Java übrigens vergessen.

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!