Recommended Posts

Are there any good alternatives to XNA for .NET? I'd like to create a simple game that doesn't require the user to install any additional runtime packages (eg. XNA) besides .NET 2.0. I really like XNA but the runtime packages are the dealer breaker. I just want to distribute a zip file with a couple of DLLs and have the user go from there without any installation required.
I've found SDL.NET (which hasn't been updated in over six months) and OpenTK (OpenGL). OpenTK seems nice since it appears to be actively updated, etc, but it doesn't provide any of the utility functions like XNA, etc.

Share this post

Link to post

Share on other sites

I'm not suprised to see the responses but I'm against installers for very small indie games.

For example, if I saw a neat game that I'd like to try but didn't have .NET Framework 3.0 or XNA 3.0 installed than I would either have to find them and install them or if the game creator bundled them then I'd have to download a very large package. On top of that, you have wait for everything to get installed, etc, etc.

I'm all for installers for large commericial games but for Windows development I like to keep everything as small and compact and possible and have the highest exposure by not requiring a lot of extra stuff to be installed.

That's just my personal opinion. Obviously a lot of people disagree :(

0

Share this post

Link to post

Share on other sites

Since you disagree with most of the rest of the software development world, you've set yourself up for an uphill battle. A few APIs have suitably lax restrictions such that you can just package up their DLLs, but you have to be careful -- for example, take SlimDX. We're fine if you just ship the DLL in a .zip file (along with a text file or some such containing the license). But SlimDX needs Direct3D... and you are not permitted to ship the D3D dlls directly, you must use the redistributable (which is why we provide a runtime redistributable installer that takes care of handling all that crap for you).

Other APIs may have similar implicit problems. Any of them that use D3D under the hood will require D3D to be installed. At that point, you're already using an installer so I don't understand the aversion to including more stuff in that installer. It's not like you're adding too much additional size -- you'd need to include the same stuff if you were capable of shipping the package as a simple .zip anyway.

Things like the .NET framework and XNA are a bit large, yes, but try to look at it this way: if your users don't have either of those (and your game needs them), they must acquire them regardless of whether or not you ship them. So if you do ship them, you're making things easier for them... a win for you. You're also then making things easier for every other developer using the same dependencies by increasing the installed base of those dependencies, and thus trending the entire market towards a state where we will be able to assume the existence of these dependencies in most cases.

The only people actually hurt by this are people who have such poor connections that they cannot cope with downloading a ten extra megabytes or so and who already have the dependencies installed. If you really care, you can pretty easily provide an installer that does not contain the heavyweight dependencies for this smaller subset of the market.