Edit: Nominating for reopen as this definitively falls in under FAQ section "matters that are unique to the programming profession".
I want to program robotics in C#. This question is about existing kits/components to do so. I welcome any pointers on where to start. For example: Is Robotics Studio a good platform for this project?
The use will be a hobby project where I program the robot to drive around in my house and perform maintenance (like getting me a glass of water). I want to put my efforts into object recognition and controlling movement (driving, arms, etc). I do not want to spend time building a robot. This is not a robotics project in that sense, it is a software project.
Are there any human sized robots with .Net SDK (or something I can P/Invoke)?
It does not need to be fully adult human sized as long as it can reach stuff on tables and similar. It also doesn't have to look like a human being.
Very large robots are expensive, powerful (and power-hungry), heavy, and in many cases absurdly complex. Hobby-oriented robotics focus on devices that won't result in injury and/or death when things go wrong.
This is a bit like asking where you can buy a remote-control helicopter at 1:1 scale.
But to get you started, I'd recommend learning to work with embedded devices so that when you build your army of killer robots (as you undoubtedly will), you'll know how to control the motors, lights, sensors, etc. C# and .NET programmability in embedded devices is not a common thing, but lucky for you, a new chip was recently announced that does just that.
Check out the Fez Domino. It's largely compatible with the more popular Arduino platform, but you program it with .NET instead of C -- which is why it's twice as expensive. Much of the necessary work for controlling motors, lights, sensors, etc., with such a device has already been done for the Arduino platform, and that should largely translate over to the Fez Domino. Though, of course, you'll have to re-write the code in C#.
Even if you want to control your legion of death-bots via full-power computers, you'll often use a micro-controller like these to handle the IO with external devices, since they're better at that sort of thing, and you can communicate with them with simple computer-friendly protocols, like serial over USB.
Start small! As tylerl suggested, the Fez Domino looks like a great board to do some microprocessor work in C#.
Start out doing some smaller projects (if you haven't already). Perhaps build a line following robot using a Netduino or similar. There are countless kits out there, or you can just build your own pretty easily.
Once you've gotten that going, maybe graduate to doing some basic vision processing with a more powerful board (Fez Cobra, etc) or just strap a laptop to a bigger bot (this has a lot of advantages such as great processing power, being able to use the full blown .NET framework instead of just the Micro framework, you can use off the shelf components like web cams, etc).
If you want to become proficient at any kind of development with robotics, you would benefit from some knowledge of electronics. These small projects can help you build that up.
You can use Bioloid (http://www.robotis-shop-en.com), some robocup teams use them to participate in humanoid soccer league.
It's a very good platform (good materials and is easy to change or add components)
Other platform is NAO (http://www.aldebaran-robotics.com/) is used in Robocup standard platform league. In my opinion is very expensive for a hoby. In a closed platform it means that is very dificult to change/add components.
http://wiki.robocup.org/wiki/Humanoid_League in this humanoid robocup page you could find humanoid TDPs (team description papers), that provide very usefull information.
Related
I'm working with a small startup with the goal of creating an iPhone application. The programmers on our team all know both C and Java, but we've got no ObjC/C#/iPhone experience -- we'll be learning something no matter what. All the questions I've seen on this subject have been from the perspective of a C# programmer getting into iOS, so I don't have any information on the relative merits of learning one or the other.
So, what I want to know is the relative merits of C# and Objective-C for new programmers, with respect to these things:
Performance
Ease of use
Ease of learning
Reliability (i.e., will a new iOS version break a MonoTouch app?)
Also, would writing in MonoTouch have any benefits for cross-platform development with Android?
If the goal of your startup is to create an iPhone app, then obviously you should learn the language iOS applications are built with, Objective-C. Your team already has experience with C, so it should be very easy to get started. The Big Nerd Ranch books will get you up and running in a week or two (I'm not associated with Big Nerd Ranch, I just think they're awesome).
I don't understand why you bring up MonoTouch, considering your team doesn't have C#/.NET experience. There are tons of other frameworks like MonoTouch, including Titanium SDK (JavaScript), RubyMotion (Ruby), and so forth. All of these are great, but as I see it are primarily for those with experience with their respective languages. They allow you to write iOS applications using a language you're more familiar with, but have the following drawbacks:
Performance can be just as good, but usually a little (sometimes a lot) worse than an application written in Objective-C.
Resources for learning are not as plentiful as those for iOS SDK/Objective-C. There are tons of people who want to make iOS apps, and of those people some use these frameworks, and they are diluted amongst them. Only a small fraction of the resources available for iOS development will be devoted to any given framework.
These frameworks are based on the iOS SDK/Objective-C, so naturally development is always a step behind. If Apple rolls out radically new APIs in the next version of the iOS SDK, you'll have to wait for these frameworks to adapt (applications written in Objective-C might break, too, but it'll be easier to deal with based on point #2).
Most of these frameworks require a familiarity with the iOS SDK. You will still need to know that an application calls the - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions method on launch, but in addition you will need to remember how to translate that into the appropriate method for MonoTouch: public override bool FinishedLaunching (UIApplication app, NSDictionary options). The iOS SDK is massive, and most iOS developers rely on Apple's documentation for insight. So you will be looking at the API docs, written for Objective-C, and translating methods into the framework of your choice.
The Objective-C ecosystem is constantly evolving, with cool new projects like CocoaPods, bwoken, etc. These are primarily developed with Objective-C and Xcode in mind. Configuring them to work with your framework of choice will almost invariably cause you extra time and work.
The above points have generally kept me from delving too much into any of these other frameworks. They're all very cool, but their primary merit in adoption seems to be facilitating development for people with deep skill sets outside of Objective-C, or allowing cross-platform development for small teams lacking the resources to invest in Android and iOS (and Windows Phone) programmers. Hopefully the benefits outweigh the above costs for adopters.
Also, would writing in MonoTouch have any benefits for cross-platform development with Android?
I suppose it would. Indeed, the MonoTouch homepage touts that as a primary advantage of using the framework. I'm not so sure about view/controller classes, since those seem like they would be tied into UIKit, but the logic encapsulated in your models should be fairly easy to port.
Long story short, I think you and your team should stick with Objective-C for iOS development.
If you're just building an iPhone app, then by all means choose Objective C. But if you want a mobile app — which may include android, windows phone, windows rt, blackberry, webos, or other options — you might want to take a close look at a few of the alternative platforms, of which MonoTouch is one prominent option.
Objective C is a strict superset of C, so if you understand the performance characteristics of compiled C code on ARM, you can just use that C subset with which you are familiar, except for the iOS UI.
There seem to exist reports that experienced C programmers start getting up to speed with writing iOS apps in Objective C in on the order of 2 weeks. But, of course, learning extensive frameworks and APIs in an ongoing learning process, whatever the language.
For performance, the answer is Objective-C, all the way.
That said, take a look at doing this with HTML5. If you stick to accelerated transforms, HTML5 performance for an application front end is surprisingly good. It's also pretty easy to move your HTML5 app to Android.
The simple answer is Objective-C. It's not too hard to learn. If you're solid on C and solid on OOP, you'll be fine.
I'm building a scientific/education application, and I need to provide power-user scripting capabilities. My choices are:
Embedding an existing language such as Python or Lua
Or creating my own language with coco/R, for example
(Initially I'm building in C#, but will probably later port to C++ for iPad & Android reach.)
Each approach has its advantages, but a big factor is that I don't want to be shut out of app stores. Apple apparently prohibits apps that run interpreted code. I don't really understand how this is defined - surely any app runs by interpreting its own data structures? I assume it's some sort of "we know pornography when we see it" definition, and you just mustn't make your system look too powerful. If this is the case, I'm thinking that if I build my own language and transmit only the active syntax tree and not the scripting source, then I'm less likely to trigger their alarm bells - it'll look like any old data structure. Anyone know if this is right?
Apple relaxed the language in their license agrement to allow Lua a few years ago. It's used in a huge number of iOS games (including Angry Birds, all EA games, etc.). In fact, there are many games on the App Store written in Lua, using Lua-based frameworks like Corona or MOAI (such as Crimson: Steam Pirates, a Bungie Aerospace funded game which was #1 on the App Store for a few weeks). There are also Apps like Codea, a Lua scripting environment that end users can use to build games/toys right on the device. Lua is very popular on the iOS platform.
Creating your own language would be absurd, IMO. Lua is too good, and a perfect fit for iOS: light weight, fast, hackable, user friendly, easily embedded and extended, etc. However, you may have trouble integrating it into a C# app. I don't really know how MonoTouch works, but in the desktop world, C# is managed code, compiled to byte code, but Lua's API is native code. Bridging that gap can be done, but it's more work.
In short, you can use Lua and you don't have to hide it. What you're not allowed to do is create a "metaplatform", where users can basically download entirely new applications (which have not been reviewed by Apple) through your app.
EDIT: Regarding "I'm building in C#, but will probably later port to C++ for iPad & Android reach", you may want to check out MOAI. It's an open source, cross platform (PC, Mac, iPad, Android, Chrome) framework written in C++ for writing games in Lua. Might save you time to start there rather than porting later. You can do pretty much everything directly in Lua, and if you run into something where you need bare-metal performance or access to functionality not already exposed via a Lua API, you can write it in C or C++.
I want to know, is there any way to develop games for Android-based mobiles (and maybe iPhone) in C#? Yep, i know about "MonoDroid/Mono for Android", but well... it's not free. Java is great but Dalvik performance is far worse than Mono. And it lacks of some features that are very useful for game development such as operator overloading. Furthermore, there is OpenTK framework which is simply amazing.
So, is it possible to get running .NET/Mono on Android for free? Or am I sentenced to Java?
You would have to be able install unmanaged code on the device. I would recommend using Java, because I can foresee deployment being difficult with mono. Google might not let you sell your app on their marketplace with large quantities of unmanaged code. It would also tie you down to Android phones sporting a particular brand of processor, not much of a problem as all of the phones I can think of use ARM processors but there are some exceptions.
You could try http://www.mono-project.com/Mono:ARM if you are sure about this.
Operator overloading is simply syntactic sugar. I'm sure you are capable of writing applications without it. And Java can't be without its own suitable frameworks surely.
Android is overflowing with java and its most likely easier not to try and fight it.
If you don't want to use Java then you should use the NDK and C/C++; especially for games. An additional upside to that is if you think ahead a bit you can have a large chunck of code that works on Android and iPhone.
I am not normally a fan of offering something outside the limits of what you've set, but you should take this advice to heart:
If you are serious about Game Development I would invest time in learning Unity3D. The non Pro version is free and does not expire. They have iPhone and Android kits that allow you to deploy your game on both of those platforms. Yes they do cost money, but start calculating how much your time is worth.
If you are doing this as an exercise to learn how Game Engines work then that is awesome and you should pursue it. If you are more focused on developing an actual game, look into one of the existing kits. Unity3d is by far the easiest and cheapest kit for all the features it has.
I have a pawnshop CRUD app written 20 years ago with INFORMIX-SQL/SE (DOS) which is currently running on DOS 6.22 within Microsoft Virtual PC 2007 on Windows Vista. I would like to modernize this app with a GUI, SQL-based engine and retain its existing functionality. It doesn't require any networking or multi-user capability. I would prefer a product which is royalty-free.
I also would like to quickly re-write it with as little effort possible. Which tool would you recommend?
I'm debating whether to re-write my INFORMIX-SQL app with I4GL (character-based) or another Windows/GUI-based tool.
My app is very robust and has some incredible features which my users are very happy with. Only obstacle which is keeping me from effectively acheiving market penetration is, believe it, my app is char-based and I would like to duplicate the same functionality with a GUI. My feeling is that its quicker for a user to process a transaction with my char-based app vs. having to focus a cursor with a mouse, but cosmetics is hurting me!
I would like to know specific instances of limitations, bugs or drawbacks of using another development tool before I invest considerable amount of time evaling another product. Answers to this question could save me a lot of time and money!
If you visit www.frankcomputer.com you can view a video-demo of my pawnshop app. (CAVEAT: The website's in Spanish, use google translate to get a more-or-less decent translation of the text. Start the video at the two-minute mark, with 720p resolution and full-screen to best comprehend my app.)
If I were doing it, I would probably choose to write a WPF GUI in C# with a SQL Server Express backend database. An embedded database like SQLite might work as well. But the main reason I would choose that is because that's what I'm most familiar with. Someone else would likely choose something else...
I might also choose ASP.NET MVC and make it a web application if that were an option (you say that multi-user is not required, but I say it's not required yet).
Also, if you're not the one who's going to be developing it (i.e. you're going to hire someone to build it for you) then I would say that you should find the developer first and let them choose (or at least have a say in) the technology. If you choose the technology up-front then you're simply limiting the field of developers who'll be able to work with you and there's really not much point in that.
I'd recommend you use Python with a PostgreSQL backend. Now some will think this is overkill, but after watching your video and reading your site (I had to use a translator), I suspect the added flexibility is something you will truly enjoy by going this route.
The reasons I'd argue for this solution are:
Python and PostgreSQL are both great products with amazing communities when you need them.
Both products have a bright outlook in their development paths. Since you obviously spent a lot of time and effort tweaking SPACE, I'm betting you will do the same over the next 40 years. So, the tools you choose now need to be there for you as you continue your development cycle.
They are both free with friendly licenses.
Cross-platform support.
Scalability. You can use PostgreSQL installed locally and connect via socket or scale it all the way up to several servers using load balanced connection pooling.
Security.
Data integrity. This includes how easy it is to make your whole environment easy to backup and thus easy to restore in the event of a catastrophe.
Whatever tools you end up choosing. I wish you the best in this project. I can tell you are working on something you truly love and that is something more of us should strive for!!
Based upon your answers and your emphasis upon time to make the changes and that you don't seem to want to change the Application at all but it is being forced upon you by then you should certainly evaluate Genero from 4js.
This will allow you to utilise your existing code but provide a nicer looking front-end. You can also maintain a single codebase supporting both character and "Gui" clients.
Choose whatever language and technology is easiest for you. If you need DB access and a short lead time it sounds like Java or Visual Basic would be best. Both have plenty of free tools to get you started.
The top languages tags in StackOverflow are C# (by a long margin), then Java, PHP and DotNet, followed by C++ and Python. Some of that will be skewed by the Joel & Jeff origin of the site, but any of those is more than capable of the task. Personally, I'd go with Java or Python but I don't like being tied to the Microsoft stack.
wxWidgets and QT might be options for the GUI components.
Of the databases, mysql, SQL Server Express or Oracle Express Edition are all free and robust. SQLite is good enough for most single user applications though. I'd put this at the bottom of the 'importance' list. For small-scale single user apps, you should be able to chop and change DB platforms without much hassle. The biggest relevance would be in how you actually backup/copy/restore data in the event of disk failure or corruption.
For a long time now C++ has been the dominate game development language. Many AAA quality 3D engines are available to fit any budget.
My question is, with the rise of XNA, has C# and the .NET framework been positioned well enough to take over as the new standard game development platform? Obviously the inherent cross-platform nature of the XNA framework (Windows, Xbox, Zune) has its benefits, but are those benefits good enough to entice large game dev studios to switch gears?
Personally, i am torn between using C#/XNA for a new project, and using Java via jMonkeyEngine. I have a great desire to have my game be portable to multiple platforms, and the only languages i know well enough to accomplish this are C# and Java. i would love to see an implementation of the XNA codebase that is powered by OpenGL and would run on Mono, but i think that is merely wishful thinking at this point.
I am curious to hear what others have experienced while building 3D games in something other than C++.
I think C++ will go out of fashion in the next 10 years just the same way as assembly did. I'm a professional game programmer for more the 15 years. In early 90's lot of people said that C is not efficient enough for games. In the late 90's same people said that C is OK but C++ is just way too slow for performance critical applications such as games. Now C++ is the standard high performance language and people argue that other languages would be too slow. In the meantime today's games use script languages like Lua, Python or Unrealscript for game logic which are ten times slower than C# or Java.
C++ is much faster when you do math in your game. Doing linear algebra is painfully slow in C# or Java. However, this is only a part (10 - 25%) of the game. When it comes to the game logic bottleneck is memory access so using an other language does not reduce the performance significantly. The tool side of the game, which use to be the 50-80% of the code, really does not require any C++. It happily runs in C# which is fast enough for almost any tool.
One also should not forget that C++ is derived from C, which is made in the early 70's. So C++ is obsolete in many ways. The most annoying thing is probably the pre-processor which kills transparency and causes insanely long compile times. An average state of art C++ game engine compiles in 30-60 minutes. In such time you could compile every C# and Java project ever made by humans. Lack of self reflection and dynamic code creation is also a drawback. It often costs a lot of development time to overcome on these shortcomings.
Nevertheless C++ development costs a lot it would cost even more for a game studio to risk a failure by switching to a new technology which is not yet proven in game development. It is also an important factor that majority of experienced game programmers use only C/C++ and they do not have experience with other languages which would definitely increase the risk of switching. Because of these, you probably will not see game studios in the next couple of years switching to C#. However, it is likely that a Microsoft owned studio will make a big hit with a C# game in the next 5 years which will convince other studios that it is feasible to make AAA titles in C# and then you will see more and more studios switching to C#.
For now, my advice is:
If you want to make an AAA multi-platform title you have no other choice than C++ for the runtime part of the game. Consider using C# for the tool side. It's a little bit tricky to efficiently connect managed and unmanaged code but on long run it worth the effort you spend on it.
If you do a hobby project or a B title where performance is less important than development cost/time then forget C++ and just use C# for everything and spend some extra time to optimize the math.
The large gaming studios will probably not adopt XNA any time soon. Some indies are using it, but definitely has the potential to eventually be very successful and leave C++ behind.
XNA provides many classes that you can use in game development, but many others often choose to use a fully fledged games engine. Although XNA is rather good for beginner's to cut their teeth on if you are new to programming games.
C# is a good language to use for games development. Games development produces applications that require sound, advanced graphics, AI, Physics, etc. All that requires a powerful and fairly quick language environment. While most of the top tier PC and console games are written in C++, C# has a road map that will likely leave C++ behind. The coming changes in C++0x will no doubt reinvigorate C++ for a little while but C# looks poised to overtake it.
If you really want to be a games developer I would urge you to at least learn C++ and write your own game engine. Using a pre-made game engine is easy and you can code something that is 'okay' but you will run into many limitations that you won't be able to code around. You will effectively be confined to the capabilities of the game engine (unless you have access to the source, which you could then modify to your liking).
Learn C++ and preferably OpenGL :)
Once you know OpenGL you can learn DirectX pretty easily.
C# is a piece of cake once you know C++.
While some time ago XNA Professional was announced, Microsoft now seems to focus on the Express edition (though it lost the "Express" in the name), and that seems to be aimed at the hobbyist market rather than the commercial market. Among other things, this largely benefits the XBox 360 community, because they now allow hobbyist developers to develop their games for Windows and XBox 360 and then to sell their games on the XBox network, and that is a good thing.
I'd really love to see XNA gaining momentum in the professional world, but this won't happen unless it's available for the other major gaming platforms (PS3 and Wii). The problem is not only the XNA framework / API, it's the language / framework requirement, so you can't even write the game in C# and then use XNA on Microsoft platforms and OpenGL on other platforms.
The performance profile of XNA is also aimed at the hobbyist market rather than commercial, though the performance seems to be quite good and there are impressive demos out in the wild.
Edit:
If your question is actually "should I use XNA now for my project with a budget much less than a million", my answer is definitely yes. Go try it out, it's free. And it's powerful.
I worked at a place called Newfire in the late 90's. Before funding ran dry, we had an engine that could render an immersive world that was 10,000 square km with a resolution of 10 cm. You could get a huge number of players in at once and persistently deform the landscape. This engine ran at frame rate on a P200 with a Voodoo 2 card.
Most of the engine was written in carefully tuned C++. All the game code was written in C or C++ or Java. I also had prototype code that could define object behaviors using a push down automata that could do very decent AI. It took nearly no CPU time. The execution of game logic was dwarfed by rendering.
At one point, I had a demo of Conway's Game of Life running in Java using our software renderer. The cells were cubes laid in a plane which appeared or disappeared and changed color as they aged more generations. While the game was running with a fixed generation rate of 4 generations per second, the 3D display was running at 20+ FPS, again on a P200 with the software renderer.
So the answer is not definitely C++. The answer, like any problem domain, is the language that works the best within that domain. C++ works well in that domain for the rendering engine, but for the actual game logic and rules, lots of languages work well. Python is great. C# is great. Java is great.
As a poster mentioned, XNA is currently limited to Microsoft platforms but you can still use C#, .NET and any .NET programming languages to develop games in a cross-platform way.
The Mono runtime does provide a cross-platform engine that can be used to run your C# (or .NET code) under a variety of desktop platforms (Windows, MacOS, Linux) as well as gaming consoles (Wii supported by Novell, PS3 coming soon and Xbox360 "on your own").
There is also a commercial gaming platform called Unity3D that has done wonders using Mono. They are a game IDE that surpasses XNA as a game development environment: physics, graphics, lights, models, collisions are handled all in native C++ code while all of the gaming logic (AI, camera control, views and so on) are handled by managed code written typically in C# or UnityScript (a strongly typed Javascript implementation that gives you the best of both world: the Javascript syntax, but strong types that improve performance).
I am not a game developer (unless you count the Reversi game I wrote in Atari 6502 assembly language in ~1982), but I do have a lot of experience writing commercial application software in Assembly -> C -> Objective-C (anybody remember the Next Cube?) -> C++ -> Java and now C#.
I cannot compare the game libraries but I do have some thoughts on C++ versus C#.
IMO, the argument for C++ over C# due to performance is not as simple as some would have you believe. The software I work on is performance critical. We compete with products compiled to native code (presumably written in C / C++ / Assembly) and we win on performance to the point that our competitors even use our software over their own for certain applications.
How can that be if C++ is faster than C#? In my experience, the answer is the fact that for any complex system, the architecture and algorithms are more important than the language (assuming that the potential performance is in the same ballpark - which it certainly is with C++ and C#). Even though I was a full time C++ developer for more years than I have used C#, I am much more productive in C# than C++. This means that I can spend more time refactoring and perfecting my architecture and algorithms than I could previously.
Now, sometimes I have to admit that I am tempted to rewrite the core engine of my application in C++ because I know that I could get it to run faster and use less memory. So far I have resisted the urge because I believe that the drop in productivity would mean that it is only a matter of time before my C++ codebase is slower than where I would be if I had stayed with C#.
I believe it is only a matter of time before game development transitions to C# and / or Java and / or some other language which is more productive than C++. Having used Java for several years and now C# for several years I would bet on C# - but that's just a guess.
If I were getting started in game development today I would definitely bet on Silverlight and / or WPF. WPF is built on Direct3D. Microsoft has already announced that Silverlight 3 will support hardware assisted 3D rendering. Silverlight runs on various browsers and the Mac. With Moonlight it runs on Linux. It has been announced for some phone platforms. Thanks to the fact that Silverlight is essentially a lightweight version of WPF (it was initially introduced as "WPF/E" where the "E" means Everywhere) you can target both without a great deal of extra effort. You can have a lightweight version (free or supported by advertising) of your game using Silverlight in the browser and the real deal for serious gamers which uses WPF and runs on Windows.
Better yet, be the person to create an excellent gaming library which allows for easy targeting of both WPF and Silverlight 3 (or Silverlight 2 if you don't need hardware assisted 3D rendering).
While I have seen no official announcement, it is hard to believe that the next generation of XBox will not support Silverlight. Of course, I would not look for it on Sony or Nintendo gaming systems.
I think that there is a kind of BS elitism that happens when people talk about XNA or java game frameworks or pygame or whatever. Yes, professional game houses will use C++ for a long, long time. But Atmospherian is asking about something for his own project, so I'm going to assume that he's an amateur (if he were the CEO of Epic or something I doubt he'd be posting on SO)
Anyway, just because you couldn't code FarCry in it doesn't mean that it's a worthless framework. Major-studio level games require millions of dollars and dozens of people, but XNA/Java/pygame/etc have allowed amateurs to do some pretty awesome stuff. Amateur games and major-studio games are two different beasts and call for two different sets of tools.
To answer your questions, Atmospherian:
-Yes, XNA can do some pretty cool stuff and people have used it to make some cool games.
-If you want XNA to be cross platform and work with mono, I think it's technically possible, but I wouldn't hold my breath.
-If you want to end up with a job in the games industry, you are going to need to learn C++.
-I think the path of least resistance to getting a working cross-platform game engine is currently in pyglet. The ease of use might trade off with speed when compared with java or C++.
Just add to the conversation ... C#/.NET is certainly available on other non-microsoft platforms.
Mono.Wii
Tao Framework
Between those two right there, you can target linux, mac, wii ... I'm sure if there was enough funding/interest in it, they can get Mono to run on a ps3 as well. At that point, you'd be able to write for all major game platforms using C# (albeit, probably not with XNA per-se).
Also, to anyone wondering about performance ... lots of great things are in the works, such as Mono's new support for fast floating point math using their SIMD extensions (x86 only for now, of course):
http://tirania.org/blog/archive/2008/Nov-03.html
Surprised nobody has mentioned the possibilities for a mobile gaming. I can't see any managed code competing with C++ anytime soon for the likes of Half-Life and Halo, but for less-intensive mobile device games it seems like it's got legs.
As a follow-up to this question, i started looking at some OpenGL based 3D engines written in C++ (CrystalSpace, Irrlicht, Panda3D), and they all look rather solid. An interesting note about Panda3D is that it is written in C++, but the main way you use it is through Python. It seems to me that method would give the best of both worlds as far as a fast engine written in C++ combined with the ease of programming in Python. I'll pose another question comparing these engines. Thanks for the replies.
Well, between those too I think C#/XNA is a clear winner based on library support and really the maturity given Microsoft's experience in DirectX. That being said, I don't see C#/XNA replacing C++ as the lingua franca of serious 3D game programming (i.e. by large development houses) for a very long time, if ever.
It is not just the studios to consider, it is the audience. Chances are that as long as Sony and Nintendo are around, they are unlikely to move the a C#/XNA platform. At least for Nintendo, when you have the mass-market appeal that they currently do, they will continue to dictate their development platform.
I love XNA, since I can now write applications for my Zune, but C++ for a broad-based development platform for gaming is going to be around for a long time. There might be an influx of new indie developers for Microsoft devices, but we are a far way from seeing XNA be used across the board, if ever.
Lua should be of interest to you, as you can embed it in C# and access your objects from LuaScript.