C# in the future

#41 Dan Moorehead,

So are you using RealmForge for developement? I was very interested in this engine, but the demo and the docs lead me to believe it "wasn't there yet".

#42 Absolutely. Especially considering that I am the lead developer for it :)

We have been going through a lot of changes including hosting, forums, docs and the v0.6 release was delayed because I decided on a complete rewrite of the underlying data module loading component. We do have a demo game, but it will be released in either v0.6 or v0.6.1 when we upgrade it to use the latest scripting, event, and behavior model. The physics support is incredible and there is an example of a cloth-based physics in it as well. We are working on conjunction with the Might and Magic Tribute development team, as that game will serve as the free and open-source RPG demo game that comes with it. All of its content as well as the contributions from many other artists are being combined into the RealmForge Media Library to help developers get started and especially the programmers who don't have an artist on board. The game is planned for use be several different companies for commercial games as well as different scientific and educational associations for "Serious games".

It is far from dead and has made incredible progress since its conception not too long ago. The project is built upon a backbone of free libraries and frameworks and the rendering engine powering it is Axiom, the C# port of the popular OGRE engine which has been used in the IFG finalist Supremacy. Its far from a dead project and many of the team members are putting 10-20 hours a week into development of this free product, however it still takes time to be completed. I would really encourage developers to use it once it is finished however, there really isn't any risk involved considering that it *is* free. Additionally, you can use whatever language you would like for development due to the 42 programming languages now supported by the .NET Framework, so it doesn't tie you to VB for instance like Blitz or a custom light-weight language like TorqueScript or UnrealScript. JavaScript is my preferred scripting language for it and the rest of it is data-driven using XML files. If you are interested in more information checkout the newly setup wiki at http://wiki.realmforge.com However it will likely be a couple months before it is production level (which is relativly short by open-source standards).

#43 Here is the link to the platform that I mentioned earlier that allows you to script in .net specific languages.
This is for anyone who is interested

www.artificialstudios.com/product_re.php

#44 No offense against anyone in particular, but this whole "get a real language" thing is ridiculous.

I used to help program an old mainframe that had rows of 9 toggle switches. Up = 1, down = 0 (9th switch was a sign bit). We had to manually set the bits for each register and then enter it. Move to the next register and put in another byte. Now THAT'S chest-thumping programming...none of this easy stuff we have today. It was also painful and would be very stupid to continue doing it that way.

Then we got punchcards and papertape (with real keyboards). wow! That was nice.

Soon we could start program using languages that almost resembled words.

Then I got to use C/C++

Then, C#, VB, PHP, etc depending upon what I was doing.

I'm glad I'm an engineer and only helped with the programming at times. Seeing a developer walk across the computer room and spill his entire box of punchcards was horrifying (and rather humorous).

The point is, systems evolve, languages evolve, programming techniques evolve, the whole industry evolves. If we don't learn to evolve with it, then our employers (or the market) will find somebody who can.

Just because a certain language seems better suited for a task today, does not mean that it will always be that way. Getting tunnel vision in the computer world is career suicide.

Pick the right tool for the job. Today, that may be C++. A few years ago, it was toggle switches. Thank God for change! Tomorrow, it may be something else.

Just be prepared to change your tools when the time is right, or be prepared to be left behind.

I have several friends who have only stuck with Cobol and never bothered to hone their skills on anything else. They're now stuck in a niche market will little flexibility. If it wasn't for some of the government's archaic systems, they'd be hurting for a job.

#45 Any time spent on thinking you are cutting edge and awesome because you are going to use the latest, greatest, flavor-of-the month language to write your game engine is wasted. Hell when Java came out people were trying to argue that using JIT it was fast enough to do a game in. It's bullshit, guys. C# is not a viable language for game development, and .NET is not a viable platform for game development. If everything I do is 2% slower in C# (which I think is grossly understated), I'm going to use C++, and so is every other serious game developer on the planet.

Well .NET and Java are rapidly becoming the de facto platforms for software development as any Forrester study can show you, so why not game development? If the market is going that way do you seriously think that the game developers (who are struggling as it is with the amount of time/energy/money/risk that they put in such as fickle market) are going to just ignore every chance they get to take advantage of a something which can afford them greater productivity, or simplicity, or less time in development, easier maintenance, or more flexibility and reusability later on down the road... I have seen *actual* interest by software development companies in developing games with the .NET Platform, not only are many programmers these days trained for developing for this platform, but they have seen tremendous benefits through its use in software development, and games is just another area software development. Who says that development companies for AAA titles are not looking into .NET? It has been suggested to me by someone in the inner circles of game development that it would be a grave mistake to assume that .NET is not being looked into and that tools are not already being developed for it.

