I tend to use different languages for different tasks. Python is nice for small modules that can be edited while the game is running, and I've used it in one of my MMOs for things like the ability system, object interactions, and various rules-based stuff. Other games have used Python for stuff like UI (largely because you can easily modify it while the game is running, and allow users to easily extend it) and parts of their AI (for basically the same reasons). It's generally quick for a scripting language, isn't a memory hog, and is easy to use within C++ programs. Other than that, at home, I've pretty much kept all game code in C++, and tools in whatever seems easiest for the task (which is usually perl, C, C++,
occasionally C#, or a bash script).
Everyone in my current studio has had to deal with *iprobablyshouldn'tnamethis*Script, however, which has basically all of the possible disadvantages of a scripting language and none of the advantages - not even compile time, since a lot of changes require a C++ recompile of most of the project. And carries with it giant overhead on
all game objects used with the engine and garbage collection of death that adds 60ms to the frame time every few minutes. So they are kinda downers on using any scripting for anything, client or server. Also, actionscript for the UI, since the UI is Flash, but that is slow as the circus and we tend to migrate the code to C++ for performance reasons (generally at least 15x speed difference, often a lot more) once we're past prototyping a given widget. So basically everything at work is C++. It would require some C/C++ work at minimum to interface with the PS3 APIs regardless, even if we had a decently fast PS3 compiler for something else (GCC isn't terribly good at optimizing for PS3), and pretty much all big studio games are C++ because basically all experienced game programmers use C++, and studios want to hire experienced people. Also, all the big engines and libraries we use tend to be C or C++.
For anything other than Big Studio Projects though, most any language works ok, as long as the performance and compatibility issues with it are acceptable to you for the game and you can handle the overall complexity in that language (games are pretty complicated beasties). Even a garbage collected language is fine if your game loop is quick enough or dropping a frame here and there is irrelevant - in Dwarf Fortress, that kind of thing wouldn't be noticeable, though the performance penalty from using any scripting language would be pretty rough. In a shmup, the last thing you want to do is suddenly drop a frame here and there (serious shmup players hate that), but as long as you can push out a frame every 33ms, it doesn't matter if you could have got it to 27ms by using a language with less overhead (assuming the traditional shmup game loop design, which I call "What is this time thing you speak of?").
Edit: Oh, I have no experience with FP, so I can't comment on how useful it is for games. I can say that I've used approximately 0 non-C libraries in C++ game development (At home and college, at least. Not true of licensed stuff at work, but most of that I would never use by choice anyway.) that aren't for things typically built in to more modern languages or have equivalents in most languages (standard containers, <functional>, <algorithm>, etc), as most important libraries have C interfaces anyway. Any hard to track memory overhead tends to be a killer for low memory console development but on PC it just depends. I keep thinking I should take a look at FP, but I feel like I need a good block of time for it, and right before E3 blocks of time are hard to find.
Author
Topic: What programming language? (Read 17902 times)