Michael Klucher - MSFT

Cross posted from: http://blogs.msdn.com/xna/archive/2006/12/03/got-a-feature-suggestion-for-the-next-version-of-xna-game-studio-express.aspx

We're putting the final touches on our first release of XNA Game Studio Express and our launch on December 11th is less than three weeks away! Many of the teams members have started to think about features that could be implemented in versions of XNA Game Studio Express down the road. While the team has ideas about things wed like to do, we rely on you to tell us about the things youre interested in or that youd like us to change in future releases of the Product. The best way to share this information with us is by using Microsoft Connect. If youre unfamiliar with Microsoft Connect, please visit this previous post on our blog, for step by step instructions on how to get started.

Weve set aside a site on Connect where you can file issues or suggest features for the next version of XNA Game Studio Express. If a feature has already been suggested, you can show your support for that feature by voting for it. We use those votes to help evaluate whether to implement the feature. Its always better to vote for a feature rather than suggest it twice. So if you have some ideas to make XNA Game Studio Express even better, head on over to Microsoft Connect and add, or vote for, your favorite feature suggestions today!

Thanks!
Michael




Re: XNA Game Studio Express Got a feature suggestion for the next version XNA Game Studio Express?

Speeding Target

Seems good.





Re: XNA Game Studio Express Got a feature suggestion for the next version XNA Game Studio Express?

parlance

At the moment this is my wish list (in order):

1. Support for compressed audio formats in XACT to make music less of a headache.

2. Support for compressed texture formats (DXTx) and runtime decompression of other formats for texture resources in the content pipeline (png, jpg, etc). I understand obviously that textures are converted into a format better suited for very fast loading at the moment, but many games tend to have a handful of textures that are used or loaded infrequently that are incredibly large, and large uncompressed textures can very very quickly explode into some massive files. In terms file size on the end-user's hard-drive it's hard to care very much, but for online distribution this creates a nightmare. Another solution would be install-time decompression (from png, jpg, into the native xna texture format) built into the publish tool for specificly flagged texture assets. Then we could still keep lightning fast load times without absolutely massive downloads for those we would like to share our games with.

3. A serious problem with XNA from my perspective is the inability for developers to easily design custom tools for the creation of meta-content (like, for instance, levels, be they 2D tiled, or 3D) which relate not directly to media, but the useful and coherent configuration of that media. No matter how you look at it, any but the simplest game is going to require a custom tool for level design at the very least, unless you think you can get away with hard-coding complex environments. Obviously, XNA wasn't designed for application or GUI-based tool development, and this forces developers away from XNA to create their tools that they need for their XNA-based game. This creates a large headache because of the amount of code that could've potentially been shared between an easy to use WYSIWYG editor and the game engine itself.

What I'm suggesting would be a seperate project template that would implement editors as another set or derived classes from seperate base classes (ie. Editor class instead of Game class, and EditorComponent, or what-have-you). These classes would be supported by a robust GUI (and if they needed to be a virtual D3D gui instead of a windows GUI, so-be-it) handling set of classes to allow users to quickly and easily develop their own content creation tools and level editors without de-integrating their editors from the XNA content-pipeline and their own game libraries/classes.

3. A cross-platform compatible version of networking support. (hehe, I know this one is probably kind of far down the list).





Re: XNA Game Studio Express Got a feature suggestion for the next version XNA Game Studio Express?

Bye Bye

Hello is it possible for microsoft to make old school game code available to build games.I think it whould be alot easier to make games on xna if you gave us more code to do certain things. Take a game like "River City Ransom" I buy the game code from you guys for $5.00 then pay royalties to the code writter if the game is a hit.The possibilties are endless.



Re: XNA Game Studio Express Got a feature suggestion for the next version XNA Game Studio Express?

glenrm

Let's all vote for build in font support

Is there any build in speech support






Re: XNA Game Studio Express Got a feature suggestion for the next version XNA Game Studio Express?

Billr17

I'd like to at least see a basic framework for .X model animation built in. If not that, possibly an better way to extend the existing content pipeline .X loader to support animation.




Re: XNA Game Studio Express Got a feature suggestion for the next version XNA Game Studio Express?

Jon Watte

Top three features:

1) Generational garbage collection on Xbox

2) Parameters for content processors

3) Support for streaming user-generated audio (I see non-managed XACT has this on PC now, btw)







Re: XNA Game Studio Express Got a feature suggestion for the next version XNA Game Studio Express?

AndyL

 Jon Watte wrote:
Top three features:

1) Generational garbage collection on Xbox

2) Parameters for content processors

3) Support for streaming user-generated audio (I see non-managed XACT has this on PC now, btw)


plus:

* Multiplayer networking on 360 (including reliable UDP, audio and all the other 360 goodies)

* Much better inlining of methods on the 360, (including ones with float parameters!)

* Multiplayer networking

* A separate VMX library on the 360 (already in connect)

* Multiplayer networking!





Re: XNA Game Studio Express Got a feature suggestion for the next version XNA Game Studio Express?

zxdgsadf

My votes are:

1) Built in boundingBox for meshes that tracks the meshes every move/rotation automatically. (boundingSphere already exists but all too often such a sphere sticks too far out away from some edges of the model to be useful.)

2) Easier picking (clicking on 3d objects) in all forms... boundingBox/Sphere or mesh.

3) More idiot proof explainations when it comes to importing and using .x models, particularly when using lighting that is different than the default lighting (which can be hard on the eyes with a flat model because the specular values are difficult to control). This really could be a good candidate for something that can be used for beginners so it would have to be easy for someone with little Xna or DX D3D experience to understand.

Scott





Re: XNA Game Studio Express Got a feature suggestion for the next version XNA Game Studio Express?

parlance

zxdgsadf wrote:

My votes are:

1) Built in boundingBox for meshes that tracks the meshes every move/rotation automatically. (boundingSphere already exists but all too often such a sphere sticks too far out away from some edges of the model to be useful.)

...

What you're asking for is a built in physics system, which I don't believe would be in the spirit of the API. XNA was designed to give developers easier access and ability to build game engines and integrate their content pipeline into that game engine, while at the same time simplifying and taking care of non-game-related functions allowing the developer to focus ONLY on the game engine, rather than the win32 API interface or complex direct3D device initialization procedures. The key point here is that a physics engine is important, but unique for each game. Depending on the kind of game, the structure API, methods and results will all vary. In other words, the physics engine is and should be part of the game, not the API. If you need finer control for simple collision detection I suggest you using several smaller bounding objects mapped more tightly to your mesh instead of one larger one, and if you demand moving and rotating collision detection with complex objects, I suggest you google "game physics".