My trials have shown C# to be faster on average then C++, this is not due "JIT being faster" as some have argued, but simply due to the fact that well-written or optimized code makes a great difference then whether or not it is compiled early or later on the CPU that it is going to run on. Garbage collection for instance does not impact speed in the slightest, with .NET 2.0 you can even control it to a much greater extent. If you check out the DirectX demos you will see that the managed demos run faster due to the presence of garbage collection as standard allocation takes much less time. Also the run-time support from everything to attributes, reflection, dynamic assembly inspection, etc provides is geared towards the development of highly reusable and maintainable frameworks... something that the game industry has been concentrating on.

In addition it works really well with late-binding of resources.... which again is what the game industry concentrates on. Now are you going to argue that "the 2% loss of speed from late binding just cant be rationalized"?? I dont think so, it certainly has, many other cuts in raw frames-per-second have been made for productivity, maintainability, easy extension of the game, or just the ability to release a game quickly and start on the next. I think that you would be gravely mistaken to decide upon working towards *possibly* gaining a +2% in FPS (which you will certainly never see an increase in sales for) as opposed to being able to start on the next game or provide a reusable framework... or anything else that can be done with the time saved for using a RAD component-based framework and dynamic platform like .NET. I am not saying that C# is the one-hit-wonder for game development, but frankly, if software development is moving that way, and there are strong arguments for its use as well as many benefits that i have seen first-hand, then i am going to make what is smart decision in my case and work with it, however if you are not open-minded enough they can you stick with C++ regardless of what benefits are shown and identify with the aforementioned COBOL programmers. I say, stick with what tools seems best for the job and can ultimately give you a chance in the industry and the best shot at turning a profit.

#46 ***NOTE: The first paragraph was a quote of Pat Wilson***, not my remarks

#47 The most ridiculous part of the argument from Pat et al. is that Torque uses a scripting language for the game logic! Surely that's a 2% or more speed hit? Why not write the game logic in assembly language? If you consider for a moment why a scripting language is being used in Torque for game logic, you understand the benefits of something like C#--productivity!

I'm not saying C# is the best for anything or is for everyone, but it's kind of shocking that a professional (and excellent) programmer like Pat would have such a closed mind to the point of arrogantly scoffing and not even researching all the tools available.

One look at Axiom is all you need. C# is a viable game development tool, even for low-level systems.

#48 Absolute, Axiom is the rendering engine that is being used under the hood by the RealmForge GDK, it is a really fine engine and serves as a great comparison for C++ vs C#. Not only are the speeds roughly equivalent (varying slightly in which is faster depending on the demo inspected), but Axiom has been written from the ground up to use the features of the .NET Framework and CLI and is far more concise and intuitive and easy to use. For instance, the demo browser that used to be in the code-base makes use of reflection for figuring out the demo type and instantiates and executes it instead of having several exe's. Things like material scripts make use of enums that have attributes applied to them to tie the string name used in the material definitions with the enum value.

