Plattformübergreifend programmieren (Adventure-Engine)

[max_power]

Ein Punkt, der mir im Fanadventure-Bereich schon häufiger aufgefallen ist, ist die Tatsache, dass es nur wenige Möglichkeiten gibt, ein Adventure zu entwickeln, das nicht auf Windows festgelegt ist – zumindest mit den verbreiteten Engines.
AGS bietet mit seiner Unterstützung für Linux zwar einen kleinen Lichtblick, bisher habe ich allerdings noch kein Linux-Spiel gesehen und andere Betriebssysteme werden wohl auch in Zukunft nicht unterstützt.
Spiele, die mit Visionaire, Wintermute oder (meines Wissens auch) AGAST erstellt wurden, laufen nur unter Windows.
Die plattformübergreifenden Engines, von denen ich mal gehört habe, wurden meistens nicht vollendet oder existieren nur in so einfachen Versionen, dass man damit kein umfangreiches Adventure erstellen kann / möchte.
Es gibt jedoch einige Fan-Projekte (z.B. Tukult, Zak2 - and the alien rockstars), die eine eigene Engine entwickeln, die auf verschiedenen Betriebssystemen laufen soll.

Mich interessiert, wie man eurer Meinung nach ein plattformübergreifendes Projekt am besten angeht. Welche Programmiersprache eignet sich am besten? Mir fallen nur Java und C++ sofort ein. Java hat den Vorteil, dass es direkt für Systemunabhängigkeit entwickelt worden ist, aber die Nachteile, dass es nicht ganz so schnell wie C++ ist und ein Java-Programm für Einsteiger schwieriger ist, da man keine direkt ausführbare Datei bekommt und zusätzlich Java installiert haben muss. C++ hingegen ist schneller und wird für derartige Aufgaben häufiger eingesetzt, aber ich bin mir dabei nicht sicher, ob man gewisse Standards oder Techniken beachten muss, damit die Plattformunabhängigkeit gewährleistet bleibt.

Mich würden eure Erfahrungen mit den beiden (oder auch anderen) Programmiersprachen und eure Überlegungen auf dem Gebiet interessieren.

[KhrisMUC]

Ich kenne nur IndianaJava:
http://www.geocities.com/SiliconValley/ ... /indyjava/

Ich weiß jetzt nicht, wie ausgereift es ist, und sicher bietet es nicht den Funktionsumfang von z.B. AGS, aber es ist sicher eine ganz nette Alternative.

[max_power]

Ich kenne nur IndianaJava:

Genau daran habe ich gedacht, als ich: „existieren nur in so einfachen Versionen, dass man damit kein umfangreiches Adventure erstellen kann / möchte“ geschrieben habe. Man kann damit zwar ein Adventure erstellen, aber z.B. lassen sich nur Standardknöpfe als Benutzerschnittstelle verwenden und ich gehe nicht davon aus, dass die Engine viele „Sonderfunktionen“ beherrscht.

[Zoldoron]

Wenn man systemübergreifend programmiert, gibt es immer allgemein verwendbare Teile und andere Teile, die systemabhängig sind. Wenn man jetzt ein gutes Design entwirft, in dem Methoden eingeplant sind, die die abhängigen Teile kapseln, muss man bei der Umsetzung auf ein anderes System nur diese Kapslen neu füllen und kann den ganzen Rest so lassen wie er ist.

Wer allerdings heftig ActiveX nutzt, wird vermutlich gar nicht erst anfangen irgendwas zu kapseln, da dann eigentlich alles Systemabhängig ist

Welche Sprache man dafür nimmt ist eigentlich sekundär. Wenn man eine Sprache wie Java wählt, sollte die Runtime-Umgebung weit verbreitet und leicht erhältlich sein, denn dann muss ja jeder, der das Adventure verwenden möchte, diese auf seinem Rechner installieren. Im Falle von Java scheint mir das gewährleistet zu sein.

Sprachen wie C++ haben demgegenüber den Vorteil, dass - wenn einmal eine fertig compilierte Version für eine Zielplattform vorliegt - der Anwender diese einfach nur noch ausführen muss.

Und C / C++ - Compiler sind wirklich seehr verbreitet.

Wenn ich sowas jetzt vorhätte würd ich Java nehmen, aber nur, weil ich C++ schon kann und in Java gerade hereinschnupper

Generell würd ich für Spiele lieber echte Compilersprachen nehmen, aber das ist bestimmt Geschmackssache. Wenn man sieht, was einige Leute schon für tolle Dinge als Flashanwendungen hinbekommen, gehts mit Java auf jeden Fall auch gut.

[Martin Lassahn]

Gerade im Bereich Fanadventures sehe ich nicht die Vorteile der plattformunabhängigen Engine-Programmierung. Der Aufwand steht in keiner Relation zum 'Nutzen'.

[Rech]

Hat das irgendwer verstanden ?

[john_doe]

Wie Zoldoron schon sagte, wenn man das halbwegs plant ist es nicht so schwer. Um einiges leichter wird es natürlich, wenn man Bibiliotheken wie z.B. SDL einsetzt, die gleich eine Menge Betriebssysteme unterstützen.

