spiele programirung

**Lin728** · 10-12-2003, 11:04

Damals nicht, damals war Java zu langsam für Spiele-Entwicklung. Da hat erst die Entwicklung von JITs begonnen und von einer schnellen HotSpot-Engine ist wiet und breit nichts zu sehen gewesen.

Außerdem darf man keine Bilbiotheken verwenden, die nur auf einer platform verfügbar sind, da du für Enviromental-Audio / OpenGL / Joystick auf native C++-Bibliotheken zugreifen musst.

Aber sagen wir mal aus dem heutgigen Standpunkt: Ja, es wäre ohne weiteres Möglich ein Spiel ala´Counterstrike mit Java zu machen.
Das wäre aber mit sauberem C++ und ein bisschen mehr Aufwand auch machbar.
Bei Java gehst vor allem um die leistungsfähige Classenbibliothek und eine klarere Sprache (das ist ansichtssache).

**fs111** · 10-12-2003, 12:54

Meist ist doch wohl eher so, dass die Engines in C/C++ geschrieben werden, und das Spiele selber dann nur noch geskriptet wird. Bei Uru (das neue aus der Myst Reihe) ist das so, und zum Skripten wird Python verwendet.

fs111

**localhost** · 10-12-2003, 16:32

hä das verstehe ihc garnicht?!!

Original geschrieben von fs111
Meist ist doch wohl eher so, dass die Engines in C/C++ geschrieben werden, und das Spiele selber dann nur noch geskriptet wird. Bei Uru (das neue aus der Myst Reihe) ist das so, und zum Skripten wird Python verwendet.

fs111

**peschmae** · 10-12-2003, 17:32

ist aber recht klar so. Das will heissen: Du schreibst, aufbauend auf OpenGL/SDL/DirectX eine Spiele-Engine (gibt auch solche, die du dir irgendwo runterladen kannst) - mit der Quake-Engine wurden z.B. viele andere Spiele geschrieben, nicht nur Quake.

Die Engine stellt quasi Funktionen auf einem höheren Level zur Verfügung.

Das Spiel selbst wird dann mit einer Scriptsprache erstellt. (Spielintelligenz und Anordunung der Objekte (aka Feinde))

MfG Peschmä

**peschmae** · 10-12-2003, 17:41

Original geschrieben von Berufspenner
Wenn ich mich jetzt aber mal ganz naiv stellen würde, dann würde ich mich aber fragen, warum sich dann Java so schlecht/gar nicht in der Spieleentwicklerszene durchgesetzt hat?

Akzeptiert. Ich frag mal gleich naiv zurück wieso die Spielerentwicklerszene und alle anderen Programme nur für Windows entwickelt werden. (Ich weiss, das stimmt nicht, aber als Naivling kann ich das ja nicht wissen

)

Ich meine, dass es doch grade die Produktionskosten senken und die Verbreitung steigern könnte, wenn man ein Spiel für eine einheitliche Umgebung, in diesem Fall dann Java, schreiben würde. Schließlich müsste man dieses Spiel dann nicht mehr portieren.

Zweifellos. Aber der Linux-Markt ist klein. Die wenigsten spielen auf AIX oder IRIX. Mac OS X ist auch nicht wirklich wichtig.
Die wenigsten Spiele werden je portiert - und wenn dann ja nur von Freiwilligen. Ich glaube nicht, dass ein so kleiner Markt interessant ist...
Halt das übliche Problem.

Also irgendeinen drifftigen Grund wird es dann wohl geben.

Hab nie gesagt es gäbe keinen. Aber ich kenne keinen. Auch Tuxipuxi und sein Interviewpartner offenbar nicht.

Da OpenGL selbst ja eh in C geschrieben ist, und meist auch mit Hardwarebeschleunigung betrieben wird, sehe ich da eigentlich keine Performance-Probleme.
Zugegebenermassen habe ich aber bisher (mangels PC auf dem man spielen könnte (-> hint, hint, wer schenkt mir einen

)) noch kein in Java programmiertes Spiel ausprobiert. Auch arkanae nicht (die Screenshots sehen aber Ok aus). Aber natürlich auch sonst keine aktuellen Games (CS, was auch immer).

