Hi,

ich habe ja meine Multiplatform Engine/Framework die bisher schon einigermaßen viele Systeme unterstützt (MacOSX [ppc, i386, x64], Windows [i386, x64], Linux [i386, x64], iOS [ARM6, ARM7] und PlaystationPortable [Homebrew])

Die engine ist in C++ geschrieben und daher problemlos auf all die oben genannten Platformen portierbar.

Jetzt gibt es aber ja noch Android und Windows Phone 7.
Bei Android ist es zumindest seit v2.3 auch möglich nativen code zu nutzen, zwar immernoch mit Java JNI binding, aber immerhin.. die portierung der engine ist im prinzip auch fertig, mir mangelt es nur an einem Test-Device

Bei Windows Phone 7 schaut es allerdings schlecht aus, genau wie bei dem kostenlosen developer program der XBox360 kann man Programme nur via C#.Net schreiben, keinerlei unterstützung für Native Code.

Im grunde macht das natürlich auch absolut sinn, denn sowohl Google als auch Microsoft wissen ja nicht zwingend welche Architekturen in zukunft noch kommen werden und möchten verhindern das alte Programme nichtmehr laufen dann..

Apple ist da - wie immer - einfach knall hart und sagt "Was interessiert uns abwärtskompatibilität?!". Wenn eine neue Platform rauskommt auf der die alten Binarys nichtmehr laufen - pech.

Aber ich frage mich, wie machen große firmen es, das ihre Spiele auf allen Systemen laufen?
Schreiben die die engine und den gesamten Code einfach doppelt in verschiedenen sprachen, oder gibt es irgendeinen tollen trick den ich nicht kenne?


Und, wieso gibt es bei Android und Windows nicht einfach die möglichkeit für "Fat-Binarys" wie bei OSX/iOS?
Bei Apple werden einfach alle binarys für die verschiedenen architekturen in einer zusammen gefasst, so das am ende ein Binary da ist welches aber auf allen architekturen läuft. Bei Android und Windows bräuchte es dafür einzelne binarys.


Um es also nochmal auf den punkt zu bringen, wie schaffen es die Hersteller ihr Spiel (z.B. AngryBirds) für iOS, Android, Windows Phone und was weiß ich noch zu entwickeln?

Aya~

Mehrere Binaries in einem, um verschiedene APIs zu unterstützen, geht ja nicht. Geht auch beim Mac nicht. Die Multi-Binaries beim Mac verwenden ja jeweils die selbe API, laufen aber auf unterschiedlichen Prozessor-Architekturen (PowerPC, x86_64).

Die Architektur ist heute weniger das Problem. Die mobilen Geräte laufen fast alle mit ARM. Aber die APIs, das Framework drum herum ist komplett anders.

Wie es Spiele wie Angry Birds machen? Nun, gibt mehrere Optionen, die man vorher knallhart durchkalkuliert und dann als Firma die billigste nimmt. Die zwei gängigsten sind:
- Neu schreiben und fortan mehrere Code-Zweige pflegen
- Gegen eine gemeinsame (vorher selbst erstellte) API coden, die die Unterschiede wegabstrahiert. Mit einem entsprechenden Crosscompiler kompiliert man dann weiter zur richtigen Plattform

Das machen einige z.B. mit Android so. Einige Firmen bauen sich ein eigenes Framework in Java, wo die benötigten Funktionen drin sind und lassen das nach Java Bytecode kompilieren. Von da aus wird das dann nach ObjectiveC binaries, Android APKs (ist ja im Endeffekt kompiliertes Java) und die ganzen anderen Sachen übersetzt und die entsprechenden APIs und Bibliotheken der jeweiligen Zielplattform verwendet. Siehe hier: http://www.youtube.com/watch?v=TG-NIt2O5J8
Die gehen dort z.B. einen Umweg über XML, wenn ich das richtig in Erinnerung habe.

Das lohnt sich für große Projekte und Projekte, bei denen man von Anfang an mehrere Plattformen im Visier hat.

Hoffe, ich konnte damit ein wenig Licht ins Dunkel bringen
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Du hast mich glaube ich missverstanden.
Mir geht es nicht darum wie man für verschiedene APIs entwickelt, sondern darum wie man für verschiedene - nicht kompatible programmiersprachen entwickelt.

