C# in the future

#21 Just to concur with FruitBatInShades, C# is not a scripted language. At runtime it compiles to native machine code (from intermediate language code). The real benefit of the language is the productivity increase. If you want to save money while building games, it's a contender.

The best evidence for its power as a game development platform is the Axiom 3d engine. In *some* cases it has been benchmarked to run faster than the C++ OGRE engine from which it's inspired, and in all cases it's comparable unless you think that 5% CPU overhead will bring your game to its knees. I think C# is a wonderful technology even though it comes from the company we all love to hate, and I plan to use it for games in the future.

#22 I agree with FruitBat. Right now I'm building a small engine to do grass rendering research with, all in C# using managed direct x. I've used both C++ and C# before and I simply like using C# better. I will agree that it probably does run a little slower (although the reports of its slowness have been greatly exagerated) then C++, but it takes me a fraction of the time to develope with. It seems like everything that used to be a bitch to do in C++ is simply trivial in C#. Without having to deal with memory directly, debuging is a breez, and everything just seems intuitive (I never actualy had to *learn* C#, when I started my engine I just opened up a new project and pretended I was writing java code, VS told me when I did something wrong, and what to do to fix it). I sort of agree that games should probably stick to C++ though, since performance is such a make or break issue with them. C# is plenty fast, but its similar to driving a sports car with an automatic transmission, it's less work to drive, but you wont have absolute controll over your performance.

I agree that this argument about languages is a little silly. Arguing whether java is better then c should be left to the freshman dorm at state universities. When it comes right down to it, you pick the language that best suites your needs. I think that C++ is probably the best equiped for cutting edge games at the moment due to the programmers ability to optimize everything. However, many games come out each year that by no means have the most advanced physics models or the best AI, and those can easily be made in C# (note I didnt say graphics as thats more of a GPU thing and not really based on the language). Even if C# runs slightly slower, a lot of companies could probably shave a month off their year of development if they moved to C#. Seems like that would make it very viable in the game industry... in any regards, keep arguing.

#23 I think that any reasonable person realizes that, long-term, the work of actual game development simply cannot continue in unmanaged languages.

The work of developing architectural components to use in these languages, yes! Go ahead. Obviously, the game engines themselves are likely to be written in C++ (and at lower levels in some cases) for quite some time.

However, as a C# coder myself, I'm going to use an analogy from my personal experience.

Many of you are probably familiar with the GraphViz library. (if not, google for it). It's a graph visualization library with some of the most sophisticated algorithms in the planet for understandably and compactly and elegantly laying out graphs. Of course, it's written in C++, because some of the algorithms would murder a managed language like Java, C#, or Scheme (although, frankly, some search algorithms are actually faster in Lisp, but even then it uses extensions to deal with unmanaged memory).

Enter NGraphViz, a beautiful wrapper around GraphViz.

Some game studios that develop console games use freaking LISP to do their AI and object/world management -- because it's simple and it's very high-level.

And more intimately, look at the work that our own Josh Ritter, with TGEPython.
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=3345

Torque is a special case since it already provides a LOT of the benefits normally associated with cross-language bindings via TorqueScript. But I think that there's certainly a role to be played for a greater architectural separation, and the benefits that a compiled, non-scripting, strongly-typed (although that isn't as necessary) language can bring to the process.

Look at business development; not all of an app is in the target language, but the primary, "business service" logic is written in the most manageable and productive language for the team, and that's where the conceptual core of the application is.

In the future I doubt that we'll be writing the conceptual core of our games in C++.

Shit, just look at the amazing variety of things that hooking Python to Torque makes available. You want to use Torque to design a 3D frontend to your company's business intelligence apps? Your funeral, of course -- but if you're going to do it, it makes sense to do it in a productive language that has a lot of libraries and can tie a lot of things together really well.

Python fits this bill in a big way but many people don't like Python. I think that C# is like a Python for people who like Java; C# has so much RAD added value right off the bat, and it's as strong as Java underneath. It puts an enormous amount of windows, xml, web-service functionality right at the fingertips, and it makes reflection-based coding considerably easier than the same thing in Java (with features like the CodeDOM).

