Nur noch wenige Stunden bis zur XNA-Beta!
-
Die Beta-Version vom XNA Game Studio Express ist nicht mehr weit!
http://msdn.microsoft.com/directx/XNA/
Developers will be able to download Game Studio Express from MSDN and develop games for Windows for no cost. Additionally, XNA Game Studio Express will allow developers to commercialize their games for Windows.
-
Es ist da!
http://msdn.microsoft.com/directx/xna/gse/
-
Wie ist denn der erste Eindruck?
-
kann man in der faq lesen
es ist eher ne alpha statt einer beta (es fehlen zuviele grundlegende dinge wie z.b. x-mesh laden, wie sollen nur die causalcoder ohne sowas effektiv arbeiteb?)
laeuft auch nur unter win, quasi abgespeckte directX managed version...
-
Habe mich eigentlich drauf gefreut, aber es scheint wirklich nicht so das Wahre zu sein. Da bleibe ich lieber bei C++ und OpenGL.
-
Wird es den Final Release auch nur in C# geben?
-
1310-Logik schrieb:
Wird es den Final Release auch nur in C# geben?
natuerlich
ich bin zwar kein linux guy, aber die ps3 mit linux, c++ und ogl werde ich dann doch den vorzug geben.
-
Tja, hab's mal installiert und drüber geschaut.
In Verbindung mit XNA Build sicherlich nicht uninteressant.Allerdings stellen sich mir folgende Fragen:
- Was ist mit der Implementierung von Fremdsystemen? Die Kollisionslibrary scheint sehr begrenzt zu sein. Da ich keinen Bock hätte, das Rad neu zu erfinden, wäre eine kleine OpenSource Physik-Engine nicht schlecht. Die gibts meistens in C++, was zwar über .NET kein Problem sein sollte, aber im Hinblick auf XNA evtl. schon.
- Netzwerk etc. scheint momentan kein Thema zu sein. Mit DX mäßig nicht auf den neuesten Stand, wie siehts denn da aus?
- Man hat schnell was rudimentäres gebastelt, das ist nicht schlecht. Aber Format-mäßig fehlt noch ein Riesenhaufen.
Insgesamt gesehen muss man sich fragen, ob man mit OpenSource Libs und Engines nicht doch besser fährt. Der Ansatz ist denke ich interessant, aber ich muss noch zuviel neu erfinden. Die Geschichte mit der XBox ist natürlich spannend, zumal die Zahlungsmodalitäten günstig sind. Naja, noch ein bischen mit rumspielen.
-
Was Microsoft unter einer Beta versteht, kann einem wirklich Angst machen...
-
Also ich finde die Idee, dass Component Model zu verwenden um Designer zu ermöglichen, prinzipiell gar nicht schlecht. Es hat nach meinem ersten Verständnis auch einige Vorteile, die Game-Klasse zu verwenden: Man kann zum Beispiel ganz einfach ein GraphicsComponent platzieren und hat automatisch kein Fenster-Gefrickel und Device-Resetting mehr.
Alternativ kann man das GraphicsDevice auch wie immer schon initialisieren und sein eigenes Fenster-Handle übergeben.
Ich bin mir im Moment noch unsicher, welchen dieser Ansätze ich verfolgen soll. Beim ersteren gefällt mir nicht so, dass ich weniger Kontrolle und vor allem auch über die Game-Loop habe. Ist denn zu Erwarten, dass in Zukunft viele weitere interessante Game-Komponenten zu verfügen stehen, so dass sich das mit dem Designer lohnt? Was meint ihr? Im Moment tendiere ich eher dazu, XNA wie managed DirectX zu verwenden.
-
Optimizer schrieb:
Ich bin mir im Moment noch unsicher, welchen dieser Ansätze ich verfolgen soll. Beim ersteren gefällt mir nicht so, dass ich weniger Kontrolle und vor allem auch über die Game-Loop habe.
wohl weil viele der zielgruppe schon unfaehig sind einen gameloop aufzusetzen, und weil eklaeren/beibringen einiges an zeit erfordert, ist es besser den leuten den fisch direkt in die hand zu druecken.
Optimizer schrieb:
Ist denn zu Erwarten, dass in Zukunft viele weitere interessante Game-Komponenten zu verfügen stehen, so dass sich das mit dem Designer lohnt? Was meint ihr? Im Moment tendiere ich eher dazu, XNA wie managed DirectX zu verwenden.
natuerlich wird es mehr solche helfer geben. wenn MS weiter so fleissig bleibt, wird Visual Developet moeglich sein und keine programmierkentnisse erfordern um kleine spiele zu entwickeln. damit deckt man eine sehr sehr breite schicht der kundschaft dann ab.
-
Also mein bisheriger Eindruck:
Ich werde XNA wohl als neues managed DirectX benutzen und das Application Framework liegen lassen. Die Idee mit den Komponenten hat mir anfangs gefallen, aber ich merke immer mehr, dass es schwierig werden wird, alles schön in Komponenten aufzuteilen, die man dann nur noch zusammenklickt.
Ich ertappe mich ständig dabei, Workarounds für Probleme zu suchen, die sich durch das Komponenten-Modell ergeben. Für GUIs finde ich sowas ganz in Ordnung, da nimmt einem der Designer auch sehr viel Arbeit ab, erstellt tausende Zeilen Code und man sieht sofort, was daraus wird. Da lohnt es sich, alles in ein Komponenten-Modell zu zwingen, von Component abzuleiten, keine abstrakten Klassen, Standardkonstruktor und Properties zu verwenden. Aber wenn ich mir hier den Designer-Code ansehe, dann spar ich mir nur sehr wenig selber zu schreiben, vielleicht ist es insgesamt sogar mehr, weil alles zurechtgerückt werden muss (Standardkonstruktor und Properties).
Zum Beispiel müsste man sich schon fast was dafür einfallen lassen, dass die Bildschirmauflösung zu setzende Properties sind. Die Auflösung sollte das Spiel aus einer config-Datei lesen und dann das Device erstellen. Und nicht das Device erstellen und dann gleich mal resetten. Das ist insgesamt schon mal mehr Code zu schreiben als gleich das Device selber mit den ganzen Parametern zu erzeugen. Immer wenn man irgendwas sauber machen will, ist das Komponenten-Modell im Weg und letztlich hab ich nichts davon, dass ich irgendwas hinklicke anstatt den 3-Zeiler auszuschreiben.
Außerdem hat mir das Eventhandling der Windows Forms ganz gut gefallen, vielleicht wäre es für einen Shooter ungeeignet, aber für ein RTS sind Events wie Click, DoubleClick, KeyPress ganz gut und sehr bequem zu handhaben und ich kann mir selber aussuchen, wann sie abgearbeitet werden, wenn ich so weitermache wie bisher. Bei dem Application Framework hat man keinen Zugriff mehr auf sein Fenster und kann nur mit XInput pollen (und natürlich eine Komponente schreiben, die dann wieder die Events anbietet).
Für mich ist das Application Framework nichts, im Grunde die selbe Thematik wie mit dem Sample-Framework aus dem DirectX SDK immer schon. Ich denke, man hat es ganz gut gemacht, dass sich jeder aussuchen kann, wie er arbeiten möchte. Das, was in XNA dem managed DirectX entspricht finde ich nach wie vor ziemlich ordentlich und auch an einigen Punkten verbessert.
-
Mir ist btw. völlig unbegreiflich, warum man C++/CLI erstmal nicht verwenden kann. Ich bin deswegen nicht traurig, aber das schöne (auf dem Papier jedenfalls) war an .Net immer dass man eine Klasse in C++ schreiben, in C# verwenden und mit VB irgendwo hinklicken kann - jeder wie er mag.
-
Optimizer schrieb:
Mir ist btw. völlig unbegreiflich, warum man C++/CLI erstmal nicht verwenden kann.
weil die zielgruppe unfaehig ist portablen code zu schreiben -> c#
-
rapso schrieb:
kann man in der faq lesen
es ist eher ne alpha statt einer beta (es fehlen zuviele grundlegende dinge wie z.b. x-mesh laden, wie sollen nur die causalcoder ohne sowas effektiv arbeiteb?)
laeuft auch nur unter win, quasi abgespeckte directX managed version...Afaik werden die X-Files nicht mehr unterstützt werden. Gab bei gamedev eine Diskussion darüber, die Funktionalitäten fliegen wohl raus.