I've started using C# to develop my helper apps for my games. And have found the managed programming to be pretty great. I really don't like how there's no pointers per se, but seeing thru the concept oriented programming, you can treat it like there is. Since when I'm coding most of the time, I usually concentrate on content nuances over paranoia over the semantics of language speed issues, I decided to consider coding my game in C#; it on the top level appears to return the same framerate my game did in C++, I suppose cause I'm not using high overhead .NET calls in the game loop, I started using it when I wanted a windowed gui in game editor, and I like the method of laying out the window forms and instancing them like any other class object. Then when the game is done, simply, remove the instances of these windows, and remove the form definitions from the project, and you have the finished game. My question is, the dotnetredist.exe issue. Users only have to download this once, but it's 19.7MB, most people probably get it from windowsupdate, but I only had it cause I use Visual Studio.NET, but my friend had to get the redist. I mean talking about complaining about file size, that's a considerable etc. But I mean, Direct X newer versions, a lot of people don't have that either believe it or not, except high end gamers, that seems like a serious impact. Do some of you have any opinions on this matter? I appreciate any feedback.

I really like dotnet, and use it exclusively in my day job, but I don't think it's viable for indie game development. The runtime download is 20 meg, and if you want native DX bindings, you'll need DX9 as well. That's a *huge* download requirement.

If you were doing a retail game that came on CD, then I think dotnet would be great. But it's just too big for internet distribution.

I suppose I already knew that, and was trying to find justification. When there was none. Hehe. I suppose I could just write my helper app, and write conversion stuff for loading in C++, shelling out to the C# editor for my local in game editing. C# has been great though, it and .NET have made me realize things about C++ semantics I didn't realize in the past years. Stuff that I suppose went over my head. Some of the managed aspects that I assumed, didn't work, and the work it took to correct issues, shed new light on coding semantic at the c/c++ level. Constructs I used incorrectly. Despite it working, and never having a problem usually, the occasional situation that never yielded a solution was due to incorrect perception of the higher level semantics to start with. I never had any schooling on it, and always read tutorials and books, and since perspective varies from context to context, your input from those sources can confuse your own perception of a subject. At least from my perspective. Hehe. Talk about a circle jerk. 8) Thanks for the input.

And the big problem is that Microsoft isn't really pushing people to download it as well as they could. Usually when Microsoft releases something, they force it down everyone's throats. They don't seem to be doing that with .net, but I wish they would.

Yeah Kronos, me too. Then the extra DL time wouldn't be as much of an issue. But it's a factor I can't ignore, especially, if I want things to work out. I guess I have more coding ahead of me than I hoped. I mean, the quickness of Window App Development in C# can't be ignored, at least for me. So I'm certainly using it to my advantage dev side, I'm developing a few things for app communication anyways, shelling out and telling my game editor what to load up and modify, and send back when I freeze the game and mouse select a game object to edit won't be that much of an issue, once it's coded, writing a C++ version won't be much of an issue. I use the same semantic in C++ that .NET uses making everything an object anyways. That's cool I suppose.

I find myself in the same boat with Java right now, but I've gotten round it by natively compiling to a .exe. I thought .NET code could be compiled normally too into x86 code? Or am I imagining it?

Cas :)

I'm relatively new to .NET. But it uses constructs called assemblies for compiling to make over all redist size smaller, it makes interop dll files that have only the referenced code in them versus compiling a library of code from which only a small percentage of objects are used. The .NET Framework that you have to install I imagine is code that makes this dynamicness possible. It must have external interdependencies that require the framework to be install to run properly. Whatever the case it seems to be a really great system of coding. I love it myself.

I find myself in the same boat with Java right now, but I've gotten round it by natively compiling to a .exe. I thought .NET code could be compiled normally too into x86 code? Or am I imagining it?


Sort of.

Dotnet is compiled into MSIL, which is equivalent to Java bytecode. On the first execution, the MSIL is converted to x86 code and cached, so you don't do the conversion every time.

Where you got Java to work is not so much the fact that it's compiled, it's that Jet stripped out the parts of the Java runtime that you didn't need. The JRE is pretty big, but if your game doesn't use JDBC, Jet doesn't include it. So instead of requiring the end user to download and install the full JRE, they only download the pieces that they need.

Dotnet, on the other hand, is all or nothing. There isn't (presently) any way to piece it out like Jet does. I don't know if that would even be possible, since the dotnet runtime is really a system level replacement of COM.

I think that LordKronos is right; if MS *really* wanted to, they could have had a much better market penetration by now. I think they are targetting the corporate environment and kind of skipping over the home market.




But it uses constructs called assemblies for compiling to make over all redist size smaller, it makes interop dll files that have only the referenced code in them versus compiling a library of code from which only a small percentage of objects are used.