Obviously, for high-level game dynamics and management, many people would say that C#/Java are a TERRIBLE fucking fit, because of how verbose OO languages can be (especially how verbose AI and behavioral/rule-based code can be in those languages; an enormous amount of architectural wrangling has to be done just to responsibly provide the functionality that a tiny amount of Lisp code might suffice for). But, then again, the strong-typing of those languages and the productivity benefits AS COMPARED TO C++ are powerful motivators for change.

#24 What I don't really get is why this discussion even exists, as if somehow C++ would cease to be used if C# became popular.

Is everyone completely forgetting there's a Managed C++ too? Has no one read what's being done with C++/CLI in Whidbey? If you haven't, take a look:
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx

This line is particularly interesting: "Furthermore, the Visual C++ 2005 compiler will be able to optimize MSIL beyond what is possible with other managed languages."

Not to mention, one of the main benefits of the .NET platform is language freedom. So down the road, you might have your engine programmers hacking away merrily at C++, C# programmers hacking away at tools, and AI programmers playing games in between hacking away with DotLisp... and at the end of the day, the whole lot being compiled into a working project.


On a personal note, I really don't want C# to get as popular as some people are predicting. There are many languages far more worthy of that position, such as Python/Ruby/OCaml and the like.

If any language is going to replace C++ in the name of "higher-level code", then it's got to offer something more than properties and delegates (even anonymous ones).

#25 On second thought, this isn't worth my time.

When someone shows me the press release where Renderware, CryTek, GameBryo, Aurora, Unreal or the next iD engine is using C# then maybe I'll put any kind of stock in this belief that the FOTM language will be the next C++. I'm still waiting for all the "killer" game engines that were comming out on Java to prove us all wrong, so hey, whatever.

#26 @Pablo Alonso
C++ is used over assembly because the the efficiency of the code with modern compilers is about the same as that as pure assembly. If it weren't the case it would be used in game programming as much as it is.

@FruitBatInShades
You are right C# is not a scripted language. It is managed though and has limitations that help protect the coders from making boo boos, which C++ lets you do. This prevents in from being as "powerful" as C++.

I believe Pat refers to C++ as a "real" language because it doesn't baby the programmer like some other languages do (java and C# for example).

@Luc Jordan

NGraphViz is as you said, a "wrapper". The actual meat of is still done with the GraphViz Lib because it is more effecient.

Your example of using TGEPython is a poor one in regards to using C#. If TGEPython had been a rewrite the TGE C++ code in Python then it would have applied. As it is Python is replacing Torque Script in that example.

Lisp was designed for working AI, even intergration within torque would make since if someone were writing a scheduler/planner type AI. I am not sure what your purpose was for the inclusion of this example was with regards to C#'s effectiveness as Lisp/schemes effectiveness was never questioned with regards to AI programming. Show me an engine programmed in lisp and then this would make sense.

Business Apps do not need to be nearly as efficient/tight as engine code. So using managed languages makes sense. Just like game logic does not need to be as efficient so torque script or any other language is fine.

#27 Also . . . no offense to Pat . . . but Python, Scheme and Ruby are "real" languages. Java and C#, ditto.

C++ is hard to work in, like a suit of armor. Of course, the suit of armor is desirable when you're grappling with a certain domain of problems -- dragons like complex physical simulations, enormous data crunching, cryptography, maximum-flow for AT&T.

But
a) When you *aren't* slaying dragons, you can't get much done in a suit of armor, and
b) If you find yourself slaying dragons on a REGULAR basis, in most cases, you're doing something wrong. A game developer may have to slay one or two technical dragons during the development of a game, but in general, unless he plans to advance the state-of-the-art in several clever technical ways (which is fine if you're John Carmack . . . and have his resources . . .) then just managing the software development process and putting a plan into action should occupy much more of his time than slaying dragons. The bulk of the work done is not dragon-slaying unless, say, you're coding a game ENGINE. :D

And a major obstacle to making game development a more efficient process is that right now, to stay current visually and feature-wise, much of the work of making the game must be done in a suit of armor. Some engines are minimizing this via script, of course, but so much more needs to be done . . .