Spontan fallen mit folgende Dinge ein, auf die man besonders achten sollte:
- Big/Little Endian, d.h. wie ein Datenwort gespeichert wird (wichtig falls es auch auf nicht i80x86-Prozessoren laufen soll)
- Dateisystem: z.B. die Sache mit dem Slashs/Backslashs, Rechte.
- Grafik, Sound: Da würde ich mir nicht den Aufwand machen, das alles neu zu programmieren, sondern wie oben erwähnt SDL benutzen
- Threads, falls man welche benutzt. Werden aber auch durch SDL abgedeckt.

Das Problem, wenn man für zwei oder sogar mehrere (Betriebs-)Systeme entwickelt ist ja, daß man sich in allen mehr oder weniger auskennen muß, und die wenigsten kennen mehr als zwei gut, die meisten wahrscheinlich nur eins, für das wird dann entwickelt.
Einzige Möglichkeit: Das Back-End, d.h. alle betriebssystemspezifischen Programmteile herausfinden und mehreren Entwicklern den Teil "seines" Systems entwickeln lassen.

Meine Engine entwickele ich hauptsächlich für Windows, weils eben das System ist, das ich hauptsächlich (fast ausschließlich) benutze, halte mir aber durch die Trennung von systemspezifischen Komponenten und eigentlicher Programmlogik die Hintertür offen, das Teil vielleicht mal auf Linux zu portieren.

PS: Zur Entwicklung benutze ich C++, ein Kollege entwickelt sein Spiel in Java, das läuft relativ flüssig.

[Fightmeyer]

Hat das irgendwer verstanden ?

Nö!

[max_power]

Wenn ich sowas jetzt vorhätte würd ich Java nehmen, aber nur, weil ich C++ schon kann und in Java gerade hereinschnupper

Ich würde im Moment zu Java tendieren, weil ich es mal sehr gut konnte und meine Kenntnisse wieder auffrischen möchte. Allerdings bin ich wohl in Java deutlich fitter als in C++, was für mich allerdings auch ein Grund für Java wäre. Ich weiß, dass ich in Java relativ einfach übersichtliche Strukturen hinbekomme und wo ich im Zweifelsfall nötige Informationen finden kann. C++ erschien mir bisher zu umständlich. Außerdem scheint mir Java „sicherer“ zu sein. Bisher liefen alle Programme, die ich in Java geschrieben habe, problemlos unter Windows und Mac OS X, mit Linux habe ich erst wenig getestet, könnte ich aber mal nachholen. Feststellen musste ich aber, dass die Programme mit Grafik auf dem Mac deutlich langsamer waren, was im Zweifelsfall ein Problem werden könnte.
Ich interessiere mich vor allem für Plattformunabhängigkeit, weil ich die meiste Zeit mit einem Mac arbeite. Da ich noch keine wirklich gute Engine für verschiedene Systeme kenne, wäre das noch eine Lücke, die man schließen könnte.

[Martin Lassahn]

Meine Erfahrungen bzgl. Plattformunabhängigkeit bei der Entwicklung von Timanfaya:

Ursprünglich habe ich bei der Programmierung auf eine gewisse Plattformunabhängigkeit geachtet: zumindest Windows und Linux konnte ich mit Delphi/Kylix bedienen. Zur Soundausgabe nutze ich FMOD und zur Grafikausgabe Softwareroutinen. Das Spiel nutzt eine Auflösung von 800*600 bei einer 32bit Farbtiefe, und beinhaltet auch ein paar relativ grosse Hintergrundanimationen. Das Spiel brachte es auf meinem 1.8Ghz-Notebook auf ca. 40fps, auf einem 800Mhz Test-PC aber auch nur auf 15fps. Zu meiner grossen Überraschung schafften einige HighEnd-PCs (2-3Ghz) nicht mehr als 25fps, was mich nachdenklich machte. Die Performance-Probleme liessen sich auf meine plattformunabhängigen Grafikroutinen zurückführen, welche je nach Rechner/-Grafikkarte sehr unterschiedlich stark ausfielen. Sehr unberechenbar. Wenn mein Spiel auf älteren Rechnern langsam läuft, dann ist es ok, aber bei neueren Rechnern sollte es schon 1A laufen.

Ich musste also meine Engine verändern. Um eine wirkliche Beschleunigung zu erzielen, musste ich auf hardware-unterstützte Routinen setzen. SDL habe ich mir dann genauer angeschaut, um meine bisherige Plattformunabhängigkeit zu bewahren. Leider basierte SDL auf DirectX7, was einige Features (zB. echter Transparenzkanal) nicht bietet. Heißester Favorit war dann OpenGL, einige Tests liefen sehr erfolgreich. Leider hat OpenGL einen grossen Haken: der Spieler hat dafür Sorge zu tragen, dass ein ordentlicher Treiber installiert ist. DirectX wird im Vergleich dazu mit dem Standard-Betriebssystem (XP) gleich mitinstalliert. Eine Hardware-Umfrage in meinem Gelegenheitsspieler-Bekanntenkreis bestätigte, dass nur wenige sich mit OpenGL oder einem Treiber-Update auskennen (wollen). Es gab nur eine Lösung: Trennen von der Plattformunabhängigkeit und direkte Programmierung von DirectX. Das ergab einen riesigen Geschwindigkeitsgewinn (von 25fps -> 500fps). Mit relativ wenig Aufwand könnte die Engine wieder auf OpenGL umgestellt werden.