spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

chrische5
Falsches Topic dafür, aber ich kann der Aussage Dustin Braun vollkommen zustimmen.

Also wer sich mal paar Wochen mit XNA beschäftigt hat, der merkt sehr schnell, dass das Hauptaugenmerk auf Consolen liegt und weniger auf PCs. Dies sieht man vorallem sehr deutlich, an der Content Pipeline, die äußerst starr ist.

Hier wird der Content (Texturen, Meshs, txts usw.) zur Kompilierungszeit erfasst und in ein eigenes Format, wo Meta-Informationen für Reflection enthalten sind, gespeichert. Dies erlaubt den schnellen Zugriff auf den passenden Loader und ermöglicht es, dass es auf jeder Plattform gleich abläuft ohne böses Erwachen. An für sich, eine ganz feine Angelegenheit. Doch was ist nun, wenn Rechtschraibfehler korrigiert wurden? Dann muss gleichzeitig auch eine neue Exe mit ausgeliefert werden. Ein unglaublicher Aufwand kann daraus resultieren, wenn es mehr als nur ein Content ist der modifiziert wurde oder ggf. sogar hinzu kam! Das ist ein riesen Problem bei größeren Games so in der Größenordnung StarCraft, Quake usw. Dem entwickler wird de facto die flexibilität geraubt Content schnell und effektiv zu ersetzen. Bei Consolen macht das keinen unterschied, da dies generell nicht immer geht. Bei PCs schon.

Damit bin ich oft schon auf die Schnauze gefallen.

Dann kommt noch hinzu, dass XNA nicht gerade Abwärtskompatibel ist und der Benutzer nicht informiert wird, dass etwas fehlt. Beispiel welches ich erlebt habe: Ich sende einer Freundin ein XNA Programm von mir, sie startet, nix passiert - keine MessageBox oder sonst was. Hmn, was tun? XNA 2.0 installieren, das Programm war aber XNA 1.1. Programm gestartet, nix passiert. Das ist höchst ärgerlich, wenn das beim Endkunden passiert, denn der denkt dann: "Inkompetentes Pack! Scheiß Programm!"

Klar, sowas passiert auch bei nativen Sprachen wie C/C++, aber wenn ich ein Framework benutze, dann soll es auch von sich aus sagen (wie in .NET 2.0 aufwärts): "Hey, hier fehlt was!"

Dann, was mir spontan noch einfällt ist das Problem einer Meta-Sprache an sich. Man kann den Code von C# (eher der CLI) obsfuscieren, doch alles was verschleiert wurde, kann wieder "entschleiert" werden. Office 2007 ist z. B. in C# .NET gecodet und obsfuskiert mit eigenem Loader usw. Es hat sage und schreibe nicht mal 1 Woche gedauert, da war der entschleierte Quelltext public. Muss man sich mal vorstellen! Ein Programm mit dem Milliardenumsatz gemacht wird ist auf einmal nicht mehr closed-source!

Dies sind denke ich unter anderem die Hauptgründe, wieso XNA nicht gegen natives oder managed DirectX / OpenGL ankommen wird.

chrische5
Die Content-Pipeline ist aber gerade der größte Vorteil an XNA. Auf den zu verzichten ist dummheit, dann kann man direkt wieder MDX nehmen.

Bei Closed-Source weiß ich nicht, aber es geht um den Image-Schaden! Man sehe nur mal die Sache mit dem HL2 Source. Klar es hat dem Verkauf nicht geschadet, aber die Lizenzkosten für Engine usw. sind in den Keller gegangen. Hier geht es definitiv um das Prinzip! "Wofür Geld ausgeben, wenn ichs schon kostenlos haben kann?"