🔒 Locked

[.net] The value of .NET in game programming.

Started by EagleEye Mar 9, 2007 at 2:08 AM 22 replies 5.3k views

Original Post

Mar 9, 2007 at 2:08 AM

Over the past few years, I did a lot of research in an attempt to find out what the best technology would be to produce my game. I was looking for a 3D engine to use, and as a result I was also attempting to decide on the language I would use for my game's core code as well. I originally was using Auran Jet (which is now a dead project evidently)... because of the lack of support and updates for that engine, I moved to Ogre. Both of these engines are written in C++... and I was content, at first, to use C++ to develop my game. I was under this really strong impression (beaten in to my head by language fanboys) that "No self-respecting developer would EVER make a game in anything but C++." I think that at the time (circa 2003 I think?), this was fairly true... But here's the problem... I absolutely HATE C++. I hate its antiquated syntax, the long compile times, the hodge-podge method of linking god knows how many dependencies together, and having to update them from god knows how many websites, etc... (ie: stlport, among others), just to get things to compile. It was, to me, like having to learn how to build a car just to get to the point of being able to learn how to drive it. The language barrier, in short, was a real downer for me... but one I was resigned to deal with simply because that was the only real option... ... or so I thought. Sometime in 2005, I found .NET. I was doing a windows maintenance utility for a company I was working for... and after starting on it in VB6 (*shudder*), I found out about VB.NET! (This was about 8 months before VS2005 was released). In a MONTH I rewrote an entire VB6 app in VB.NET, learning the syntax as I went... with no compiler problems, or having to debug linker issues, or having to track down problems with invalid paths in my dependencies, etc... It was amazing! And what I found even more amazing... I learned that VB.NET was fully capable of doing damn near EVERYTHING that C++ is capable of doing... at least in the meaningful things. It truly was like driving a Cadillac! So, I started looking for other engines for my game... I did my research, asked a lot of questions about performance, etc... what I found was this: C++ programmers, in general, are fanboys that don't want to even LOOK at .NET because they simply can't allow their egos to risk having their "leet skillz" become obsolete. They will trash .NET (especially VB.NET) at every opportunity. (On that note... I found it hilarious when I would ask if they liked C#, and they would be like "Oh yeah, that language is fine... but VB.NET sucks!" Then I would point out to them that they're stupid, because C# and VB.NET compile down to the same intermediate language that is compiled by the JIT compiler... made them eat a little crow there...) I found that there ARE C++ programmers out there that are knowledgeable about .NET... amazing how they don't mind it at all, but the C++ programmers that haven't even LOOKED at it, and know nothing about it, make it out to be like it's worthless. I found that .NET is about 95% to 98% of the performance you'd get from a C++ application... and I determined that the minor performance hit was worth it for the reduced headaches and shorter production time. I found that .NET has a lot of premade stuff in it that, while available in C++, you'd have to find the right addon library for it, and add yet another dependency... it's all just THERE for .NET. IT was then that I realized that the .NET library is pretty much an UPGRADE of the old C++ "MFC". So anyway... I am now working with a .NET-based 3D engine (Truevision3D), which is basically a front end API for DirectX... it exposes all of the capabilities of DirectX to VB.NET (and C#, and Delphi, and ASP.NET, etc... even VB6!) SO here I am, with a client app written entirely in VB.NET... with an input system, a GUI system that I wrote FOR Truevision3D, a fully functional networking system (using TCP and UDP), that communicates with a server... again, which is written in VB.NET, using an ODBC connector to do the database work, a multi-socket network listener... even a Windows Form on top of it all to control the game server's settings while it's running! And the damn thing is SCREAMING fast! There is one thing missing from it all... AI. That is the ONLY thing I haven't even bothered to do anything with, because my brother (Dave, aka InnocuousFox) is going to be handling that. Here's the problem, though. Dave seems convinced of the same things those above-mentioned "fanboys" all chirped at me... maybe not specifically with game programming as a whole, but specifically with AI. He seems convinced that AI is best done in C++, and that we'd rather deal with the hassles of interop/CLI/COM, than for him to learn a new language and library. Now, he may very well be right here... maybe AI *SHOULD* be done in C++... But I'd like the opinion of some fellow .NET people here, as well as other AI programmers, or just other game developers in general. Am I being anti-C++ here? Is Dave being anti-.NET? Would Dave benefit in other ways from learning .NET? Should Dave ditch his "C++ only" mindset? Am I not realizing the limitations of .NET, or is Dave not realizing its potential and power? Is it really necessary for game developers to know C++ when they're not doing any low level hardware-layer stuff (like you would do in the actual 3D engine)? Hell... is C++ even NECESSARY for non-engine game programming? If given the choice, would YOU pick .NET over C++ for your game development, specifically for things like game LOGIC (not just AI, but game flow and message processing between systems like input to GUI, network to... anywhere?) Discuss please! [Edited by - EagleEye on March 9, 2007 3:33:00 AM]

carllloyd

Mar 9, 2007 at 2:35 AM

Am I being anti-C++ here?

No, you are doing the exact same that a C++ fan boy would do by saying, why should you write in another language when you are happy with VB.NET :) Its all personal preference and some people still maintain that C is still the best development language because its fast.