An "assembly" is just an exe or dll with manifest info included. "Interop" is making COM calls from dotnet. You've got the right idea, but the wrong terminology. :)

The first place we're likely to see a consumer rollout of .net is Xbox2. You heard it here first ;)

Cas :)

isnt the new version of the xbox sdk for .net?

Well it could still be for VS.NET without actually using any of the .net components or managed code. That's the trouble with microsoft's brilliant idea to name anything and everything .net ... at least they came to their senses and change Windows Server 2003's name (it was going to be called Windows.NET, and much more confusion would have insued).

The first place we're likely to see a consumer rollout of .net is Xbox2. You heard it here first


The first consumer rollout will be Longhorn or the new Office, which ever comes out first. I think xbox2 is still down the road a ways.

In any case, the xbox has been a much discussed target of the compact framework for months.

ah, but which one will ship first :D?
Oh, I don't much care anyway, as my money's on Java!
Or, er, not. As the case may be.

Cas :)

The latest xbox sdk have support for .NET. This means you can use the xbox sdk with the .net IDE. However, it does not mean using the .net framework, or C#. It's still all C/C++.

I believe that in a few years .Net development will become dominant in the Windows arena. It leads to higher code quality as well as smaller downloads. In time, specific cpu and cross library optimizations will even allow it to surpass C/C++ in speed.

Of course, today these assumptions are not true.

I wouldnt even begin to consider using this stuff for development at the moment. I presume my users have DX7 and thats it. Youd be surprised how many people run games fine on win95 or win98, and how many have 56k modems. Most people I know wouldnt know where to get this .net framework if they wanted it, and certainly wouldnt appreciate the download.
Even as a developer and keen gamer I dont have the latest of anything other than DX9. My drivers are the ones that shipped last year with my card(they are stable, and I have had all sorts of problems with the detonators). I also run Windows 2000, (dont see the point in blowing money on XP) and dont have the latest service pack ( it wouldnt install, and I cant be bothered to work out why).
Unless you are only targeting hardcore gamers, be very careful what specs you require ;)

We write tools in C# and .Net for speed and ease of creation (like was mentioned, windows apps are a breeze in this env), but I agree completely, that you couldnt ship a game with .NET for the forseeable future.

The light at the end of the tunnel is that .net will be a system component of all future OS's, but the black mark is that obviously that wont work well for us indie devs (unlesss its ok requiring a 64bit OS :))

Lets face it, use it for tools, do the game code in C++.

Phil.

I don't have much experience with .NET, but it seems like an interesting way to write platform-independent programs.

I downloaded the SDK from MS once, but it didn't seem to have any compiler :( Later I tried sharpdevelop, which worked fine and was easy to use. But then I couldn't get any program to work on a friend's pocket PC.

Anyway, I read somewhere that it's easy to decompile, modify and then recompile bytecode of .NET programs (a virus named "serot" spreads itself by doing that), which means your game would be easy to crack!

Mike

Originally posted by Mike Wiering

Anyway, I read somewhere that it's easy to decompile, modify and then recompile bytecode of .NET programs (a virus named "serot" spreads itself by doing that), which means your game would be easy to crack!And that would be different from almost any other game how? :) Yeah, people like to point things out like that, as if it hasn't been an issue since the beginning of time. While bytecode might be ever so slightly easier to decompile than native machine code, with modern tools it makes little or no difference to the people doing the cracking.

The only trouble with doing cross-platform programs with .NET is that there arr effectivelt two versions of the .NET architecture-- the 'full' implementation and then the 'cross-platform' implementation. The cross-platform one is considerably less robust, in order to make it a less daughnting task to implement it on other platforms... but adhereing to that down-graded standard in code can be cumbersome.

Microsoft does provide tools to test your program for compatability with that cross-platform standard however, although I haven't used it myself.

And what, exactly, do you think they mean by "cross-platform"?
It doesn't bring any new technology to the table, it's definitely not cross-platform as I understand it, and it's got several years of catching up to do. It's pretty much madness to try and write a game in it on nearly every count right now.

Cas :)

Several years of catching up how? In being cross-platform?

I don't think it would be madness to write a game with it now, if you could do something about the download size. From a technical perspective, it's more than ready. It's just really really big.

Well, it's a couple of years behind its main competitor performance-wise.

And it's over twice as big.

And it brings nothing new to the table.

I can't see a compelling reason to use it over Java, which is more widely supported, faster, smaller, and mature. I'd be using it myself if it was faster and smaller and crossplatform and had excellent development tools - but it just doesn't.

Cas :)

Originally posted by princec
I can't see a compelling reason to use it over Java, which is more widely supported, faster, smaller, and mature. I'd be using it myself if it was faster and smaller and crossplatform and had excellent development tools - but it just doesn't.
Cas :)