C++ geht nunmal auf Windows Phone 7 definitiv nicht, welche möglichkeit ausser die gesamte Engine (welche die APIs natürlich abstrahiert kapselt) in C#/XNA neu zu schreiben hat man denn?

Nun, die Zielplattform (Windows Phone 7) futtert nur etwas, was aussieht wie das, was C# ausspuckt.
Du musst es also schaffen, dass auf dem Phone etwas landet, was wie ein C#-Kompilat aussieht.
Das steckt hinter den ganzen Cross-Compilern.

In dem Youtube-Video wird ja Java und Android verwendet. Nicht C++ (native) und Android.
Android erwartet nach wie vor Java-Binaries. Dass das Java im Hintergrund aber nativen Code verwendet, interessiert Android nicht.

Genau so erwartet das Windows Phone 7 C#-Binaries. Möglicherweise kannst du aus C# heraus native Bibliotheken (deine Engine) verwenden (und natürlich die Bibliotheken von Windows Phone 7, die auch für native Anwendungen verfügbar sein müssen) - falls nicht, musst du deine Engine in den Bytecode von C# cross compilen.
Dem Smartphone ist es herzlich wurst, wer den Bytecode gebaut hat. Ob das jetzt der Compilter vom Visual Studio war oder sonstwer. Und diesen Umstand kann man sich zu Nutze machen und von C++-Kompilaten in C# Bytecode zu übersetzen.

Und ja, das ist natürlich verdammt eklig, wenn du als Ausgangssprache C++ genommen hast. Sprachen wie Java oder C# tun sich da viel leichter, weil Bytecode wesentlich einfacher auszuführen ist als Maschinencode. Da gibt es sehr komfortable Bibliotheken, um den Bytecode zu lesen und zu verändern und sonstwas damit zu machen.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ich bezweifle aber das es einen solchen CrossCompiler für C++ -> (Managed) C#.Net gibt...

Insofern in der theorie möglicherweise eine nette Idee, in der Praxis allerdings glaub ich (aktuell) nicht möglich.

Zumindest, wenn man C++ oder eine andere nativ kompilierende Sprache verwendet, ja. In der Praxis verwenden viele Firmen, die für mobile Geräte entwickeln, aber tatsächlich Java u.Ä., insofern ist dieser Trick durchaus praxisrelevant.

Du hast dann, so wie ich das sehe, keine andere Möglichkeit als auf native support bei Windows Phone 7 zu warten oder du lässt diese Plattform einfach mal großzügig aus. Der Marktanteil von dem System ist glaube ich auch vernachlässigbar im Moment

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Android

Wenn dein Programm auf Linux läuft wirst du hier keine Probleme bekommen. Es empfielt sich aber trotzdem ein Launcherprogramm für Dalvik
(es ist übrigens ein fataler Irrglaube das Android mit Java arbeitet!!!) anzulegen da die meisten Versionen nur diese als Einstiegspunkt akzeptieren.
Ansonsten müsstest du noch darauf Achten, das Android die Hardwareeinstellungen während der Laufzeit ändern kann (z.B. Screenorientation)
was ggf. zu Problemen führt wenn du das nicht für dein Programm deaktivierst. Schau dir einfach mal den Port von Quake 1 an dort hast du ein
mehr oder weniger brauchbares Beispiel.

WP7

Hier bleibt dir nichts anderes übrig als auf C# zu setzen, es gibt zwar gewisse Wege das zu umgehen aber das ist eher semi-legal lol Es empfiehlt sich
übrigens eher mit Silverlight und Softwaregrafik zu arbeiten da du so wesentlich bessere Ergebnisse wie mit XNA erziehlen kannst (außerdem ists einfacher lol).

IOS

Auch hier kannst du ohne weiteres C & C++ mit Objective-C verbinden, was ziehmlich geil sein könnte. Allerdings ist hier das verhalten von Gerät zu Gerät
teilweise so extrem unvorhersehbar und die Entwicklertools von Apple so extrem beschissen das du hier sehr viel mehr Zeit mit der Fehlersuche anstatt mit
programmieren verbringst. Das wäre ja an sich nicht einmal so Schlimm wenn es auch tatsächlich "unsauberen" Code betreffen würde aber das ist nicht der
Fall. Ich kann dir versichern das es in 99.9% der Fälle Systemkomponenten, wie z.B. das UIImageView, sind die dir deine App total zerschießen, wenn du ansonsten
Sauber gearbeitet hast.

_________________
Meine Homepage