The TorqueScript argument brings out a good point. One of the great features of .NET is that you can dynamically compile scripts (in any one of the now over 40 .NET languages that exist. Of course quite a few of those are very specialized languages, however pretty much all of the popular ones are supported. For instance, if would like to script your game in any language, all you have to do is expose a scripting API any of these *full-fledged* programming languages (not some esoteric custom one), can be used to script your game *with the same speed as if it where built into the engine*. The script can be compiled to MSIL and JIT'd the second you load it and then run as native code. I think that the ability to have scripts run as fast as code would actually push speeds in favor of engines implemented with .NET since scripting is a good portion of the dynamic data-driven games these days. Additionally, the ability to allow a developer to choose what language he and his team members are most proficient with (whether it is C++, VB, Perl, JavaScript, Java, Python, Delphi, RPG, Eiffel, Lua, Lisp, SmallTalk, Pascal or even COBOL or Fortran).

If you provide the scripting API and the Common Language Runtime, its really just a matter of syntax from there, as it should be. I would suggest using Fortran, however the ability to use your development language of choice such as C#, VB, C++, or Java or a favored scripting language such as JavaScript 2.0 (Jscript.NET), Lua, Python, or Perl. The choice of writing a game using .NET is quite different then a programmer who decides to write a game in VB as it is a matter of choosing an entirely different software-development paradigm of component-oriented programming, and a large object-oriented framework, and runtime platform with garbage collection. It is even different the choice to use Java, because you are not restricted to native code, it is actually very easy to interface with native code and you are opening up the game to development and scripting in countless different languages.

#49 K this all sounds fine and dandy but so many of us remember the bs hype around compile once run slow everywhere (known as java).

it comes down to really depending on what your trying to do, If you trying to write a server (sorry I still dont see windows as a viable, scalable, maintenance free server platform), then C# is out of the question unless it can run on a mac, under linux(pc), or on a sun, then its not going to happen for some of us.

plus c# will be around as long as microsoft decides to keep hyping it (of course until the next thing comes along they want to hype) which they are notorious for doing to us.

c# looks like a fantastic prototyping language (especially combined with the cool .net stuff).

but as a scalable, supports thousands of players, server solution, nadda, ill stick with c++ thanks.

another problem you likely to run into is memory managment especially the "automated, do it for you kind", this has always been problematic. sure c# does it for you, but what if I need a different memory model because I do lots of large allocations or lots of small allocations or lots of both? these automated memory manages are never optimized for your specific application, they are too generic.

so maybe they can solve that one, but as a server programmer I certainly dont want to be glued to having to run a windows server.

#50

Quote:
The most ridiculous part of the argument from Pat et al. is that Torque uses a scripting language for the game logic!

Yes, and game logic isn't run every frame is it. Stuff you'll find in script is: "Hey player id N just collided with flag id F. What happens," and the script says, "Mount the flag to mountpoint 2," or, "Add a flag to his inventory," or, "His head asplode!"

#51 This thread seems to have grasped on C# being 2% slower than C++, which was a guess way back up at the top by someone.

Here is a real world example and some a bench test:
Real World:
--------------
A while back they ported Quake II from C to C++ "Managed" code and had 15% speed drop. see here
Now port from managed C++ to C# and you would see a bigger drop.

Benchmark:
--------------
See Performance comparison C++, C# and Java
(note: page does an odd load/reload)

Of course as it shows, depending on what you are doing the speed of slightly C# can be faster than C++ (based off of the test code) just as Java is slightly faster than C# in some test cases.

But of interest and what I noted above, C# is far slower for nested loops. It also appears to be far slower in matrix math. Both of which would be significant in a high end AAA title engine.

#52 The best argument for C# as a development tool is to look at Axiom. Here's a benchmark comparison of OGRE (C++) and Axiom (C#). Can you honestly say that Axiom isn't capable of being used in a commercial game? A 98 fps average (vs OGRE's 97 fps) seems respectable to me if the only way you measure a language's worth is by raw speed.

Porting Quake II using managed C++ is far different from designing from the ground up for C#. That's apples and oranges, and it should be obvious if you've checked out Axiom's performance. I think it's safe to say that there are plenty of loops and matrix math in those tests. It's not 15% slower--in some cases it's faster, in all cases it's comparable.

C# is simply not as awful as you guys are painting it to be.

#53

Quote:
Can you honestly say that Axiom isn't capable of being used in a commercial game?

I never said that, just people were stating 2% difference in speed which was a guess by someone above and wasn't the benchmarking data I had, nor what my tech books on C# were telling me. Thanks for the comparison page. I missed that when looking at Axiom.

As far as a commercial game, I don't think anyone argues that speed maters for all commercial games. My 3 year olds commercial games do not need anything nearly as fast as anything listed above.

This thread probably has exhausted all "talking points" so the best way to put it to rest is to show a Commercial Quality High End game using the Axiom Engine or Realmforge. Not a tech demo. Not a game being worked on. I personally am a little bit cynical of tech demos or screen shots of games in progress. After all, its the shipped product that makes an engine or not.

Does anyone have a pointer to one?

Yes its true... I just want to check out a cool game. :-)

#54 Well the RealmForge GDK dev-team is partnering with the Might and Magic Tribute project to develop a fan-based creation to be the next in the series. This will serve as a example as it progresses, however i cant show you too much at the moment. You can check out comercial game developed with C# and Managed DirectX (http://www.experiencegaming.com/content.php?contentID=524&pageNumber=1) (http://www.koiosworks.com/), (http://www.thezbuffer.com/articles/90.aspx)