I would say the compelling reason is that MS is fighting Java and building .Net. I would guess that the improvements to .Net on the Windows platforms (XBox, Pocket PC, etc) will far exceed Java in the long run. In time, the framework will be a given and Java will be the big bulky install.

Cross platform is a great weakness of .Net. There is no way to be assured that it will port well in the future. I am sure it is not on the top of MS's to-do list. For me this is not an issue since I only code for Windows.

I can't see a compelling reason to use it over Java, which is more widely supported, faster, smaller, and mature. I'd be using it myself if it was faster and smaller and crossplatform and had excellent development tools - but it just doesn't.


I've used both, and there are a lot of things that dotnet does far better than Java does. Sorry, but the VS.Net dev environment beats the pants off of anything in the Java world. The speed is good enough*, and I don't give a hoot about cross-platform.

* Can you cite any (possibly unbiased) studies that compare the speed of Java VM to that of the dotnet CLR? I know when MS was doing Java, their VM was quite a bit faster than Sun's.

Sun's VM has gotten an order of magnitude faster since then whereas the MSVM doesn't seem to have improved. YMMV but I now see very little difference between the Sun server VM and exe compiled code now. And what of Eclipse, Netbeans, Jbuilder, IDEA...? The crucial difference being that there is actually a wide choice to suit everyone's different programming styles.

Out of proper interest - what things does .net do better than Java? (Apart from integration with DirectX :p )

Cas :)

Well, these are my own opinions naturally. I did one large Java project and several smaller ones before taking a look at dotnet, and it's certainly possible that I could have done things differently.

Java on the desktop is just plain awful. My project was Swing based, and it was clunky and didn't play nice with other apps. I guess most people are using SWT now? Because it didn't integrate well, printing was a gigantic pain. I ended up using IBM's Bridge2Java in order to hook into crystal reports.

ADO.Net takes half the effort to get productive than JDBC does. And at the time, I was stuck using the ODBC bridge, which was slow and inflexible.

Anonymous inner classes for event handling is ugly. Delegates are much nicer. And Delphi-style property handlers.

Webservices are much simpler and tremendously faster than J2EE.

With dotnet, you get most of your needed functionality in one package (hence the huge download). With Java, you have the base package, the javax packages, the J2EE packages, the Apache/Jakarta packages.

Basically, I began to dislike Java because Java apps don't interact with the OS. They don't look like Windows apps, they don't feel like Windows apps, and they have a hard time taking advantage of OS services. The end users of the app I wrote didn't care that it was cross platform (which it really wasn't because of the crystal reports dependency), they only knew that it didn't feel right.

I think the way that you are using Java is great. You're basically hiding the fact that it's Java. Games don't have the same UI constraints and expectations that a business app does. If I were going to start coding a game from scratch, I could easily consider looking at how you did it.

But for business apps, which is supposed to be Java's strong suite, it just falls short. Maybe it's stronger on the server, but after looking at J2EE, I don't see how.

I've only looked at NetBeans and JBuilder (I used JBuilder the most), and both were slow, feature-free memory hogs.

Looks like you were using an older version of Java than I. The desktop integration is now excellent, although many people including myself think that Swing is more complicated than it ought to be. SWT isn't bad but it's not as well supported. Neither of them are particularly useful for writing games ;)

JDBC is absolutely trivial to use - I don't know anyone who's used the ODBC bridge except you (!) because pure Java JDBC drivers are available for just about every database out there. Again, probably not so useful for gaming but good on the server. I use it to do my registration stuff.

Anonymous inner classes I use all over the place for all sorts of things. I don't actually use them for event handlers - I always define an explicit inner class usually called EventHandler for that, and it seems to be a much more powerful and useful mechanism than delegates. Delegates are a handy pattern however; but now my IDE has a wizard that writes them for me. I use both in Alien Flux extensively.

All the javax packages you generally need are built in to J2SE now, with only a few of the more webby/EJB things in J2EE. I don't like J2EE much but a bunch of huge usabilty improvements are being added in the next release of Java which should help. Again, this extension stuff isn't generally useful for games.

One thing I have found extremely useful is Java's remote method invocation - it's absolutely trivial to create servers and have your Java game talk to them. Very handy to do regcode checking and online hiscores! In fact I could do the instant buy credit card stuff too in a trice except I don't have a merchant account.

Don't know about webservices - it looks like a hideously complicated way of doing something really simple - but I'm going to find out later this year...*

But when it comes to interacting with the OS - for games, we're all sorted now. Using that LWJGL (http://www.lwjgl.org) lib to take care of the boring boilerplate code we've got all the OS interaction we need.

You should take a look at Eclipse (http://www.eclipse.org) IDE - it's free, fast, and well-featured. It's what I use and I don't think I could ever switch now.

Cas :)

* unless sales of Alien Flux rescue me