Das Problem ist wohl - wie meist bei Entscheiden gegen Java - die Psychologie. Swing war lange Zeit sehr langsam. Extrem schnell ist es auch heute noch nicht.
Mit so einem Ruf ist es natürlich schwer für Java, sich durchzusetzen.

MfG Peschmä

**anda_skoa** · 10-12-2003, 21:16

Original geschrieben von peschmae
Akzeptiert. Ich frag mal gleich naiv zurück wieso die Spielerentwicklerszene und alle anderen Programme nur für Windows entwickelt werden. (Ich weiss, das stimmt nicht, aber als Naivling kann ich das ja nicht wissen )

Wie gesagt:
- Abhängigkeit auf alte, nicht portierbare, interne Libs
- Abhängigkeit auf nicht crossplattform erhältliche Komponenten von Drittherstellern
- Unkenntnis von der Möglichkeit plattformübergreifender Entwicklung
- wenig Know-How bei den Entwicklern (zB Plattformhacks)
- alte Informationen im Management (Java sei langsam, oder man müsse auf andere Plattformen "portieren", etc)

Ich würde schätzen am häufigsten die ersten beiden und das letzte.

Ciao,
_

**peschmae** · 11-12-2003, 07:18

so in etwa hab ich mir das auch gedacht. Aber ich hab ja nicht dich gefragt

MfG Peschmä

**localhost** · 12-12-2003, 22:00

und wie ist den jetzt der stand der dinge ??
java für game´s ja nein oder was anderes ?!,daföj

**peschmae** · 13-12-2003, 07:37

kommt drauf an. Was für ne Engine und so...

Unter Linux wird wohl recht viel die libSDL verwendet.

MfG Peschmä

**SeeksTheMoon** · 18-12-2003, 11:40

Es stecken also wesentlich mehr Dinge dahinter als nur die Programmiersprache und deren "Geschwindigkeit". Wenn man sich damit eingehender befasst (so wie ich), wird einem die Sache klarer. Ich will mal meine Erfahrungen mit der Spiele-Entwicklung und besonders mit der Java-Spiele-Entwicklung posten.
Der Text ist was länger, aber er ist für euch mit Sicherheit interessant.

Vorweg etwas zu Java:
Java ist NICHT zu langsam. Richtig, es IST langsamer als C, aber nicht ZU langsam. Diesen Unterschied muss man erkennen.
In den Anfängen von Java (1.0, 1.1) war es wirklich sehr behäbig, aber 1. sind die SDKs immer schneller geworden (und werden es auch weiterhin mit jedem Release) und 2. sind auch die Rechner schneller geworden. Dennoch hält sich dieses Vorurteil der Langsamkeit extrem hartnäckig.
Früher hat man auch gesagt, C wäre viel zu langsam, nur Assemblerprogramme wären richtig gut. Bullshit, wie man heute sieht.

Ich wollte selber mit meiner Crew ein sehr aufwendiges Spiel in Java programmieren. Was ich eben zu Java gesagt habe, hatten wir dabei im Hinterkopf. Wir haben viel mit Java programmiert, so dass wir zu dieser Ansicht gekommen sind. Ein weiterer Faktor für Java war die Tatsache, dass anscheinend niemand sonst so etwas in Java realisiert hat, wie auch oben bereits angemerkt wurde. Es war also auch eine Art Pioniergeist und Freude am Experiment dabei.

Anforderungen an das Spiel und die Bibliotheken:
3D-fähig, netzwerkfähig, plattformübergreifend, multimediafähig (also außer 3D noch Sound, Bilder und Videos), alle Bibliotheken müssen kostenlos verfügbar sein, sich aber für geheim gehaltenen Quellcode eignen und weiterhin entwickelt/supportet werden. Die Dokumentation muss auch so gut sein, dass eine Einarbeitung gut möglich ist, bzw dass man überhaupt eine Ahnung von den Fähigkeiten der Bibliothek bekommt, sonst fällt einem möglicherweise ein Fehlgriff zu spät auf und man braucht dringend Ersatz und hat Zeit verloren.