Is Dave being anti-.NET?

No, he may be onto something but it depends on what AI system your using. I think as a rule, if you need it to be really, really fast then you have to consider C/C++.

Would Dave benefit in other ways from learning .NET?

Probably, I love C++, but I would like to learn C# for Tool development and rapid application development

Should Dave ditch his "C++ only" mindset?

Thats up to Dave :)

Am I not realizing the limitations of .NET, or is Dave not realizing its potential and power?

No Dave has a good point about speed in an application and you have a good point about speed of development.

Is it really necessary for game developers to know C++ when they're not doing any low level hardware-layer stuff (like you would do in the actual 3D engine)?

Yes, because the majority of the time I dont do low level hardware work and it still needs to be blisteringly fast or i would be fired :)

Nypyren

Mar 9, 2007 at 2:53 AM

I've used a LOT of C++ and C# (and a bit of C++/CLI), and I've also coded some sections of high-level AI in C++ for two games so far. As far as AI goes, other than the low-level pathfinding and line probing stuff it's really not that math/processor/memory intensive, and is more about making sure you're just handling the bajillion state/animation transitions between different entities in the correct order.

For everything other than pathfinding, having the ease-of-development from .Net would win versus anything I can think of that C++ might do better (which isn't much).

C++ has some things that .Net languages don't... Macros, insane template tricks, multiple inheritance... But many of those things just completely confuse the hell out of you when something goes wrong. Can you debug some ridiculously gory expanded template mess? Sure. But do you WANT to?

.Net languages (C# in particular) have things that C++ needs ugly templates or hacks for. Delegates? Anonymous delegates? Reflection??! Fully automatic GRAPH deserialization (without more than one line of code tagging serializable classes)?! On the fly compilation (not interpreted!) of code? (the built in .Net Regular Expression system uses this, and trust me, that system is 'blisteringly fast') There are tons of totally different ways to do very very complex tasks using very simple methods in .Net that are still easy to understand and debug.

Perhaps the best part about .Net is that you can mix-and-match your languages. If Dave wants to use C++, he can use C++/CLI (although why bother learning the extra freaky keyword rules when he could (probably) learn C# faster?)

EagleEye

Mar 9, 2007 at 3:32 AM

Interesting analysis there Nypyren...

To be sure, Dave is VERY smart, and can learn new languages very easily... hell, he has a background in VB (for MS Access)...

I think one of his issues is that a lot of AI stuff out there (like code samples in books and such) are already done in C++, and he would want to just drop pre-done code in to start things out, and work up from there.

I think one of the major disconnects C++ programmers have when it comes to .NET is they think they'll have to rewrite all this old code they have built up over the years that allows them to do the stuff they want to do... when in fact, .NET removes the necessity of that cludged coded entirely... the library truly is cutting-edge.

Machaira

Mar 9, 2007 at 7:05 AM

Quote:
Original post by carllloyd
Am I being anti-C++ here?

No, you are doing the exact same that a C++ fan boy would do by saying, why should you write in another language when you are happy with VB.NET :) Its all personal preference and some people still maintain that C is still the best development language because its fast.

A true fanboy would say "C++ only because .NET sucks" without even knowing anything about .NET. [wink]

I've done C++ in the past for many years and I'll never use it again unless I'm forced to. There's just no good reason for me to use it.

Unless you're doing near-cutting edge stuff, .NET is perfectly capable of doing great games, especially with the advent of XNA. Take a look at the results of the Dream-Build-Play competition when it's over and see if that's not the case.

morx

Mar 9, 2007 at 7:17 AM

The reason I don't like .NET isn't from a programming standpoint, but rather a user standpoint. On every computer I've seen, .NET applications take much more time to load and are less responsive than native applications. Now, I know there must be some .NET applications that don't fit this stereotype, but I have yet to find one.

I'm sure .NET is much easier and probably more fun than coding in C++, but I think the users are paying the price.

My recommendation would be to use .NET (or java) for in-house tools, and use native code for anything that will be sold or released to a user.

Sijmen

Mar 9, 2007 at 7:56 AM

I'm just really sad that there isn't a half-decent C# IDE for OS X, and the end-user problems (on Mac) are even more annoying.

TheTroll

Mar 9, 2007 at 7:59 AM

The reason you see that some .net apps are slower is becuase the people writing them didn't take the time to understand the costs of varies .net calls. It is no different then doing Win32 api calls and not understanding what is being called. There are many Api calls that will drag an app to a stop if you use them too much. If the call is going to take a lot of time then you need to either let the user know this by some method or call it in a non-blocking fasion so the application keeps running.

In my opinion it is not .NET that is at fault but the people using it without understanding what is going on under the surface.

theTroll

IADaveMark

Mar 9, 2007 at 8:24 AM

I must mention that I have been a little misrepresnted here. ("You can indict a ham sandwich.") I AM a VB guy... years worth of VBA while doing Access/SQL databases. I am only recently come to C++ in fact which I learned specifically for game development. The reason I did that, in fact, was that I found that 90% of the game development world was written in C++. Because of that, I found that if I wanted to use anyone else's code to plug into my own game projects (e.g. downloads or AI code from the "Gems" books or "AI Wisdom"), then my project needed to be in C++. I am not inherently biased against .NET or VB - the existing base of game code is. I am not convinced that AI is best done in C++... I'm convinced that all the stuff I want/need to use already IS in C++.

To specifically answer the questions he posed:

But I'd like the opinion of some fellow .NET people here, as well as other AI programmers, or just other game developers in general.

First note... you actually think you will get an unbiased answer in the .net forum? People who don't use .net for whatever reason don't even enter this forum. Try asking the question in the "Game Programming" forum if you want unbiased answers. (Note: if you misrepresent me again the way you did here, I'll simply drive over and kick your ass.)

Am I being anti-C++ here?
No more than Mac or Linux people believe in their products over the popular alternative.

Is Dave being anti-.NET?
The way you present it? Sure. But, as mentioned, I'm being pragmatic. I simply don't want to rewrite a ton of already written code that I like to use simply because of the preference of one developer that I may or may not work for - for free.

Would Dave benefit in other ways from learning .NET?
Sure. It would make me more employable outside the game world. Same thing for Java and a lot of other languages. Hell, in 1999, it would have been nice to know COBOL to help with the Y2K bullshit. I actually plan on getting into .NET at some point... but probably not for AI or game programming simply because it is not yet convenient.

Should Dave ditch his "C++ only" mindset?
...which I don't really have. However, I have a bookshelf full of articles and code that are... oddly enough... "C++ only".

Am I not realizing the limitations of .NET, or is Dave not realizing its potential and power?
I think you are not realizing the scarcity of .NET... and simply the fact that I don't want to burn calories on another language at the moment.

Is it really necessary for game developers to know C++ when they're not doing any low level hardware-layer stuff (like you would do in the actual 3D engine)?
If you want to get a job working for or with someone other than yourself, you damn well better know C++.

Hell... is C++ even NECESSARY for non-engine game programming?
Define "necessary"... you can actually write entire games in Python if you want. And with the pre-written engines and SDKs out there, you don't need to do a lot on your own to write an actual working game.

I can't believe that I actually had to deal with this...

edit: added other references from other forums on GameDev

One large one and others referenced in that one.

1) Professional Games Made In C#?
2) Java for game development?
3) Java----C/C++
4) c++ or c#
5) Question about Java Vs. C# Vs. C++
6) Java Games?
7) Java is fast?
8) Secondary Language:VB or Java?
9) What makes C++ so powerful?
10) C# games and cheating...
11) Is C# good enough for system utility programming
12) MC++ vs. C#
13) Which language is best for a 3d Games Engine?
14) C# vs C++ as a choice for development
15) Is Java the Future?
16) why C# and not Java?
17) What do you think of the D language?
18) my c++ d c# benchmark!
19) The Definitive Guide to Language Selection
20) Sharp Java
21) C++ or C#?

