Hi everyone,

I've been learning for a little while now, but I'm not sure if I'm heading down the right path...  Before I get in too deep, I really need a few questions answered.  Most of you have much more programming experience then I do...  Could someone please shed some light on the limitations of the two languages, and the limits imposed by XNA??

Can C# generally accomplish the same things as C++?  That is, when using C#, do you eventually run into limitations of the language that only using C++ could overcome?  I know that indie games are commonly written with C#, but what about Xbox Live Arcade / WiiWare / PSN releases?  What about full retail games? 

Do Xbox Live Indie Games HAVE to be made with XNA and C#?  If I made a game using C++, I'd be out of luck?

Is it true that games made with XNA can ONLY be played on Windows and Xbox 360?

Any help would be appreciated.  Thanks! .............................................ken

Midnite Zone:

Can C# generally accomplish the same things as C++? That is, when using C#, do you eventually run into limitations of the language that only using C++ could overcome?

Generally speaking, yes. If you're really running close to performance bottlenecks, then C++ is a better language for optimizing, but it is extremely difficult for an indie developer to run into this scenario. The choice of language should be based on the experience of the developer(s) and the technology that you want to use. XNA Game Studio officially supports only C#, though I have heard some talk about getting it to work with other languages.

Midnite Zone:

I know that indie games are commonly written with C#

Not necessarily true, but it depends heavily on what platform you're talking about. If you mean Xbox LIVE Indie Games, then yes, that's true.

Midnite Zone:

but what about Xbox Live Arcade / WiiWare / PSN releases?  What about full retail games?

This is coming from someone outside the game industry, so take it with a grain of salt, but professional games are largely developed in C++. This is mostly because the tools and engines that currently exist are written for C++, so that's what they use. There are always exceptions, of course.

Midnite Zone:

Do Xbox Live Indie Games HAVE to be made with XNA and C#?  If I made a game using C++, I'd be out of luck?

From an official support standpoint, yes, you have to use C# and XNA Game Studio if you want to publish on Xbox LIVE Indie Games. As I said, I have heard of some people getting XNA GS to work with other languages like VB and F#, and I'd imagine you could get it to work with C++, too. It has to be managed code, though; there is no method to get unmanaged code to run on the Xbox without a dev kit.

Midnite Zone:

Is it true that games made with XNA can ONLY be played on Windows and Xbox 360?

Windows, Xbox 360, Zune, and Zune HD are the supported platforms for the latest version of XNA Game Studio. Edit: There is also a project called SilverSprite that lets you run 2D XNA GS games on Silverlight.

Daniel Hanson:

Midnite Zone:

Can C# generally accomplish the same things as C++? That is, when using C#, do you eventually run into limitations of the language that only using C++ could overcome?

Generally speaking, yes. If you're really running close to performance bottlenecks, then C++ is a better language for optimizing, but it is extremely difficult for an indie developer to run into this scenario. The choice of language should be based on the experience of the developer(s) and the technology that you want to use. XNA Game Studio officially supports only C#, though I have heard some talk about getting it to work with other languages.