Der Java-Ansatz ist während der Planungsphase an folgenden Dingen gescheitert:

1. Man hat für 3D-Grafik die Wahl zwischen GL4Java und Java3D.
GL4Java bekam schon lange keine Weiterentwicklung mehr verpasst und es lies sich auf keinem unserer Rechner zum Laufen überreden.
Java3D funktionierte auf Anhieb, dafür gabs folgende Probleme:
a) schlechte Doku (die von GL4Java hab ich mir nicht angesehen, weil es nicht lief), vor allem gibts bis auf 1-2 alte Bücher keine deutsche Doku.
b) Die Plattformunabhängigkeit ist im Ar..., weil: J3D gibts nur für Windows und Solaris (wer benutzt Solaris?), die Linuxversion hinkt ein Stück hinterher und wird von Sun nicht supported. Eine Mac-Version gibts überhaupt nicht!
J3D bietet Support für spezielle Eingabegeräte (Joysticks, Brillen, ...), allerdings nur auf DirectX Systemen.
c) Wie bei allen Libs, muss man dieses Paket vom Anwender installieren lassen.

2. Soundbibliotheken sind ganz großer Mist:
Die Soundformate, die man von offiziellen Erweiterungen benutzen kann, sind grauenhaft (au, aiff, nur bestimmte wave-formate). ogg und mp3 sind da nicht bei.
Es gibt diverse ogg und mp3 Libs, aber deren Lizenzen schmecken einem nicht immer, vor allem wenn man ein kommerzielles Game schreiben will. Außerdem liest man in einschlägigen Foren, dass diese Libs schweine-langsam sind.

3. Video-Bibliotheken
Ich hab bis heute noch keine Lib gefunden, die divx oder sonstige Formate abspielt. Das hat wohl lizenztechnische Gründe.

4. Bild-Bibliotheken
Java unterstützt nicht viele Bildformate. Man muss mal wieder mit einer weiteren Lib nachhelfen.

5. Dateiloader
Man braucht Loader für 3dmax oder sonstige Dateien und davon gibt es kaum welche. Für 3dmax gibts zwar mehrere, aber welcher davon am besten ist, wissen nichtmal die Autoren.

6. Kommerzielle Anwender wollen sich nicht in den Sourcecode schauen lassen
Also muss man den Java Bytecode durch einen Obfuscator jagen. Das Ergebnis ist zweifelhaft, denn man muss dann auf jeden Fall weitere Tests einplanen, weil der Obfuscator sich oft massiv des Name-Manglings bedient und wenn man dann einen Fehler findet, dann ist dank des Obfuscators die Fehlermeldung so komplex, dass man selber den Bug kaum findet.
Wer viel Geduld hat, wird übrigens auch mit einem obfuscierten Code (nennt man das so?) fertig und schreibt den um.
Zu Anfangszeiten von mp3 gabs ein Tool das den Fraunhofer Codec verwendet hat. Der Cracker, der das Prog zwischen hatte, der hat (trotz Assembler-Output) noch Stellen im Codec gefunden, die er verbessert hat. Unmöglich ist also nichts; auch wenn das vieleicht nur 1-2 Leute auf der Welt schaffen. (Nur das verschleierter Bytecode wesentlich einfacher zu entwirren ist als Assembler)