I mean, shit. How many C++ devs are familiar with Hibernate for data access? Frankly, if you are thinking about storing game data in an embeddable ODBC-compliant relational database on the client (not only not farfetched, but a great idea in many cases), not having access to Hibernate is a huge shot to the groin. Managing the data access code on the client is a big proposition if your core featureset doesn't make it an absolute necessity.

Of course, with Hibernate, data access is essentially free, effortless. So you might as well do it; who knows, having access to the kind of pure organization that relational db's provide might your life a lot easier.

But if it's not effortless, the likelihood shrinks.

I dunno -- it just seems funny for C++ to be called "a real language" at this late date. Java and MS Java (C#) were created because there was simply zero profit margin in using straight unmanaged languages for things that don't need massive speed. And we aren't talking about bullcrap apps; we're talking about the apps and systems that, by and large, run the world (primarily Java). And, hey, even from a game dev POV, simpler (at least from a base language element measure) languages like Lisp (it's all just s-expressions) do some tasks, like AI/behavioral code, with much less effort.

#28

Quote:@Luc Jordan

NGraphViz is as you said, a "wrapper". The actual meat of is still done with the GraphViz Lib because it is more effecient.

Exactly. You've grasped the point precisely.

Quote:
Your example of using TGEPython is a poor one in regards to using C#. If TGEPython had been a rewrite the TGE C++ code in Python then it would have applied. As it is Python is replacing Torque Script in that example.

No, you're completely wrong there. TGEPython provides the same kind of Python integration that makes development in Python (via, for instance, wxPython) such a joy: it controls everything, tells everything how to work, and hands off jobs to the modules that are best suited to handling them. But it's in charge. TorqueScript can't provide seamless integration with a webapp, RDB, and distributed servers the way that TGEPython makes possible.

Quote:
Lisp was designed for working AI,

Completely wrong again. Although you're correct in the sense that it's been USED for AI, but it still makes as much sense, and is as materially accurate, as saying that C++ is a language that was designed for creating office software.

Lisp was designed to be an alternative to the approach taken by Ada(C++); functional vs. procedural. It's easily one of the most powerful, although counter-intuitive (at least it's still not INTUITIVE for me, I'm getting there) languages out there, but I think that Python and Ruby have it beat for real-world applicability.

Quote:
even intergration within torque would make since if someone were writing a scheduler/planner type AI. I am not sure what your purpose was for the inclusion of this example was with regards to C#'s effectiveness as Lisp/schemes effectiveness was never questioned with regards to AI programming. Show me an engine programmed in lisp and then this would make sense.

Again, you obviously miss the point completely.

The entire point of my post -- and I think that the examples I included make it pretty obvious :P -- is that the ENGINE (or, rather, engines), the number-crunching beasts of algorithmic beauty that have to push the limits of PERFORMANCE -- these things are all going to be done in C++. An underlying engine should be coded in whatever makes the most sense, and for performant game ENGINES this means C++.

Nowhere, however, does this mean that the GAME has to be in C++. That's the whole point. We get an interface to use the underlying functionality of the engine from another language. For instance, Python. A torque script exists only in the engine, and serves an important purpose, but a Torque script can't launch the game and make direct unfiltered API calls into it. TGEPython allows people to write Python applications that can use everything the Torque engine has to offer; this likely includes pertinent gameplay code, or in the case of the only existing heavy-duty application of TGEPython, everything of any importance, including support for a cascading system of subserver authority and transition of state between servers.

Quote:
Business Apps do not need to be nearly as efficient/tight as engine code. So using managed languages makes sense. Just like game logic does not need to be as efficient so torque script or any other language is fine.

Again, if you had paid any kind of attention -- any attention at all -- to my post, you wouldn't have written that post.

/me exits tribalwar mode.

#29 Most of IL-2 Sturmovik was written in Java. I remember when people had this attitude about C++. With the way hardware keeps improving, there is a point when the savings in development time outweigh the performance gains. Otherwise, we'd all still be writing games in assembly. Now I'm not saying C# and the like are ready now, but who knows in the future...

#30 @Luc:

Quote:


Quote:

--------------------------------------------------------------------------------

Lisp was designed for working AI,
--------------------------------------------------------------------------------



Completely wrong again. Although you're correct in the sense that it's been USED for AI, but it still makes as much sense, and is as materially accurate, as saying that C++ is a language that was designed for creating office software.

Sorry man, but Lisp was designed for working with AI, and in fact was designed by the very engineer that coined the term "Artifical Intelligence", John McCarthy.

Forum Decorum suggestion: If you are going to go ballistic on someone, it helps to be solid on your claims.

#31 Well, C# *is* Java. .NET is Microsoft's answer to Java.

I think that the underlying concepts in .NET are actually better than their java counterparts; compiling down to an intermediate language is a real advance that allows for great reflection tools much more directly than doing the same in Java, and I think that overall .NET shows more promise, but Java has been around for a while longer, and is less strongly tied to a particular vendor; thus, until Mono gets really solid, until most open-source Java projects have counterparts in .NET, and until more application and MVC frameworks are available for .NET, Java will probably continue to be where most real work gets accomplished.

However, .NET has already expanded on the MS trademark of allowing people to do things that LOOK like work, to managers, except that now it's possible to really do the work -- to really solve business problems -- in ways that old Visual Basic apps so rarely did. (Sure, they may have plugged a hole at the time, and addressed a specific problem, but going forward . . .). So coding in C# has a great built-in competitive advantage: you can do the kind of truly MINDLESS RAD that people expect from Visual Basic devs, and have great visual tools, but you can also build powerful Java-style oo architectures.

Personally, Python makes me hot under the collar.

#32

Quote:I believe Pat refers to C++ as a "real" language because it doesn't baby the programmer like some other languages do (java and C# for example).

So programming is really about how hairy your chest is and real men only use C++. This attitude confuses me in light of the costs of production and getting the job done to spec regardless of the means.

Microsoft wouldn't be pushing .NET on such a massive scale if it was flavor of the month. It's going to become more and more prevalent and improve like their other technologies that went through iterations to become defacto (WinXP, DirectX, etc). Not that it will replace C++, but why should it be either/or? Is compromise too sissy?

#33

Quote:So programming is really about how hairy your chest is and real men only use C++. This attitude confuses me in light of the costs of production and getting the job done to spec regardless of the means.

Just because we don't like being babied doesn't mean we're running around thumping our chests.

I think the problem most seem to have with C#/Java, is they provide benefits, but at the same time they take a lot away.

Most of the time we'd love to have out objects cleaned up automatically (note the growing use of scripting languages in games), but it's those other times that really irks you. Anyone who's kicked up performance by a double digit percentage after using a memory pool in the right place will know what I mean.

In any case, .NET and C++ aren't incompatible. As I mentioned previously, C++/CLI is looking to be great. All the power of C++, all the .NET time savings, all when you choose to use it.

#34 I admit some bias against C++ because I've been programming with it for 8 years, and it's getting on my nerves at this point. :) It's overly complex, hendered by legacy considerations, and error-prone things like header files should not be necessary.

I personally find the conveniences of C# a welcome change to the tedium of C++, and I'll trade a small performance hit to get the job done quicker and with fewer mistakes in a cozy language that doesn't fight against me. Optimizing for 5-10% (or 2% as I think someone mentioned) performance gains is a point of diminishing returns. I prefer to let the tools do the dirty work while I focus on the algorithmic and architectural issues.

The success of a game is far less about technology and more about game design anyway, so spending so much time/money on technology doesn't make financial sense to me to begin with.

To each his own, of course.

#35 First of all, it isn't a matter of C# vs C++. The .NET Framework allows the use of any language ranging from Python to Delphi to VB and Java. Really being able to pick your language of choice for development and then another (or the same) for scripting without a lost of speed (as it will also be JIT'd and optimized) is really work quite a lot. Also .NET (like Java) brings a lot of productivity to the table, though without many of the restrictions. It automatically inline the calls that are made often during JIT'ing. If you want a finer control over it, then you can use C++ .NET and even a mixed mode assembly for a seamless combinations of use of .NET and highly optimized native code. C# is certainly welcome in development due to gains in productivity, simplicity, maintainability and all that is good. Software development companies are moving towards one of the component-based, managed language platform (either Java or .NET) as can be seen in the Forrester Research studies as well as others. One of the things that .NET has going for it in comparison with Java is that it works seamlessly with native code using p/invoke, C++ .NET, and/or mixed-mode assemblies and you can port code over bit-by-bit from legacy code-bases, as can be seen with Quake II .NET.

When it comes to "that extra 2%", you can easily make that up by refactoring your core design or compensate for it with a flexible design. The latest games are making use of late-binding of their resources, which certainly incurs memory and CPU overheads, yet it is still a smart move. If you can make a more maintainable game or develop it rapidly, then 2% or the like is a welcome penalty. If you shave it off FPS, it certainly won't be noticed and you can make up for it by spending time optimizing your core components, refining gameplay, or adding new features. It really a matter or where you put your development time. Why not just use Assembly to make games?? Heck I am sure you can push the FPS with it. Certainly that remained the argument for quite a while, but as you can see its credibility as died away and that will only become even more apparent with .NET seemingly being *too slow* as Moore's law progresses. If software development industry is moving towards using a modern framework and rapid development platform such as .NET or Java, then you will surely see the game industry follow suit (with a slight delay of course). Rumor has it that the Xbox II has a silicon implementation of MSIL instruction execution. This will be really fast and certainly shows where the game developers will be going... even for console games and especially if Microsoft is backing it. However, just because you make use of the .NET Framework doesn't mean that you tie yourself to MS, you have the Mono and GNU Portable.NET implementations of the CLI... which allows for *truly* cross-platform games without having to maintain separate builds or spend precious development time increasing complexity by making allowances for the different platforms.

There are many reasons to use .NET for game development and with both Moores law's reigning true and the heavy reliance on GPUs for much of what games handle, you will see very little difference in speed (as can be seen with my comparison of the very similar OGRE and Axiom engines at http://axiom3d.org/Default.aspx?tabid=27&g=posts&t=1494). Again, use the best tool for that job... whatever allows you to develop a game with the lowest overhead/cost/time requirement. .NET does have many additional benefits of allowing the creation of a *very concise* engine/game and a dynamic framework.

#36 With regards to the comments about RealmForge:

Of course the editor isn't fully featured yet, considering that the toolset has not yet been completed, let alone in many cases started. The project *is* in alpha, yet is very promising nonetheless. There is a feature-for-feature comparison of RealmForge vs Torque. Checkout the DevMaster.net listings for the two projects (http://www.devmaster.net/engines/engine_details.php?id=68 and http://www.devmaster.net/engines/engine_details.php?id=3). Not all the features in the RF one are completed yet however. RealmForge does have additional benefits of being free, open-source, and providing demo games which will be released as examples in later file releases. You can check out more info at the wiki (http://wiki.realmforge.com), or check out screenshots including those of the integrated *Run-time* toolset which is similar to Visual Studio .NET and can be toggled on and off during gameplay (http://realmforge.com?url=Screenshots)

#37 The point about Moore's law is a good one...can someone point me to the .NET platform for the PS2?

#38 You are not going to find .NET on PS2 or any recent console, it is a relativly new technology and current consoles have some serious memory and hardrive limitations. However, the next generation consoles (Xbox II, PS3) will be more powerful then many computers. However, you can theoretically run .NET on a PS2 or Xbox (as in the architecture is supported) with GNU Portable.NET.

#39

Quote:
There is a feature-for-feature comparison of RealmForge vs Torque

I looked at that. Interesting, but its a "Planned feature list" (RealmForge) vs "Implemented feature list" (Torque). Not quite a fair comparision. Afterall, Torque has plenty of planned features too.

#40 It not just a matter of what is "planned". Most of those features are partially implemented and have developed currently working on them. The majority of the features are full implemented including all of the graphical or 3D rendering engine related capabilities, which is certainly far more then Torque supports in that area.