The best programming language for games?

[Strazos]

I took QBasic and VB.

That's pretty much where I stopped.

[Roac]

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.   

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. 

[Soln]

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.

[Yoru]

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.

[Samwise]

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.

[Murgos]

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.

[Margalis]

Especially in 3D graphics.

[Murgos]

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.

[Stephen Zepp]

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!

[Jayce]

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.

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).  It's a C# port of an open source C++ graphics engine, Ogre (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.

[Trippy]

Also all C# apps run as native code, and don't run in a VM as such.

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.

[Jayce]

Also all C# apps run as native code, and don't run in a VM as such.

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.

[Samwise]

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.

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.

[Jayce]

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.

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.

[Trippy]

Also all C# apps run as native code, and don't run in a VM as such.

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.

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):

The Common Language Infrastructure (CLI) provides a specification for executable code and the execution environment (the Virtual Execution System) in which it runs.
[...]
The VES implements and enforces the CTS model. The VES is responsible for loading and running programs written for the CLI. It provides the services needed to execute managed code and data, using the metadata to connect separately generated modules together at runtime (late binding).

[Jayce]

.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.

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?

[Trippy]

.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.

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

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.

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.

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.

.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.

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).

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.

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.

 Also AFAIK the Java VM can't be loaded into another process to run a Java class in-process.  Is that correct?

As I said earlier that's not correct.

[Jayce]

.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.

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

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.

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.

[StGabe]

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.

[WindiaN]

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++

[Prospero]

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++.

[geldonyetich]

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 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.

[naum]

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, 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.

[raydeen]

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

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.