Diese Dinge braucht man um eine Engine zu schreiben, weitere Funktionen wie relativ komfortable Dateiarbeit, GUI und Netzwerk sind bei Java schon dabei.
Wir nähern uns übrigens inzwischen der 100MB Grenze nur für Bibliotheken (das Java-SDK eingerechnet)
Eigentlich muss man sich schon eine eigene Engine schreiben, weil es keine fertigen gibt (s.u.), aber dann erstickt man in diesem Bibliotheken-Müll von dem keiner weiß ob diese zusammengeschusterte, fette Konfiguration auf anderen Rechnern läuft.
Ich habe mal kleine Applikationen für eine Gruppe von Anwendern geschrieben. Denen musste ich erstmal mühselig verklickern, was jar-Dateien sind, dass sie sie nicht mit WinRAR öffnen sollen und dann stellte sich heraus, dass bei 95% der Anwender das Java falsch installiert war und die Programme deshalb nicht liefen. Und sowas stelle man sich mal mit 6 verschiedenen Bibliotheken bei 1000 Anwendern und 10 verschiedenen Betriebssystemen in 1000 verschiedenen Konfigurationen vor (jedes Windows-Release zählt als separates OS).
So ist es auch bei C. Es ist völlig egal, ob man SDL, DirectX oder OpenGL verwendet. Zahlreiche Features vermisst man dennoch. Man braucht eine Bibliothekensammlung, die wirklich alles abdeckt. Am besten direkt aus einer Hand und ohne *Kompatibilitätsprobleme*. Je mehr verschiedene Produkte man benutzt, desto mehr Support von verschiedenen Stellen braucht man auch.

Oder man fängt echt bei Adam und Eva an und baut sich ein komplett eigenes SDK aus komplett eigenen Grafik-, Sound-, Loader-, Video-Bibliotheken und dann ein Spiel das darauf basiert.
Wenn man zu viel Zeit und Geld hat, kann man das machen, die Entwicklungszeit verdoppelt sich mindestens dadurch, verdreifacht sich wohl eher.
Dann hat man auch wieder Plattformunabhängigkeit, denn die meisten dieser Libs gibt es in Wirklichkeit nur für 1-2 Betriebssysteme.

Wer das nicht kann oder will, greift vielleicht auf ein fertiges Spiele-SDK zurück:
Ich habe nur 2 SDKs für Java gefunden: davon war eines GPL und kein Stück dokumentiert (das eignet sich nicht fü kommerzielle Programme und man muss sich zu lange einarbeiten), an das andere kann ich mich jetzt nicht mehr erinnern, aber doll war es auch nicht.
Dann gibts noch 1-2 kommerzielle Engines, aber die kann sich keiner leisten (höchstens Firmen) und so ganz feature-reich sind die auch nicht.

Fazit: Die Sprache an sich ist toll. Man kann schöne Anwendungs-Programme schreiben und diese sogar mit dem einen oder anderen komplexen multimedialen Feature anreichern, aber wenn man ein aufwendiges Spiel mit aktuellen Anforderungen (Erwartungshaltung der Kunden/des Chefs und unter Zeitdruck) schreiben will, ist man auf eigene Bibliotheken und ein dickes Budget angewiesen. In der Planung für das Spiel muss man das auch berücksichtigen; nach 2-5 Jahren hat sich schon so viel auf dem Markt getan, dass man mit etwas Pech sein ganzes SDK in die Tonne kloppen kann und das Spiel gar nicht mehr anfangen muss.

