Release A Casual Game That Requires .Net 2.0?

[dxgame]

Is there enough end users to release a casual game that requires the 2.0 .NET Framework? Now, 6 months from now, 1 year from now? Thanks for your input.

[cliffski]

I still dont have that framework installed (is there a new one now?) and see no reason to install it either. I'd steer clear.

[PrefixEx]

Most of the reading suggests "casual" gamers are generally somewhat behind to far behind the leading edge (on average: old hardware / even older OS). A .NET 2.0 game does not seem like a good fit for such customers.

[ThomasW]

If you're going to go .NET, why not compile to v1.1 so it has a wider user share? I can't think of any 2.0 features that'd be of significant enough advantage to counter the disadvantage of the smaller 2.0 user base.

There will be a not insignificant number of people without any .NET installed though, so you would have to cater to them. You would either have to offer your game download by itself with a link to the .NET Framework download page for those who don't have it (which could confuse some non-technical people and annoy others who don't want to download and install a 23mb program), or you'd have to offer two versions of your game to download, one which also installs the .NET Framework (and is thus 23mb bigger).

Unfortunately .NET executables give an ugly error message when run on a non-.NET machine, so you're likely to get users downloading the regular version and then emailing you upset that your game doesn't even run. You could maybe handle that by detecting the presence of .NET from your website, maybe with a .NET web 'applet'.

The problem would be compounded if you're trying to sell the game through portals, though, as you wouldn't have that much custom control in the versions you offer for download. You might be able to offset that if you can get a relationship with Microsoft, as they are interested in promoting the use of .NET and existing games that do so serve as good examples for them to use.

We're making our game, Cavemen, for Pocket PCs and Smartphones with the .NET Compact Framework, but that comes pre-installed on a majority of devices (any from mid-2002 onwards) and is only a small download otherwise. We do plan on doing a PC version of our game, though, and are going to face these same issues in how we offer it.

[gosub]

I'm using .NET 2.0, C#, and Managed DirectX 9. I have my setup program (thank you Indi Gamer people for pointing me to Innosetup) configured to display my "Requires .NET 2.0" web page if it's not installed. E-mail me through my web site, and I'll send you Innosetup code to do that. http://gosub.com/OpenSource/DirectXControl/DirectXControl.htm

<My opinion> My game is already too big for people using modems. Another 20Mb won't hurt broadband users. I want nice graphics, so I need modern hardware and DirectX 9. Microsoft will be installing .NET on all future versions of the operating system, and more and more people will have it. C#, garbage collection, and delegates are priceless. Don't bother with .NET 1.1 because it's useless without generics. </My opinion>

-Jeremy

[arcadetown]

If a technology's not going to cleanly run on alteast 99.5% of user systems (w/o additional downloads) I'd avoid it like the plaugue. Thus I'd avoid .net for now. Probably not feasible till 2 - 3 years after Vista has been out building a decent intall base.

[Hiro_Antagonist]

Neither .NET 1.1 or 2.0 have enough of a user base right now to assume customers have it. So honestly, at this point you should go with 2.0. I can't think of any practical reason to stay with 1.1.

If you use either version of .NET, you *must* include that version of the .NET framework as part of your installer. This honestly isn't a big deal and can be done transparently, but it will increase the size of your installer by up to 30MB.

FWIW, there are only a handfull of people who have *released* a for-sale game built on .NET, and I'm one of them. =) All things being equal, I recommend not using .NET for game development, but if you do, be prepared to have your installer size increased.

Also, Managed DirectX is a much nastier beast. We used Managed DirectX, and that's where most of our problems came from. If you're going to use .NET, try to use some other graphics API other than Managed DirectX if at all possible. That's where the majority of our headaches came from.

[Mike D Smith]

I would say no. But I have a friend who does just what you are talking about.

Check out:

www.flatredball.com

You can also contact him directly at:

VicChelaru@gmail.com

[gosub]

Also, Managed DirectX is a much nastier beast. We used Managed DirectX, and that's where most of our problems came from.
Is that because of the API itself, or because users need to install it separately? I haven't had any problems with the API (however, the Beta versions were very buggy). As for installation, I recommend distributing the Managed DLLs (and the unmanaged dependency, d3dx9_30.dll) with your application.

My own preference is to not distribute the 23Mb .NET platform with the installer, but I it's certainly an option.

-Jeremy

[Hiro_Antagonist]

Is that because of the API itself, or because users need to install it separately? I haven't had any problems with the API (however, the Beta versions were very buggy).
The Managed DirectX code is somewhat buggy, poorly documented, and not supported particularly well. But that shouldn't be too surprising, given how new the Managed DX wrapper API is. We found things that just plain didn't work right.

But the bigger issue is distribution/installation. It will inflate your install size even more, and it's impossible to have a truly silent install for managed directx. Plus, I've found machines that just plain won't let us install it, and we've never been able to figure out why. Luckily these are a rarity, but every single machine at the IGC in Eugene last year rejected our managed directX installer. So it was obviously something about their configuration, but we were never able to pinpoint what it was...

As for installation, I recommend distributing the Managed DLLs (and the unmanaged dependency, d3dx9_30.dll) with your application.
This would be ideal, except that it's a violation of the terms of use. (Or at least it was when we looked...)

My own preference is to not distribute the 23Mb .NET platform with the installer, but I it's certainly an option.
It's not an option. It's a requirement if you plan on selling your game. Period. Sorry to sound harsh, but if you claim otherwise, then you clearly have never tried to distribute something like this, even though an alpha/beta.

No offense, but if you think that people are going to track down these components (.NET framework and maybe Managed DirectX too) and install them themselves before they try your game, you are very, very mistaken. Especially when you're talking about a casual audience, where the assumption is that they barely know how to download/install a game in the first place.

During our own beta phase, before we had .NET/MDX integrated with the installer, I posted extremely clear directions, complete with download links. And from what I could tell, the actual success rate of those who tried was only about 50%. And those were tech-savvy people who had clear instructions available. There were tons of other people who didn't even bother trying because the instructinos were too much work.

So seriously, distributing your game w/o any dependancies built in is suicide, and it's pointless. Especially if the install base for your dependancies is <80-90%. (And, FWIW, I would expect .NET 1.1 to be <10%.)

[gosub]

Fair enough. I would suggest trying the later version of managed DirectX, as I haven't had problems with them.

BTW, there are programs you can buy that will package your .NET program to a stand alone application while stripping out all the unused .NET portions. Last I heard it would add about 3Mb to your executable. As for whether or not that's a violation of Microsoft's license... I wouldn't know. However, Microsoft's own web site points to these programs so I doubt you'll get in to trouble as long as it only runs on Windows. My guess is that the license is mainly to prevent you from running Microsoft DLLs under a non-windows platform.

I'll be investigating these programs before I release commercially. Thanks for the input.

-Jeremy