[Edited by - InnocuousFox on March 9, 2007 10:24:15 AM]

benryves

Mar 9, 2007 at 9:36 AM

Quote:
Original post by Nypyren
C++ has some things that .Net languages don't... multiple inheritance...

For the record, that is not entirely true. Multiple inheritance is supported with interfaces, just not with classes.

Xai

Mar 9, 2007 at 10:56 AM

Quote:
Original post by benryves
Quote:
Original post by Nypyren
C++ has some things that .Net languages don't... multiple inheritance...
For the record, that is not entirely true. Multiple inheritance is supported with interfaces, just not with classes.

Believe it or not, I program in C# for over 80% of my tasks and time and multiple inheiritance (of implementation) is one of 3 things I constantly hate not having in .NET.

I use interfaces (extensively), and build systems of reusable, plugable binary components.

But dammit, whenever you want a things which needs to act as an A and a B, having to frigin forward all the calls of 1 or the other behavior manually just because the compiler is too stupid to support a syntax for specifying that in one line, pisses me off.

I'm not even asking for C++ style, identify modifying, legacy pointer based multiple inheiritance. And yes, I understand the evil problems for both compiler writers and programmers in such a system (when dynamic_cast(obj) != dynamic_cast(obj) it is easy to screw up logic big-time). But dammit, C# has explicit interface implementation, whatever happened to HELPING developers GET WORK DONE. how about something like:
public class C : IA, IB{ private A a; private B b; forward IA a; // auto forward all methods in interface IA to member object a; forward IB b;}

that's just thought one, obviously the compiler writters can change the details to be truely appropriate to their vision, but come on, THIS:
public class C : A, IB{ private B b; void IB.Method1(a1, ...) { b.Method1(a1, ...) } ...}

just sucks!

Sneftel

Mar 9, 2007 at 11:16 AM

Personally, I hate doing AI stuff in C++. This is primarily because I do AI stuff in a generic style with lots of functional programming, and in C++ this generally means either disgusting amounts of runtime overhead from Boost's nooks and crannies, or ten times as much code.

With that said, Dave's a smart guy. He's fully capable of doing stuff in C++. And getting C++ and .NET to talk with each other turns out to be really, really easy, so there's not that much development friction that'll be added by going with a mixed approach. Let Dave do his thing, and you can do yours.

EagleEye

Mar 9, 2007 at 11:48 AM

Quote:
Original post by Sneftel
Personally, I hate doing AI stuff in C++. This is primarily because I do AI stuff in a generic style with lots of functional programming, and in C++ this generally means either disgusting amounts of runtime overhead from Boost's nooks and crannies, or ten times as much code.

With that said, Dave's a smart guy. He's fully capable of doing stuff in C++. And getting C++ and .NET to talk with each other turns out to be really, really easy, so there's not that much development friction that'll be added by going with a mixed approach. Let Dave do his thing, and you can do yours.

I do want to say that I agree with you here... Dave IS a smart guy, and I never intended to make it out like he wasn't.

He linked me to a bunch of threads on here where the topic has already been discussed... most of them are "C++ vs C#" threads, but it's all the same. :)

The thing that kinda bugs me about this particular case is that we're specifically talking about AI here, and the assumption that it's better to use pre-written code in C++ (and then modify it to the needs of the app), than to use the language the rest of the game is being written in. Especially if, as you say, C++ AI code is cumbersome and has tons more code, etc... It seems to me the benefit of using the pre-written code snippets would be offset by the necessary customization of that code, and the integration in to the main project.

Honestly, if C++ were to be used on a game server's AI for the entities, it might as well be used for the rest of the server as well, just so all of the data is preserved and not having to be passed between languages all the time.

It's that transition between the two languages that really concerns me...

Sneftel

Mar 9, 2007 at 12:21 PM

Quote:
Original post by EagleEye
It's that transition between the two languages that really concerns me...

It certainly seems so. If I were you, I'd spend a few hours learning about this. Figure out what's involved in using C++ with .NET, so that you can determine exactly what it'll add to your particular project.

Bob Janova

Mar 9, 2007 at 1:21 PM

For AI, which is mostly algorithms and maths, any compiled language is fine. The code will probably look pretty similar in C++ or C# ...

But yeah, asking this in .Net isn't going to get a lot of anti-.Net sentiment.

IADaveMark

Mar 9, 2007 at 1:53 PM

Please note that HIS code is written in VB.net - so we aren't just talking C++ connecting to C#. That's where the problem lies. If he creates all the character info and the world code in VB.net, it isn't so easy to write the actual "monster" AI in C++. For example, there would be a lot of shared base classes between the character and the world entities. Which language do you write them in? See the problem?

I would like for "BaseEntity" to be in C++ so I can inherit stuff all the way down the tree from that. However, that means that his character stuff (in VB) would then have to either have its own base class or we have to band-aid things together. Alternately, if "BaseEntity" is in VB, and maybe even "MovingEntity" (inherited from BaseEntity), then where does the C++ begin? *shrug*

It's his project, so he makes the call. But at some point, I may not want to bother.

EagleEye

Mar 9, 2007 at 2:18 PM

What he says is right... do we really want to have duplicated class structures across languages, and pass the data between the two? That's a nightmare for sure...

The way I see it, that's not really an option, so the only options I really see are:

- Rewrite the server to be completely C++ (which I wouldn't really object to for speed reasons... just that it would be a major PITA to do so, considering I already have the network and database code done).

- Do the AI in .NET... and have me actually do the programming, with Fox doing the design of the actual objects, and conceptual AI documents that I can work off of.

That second one is the more attractive option for me... I'm sure I can write the AI myself. I think I just need help with conceptual stuff anyway.

To a certain extent, I have to admit that I'm sort of a ".net fanboy" myself... I'm writing an entire game in VB.NET... both client and server... (granted, using a C++ engine core in the DirectX SDK, with an API to access it via .NET in TrueVision3D). I certainly have my technical reasons for doing so that go beyond mere "fanboy"-ism. I have to admit, though, that I want to prove to the world that .NET is a capable game development platform. The whole "Everyone else does it this way so this is how it must be done" thought process is one that I instinctively reject... but that's a topic for another day. :)

Anywho... thanks for the feedback guys...

IADaveMark

Mar 9, 2007 at 2:27 PM

Quote:
Original post by EagleEye
The way I see it, that's not really an option, so the only options I really see are:

- Rewrite the server to be completely C++ (which I wouldn't really object to for speed reasons... just that it would be a major PITA to do so, considering I already have the network and database code done).

- Do the AI in .NET... and have me actually do the programming, with Fox doing the design of the actual objects, and conceptual AI documents that I can work off of.

#3, the network code and actual serialized database (which you don't use live-time anyway) can stay as is. Only the game object hierarchy needs to be homogenous. It doesn't matter how you transmit or save the data really. But now we wander off topic... I only post it here to see if anyone has ideas on how this sort of thing could be accomplished.

intransigent-seal

Mar 9, 2007 at 2:38 PM

You want to use C++ so that you can use existing libraries?

Well then, use managed C++ (yuck), C# or VB.NET for the code that you write, and then interop with the existing (native C++) libraries. This will presumably be easier than writing all your code in C++ and having interop between that and the rest of the game code, because the interfaces to the external libraries/code-bases that you're using will have nothing specific to your game in them, and will be much more easily to isolate.

If you want to work with existing code bases but modify them to fit into your project, then that might just be one of the occasions where managed C++ could actually be useful - if you're going to be modifying the code to fit in anyway, then it hopefully wouldn't be too hard to apply whatever modifications are needed to make it run in a managed environment (but I have no experience with this - it's just a hunch).

John B

IADaveMark

Mar 9, 2007 at 3:15 PM

It's not just a matter of using libraries with hooks in them. This is code that I want to use in and around my own things... an A* algorithm or a state machine system that I will actually import and modify for my own use. This is stuff that will be actually used INSIDE my own classes as well as being connected to them.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.