Wie gesagt, ist der Java-Ansatz von uns deshalb verworfen worden. Jetzt benutzen wir die Engine Crystalspace, die schon über 1,2 Mio LOC (Codezeilen) hat (das muss man erstmal selber machen, da sitzt man aber ein paar Jahre!), die unter der LGPL steht (auch gut für kommerzielle Anwendungen), extrem viele Features hat (das hat man alles schonmal an Zeit und Arbeit gespart), relativ gut dokumentiert ist (es reicht für erfahrene Leute um sich einzuarbeiten und um damit zu arbeiten) und sich obendrein noch komplett wie Java benutzen lässt! Die Engine ist zwar in C++ und Assembler geschrieben, hat aber Mechanismen implementiert, die wie intelligente Zeiger mit Garbadge Collection und Java-Interfaces funktionieren. Man entwickelt also abstrakt und bequem.
Im Gegensatz zu einer zusammengefrickelten Java-Lösung wie oben beschrieben, ist die Engine auch wirklich plattformunabhängig und bietet alle Features unter Windows, Linux, MacOS, BSD usw.
Außerdem - und das ist nicht zu verachten - wird sie von vielen Entwicklern weiterhin gepflegt und erweitert. Die Engine modernisiert sich also, ohne dass man dafür auch nur einen Wimpernschlag unternehmen muss:
Heute arbeitet man mit Version x und vor Release (oder während der Entwicklung) kann man auf die neuste Version der Engine umsteigen, die z.B. bessere grafische Features hat, weniger Bugs hat, vielleicht sogar mehr plattformen unterstützt. At no Costs!!
Bei einem eigenen SDK macht das kein Mensch, sofern man niemanden extra für die Engine-Entwicklung hat. Das Produkt altert schon bevor man es benutzen kann.

Die Spielefirmen haben teilweise andere Interessen; so interessiert sie die plattformunabhängigkeit nicht immer (dank Zielgruppenbestimmung und Marktanalyse) und für eine eigene Engine, die genau auf die Bedürftnisse zurechtgemacht ist, muss man auch keine Lizenzen bezahlen oder fremden Support bemühen (sofern es ihn gibt).
Wenn man längere Zeit seine Engine pflegt und Erfolge mit darauf basierenden Games landet, dann kann man sogar mit der Engine Geld verdienen (siehe Quake/Doom-Engine oder UT-Engine), weil weniger zeit/geld-reiche Firmen oder Newcomer dann ankommen und sich die Engine mehr oder weniger günstig borgen.
Weil das seine Zeit dauert und aufwendig ist, macht das auch nicht jeder (bzw KANN das auch nicht jeder um in der Oberliga mitzuspielen).
Im übrigen gehört das zum Kalkül dazu: Wenn man sagt, dass man z.B. die Doom3 Engine verwendet, dann kann man jetzt schon davon ausgehen, dass man damit ein werbeträchtiges Argument und ausreichendes Kundeninteresse gratis dazu bekommt. Da spielt das Spiel schon fast keine Rolle mehr.

So, ich hoffe mal, dass das einen tieferen Einblick in die Problematik verschafft hat.

**Lin728** · 18-12-2003, 14:00

CS ist von den features her super, aber die api finde ich irgendwie bastlerhaft,

**localhost** · 19-12-2003, 11:15

giebt es ein spiel das so änlich oder so ist wie cs für linux ?

**tuxipuxi** · 19-12-2003, 11:48

Original geschrieben von localhost
giebt es ein spiel das so änlich oder so ist wie cs für linux ?

wenn du unter ähnlich einen shooter verstehst, ja. ut2003, quake und enemy territory.

gruss,
tuxipuxi.

**Lin728** · 19-12-2003, 12:28

CS != Counterstrike....

CS steht für CrystalSpace einer leistungsfähigen C++-3D-OpenGL engine

**anda_skoa** · 19-12-2003, 12:52

Original geschrieben von SeeksTheMoon
Früher hat man auch gesagt, C wäre viel zu langsam, nur Assemblerprogramme wären richtig gut. Bullshit, wie man heute sieht.

Wobei in bestimmten Gebieten immer noch Assembler eingesetzt wird.
DSP Codecs zum Beispiel.
Aber der Trend ist dort auch, dass man solche Module praktisch vom Hersteller des DSP kauft, bzw von einer darauf spezialisierten Drittfirma.

alle Bibliotheken müssen kostenlos verfügbar sein, sich aber für geheim gehaltenen Quellcode eignen und weiterhin entwickelt/supportet werden.

Sind wir ein kleiner Freeloader, hmm?

1. Man hat für 3D-Grafik die Wahl zwischen GL4Java und Java3D.

Hat schon jemand Erfahrungen mit den neuen GL Bindings von SGI (falls es die schon gibt)?