The reviews (http://www.strategyinformer.com/reviews/tinsoldiersalexanderthegreat.shtml)
show graphics as an 8 and AI as a 9... hardly complaints about speed in those demanding areas.

Quote:
Yes, and game logic isn't run every frame is it. Stuff you'll find in script is: "Hey player id N just collided with flag id F. What happens," and the script says, "Mount the flag to mountpoint 2," or, "Add a flag to his inventory," or, "His head asplode!"

So because some games dont use game logic as much as others that means that using a really slow scripting solution isnt a bottle neck. God forbid you try and script characters or AI logic. RealmForge takes the approach of allowing all the objects in the game to be scriptable. You can even script different components ranging from the AppManager to the Integrated development tools or Rendering Engine or Scene Manager. You can extend it to consume your own data files and modules with importer scripts. All of this can be done as fast as if it was not scripted and you can even hook scripts up to pre-existing .NET events such as System.Windows.Form.Load Additionally you can use whatever language you are familiar with to do so and dynamically load and compile scripts. I am also working on a visual editor for constraint-systems so that for instance you can script dialog just be design a easily complex set of constrains using pre-defined conditionals with parameters. This is certainly much easier to edit and maintain and much more efficient then trying to script every dialog topic using a custom language.

There is also a community that is contributing to the RealmForge Media Library for free usage of its media, scripts, and their games. This is just taking off, but there is a lot of interest in it and everyone will have access to it instead of just those that shell out more money for the different starter kits.

#55 @TheMartion

With regards to the "Java revelation". Java is not so slow as you would consider it, espeically now with Hotspot compilation. It has been used in high performance 3D games before including Runescape and is far from slow. I would not suggest its usage in comparison to .NET however.

Also, Micrsoft is not going to just drop out the push for .NET to be used, it will only become increasingly more used as they continue to push it and as others discover how effective it is for low-cost and rapid development of portable applications.

It has been used in many applications including larger ones, scalability issues (like with anything) depend on your implementation. There are ways to actually make good design decisions for higher performance of scalability and there are ways to prevent cases in which you repeatidly create and destroy objects... just research different design patterns such as Flyweight.

With regards to memory, again if the developer using .NET has a good understanding of its memory management he can optimize for it. Out of the box, it provides a better model then C++ such as can be seen in the DirectX demos in which the managed ones run faster due to the lack of a presence of garbage collection in them causing the new operator in C++ to act fairly slow. In .NET 2.0 you will see the ability to also hint to the garbage collector what it should do so you can optimize it which i doubt you will find with something like TorqueScript. Also float arithmetic should improve as well.

#56 Like I've said before:

People learn to program in languages that will probably get them jobs.
C# is a vb style C++ type language that allows you to build both visually and very quickly.

Business people want results fast. With .Net there already getting them. So it's a good guess to say that it will slowly take over.

When the day is done, as long as C# can do the job without that much work around of problems, I can't see how it will not take over somewhere down the road.

#57 Really this whole debate is pointless. What matters is that you can get the game you want to make completed while hitting your minimum specs and target performance on your target platform(s) - preferably on time and under budget. It doesn't matter if you use C# or type straight to binary in a hex editor to get there. Pat's arguments, IMO, only apply to cutting edge development houses. Not everyone needs to drop down and do simd instructions for every game they make, and of course IDs and Epics of the world are going to want every ounce of performance for their cutting edge engines. But many an indie game is being sold online right now that was created with Delphi, Java, VB, BlitzBasic or some other 'too slow for games' language (Puzzle Pirates and Tribal Trouble are two of my favorite examples). For indies in particular there are many factors involved in language choice other than performance potential (which is what people really mean when they talk about how fast a language is).

#58 The only type of C# games you'll see will be similar to those made in Java. For fast 3d type game development the speed won't be there. Ever.

#59 I think this cuts to the core of the discussion. The quesion I have is: why can't C# be used for fast 3d style games, not simply as a scripting language, but for the core engine; if it can't, would simple library or compiler changes (i.e. SIMD statements) fix it?

#60 I remember reading somewhere about a future processor that ran .net byte code directly. That would eliminate the slowest part of .net. Not sure if this was just a pipe dream or a serious post though as I can't remember where I read it.