f13.net

I'm not expert at this, so feel free to correct me where I am wrong...
And if this has already been written on, or you know of a better place to ask something like this then let me know.

I'm teaching myself how to program; I've started with C++, but I'm also interested in C#.  I'm still still an amateur, though I think I'm starting to get to the point where I can begin writing programs I wanted to in the first place, such as games.

What is the best programming language to write games with?  Until now, most people have chosen C++, especially for games intended to be released commercially.  C++ has been the most popular for game development for a (long?) time--but is it the only choice for a commercial game?

I'm not saying I'll ever be able to write anything people would actually buy (though it is a goal).
This is an honest question (you can probably tell because I don't sound very knowledgeable about it). 

Why hasn't there been much game development in other languages such as C#?  C++ is very messy syntax-wise:  it's all over the place. 

But it was, if not the first, the first major object-oriented language, but it is definately not the only.

I've been told by non-game programmers that one of the major differences between C# and C++ is that programs written in C++ run faster.  Is this because C++ code is easier to optimize?  Does C# have too many additional processes running that C++ avoids by not having automatic garbage collection?  Does the .net environment create something of a barrier in getting to the CPU quickly?  I think that the speed issue is probably something that can be worked around, or improved with later versions of the language.  Is that really all that is holding C# back from becoming another choice, or even a better choice for game development?

Have methods or libraries that are common in C++ for game development not been created in C#?
Are current developers just used to C++ since they have been using it for so long and see no reason to switch?

At least one somewhat major independent game that I know of, Arena Wars, was written in C#.  I haven't played it much--I don't find it to be very enjoyable--but on the technical side, it seems to run well and has good graphics. 

Please,  share any knowledge or thoughts you have on the matter.  I'm hoping at least a few people here know something about this and will be able to help.

<patronizing engineer>Languages are a tool for a job. There's no one best language.</patronizing engineer>

My impression is that most modern games are built around a C++ core engine which then runs an interpreted language that defines most of the game's behavior, e.g. Python, Ruby, Lua or a custom one. For example, I think GarageGames' Torque engine is this sort of two-stage engine.

Anyway, the best programming language to pick up and program games with right now, with the goal of being able to put something out quickly? Probably any language you can find a prebuilt 'engine' environment for, like Torque. I've not extensively investigated the various ones; I know BigWorld (a commercial MMO dev package) uses Python. Search around, particularly on sites like Flipcode (http://www.flipcode.com) or Gamedev.net (http://www.gamedev.net). There should be some articles there on prebuilt engines.

Now, if you want to build an engine from the ground up... you're heading into rougher waters. C++ or a similar language that lets you get 'closer to the metal' may be in order. You'll need to deal with stuff like memory allocation and do without nice things like reflection. You'll also have to write your own libraries for network communication, audio I/O, keyboard/mouse I/O and graphics.

If you're more into casual games (e.g. cellphone games), which are certainly a good starting point, you probably want to start out with a slightly higher-level language until you've grasped the basic algorithms and programming constructs of imperative programming languages. (I don't think there's any major games written in functional languages... Rednames and grizzled grognards, prove me wrong.) Java is used fairly often for cellphone games, I believe, and you can also write web-applet games in Java.

If you're talking about commercial games, then, technically, no, C++ is not the only avenue. There's pay-to-play MUDs written in LPC, cellphone games written in Java, indie games written in a vast variety of languages. If you want to code the low-level engine of a AAA-title, knowing C++ well is probably very helpful. I also doubt you're doing that.

Performance

C# is run inside the .NET runtime; it's sort of interpreted, in the same way that Java is interpreted - an intermediate bytecode is translated into native binary code at runtime. C++ is completely converted to native binary code at compile-time, so there's no interpretive step at runtime. This is why (in theory) you can grab a compiled Java program and drop it on any system with a Java runtime engine whereas you need to recompile a C++ program for each different platform.

Note that, even today, I've heard that the inner loops of performance-sensitive routines (e.g. graphics) in modern games are often hand-optimized in Assembly. I would strongly advise you to not think about doing that right now. Or anywhere in the near future.

Engineer's mantra: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." Until you're writing something with a serious computational bottleneck (big AI, massive datasets or heavy 3D graphics) you can probably do fine for performance with Java, C# or any other bytecode-based language.

Nice Features

C# and other interpreted or semi-interpreted languages do a lot of nice things for you that can make it easier to get something working. Garbage collection is one of them. If you intend to move down to lower-level code, you will eventually need to learn about all the stuff that those interpreted languages are doing 'under the hood' - threading, mutual exclusion, memory management, etc.

However, a lot of these can be done in C++ with the right libraries. These languages are all Turing-complete. It's just a question of how much of a pain in the ass it is. (If you really intend to code in C++, I suggest picking up a good Smart Pointer library; if you learn how to use smart pointers properly, they can help with a lot of the memory management bugs that programmers tend to make in lower-level languages.)

So to wrap it all up - I suggest a higher-level language like C# or Java for the beginning programmer. Get used to programming, make sure you enjoy it. As processor speeds advance and more stuff gets offloaded to auxiliary processors (PPUs, GPUs, etc.) the requirement to absolutely minimize the number of instructions being executed relaxes, and you'll see more emphasis on using higher-level languages to cut down on development and QA time.

No, but if performance and code security are the main concerns C++ (and C) will continue to be the primary choice. There are other choices of course. E.g. Puzzle Pirates is written in Java and there are tons of games written in Flash. On the code security side interpreted languages like Python, Perl, Ruby, Tcl, Lua, etc. expose the source code to everybody. Byte code languages like Java and C# are harder to read in their byte code "compiled" form but "disassemblers" that reconstruct the original source are easy to come by. You can, of course, disassemble C and C++ code but that means reading through assembly code not the original source code.

If you are doing DirectX 3D graphics C or C++ will give you the best performance. There is something called "Managed DirectX" which is the .NET version of DirectX that you can use with C# but there's still a performance penalty (somewhere around 10% from what I've read).

C# runs in what's called a virtual machine like Java does (Microsoft calls it "managed code" just to be different). You can compile virtual machine byte code down to native machine code (e.g. using a JIT (Just in Time) compiler) but you still have the overhead of running through the "management" layer for everything.

Automatic garbage collection is one of those things that can cause problems in games. In normal operation the interpreter/virtual machine decides when to garbage collect and there can be a signifcant slowdown while it reclaims memory. Managing memory yourself is a total pain in the ass but when performance is crucial it's a necessary evil.

I was trying not to get bogged down in details.. you can force the Java GC to collect, I believe. I diddled with that a bit back when I did more Java programming. I believe you can also force the C# runtime to collect. I'm not sure if you can explicitly force objects to deallocate, either directly or automatically when they fall out of scope, in either language.

Like I said, smart pointer library in C++. Write/find one, learn it, love it.

I also maintain that for beginners, the important part is getting something going to maintain the motivation to code more and learn more. Not having to deal with low-level issues quite yet, while still learning how to properly structure and engineer a program of more than trivial size, is more beneficial than getting caught up on segfaults in your first few efforts.

Pretty much everything everyone wrote is absolutely correct, so just to touch on a few points:

There is a trend right now to get away from "custom script languages", and simply allow bindings to traditional/new-but-open scripting languages, such as Lua, Python, and the like. Trippy was correct--Torque has TorqueScript, a C++ like byte code compiled scripting language, but current use of our engine does require you to learn TorqueScript. However, many people have extended the engine to allow custom bindings to not only Python, but Lua, and even C# as well, and with just a little work any source-available engine can let you use whichever scripting language you like (note that it has to most probably provide either an API for this type of new language binding, or the source code of the engine itself).

The performance concerns with C#, combined with the fact that almost by definition (it's an MS initiative) you are limited to only one (obviously the biggest, but not the only) operating system/platform. However, there are quite a few initiatives going on that may make C# more attractive for future game development.

General Advice (and I'm trying desparately not to be self-serving here!)--pick up any engine that allows you scripting capabilities (also called modding capability), and simply learn game development, instead of focusing on which language to learn so you can then learn game development. As you become more and more familiar with the general concepts, language choice becomes a tool selection (as Yoru said), instead of a barrier to future development, wherever it goes.

.NET (whether C# or VB) is going to be more marketable overall, mainly because the garbage collector frees up the programmer from most memory management issues, which are a significant time sink for most dev efforts.  What C++ gives you is total control, and I would suggest if you are learning to program and want to be serious about it, you go with it.  If you're a good C++ developer, you can move to C# or Java.  It's much harder to take a modest C#/Java guy and go C++.  If you're wanting to go professional with game development, it's almost certainly a must.

However, if you're not wanting to make a career out of this, I would suggest going with VB.NET.  It's a bit simpler to work with than C#, there's not really any performance differences between them, and there is a ton of sample code on the net for it.  You'll obviously go DirectX with this, so grab the SDK and some sample game modules along with a decent book.  You can get source for simple 3D game worlds from a few places, which will let you start messing with something right out of the box. 

If you want to go development but not game programming (it's a tough market), keep an eye toward either .NET (C# or VB, doesn't much matter) or Java.  You can go C++, and make good money at it, but there's more mobility in the other two areas.

There are a bunch of questions here.

What is the best language to learn to write games with?
C/C++ is the only answer. Because if you know C/C++ you know Java, C# and any other procedural language. If you can ride a bicycle you can ride a tricycle. I'm no C/C++ snob (the last programming I did in C/C++ was 4 years ago) but if you are looking to learn I would do that hands down.

What is the best language to write games with?

Mobile (cell) games? Java, Brew (is that still around?) or something like that.

Game boy games: C + assembly. (Actually quite enjoyable)

PC Games: C/C++ (with caveats see below)

Console games: C/C++


Why?

I'll focus on PC games here. PC APIs like DirectX are C. C gives you direct memory control. C is faster. C allows to do crazy things like pack 2 ints into a float, move them across a bus and unpack them other time. (I just explained how to double your drawing performance on the Mac in 1995 yay!) C allows you to do crazy pointer things. C works.

Java has problems. The support for sound isn't so great. The support for input (keyboard, mouse, joystick, etc) isn't so great. The support for full screen drawing isn't so great. The 2D graphics performance is terrible - but you shuold be using 3D to do 2D now anyway thanks to graphics cards. Garbage collection is an issue in Java. Doing things like flipping vmem pointers in Java is a problem. Sometimes you can't get close enough to the hardware and APIs.

Other languages? C# is MS only and is not widely supported. Anything else (scripting languages, LISP, etc) are unusable. There really aren't that many choices.

Caveats?

First, again if you learn C/C++ you can learn anything. And you can learn the language all consoles use. So you can't go wrong there.

You could write a game in Java or C#. People have done it. I'm doing it. But I would only do that if I had enough experience to know what I was getting into before-hand. In my case I have very low performance requirements and don't need to do many fancy things.

At my company we produce a Java product but we will seriously consider people who only know C++. Because people who are good at C++ are good at programming, period.

I would never hire someone to work in C++ that only knew Java. Not in a million years.

Well the same could be said for Java, Smalltalk, Delphi, Objective C, Pascal.... There are only three different paradigms that programming languages follow (at least if you count languages outside the academic domain). They are either procedural languages (c, pascal, fortran, most older scripting languages), functional (sp? don't know if that is the correct term in english) languages (lisp, sheme etc.) or object-based/object-oriented languages (C++, Java, PHP, C#, Objective C et.c)

If you know one language that fits one of those paradigms then you basically know all of the languages that fit that paradigm. The biggest differences between languages would be syntax and maybe some very advanced features.

If you want to learn programming I'd never suggest C++ as the first language because it is harder to learn than for example C# or Java. It has such a messy syntax and many ideosyncracies that come from its c-compatability and the fact that the inventors of c++ are shoehorning every advanced feature under the sun into the language definition.

If all you want to do is develop games I'd suggest one of the many available engines with attached scripting capabilities that greatly ease development of games for the hobbyist.

If on the other hand you want to go deeeper into programming like writing your own engines doing some fancy graphical works over the like C++ will be your language of choice for the simple reason that the vast majority of libraries and toolsets out there have bindings for C++ (sometimes even exclusively c++).

The question is a bit off by the way for the simple reason that in most programming tasks the language is just interface to commercial libraries. If you program for windows you will use DirectX and other system libraries that use c++ bindings.

Pointers are the key, though. Some people just never get them. If you can handle pointers in C/C++ that means you can handle other procedural languages easily but the reverse is not necessarily true.

My belif is that C# will gain ground on C++, not in games requiring performance, but other tools and more causal games. I would start out with C# if I was beginner. If you start with C++ on your own you will probably get discouraged if you're not a genious.

Ajax is grabbing a lot of people, and Google realease today its API for it that they use for Gmail and other things.  So, if casual web, Java is still big. And I think everyone has summarised well otherwise what's out there.  For robust apps, C++.  Of course, world designers etc. would never need to learn it. 

Javascript which Ajax uses is nothing like Java though.

Correct.

What Google released is a toolkit (Google Web Toolkit) that takes your Java application and translates it over to AJAX (HTML and JavaScript). It should be quite handy if it works well. I haven't had the chance to try it out yet.

If you're just starting out learning programming, I'd recommend LOGO.  Marvel at how easy it is to make cool things happen on the screen with little effort.

If you've mastered LOGO and want to try playing with something a little more flexible, take a look at Scheme.  Marvel at all the weird shit you can do with functions, which you previously thought of as static pre-defined things.

Once you start doing OOP and find Scheme cumbersome for that, try Java.  Marvel at how much cleaner the object semantics are, and how inheritance is implemented for you.

Once you get tired of your Java apps running like ass, learn C.  Marvel at how much faster everything runs, for the very small price of having to remember to "free" after you "malloc".

And when you start missing OOP again, learn C++, and marvel at how they managed to graft OOP onto C without making it slow as ass.


If all that sounds too hard, just learn Flash and focus on becoming the next Joe Cartoon.   :wink:

lolz I forgot about that one. I did a data structures course once with Pascal and PixieScheme.  Funny.  Kinda.

Scheme is a bitchin' language to start programming in.  It's got extraordinarily clean syntax with very few special rules or exceptions, and it exposes a lot of very powerful programming concepts while still making it simple to write simple programs.

On more than one occasion I've found myself wanting C++ to provide Scheme-like flexibility with regard to treating functions as first-class objects.  You can fake some of it with inheritance, but there's just no real substitute for a (lambda (x) ...).

Just a note: If you're going to learn C++, learn to love templates. Learn to understand them. Because trust me, when you need to use hashes or trees to store your objects, it's just easier to use a template someone else has written. Reinventing the wheel is a stupid waste of time. You don't need to write your own hashing tables or functions unless you're running into perfomrance issues.

Having said that, I once spent a great deal of time helping rewrite the C standard libraries to improve performance. We did it by stripping them totally bare -- you could really shoot yourself in the ass with what we created, but we were using it to deal with a simply insane amount of data on a very rabid heartbeat. Not something I'd like to do again, really. C libraries aren't exactly idiot proof to begin with, but when we were done the ones we had to use for the dataflow layer --- well, let us say our testing process was damn rigorous, even by the man-critical QA standards.

One of the things that vexes me most about C++ is that templates are even necessary.  If all C++ objects had a base class (instead of "void *") and C++ offered some sort of decent runtime type identification, templates and all their associated idiosyncrasies would be right out the window.  Of course, that's how we ended up with Java, but that has its own set of obnoxious problems.   :-P

Don't knock void* or void* will knock you. It's either that, or using an unsigned short char to represent each byte of a more complex item.

I had to look at code that used memcpy() to paste in the virtual function table of an object the other day. It was nasty. (The short answer is that someone was trying to duplicate the under-the-covers RPC communication of .Net without using .Net. The long answer is MY EYES THE GOGGLES THEY DO NOTHING!!)

Write it in Basic.  And not this faggoty Visual Basic, or even that shit where they got rid of line numbers.  No, you'll code your lines on numbers in multiples of ten, and if you find a place where you need to insert more than nine lines of code, then it's gosub/return for you, bitch.   :-D

Well at least they succeded in making the syntax of C++ look like ass  :rimshot:

I'd start with something like C# or Java or Python.

If you start with C++, you're just going to be writing bad C++ for a long time, and not really understanding it.

Once you understand conditionals, loops, recursion...then learn C.

Better yet -- just get a BS in Computer Science. They'll teach you all that shit. And you can use it to get a job.

My favorite part of my undergrad degree was doing advanced data and file structures and learning -- to my utter horror -- that our book didn't even get the algorithm for a B+ tree right. And then finding our book wasn't alone. Apparently, no freakin' book in existance has ever done that algorithm correctly -- ironic, given how frequently they're used (file structures and DB storage, to name two).

I irritated my professor by doing my distributed shared memory assignment in C (rather than java) -- I figure if I'm going to play with sockets, I'd like to get my hands on them and not use Java's high level interfaces. I'm looking forward to my datamining class, even if i have to pick up C# to do the assignments. (A requirement for his projects, for some reason). Financial data mining is fun. :)

Mine didn't. :(

The only good classes I had were Assembly and C++.  Both because of awesome visiting professors and they actually taught the language.  The rest of my comp sci degree was a massive waste of time.  (Well, my Tcl/tk class was fun, but I love programming, it was an elective, and had little real word value.  Come to think of it, that was when I was a chemistry grad student anyways.)

Let's see -- as an undergrad, what did I take that was useless (core classes, not the "required two semesters of English and Government" stuff)?

Well, in a sense the three semesters of Calculus, the probabilty courses and the linear algebra and differential equations classes were probably useless. I don't really use much of that directly. However, for someone unused to the sort of thinking patterns good programming requires, it would be helpful in teaching them how to think (and thus code) logically and rigorously. The discrete math class was useful -- anything with boolean algebra is useful for programmers, if just to get a very solid feel for certain types of code flow. Numerical methods was usefull -- I've had to create my own data types to hold floats with more precision than C is capable of, and had to do complex math on them. Heck, that makes Diffy Q useful, because we were solving differential equations. :)

The data and file structures class was rather useful. I'll never code a linked list, B+ tree or hash again -- but I'll use them. Same with searches and sorts. The basic DB classes and basic web software classes weren't directly useful, but came in handy when I had to start working with both -- kind of useful as background knowledge.

Assembly language was useless, as was machine language. You'll have to stick a gun to my head to get me down to that level. I understood it, I just hated it. Ditto for the computer architecture and circuits stuff I had to learn. Ditto Ada. Talk about strongly typed hell.

The Java, C++, object oriented design, and basic software engineering classes were a decent base for what I ended up doing "In the real world".

That was about it, really. A BS in computer science is really just giving you a basic understanding of concepts, and some familiarity with common tools. My graduate program is a hell of a lot more interesting -- the distributed computing stuff was fun, especially once we moved past traditional client/server models. Implementing workable distributed shared memory was a lot more challenging than most of what I get paid for, although part of that was the tight time frame for development.

The compilers and program language theory classes were interesting, but other than picking up some useful string parsing techniques, I suspect I'll never give it another thought. The advanced database class was VERY useful (although difficult), and I'm looking forward to my datamining class next year. Advanced Java I'm just taking as a refresher (half our department works on a very complex Java tool, and I haven't touched Java in years -- so I can brush up on the company dime in case they need another hand).

Starting in the spring -- genetic programming and that n-tier client/server architecture, and then my thesis. (Genetic programming).

I guess it really depends on what you want to do. I think the BS -- at least from a good school -- gives you the sort of foundation where you can pick up what you need quickly. It just integrates into the broad understanding you have of how computers work, how programming languages work, and the sorts of techniques and approaches that are available (and which are appropriate to the task at hand). Post-grad, well -- you've got to have a real interest in something. :) For me, it's genetic programming. That shit's just too damn cool.

Of course, my company is paying for the whole damn Master's, plus a 10k bonus when I get my degree. I'd be a fool not to pursue it.

When I got my CS degree we didn't have any required classes where you "learn a programming language" - instead, the class would focus on teaching some larger concept, like OOP or data structures or hardware-software interaction, and you were responsible for learning the programming language for the assignments on your own (either as you went or, if you're a big wuss, as a self-paced elective course before you take the real class).

IMO this is the only way to do it.  Learning a language on its own is almost useless - the concepts that transcend individual languages are the important stuff.  Which is why when someone asks 'what programming language should I learn' I generally respond with a big laundry list - people who decide that "learning a language" is their focus and don't at least try to dabble around a bit are pretty much doomed from the start.

My CS undergrad experience was similar to Samwise's; most of the classes taught underlying theory and it was mostly up to you to learn whatever language the professor demanded his assignments in. The kinder ones would offer a short tutorial on it. From what I heard, CS101 and CS102 had some just-learning-C++ content, but I skipped those. Some of the upper-level courses that were attempting to teach something that had a direct real-world parallel would foray into the realm of application (e.g. our network communications course did some stuff on CORBA and RPC).

There were small 1-credit elective courses you could take to just learn a single language; they varied in how much they were worth. Our java course was hard-core (final project: build winzip in Java. You have five days.) whereas our Perl course was little more than entertainment for unix geeks.

I pretty much agree with this approach; while you're not quite as ready as a focused software engineering curriculum to just go out and work on a huge app right out of school, a solid grasp of the underlying theory makes transitions between languages, platforms and tools much easier. It's the difference between learning an alphabet to make words or learning a hieroglyphic script.

I don't think any CS programs require more than one language. I took Ada and Java as electives, and my C++ course was really a course on object-oriented deisgn. At the master's level, my advanced OS class was really "Distributed computing" since the undergrad OS course taught everything you needed to know about an OS. (By time you finished the last project in undergrad OS, you had coded a nanokernal with it's own file structures, locking mechanisms, and client/server IPC).

Languages are quick and easy to pick up, once you have one under your belt. (Unless you're jumping to prolog or Lisp from C++ or something). It's the concepts and advanced techniques that are the core of a good CS degree.

Where'd you go to school, Yoru?  Your CS program sounds a lot like UCB's, but the course numbers are different.  (MIT?)

RPI (http://www.rpi.edu), in Troy, the Armpit of New York.

Most of my courses were like y'all's, but they did not teach even the theory very well.  A good portion of the students did not have enough programming experience to really be able to combine the theory with a working program, they might kind of understand one or the other, but trying to learn both at once only caused further confusion.  (Those of us with coding experience already understand the theory, so it wasn't of much benefit to us either.)  I think they would have done much better if they got the theory with a code snippet to have something to relate the two together.

I can't remember if this was required or not for our CS degree (it was so long ago, heh, plus I was EE) but we had a "learn a bunch of languages" class where we learned things like Prolog, Lisp, and Ada but that was as much to expose us to different programming methodologies (e.g. logic, functional, and modular programming) as it was to learn the languages themselves. We did have an specific "learn C" class at the 100 level since Pascal was the teaching language of choice back when I was in school and there were other language classes as well (assembly, more Lisp, etc.).

Edit: fixed typo

I had that as a grad course -- except it was two weeks of "Here's everything you need to know about the various types of programming languages" and then a semester worth of program language and compiler theory. Much as I try, I will NEVER be able to forget what an NP complete problem is, or how to tell whether a language is context sensitive or context free. Ugh.
 

Good to know.  Precious few CS programs I've investigated do it that way - from the people I've talked to, it seems like most schools do the "freshman year you learn Java, sophomore year you learn C++, junior year maybe you do something exciting like write an IM program" curriculum.  Blech.   :-P

I took QBasic and VB.

That's pretty much where I stopped.

CS 101/102 were learning C++.  Some 500 level courses used Java, or allowed it in lieu of C, but there wasn't a course that taught you Java.  Everything after 101/102 was theory/math stuf, except for a few weeks where one GA showed us some quirks with one variant of C combined with Unix scripting (but that was an elective, and taught by a GA).  The other was a class that mixed a half dozen languages - something like 2 weeks per language, with the premise being to expose people to a variety of language styles as well as educate on the use of scope, etc. 

Java has now replaced ANSI C as the entry level language in CS programs.  At least when I last checked as a TA few years back.

Most CS programs, maybe. I know of at least one that still uses C++ as its entry-level language. For now.

I think UCB consciously avoids having the entry level language be something "industry standard" like C was or C++ is or some people think Java might become, so they won't have to worry about continually changing the curriculum to keep up with the industry.  Hence Scheme.

My cirriculum was a bit different.  I did a degree in computer engineering.  Pretty much everything was theory and then labs were practical application.  We got mix up our courses between EE and CS.

Because of my degree type very little of what I did was high level.  There were programming language classes but you could only count one towards graduation.  Also I think that by the end I had 11 semesters of math :)

People who say that math skills are irrelevant to programming and that they never use it have no idea what they are talking about.  Programming is ALL math from top to bottom.  I think that might be a 'can't see the forest for all the trees' issue though.

Especially in 3D graphics.

Yeah, the study of optics was one of the driving factors of Newton's studies.  3D graphics is in large part application and optimization of the physics of optics.

My degree was quite a few years ago (graduated in '89), and the one thing I suffer from now more than anything else was that it did not include any real programming focused math. From discrete math to matrix and quaternion theory, I have huge blank areas in my formal education that required quite a bit of personal study to "catch up" to today's technological advances. I personally feel it's extremely important to get a firm grounding in the theory behind what real time scene rendering and manipulation entails if you plan on being able to jump right in to 3D related programming.

Of course, much of that technology didn't even exist in the "common" industry back then--hell, it took 3-4 hours to render a single frame in most cases!

Edit: Wow, I just realized how old this thread is.  An Corp!
------------

I agree that math is important, especially if you are doing graphics, when you will really use it, but also for programming in general.  It really teaches you how to think about the sorts of problems you will encounter.

Regarding the OP's question:

Not to knock functional languages(Scheme/Eiffel/etc), because I have heard that they have a lot to offer, but I would not go that route, at least at first.  They are just now getting semi-wide recognition as something that might be useful outside academia.  You will probably not find any game dev houses (or any kind of business) using functional languages for the near future.  IMO they are something you look at after you get the more common imperative programming down to widen your knowledge and understanding.

C# has a Linux implentation(mono), and it's a ECMA standard so conceivably someone could port it to any platform.  In practice Linux is the only one so far, so it's certainly not as platform-agnotic as Java, but it's no longer single-platform either.

The garbage collector (IMO) is pretty good.  I don't know how it compares to Java (not knowing how Java's works), but it is optimized for speed, and you would have to be pretty smart to write a better one given the caliber of people who worked on the .NET one.  It's nondeterministic, meaning it can collect at any time, but it will generally not do so unless there is memory pressure.  There are also several "generations" whereby longer-lived objects are less often evaluated for collection, since they are statistically less likely to need to be collected.  When it runs, it compacts the managed heap so that new allocations are really fast - just involves moving a pointer and returning the new object's memory address.  It's considered bad style to force a collection, as the GC is almost always a better judge than the programmer of when it's a good time.

Also all C# apps run as native code, and don't run in a VM as such.  When you load a .NET exe, it goes out and loads the .NET runtime in-process and uses that to JIT-compile what is effectively bytecode.  From that point it's all native code.  C# does abstract a fair amount of stuff though, and that always introduces code bloat.  On the other hand, C/C++ can be dangerous in inexperienced hands.  Pointer bugs are probably the #1 cause of crashes and memory leaks.  With C#/Java you gain safety in that area, but almost certainly lose some performance.

One interesting project to check out is the Axiom engine (http://axiomengine.sourceforge.net/wiki/index.php/Main_Page (http://axiomengine.sourceforge.net/wiki/index.php/Main_Page)).  It's a C# port of an open source C++ graphics engine, Ogre (http://www.ogre3d.org/ (http://www.ogre3d.org/)). I have not looked at it in a while, but in my limited poking around with it, it seemed fairly fast.

I know that I sound like an MS shill, but I am actually pretty neutral in that area..  .NET is just what I happen to know best.  For the record I am no fan VB6 and for that matter, most of MS's older products. .NET is the first one they got right IMO.

I have seen two schools of thought on whether to tackle higher or lower languages first.  One school says to learn a high level language first (C#/Java/VB), get the basics of programming down and have some nice success experiences so you don't get burnt out or frustrated.  The other says to start with C or even assembly, move up to C++, then into higher level languages.  This is the harder route but you will end up understanding everything that the higher level languages are hiding from you, leaving you much better equipped to troubleshoot when the abstractions break down.  I guess it depends on your personality, free time and level of dedication.

Yes they do. The whole point of .NET is that it's "managed" code (Microsoft's term) meaning programs run inside the .NET VM (CLR in .NET-speak). Yes the bytecode (MSIL in .NET) does get compiled down to native code but that code is always running within the CLR. That's where the memory management and other services come from.

I'm aware of that, but the VM model of Java and the runtime model of .NET are different.  Java apps run inside a VM, but .NET the VM (CLR) is inside the app.  The code doesn't run within the CLR, the CLR is just in-process providing the services you mention.

I guess that explains why whenever I forget to turn off managed extensions in new Visual Studio projects, my app takes five seconds to start up before it executes any of my code.

Yep.  There are ways to pre-compile (ngen it's called) it but under .NET 1.x they are not recommended.  Under 2.0 the situation is better but there are still some optimizations the JIT compiler can do that you lose out on when you pre-compile.

No that's not right otherwise why would there be a PInvoke function? Using your model, .NET applcations could call out to Win32 APIs whenever they felt like without needing something like PInvoke. There would also be no security enforcement since .NET applications could simply bypass the CLR security services. And finally people wouldn't be talking about .NET performance issues since there would be no difference in performance. .NET apps run *inside* the CLR -- that's just way it is. If you don't want to call it a VM that's fine, I don't care, but it's not the same as running a compiled non-.NET application.

Let me quote the ECMA spec for the CLI (Common Language Infrastructure):

I think we might be saying the same thing, springing from my lack of knowledge about the Java VM.

Where I work we open a .NET windows forms screen from a legacy app.  It doesn't start a separate process, just loads the CLR into the existing app's process.  Can Java do that?  I'm not being rhetorical, I really don't know.

.NET exes and DLLs are just like any other exe or dll - they have an entry point, preferred load address etc.  The only difference is that when they are started, the first thing they do is go get the CLR and load it in.  Any calls for system resources are handled by the CLR - this is where the security, memory management, etc. comes into play.

As I understand the Java VM, the VM is the main process and the java class just runs inside it.  The Java classes aren't self sufficient in that they don't know how to load the VM - the VM loads them.  Also AFAIK the Java VM can't be loaded into another process to run a Java class in-process.  Is that correct?

I'm not sure that we are. You seem to be hung up on the "boostrapping" differences between .NET and Java and that those bootstrapping differences mean that the .NET runtime model is somehow different than Java's.

Again I don't see how matters to how the runtime model works. The CLR is still what is loading the .NET CLI code and the CLI code is still running *inside* the CLR. In any event, you can do the same with the JVM -- it's what a Java plug-in for a browser does (check and see, you won't see a new JVM process appear as a standalone process) and there are other ways of "embedding" the JVM into an app such as using JNI.

The reason .NET exes can "bootstrap" themselves is because Microsoft installs special "runtime hosts" when you install .NET. A .NET exe points its entry point to the shell runtime host mscoree.dll (installed by .NET) which knows how to launch the CLR which then handles the rest of the loading process (actually I believe newer ".NET-aware" versions of Windows don't use mscoree.dll since they can identify .NET exes directly). So the CLI code doesn't actually load the CLR, it's mscoree.dll and basically Microsoft is using the exe entry point as a "hack" so the user isn't aware of any difference between a .NET application and a non-.NET one (other than you need to have the .NET Framework installed).

Sun, for obvious cross-platform reasons, didn't feel like creating additional OS specific loading hacks for Java though there are 3rd party tools that will do that for you (i.e. create a .exe you can double-click to run your Java application).

This is no different in .NET. As I said above the CLI code doesn't know how to load the CLR -- it's the mscoree.dll wrapper on Windows or another one of the Windows-specific runtime hosts (there's one for IE and one for ASP.NET in addition to the shell runtime host) that handles that process.

As I said earlier that's not correct.

I think we are.  I was probably just unclear.  You seem hung up on telling me that the code runs in the context of the CLR or VM, which every you prefer, which I don't dispute.

I'll be one to say that the "patronizing engineer" who says that the right language depends on the task is correct.  For this to be true, you can't define games as programs with the goal of displaying the maximum number of pixels or polygons on the screen at once.  There are some pretty significant differences between Java and C++ (security, type safety, garbage collection, portability, reflection, etc.) that can make it a good choice IF you know that the technical requirements of your project can be met (also the latest Java releases compile much more efficient byte code -- although game API's are still somewhat lacking).  If you want to create a web game using the framework with the greatest %'age of support among web surfers then you are looking at using Flash 7.0.  If you want to expand your horizons as a programmer and don't care if you get a game out of it, then Scheme, Haskell or ML are all great.

Regarding CS education, the goal of many programs is NOT to teach directly applicable skills but rather to teach you the general skills that will allow you to quickly learn any applied skills you need.  If you come out of school only knowing Scheme, but you can pick up other languages in a short time, then you're a much more valuable commodity than someone who learned all the latest but only knows how to write the programs that they had assignments on and can't extrapolate to anything new.  I came out of grad school into a job in gaming that involved all kinds of stuff that I didn't know (hadn't programmed in the language much, never for that platform, etc.).  But in the end it's all just a matter of problem-solving and ability to pick up skills on the fly.  Within 2 months I had a beta of my first published game and the majority of that code made it into the release version.  My school program was pretty freeform.  I took a data structurs course in C++ to start off with -- with the expectation that I knew C++.  Then I took a lot of general courses where we used C++ or we learned another language on the fly.  During the latter part of my study they started bringing Java into the curriculum more and I had to pick that up for a few courses.  In the two programming language courses I took I learned a couple functional languages and some other weird languages that I never looked at again.  I ended up using functional programming a lot in grad school and I highly recommend learning some Haskell, Scheme or ML just for the experience.  Now as a game programmer I use the stuff I learned in my math courses a LOT.  Probably as much as I use the stuff from the CS courses I took.  At first I was using a lot of trig, calculus and physics.  Recently I've been using a lot of game theory, graph theory and probability.  If you want to program games you really can't get around learning a lot of math.

Personally, if I'm the only programmer on a project or the programmers are all working on very compartmentalized components, then I lilke to program in C.  When I want something like inheritance, interfaces, first-class functions, etc., then I'll write it myself using function pointers.  I'm most comfortable with lots of control and a smaller API.  If I have to work closely with other people, however, then I find a more verbose language is better.  For this I prefer Java or C++.  C++ if performance is the biggest issue and Java if debugging and ease of maintenance is the biggest issue.  I am comfortable doing all my memory handling on my own, for example, but I'll gladly defer the responsibility if performance isn't an issue.  No matter how good a programmer you are, bugs happen.

the intro to CS class I took last year as a freshman was Java, i think thats pretty much standard these days... although the intro to CS class in high school was C++

I'd say C++ is the way to go right now. Sure, someday we may all be singing the wonders of C#(it is rad), but if you want to work with today's engines you need to know C++. Hell, even if you get into C# you're going to want to write the more performance intensive bits in C++.

I'm going to reinforce the points made back in May and say that programming language isn't as important as the game design.  It's a common misconception that you can start programming and a game will assemble itself.  I mean, you could, but it's going to be an ugly trial and error process as you delete tons of lines of code that you realized later are entirely unneccessary.  This is how far my education in dabbling with programming games myself has taken me.

I've determined that what I really need to do is first come up with the game concept, then iron it out until I can play every little nuance in my head (or on paper if it won't fit comfortably in my head).  At this point, I'll have a rough idea of if what I've assembled is fun.  Then I can go through the process of teaching the computer how to do that.  There's where programming comes in, and it's an entirely different step.

I don't have as much experience with programming languages as some of the other posters here, but from what I gathered C++ is the closest to machine level as you want to get.  If your game demands extremel processor power, then C++ is a given.  Of course, you don't write the whole thing from scatch, you get access to libraries where most of the code is written for you and frankenstein something together from there.  Assuming you never have to deal with assembly language, your choice of programming languages just gets higher level if you pass on C++, meaning easier to use but less powerful/flexible:

Hovering around the highest level is Virtual Basic.  I've found it a fabulous language for putting together Windows applications in short order.  It blew me away that you can just pull buttons and menus and whatnot right into a template and VB's API does most of the work - this little app (http://www.donaldhawthorne.name/grieflink/Other/DDO%20Roll%20Avger.exe) took me about 10-30 minutes (incidentally, it's typically bad form to run .exes from strangers you meet on forums).    The downside (aside from it being an interpretted language and therefore a little slower) is that VB is for making Windows applications, don't expect it to be an easy task if you decide that you want Macintosh users (without Windows installed), Linux users, or Consoles (where it seems most of the gaming community is going) to be able to play your games.  Latest versions include Object Oriented functionality, which is damn nice once you get used to it.

If you want something even easier than that, there's always Neverwinter Nights.  It's not neccessary a bad idea to start out with something easy.  For most of us, walking before you run is a neccessity to overcome willpower blocks.  Before you know it, you'll be an EA code slave.  Erm... yeah, there's such a thing as too much willpower too little foresight as well.

Depends on what your definition of "best" is… …not to sound Clintonian or anything…

Depends on what your desired platform and graphics framework/platform… …in most contemporary cases, it means C++… …though many, including myself,  consider C++ to be an abomination…

Depends on the type of game you are planning to build… …is it going to be a state of the art 3-D graphical gem with realistic rendering and physics adherence? Or is it an abstract strategy game where its always important to craft a professional display, but not imperative to grind every bit of efficiency for sake of performance? Then maybe Java (which sucks even more than C++ IMV…) or Basic or C# will fill the bill. Or maybe the user can run it from a web browser… …5-10 years ago that would seem laughable, but browser UI continues to evolve and while a full fledged animated offering is an impossibility, technology today can be harnessed to create a nifty strategy game. Or it runs server side and you can write a custom client to use instead of a browser. Or  maybe jump on the Flash bandwagon.

My druthers… …something like Ruby or Python the performance critical pieces written in C…

VB may be MS centric, but there exists RealBasic (http://www.realsoftware.com/), originally created for Mac software development but it  (professional edition) capable of creating cross platform binaries that run on Mac, Linux, or Windows and you can develop on any of those platforms.

Just throwing this out because I'm psyched. Don't know if this will be applicable to game development per se.

www.turboexplorer.com (http://www.turboexplorer.com)

Can't wait to get Turbo Delphi and pick up where I left off ten years ago.

And check out the 'Developer Tool Time' video on the site. One of the best parodies I've ever seen.