It is rather simple to use the XNA Framework with any .NET language on Windows (the content pipeline project is the only thing heavily tied into the C# project structure).

Daniel Hanson:

Midnite Zone:

Do Xbox Live Indie Games HAVE to be made with XNA and C#?  If I made a game using C++, I'd be out of luck?

From an official support standpoint, yes, you have to use C# and XNA Game Studio if you want to publish on Xbox LIVE Indie Games. As I said, I have heard of some people getting XNA GS to work with other languages like VB and F#, and I'd imagine you could get it to work with C++, too. It has to be managed code, though; there is no method to get unmanaged code to run on the Xbox without a dev kit.

Even from an unofficial standpoint it is a definite yes: converting a native C++ to C++/CLI or C# is about the same amount of work, with C# being the easier option due to the nature of the XNA GS.

Daniel Hanson:

Midnite Zone:

Is it true that games made with XNA can ONLY be played on Windows and Xbox 360?

Windows, Xbox 360, Zune, and Zune HD are the supported platforms for the latest version of XNA Game Studio. Edit: There is also a project called SilverSprite that lets you run 2D XNA GS games on Silverlight.

And we all care about the Zune!

C++/CLI requires certain runtime support, which is not available on the Xbox. Only "pure" CLR assemblies can be ported to Xbox, and then only if they don't reference any other assemblies that aren't available.

The main reason you want to use C++ instead of C# on the Xbox is that the Xbox CLR performance is very slow. If the Xbox CLR was as fast as the desktop CLR, and could take advantage of VMX/AltiVec, and if the XNA framework gave access to all the low-level details that the XDK does, then C# would be a viable alternative for AAA game development on Xbox. Unfortunately, those are two really big hurdles to overcome.

On the desktop, I think it's totally possible to develop a AAA game today with a combination of C# and available libraries (physx, havok, etc). Of course, those libraries are, in turn, written in C++, but as a game developer, you don't need to necessarily care that much, other than writing a P/Invoke wrapper for the parts of the API you use.

Thorough answers, thanks!  So both languages can largely accomplish the same things... But it sounds like C++ is more powerful in the real world, because of the engines & software available.  Obviously that's an important consideration when making a modern 3D game.  But what about when working exclusively in 2D -- are pre-built engines still important?  Are C# and C++ equal when you're only using technology that is 15+ years old?

Also, it sounds like learning C++ is important if seeking employment in the industry.  Maybe even essential...?

Last question, just to clarify:  You HAVE to use XNA (and C# by implication) to make a game for XBLIG, but then the game can ONLY run on Microsoft platforms.  In order to develop for consoles (someday), any work done with XNA would be useless, and any work done in C# MIGHT be useless (and probably would be if I want to use modern technology).  Is that basically right?

...................................ken

Midnite Zone:

Also, it sounds like learning C++ is important if seeking employment in the industry.  Maybe even essential...?

Midnite Zone:

But it sounds like C++ is more powerful in the real world, because of the engines & software available.  Obviously that's an important consideration when making a modern 3D game.

Maybe. You can make a modern 3D game with C#. It all depends on if you actually reach a point where C# and the CLR aren't performant enough.

Midnite Zone:

In order to develop for consoles (someday), any work done with XNA would be useless, and any work done in C# MIGHT be useless (and probably would be if I want to use modern technology).  Is that basically right?

I wouldn't personally refer to anything that can be used a learning experience as useless.  C# may be a "little brother" of C++, but it gives you a deeper understanding of the code structure, methods, object oriented programming, and allows you to develop a style of coding.  All of this can be done without trying to understand the intricacies of pointers to functions or self garbage collecting.

Nick's post does a pretty good job of summing it up.  However, I'll still say that if you aspire to work for anybody shipping retail titles on any of the three major (360, PS3, Wii) platforms, then you're going to need to know C++ if you want to work on anything other than scripting.  With that being said, C# and XNA is a great place to start.

I don't think Microsoft would be opposed to a disc released game made using XNA GS.

I think you wouldn't actually pass the quality bar. Yes, there is a quality bar for publisher/platform acceptance for disc release, and no, unless your game is turn-based, XNA on Xbox won't create a competetive 3D game.

jwatte:

I don't think Microsoft would be opposed to a disc released game made using XNA GS.

I think you wouldn't actually pass the quality bar. Yes, there is a quality bar for publisher/platform acceptance for disc release, and no, unless your game is turn-based, XNA on Xbox won't create a competetive 3D game.

My point is that if you create a game with retail quality in XNA GS, you could probably get a disc release. Whether or not that's technically possible is a debate that has been had enough and is for a different thread.

jwatte:

I don't think Microsoft would be opposed to a disc released game made using XNA GS.

I think you wouldn't actually pass the quality bar. Yes, there is a quality bar for publisher/platform acceptance for disc release, and no, unless your game is turn-based, XNA on Xbox won't create a competetive 3D game.

I'm not sure about that - so long as you don't require physics or much in the way of collision detection, I think it would be ok; Viva Pinata for example. If XNA had a physics library built in and the depth buffer resolvable to a texture, I think a great many commercial games could have been produced using it.

Nick, your first reply really helped me put all this in perspective.  Plus you had the optimistic answers I was hoping for!  Thanks man.

...And thanks everyone for replying.  I've got a lot of work ahead of me.  Hopefully I'll be building & playtesting games along side all of you in the not-too-distant future!!  Wish me luck ......................................ken

Daniel Hanson:

Midnite Zone:

but what about Xbox Live Arcade / WiiWare / PSN releases?  What about full retail games?

This is coming from someone outside the game industry, so take it with a grain of salt, but professional games are largely developed in C++. This is mostly because the tools and engines that currently exist are written for C++, so that's what they use. There are always exceptions, of course.

Many games also use Python or Lua as a scripting language for various parts of the game, because hardcoding all your levels is generally a bad idea ;)

"Many games also use Python or Lua as a scripting language for various parts of the game, because hardcoding all your levels is generally a bad idea ;)"

Hey, could you elaborate?  I'm trying to learn as much as I can about the various languages.  .........................ken

so long as you don't require physics or much in the way of collision detection

Modern graphics is fairly CPU intensive as well. It does a lot of per-frame calculation and set-up for things like silhouette extraction, spherical harmonics, light interaction computation, etc. Even Viva Pinata probably uses a fair bit of the CPU -- I don't think all the animation is shader based (but I could be wrong). Any kind of fancy particle systems that interact with the environment, and secondary animation will generally be CPU derived, too.

There was a post-mortem of Viva Pinata in Game Developer by one of the Rare guys. Maybe it's still available on Gamasutra? It might mention whether they only needed 10% of the CPU or not.

I honestly believe you'd be pretty hard pressed to ship a competitive $60 360 game on the current XNA Framework and Compact CLR. It's just that bad! I would be ecstatic to be proven wrong, though! Maybe you can come up with a magic mix of graphics and gameplay that just doesn't need much CPU to speak of, and is still competitive.

The problem with comparing C# with C++ is similar to the problem with comparing Java to C++. C++ is faster because it's compiled to native code, however it is platform specific, where as java and C# are not.

Java running on a virtual machine doesn't compile to platform specific code, it compiles to Java Machine Code, which is run on the Java Virtual Machine. The jist of java is that you are running an emulation of a machine that never existed in the first place to run your programs. You only have to program your program once for all platforms that have a Java virtual machine.

C# is not compiled to native code either. C# it compiled to a byte code like language called the Common Intermediate Language, in fact all Common Language Runtime (CRL) programming languages are translated to this language. This language is set up in blocks of code that can each be compiled to the native code and run in real time, however doesn't require the REST of the program to be compiled in order to do so. So the chunks of code are compiled just as you need them to be (an approach called Just In Time compilation). This results in a platform independent programming environment like Java but one that runs native code which is faster (sometimes) than Java's interpretive approach. Certain C# programs may run slower than it would if it were in Java initially because they were formatted in such a way to not take advantage of the JIT compilation.

While C# is platform independent XNA games are not. XNA is a wrapper for DirectX9 which is a Microsoft product, which is why XNA games only run on Microsoft platforms. C# can be used for other platforms so long as a CRL is built for them, just like you can use Java for any platform that has a Java Virtual Machine.

C# can accomplish ANYTHING that C++ can, both are eventually compiled to native machine code. However there is no getting around that C# is less native than C++ and is a higher level language than C++, so because of that C# is slower.

XNA does not restrict you at all, it's all the CLR's fault :) However the XNA framework will provide guidance (heavey handed guidance) about how to make your program to take advantage of the JIT compilation process. To ensure your game runs swiftly. Other than providing a user friendly wrapper to DirectX, there is nothing more to XNA than that. (well there is, but it's just more stuff to make game dev easier)

As far as I can tell, P/invoking a C++ library consists of the CLI including pre compiled C++ code, that is just passed directly to the native code during the JIT compilation process. If this is true, this will break platform independence, but it will allow you to run high speed C++ code for your computationally intensive algorithms provided you've compiled them into a C++ library and wrapped them so you can use them with the rest of your C# code.

Sure, take ~10% (or whatever it works out to be) straight off the top for CLR related issues.  Aside from that, I think some pretty heavy hitting stuff is doable with C# and XNA.  I've said this a few times at this point, and I'll keep saying it -- I think the biggest win by a mile would be to see SIMD support added.  If you think about most of the math intensive things you do in a game, physics, collision detection, and CPU soft skinning are usually up there as the worst offenders.  With physics and CPU soft skinning lending themselves most easily to speed ups via SIMD instructions.

Daniel and other guys have put it pretty clear.

For me, I'm a hardcore .NET fan. (for it is way easier than C++ and so) But I really doubt it will ever get into mainstream of game industry simply because of its simplicity - the easier to develop, the easier to do reverse engineering.
Regarding limitations, I think there's always some workaround for any functional problems, but C# will never have the efficiency C++ has.

Goronto:

For me, I'm a hardcore .NET fan. (for it is way easier than C++ and so) But I really doubt it will ever get into mainstream of game industry simply because of its simplicity - the easier to develop, the easier to do reverse engineering.

I'm pretty sure it's already been proven that it's not a high priority anymore to make reverse engineering difficult, so I don't see this as a barrier.

Companies have gone down the piracy protection route and failed, where as others have completely ignored it and instead focused on trying to supply a product that the typically high piracy regions actually want, and this has worked because the pirates didn't pirate because they didn't want to pay, they pirated because the product was not what they wanted *in their region* so they took the attitude that it was not worth the going price, so they pirated. Now some companies are actually supplying what they want, they are happy to pay the asking price.

Midnite Zone:

"Many games also use Python or Lua as a scripting language for various parts of the game, because hardcoding all your levels is generally a bad idea ;)"

Hey, could you elaborate?  I'm trying to learn as much as I can about the various languages.  .........................ken

Many games will read in level layout or AI behavior or what have you from a file, one that isn't compiled code. For something like a simple static level layout, you could use a simple file format you devise yourself, or some XML structure. But if there are things like events at certain times/positions in your levels which aren't universal to your game, or if you're loading AI behavior from a file, you need something more complex than XML. But you also don't want to have to recompile your level/enemy behavior every time you change it, you just want it to work. The solution is to use some scripting language, and have a parser/interpreter for that language as a part of your game. Python and Lua are fairly common choices, because they're reasonably simple to implement and fairly well-documented. I think there are some games using Ruby, as well. You could, of course create your own scripting language, but then you have the hurdle of designing a language and standard libraries for that language on top of parsing and interpreting it.

Depending on how your parser/interpreter is implemented, it's even possible to alter your gameplay while you're playing the game. That can be useful for balancing difficulty/effectiveness of different parts of your game, since you don't have to quit, change a setting, recompile, and launch the game every time you want to make a small tweak to some setting.

Another advantage to scripted levels/AI is that your designer doesn't need to be familiar with or ever even see the game's actual codebase in order to design a level or new enemy type. This doesn't mater if the designer is familiar with your chosen language and your game's framework, but in larger game projects, division of labor is often key to making things work, and work on time.

In my most recent game, I didn't have scripted levels or anything like that. But I did have an XML file defining missions that can become available to the player, and I did create a developer's console within the game with which I could modify certain parameters while debugging. For example, I used my dev console to find the correct offset from the center of the player's ship for missiles to correctly fire from. It took me around 20 minutes to position the missile exactly as I wanted relative to the ship model, and that was without having to exit, rebuild, and reload the game each time. Once I had the offset set using my dev console, I could set it "for real" in my code, and I only had to launch the game once for my testing, instead of dozens of times.
(What's a "Developer Console"? Think to various PC gmes you've played where you could enter 'cheats' by pressing tilde [~] to have a new window open up where you could enter codes. That's a developer console.)

Midnite Zone:

"Many games also use Python or Lua as a scripting language for various parts of the game, because hardcoding all your levels is generally a bad idea ;)"

Hey, could you elaborate?  I'm trying to learn as much as I can about the various languages.  .........................ken

Let me give you an example from my game currently in the work.

In my game, players can have skills... lets call them "spells" because most people are familiar with those.

Well, the spell "system" is basically a large function that gets passed CASTER, SPELL, PLAYERS where CASTER is the entity that cast the spell, the SPELL is the spell being cast and PLAYERS being the players that can be affected with this spell.

I could hard code this.. like

if (SPELL = Fireball) DamageEntity(Caster.Target, 50dmg);
if (SPELL = Fireblast) DamageAllEntities(Caster.Position, 50yards, 30dmg);


But, what if I have people working with me? Well, I have a friend whose an artist that also wants to help out with the game. He doesn't know very much C# but hes a smart guy and can understand basic commands. Now, if I script-ify my function, then my friend can join in on the spell making fun. In fact, if the scripts are plain text lua or python (or for that matter, anything i concoct up), then he too can participate. Furthermore, making the entire function a script guarantees that my less-able friend doesn't screw up large portions of code, or introduce weird bugs that I'd lose hair trying to discover.

What do I lose with the second approach?
1) Performance - Scripting languages don't compile into machine code, and at any rate, I'd have to add another layer that parses the "code" into instructions
2) Time - I'd have to set up a parser and build in additional things.

In the end, we actually decided not to go with a script based approach, but that's specific to our game.

It took me around 20 minutes to position the missile exactly as I wanted relative to the ship model, and that was without having to exit, rebuild, and reload the game each time.

I'm glad that you found a way to improve your development speed.

When I solved the same problem a while back, though, I simply put a Dummy node at the spot where I wanted the missiles to fire from. That Dummy node got exported as a Bone, which I simply looked up by name, and used as the initial transform of the missile. Total time: 30 seconds :-)
(The other benefit of that approach is that artists can build any model, and still make the missiles come out from exactly where they want; no programmer involvement needed)

jwatte:

It took me around 20 minutes to position the missile exactly as I wanted relative to the ship model, and that was without having to exit, rebuild, and reload the game each time.

I'm glad that you found a way to improve your development speed.

When I solved the same problem a while back, though, I simply put a Dummy node at the spot where I wanted the missiles to fire from. That Dummy node got exported as a Bone, which I simply looked up by name, and used as the initial transform of the missile. Total time: 30 seconds :-)
(The other benefit of that approach is that artists can build any model, and still make the missiles come out from exactly where they want; no programmer involvement needed)

In my defense, it was also my first attempt at a 3D game ;)