b) Die Plattformunabhängigkeit ist im Ar..., weil: J3D gibts nur für Windows und Solaris (wer benutzt Solaris?), die Linuxversion hinkt ein Stück hinterher und wird von Sun nicht supported. Eine Mac-Version gibts überhaupt nicht!

Sun ist leider sehr gut darin, sich selbst in den Fuß zu schiessen.
Das "böse" Linux wurde bewußt vernachlässigt, was keine so gute Idee war, weil dort doch viele Entwickler unterwegs sind und dadurch Java nicht gerade guten Ruf in der Zielgruppe bekommen hat.

Ein ähnliches Stiefkind bei den APIs ist das Java Media Framework.
Rick Ross, der JavaLobby Gründer schimpft da öfter

c) Wie bei allen Libs, muss man dieses Paket vom Anwender installieren lassen.

Nunja, das dürfte bei allen Sprachen so sein.

3. Video-Bibliotheken
Ich hab bis heute noch keine Lib gefunden, die divx oder sonstige Formate abspielt. Das hat wohl lizenztechnische Gründe.

Dazu muss man ein paar Postings von Rick Ross lesen

Eine der Ausweichlösungen die auch von ihm benutzt wird, ist eine Quicktime Bibliothek für Java, allerdings geht die wieder nicht unter Linux.

6. Kommerzielle Anwender wollen sich nicht in den Sourcecode schauen lassen
Also muss man den Java Bytecode durch einen Obfuscator jagen.

Diese ganze Obfusicator Sache ist mir immer höchstens suspekt.
Bei Bedarf kann man auch echten Maschinencode reverse-egninieeren, besser wäre es, die interessante Teile an Interessierte unter günstigen Konditionen zu lizensieren.

Eigentlich muss man sich schon eine eigene Engine schreiben, weil es keine fertigen gibt (s.u.), aber dann erstickt man in diesem Bibliotheken-Müll von dem keiner weiß ob diese zusammengeschusterte, fette Konfiguration auf anderen Rechnern läuft.

Wenn es etwas nicht gibt, aber Nachfrage danach besteht, nennt man das eine Marktlücke

Man braucht eine Bibliothekensammlung, die wirklich alles abdeckt.

Deswegen gibt es auch im Fahrwasser der Spieleindustrie eine große Anzahl von Bibliothekerzeugern, die dann Engines, Sounds- und Videobibliotheken machen.
Praktisch keine Spielefirma macht die selbst, das ist in Anbetracht von Time-To-Market keine gangbare Lösung.

Teilweise gibt es da aber große Kommunikationsschwierigkeiten, besondern was Angebot und Nachfrage betrifft.
Einige erinnern sich sicher an das Never Winter Nights Debakel, wo die Spiele Firma wochenlang nach einer Linux Alternative für ihre Soundlib gesucht hat, bis der Hersteller durch as Medienecho drauf gekommen ist und die Firma draufhinwies, dass es ohnehin auch eine Linuxversion gäbe.

Oder man fängt echt bei Adam und Eva an und baut sich ein komplett eigenes SDK aus komplett eigenen Grafik-, Sound-, Loader-, Video-Bibliotheken und dann ein Spiel das darauf basiert.

Gibt es eigentlich eine Java API zu SDL?

Die Spielefirmen haben teilweise andere Interessen; so interessiert sie die plattformunabhängigkeit nicht immer (dank Zielgruppenbestimmung und Marktanalyse)

Das ist glaub ich nicht so richtig, je nach Genre sind die Firmen durchaus daran interessiert, das Spiel auch auf diversen Konsolen anbieten zu können, bzw. einen Konsolentitel auch auf PCs.

und für eine eigene Engine, die genau auf die Bedürftnisse zurechtgemacht ist, muss man auch keine Lizenzen bezahlen oder fremden Support bemühen (sofern es ihn gibt).

Wobei man hier sieht, dass das zweite offensichtlich der bevorzugte Weg ist.

Ciao,
_