Rather than give you opinions on each language, I'll go through each one I've used and explain what task I've used them for and why I chose them.
Not everyone else will make the same sort of games as I do for the same platforms so this is fairly subjective but I hope it will provide some useful information.
Afterwards I'm going to go through a number of games I've worked on and break them down into which languages we used and why.
C++
C++ is still the language I use the most for general purpose programming. This is mainly because I still seem to be writing games using in-house engines or using games engines which are programmed using C++. We've always felt that C++ provides the best compromise between performance and usability which is why we still use it for most of our games. Also having over 20 years experience with C++ influences the decision.
C#
A few years ago I'd never used C# for anything but since Unity has become popular I find myself using it more and more. Besides Unity, I've also used it for cross-platform utilities, build tools as well as a bit of server programming. I really like C# and hopefully one day I will use it for writing all my games.
Lua
Lua is my scripting language of choice and has been for a number of years. Since it is so easy to integrate into a C++ based games engine, I've used it as the scripting language for most C++ based games I've worked on for the last few years. I've used Lua in about 4 commercial titles for scripting high level game logic and UI. I've always found that Lua have great performance when used properly and that people find it easy to learn due to its simplicity.
Lua is also the programming language we use to set up our build system, Metabuilder.
Objective C
I've used Objective C for iOS titles and I've tried to use it as little as possible. This isn't because I don't like (actually I love it!) but mainly because it isn't really portable and I'm usually writing multi-platform games. Typically I'll use it to interface with the iOS API for such things as Game Centre integration, iCloud saving etc.
Javascript
I've used Javascript for various random bits and pieces. Mainly for HTML5 coding and a bit of NodeJS.
Java
I never really wanted to learn Java as I've only heard bad things about it from other programmers. But with Android development I've found myself learning it bit by bit as I've tried to get my games working with the Android OS. I've used Java with Android in a similar way to how I've used Objective C with iOS - mainly for interfacing with the OS for multi-platform games.
Because of the specialised nature of geometry wars it was obvious from the start that our best option would be to write our own game engine. Our requirement was for a high performance, portable programming language. C++ was the obvious choice.
Lua: Individual level scripts
We wanted to give our level designers as much flexibility as possible when creating their levels. We'd used Lua before many times and knew from experience it would be the best choice.
We developed the game using Unity and for us C# was the best choice of the scripting languages Unity has to offer in terms of features and performance.
Objective C: Native plugin to access PSN
We had to access various 3rd party libraries and network services. This had to be done through Objective C so we wrote a Unity plugin using Objective C.
Most of the high level game logic was implemented using Unrealscript.
ActionScript: Puzzle Logic
The puzzles were developed in flash and then run in-game using Scaleform
C++: Engine customisations
C++ was used to make any changes to UE3 which were required to support the game.
We implemented a fairly typical driving simulation using C++ because we felt that it would give us the level of refinement required to develop the driving simulation we were aiming for. The driving simulation was very closely tied to the Bullet physics engine which we made several customisations to.
Lua: Event logic & in-game UI
Our game levels in 2K Drive were individually scripted driving challenges. We felt Lua would be the best language to script the challenges due to its simplicity and how easy it would be to integrate into our game engine.
Javascript: Magazine user interface
For the magazine part of 2K Drive we decided that we wanted it to look as much like a webpage as possible so we implemented using HTML5 using a web view in iOS.
Objective C: iOS integration, achievements, leaderboards
We only used Objective C where absolutely necessary to interact with iOS.
PHP: Server backend
There was a fairly significant server implementation required for 2K Drive. We decided to use PHP because it was popular, well documented and free. Part of our decision to use it was based on the availability of PHP programmers.
C#: Game database tool
We needed a database tool to set up our game data. We decided that it would be best to use C# to develop a cross-platform database tool that we could run both on PCs and Macs.
Travel bug was an early Vita game so C++ was the only really choice of programming language. It was a pretty simple game and a fairly straightforward task to implement.
Bloodstone was a fairly typical AAA in-house C++ engine developed game. We used a C++ game entity system for the game logic which meant all the game entities were coded using C++.
Lua: User interface
Our user interface system used Lua to script all the game screens and UI widgets.
We developed our own multi-platform game engine for The Club using C++. All the core game logic and entities were written using C++.
Lua: Level scripting & UI
We integrated Lua and provided an interface to our game engine that the level designers could use to script the logic for their levels. We used Lua because it provided the level designers with a lot of flexibility and freedom to try ideas.
This was our first C++ game engine. We wrote a fully OO game entity system where entities could be placed and configured using our game editor. All the game entities were written as C++ objects.
VU Assembler
Parts of the graphics engine was written in VU assembler for the PS2's vector units. The only way of programming the vector units was by hand-coded assembler and this was vital to get maximum performance out of the PS2.
Since the GBA had limited resources we wrote the game engine in some very tightly write C. We chose C over C++ because it produced simpler code and didn't encourage elaborate implementation techniques (e.g. full OO based entities) that the GBA's 30MHz CPU would have difficulty coping with.
ARM assembler: Low-level interrupt handler, fast maths routines.
Some of the more optimal code had to be written in assembler, also some of the interrupt routines needed to be written in assembler due to their low-level nature.
When we initially wrote Fur Fighters there was no C++ compiler available for the Dreamcast so we had to write all the game engine & logic in C. The game incorporated quite a few OO concepts so we had to work out ways of coding them in C rather than C++.
Objective C: iOS access to achievements & IAPs
When I ported the game to iOS (many years later!) I had to use objective C to interface with iOS for Game Centre integration.
SH4 Assembler: Inner graphics transform loop
The transform loop in the graphics engine was one of the most performance critical pieces of code in the game, it was originally written in C but we wrote an SH4 assembler version using some of the CPUs special features (SIMD & StoreQ) making it 3-4 times faster than the C version.
Nearly all of the game engine and game logic was written in C. The PS1 was the first console whose primary programming language was C. This was a new and exciting time allowing us to write far more complicated games than we'd ever done before.
R3000 Assembler: Vehicle dynamics (PS1)
We still needed every ounce of performance possible to simulate a full grid of F1 cars so the vehicle dynamics were written in R3000 assembler, also the vehicle dynamics coder was a little crazy and he liked that sort of thing!
Language Breakdowns
I thought it might be a good idea to breakdown some of the titles I've worked on into which programming languages were used and what they were used for. I'll also try and explain our thinking in using the various languages.Geometry Wars 3 - PS3, PS4, PSVita, XBox360, XBoxOne, PC, iOS
C++ : Game engine, main game logic & user interfaceBecause of the specialised nature of geometry wars it was obvious from the start that our best option would be to write our own game engine. Our requirement was for a high performance, portable programming language. C++ was the obvious choice.
Lua: Individual level scripts
We wanted to give our level designers as much flexibility as possible when creating their levels. We'd used Lua before many times and knew from experience it would be the best choice.
PSPets: Puppy Parlour - iOS (Unity)
C#: Game logicWe developed the game using Unity and for us C# was the best choice of the scripting languages Unity has to offer in terms of features and performance.
Objective C: Native plugin to access PSN
We had to access various 3rd party libraries and network services. This had to be done through Objective C so we wrote a Unity plugin using Objective C.
Jacob Jones - iOS,Android, PSVita (Unreal 3)
UnrealScript: Game LogicMost of the high level game logic was implemented using Unrealscript.
ActionScript: Puzzle Logic
The puzzles were developed in flash and then run in-game using Scaleform
C++: Engine customisations
C++ was used to make any changes to UE3 which were required to support the game.
2K Drive - iOS
C++: Game engine, vehicle simulation & physics.We implemented a fairly typical driving simulation using C++ because we felt that it would give us the level of refinement required to develop the driving simulation we were aiming for. The driving simulation was very closely tied to the Bullet physics engine which we made several customisations to.
Lua: Event logic & in-game UI
Our game levels in 2K Drive were individually scripted driving challenges. We felt Lua would be the best language to script the challenges due to its simplicity and how easy it would be to integrate into our game engine.
Javascript: Magazine user interface
For the magazine part of 2K Drive we decided that we wanted it to look as much like a webpage as possible so we implemented using HTML5 using a web view in iOS.
Objective C: iOS integration, achievements, leaderboards
We only used Objective C where absolutely necessary to interact with iOS.
PHP: Server backend
There was a fairly significant server implementation required for 2K Drive. We decided to use PHP because it was popular, well documented and free. Part of our decision to use it was based on the availability of PHP programmers.
C#: Game database tool
We needed a database tool to set up our game data. We decided that it would be best to use C# to develop a cross-platform database tool that we could run both on PCs and Macs.
Travel Bug - PSVita
C++: Game engine & logicTravel bug was an early Vita game so C++ was the only really choice of programming language. It was a pretty simple game and a fairly straightforward task to implement.
007 BloodStone - PS3, Xbox360, PC
C++: Game engine & logicBloodstone was a fairly typical AAA in-house C++ engine developed game. We used a C++ game entity system for the game logic which meant all the game entities were coded using C++.
Lua: User interface
Our user interface system used Lua to script all the game screens and UI widgets.
The Club - PS3, XBox360, PC
C++: Game engine & logicWe developed our own multi-platform game engine for The Club using C++. All the core game logic and entities were written using C++.
Lua: Level scripting & UI
We integrated Lua and provided an interface to our game engine that the level designers could use to script the logic for their levels. We used Lua because it provided the level designers with a lot of flexibility and freedom to try ideas.
Treasure Planet - PS2
C++: Game engine and game logicThis was our first C++ game engine. We wrote a fully OO game entity system where entities could be placed and configured using our game editor. All the game entities were written as C++ objects.
VU Assembler
Parts of the graphics engine was written in VU assembler for the PS2's vector units. The only way of programming the vector units was by hand-coded assembler and this was vital to get maximum performance out of the PS2.
Treasure Planet - GBA
C: Game engine & logicSince the GBA had limited resources we wrote the game engine in some very tightly write C. We chose C over C++ because it produced simpler code and didn't encourage elaborate implementation techniques (e.g. full OO based entities) that the GBA's 30MHz CPU would have difficulty coping with.
ARM assembler: Low-level interrupt handler, fast maths routines.
Some of the more optimal code had to be written in assembler, also some of the interrupt routines needed to be written in assembler due to their low-level nature.
Fur Fighters - Dreamcast, PC, PS2, iOS
C: Game engine & game logicWhen we initially wrote Fur Fighters there was no C++ compiler available for the Dreamcast so we had to write all the game engine & logic in C. The game incorporated quite a few OO concepts so we had to work out ways of coding them in C rather than C++.
Objective C: iOS access to achievements & IAPs
When I ported the game to iOS (many years later!) I had to use objective C to interface with iOS for Game Centre integration.
SH4 Assembler: Inner graphics transform loop
The transform loop in the graphics engine was one of the most performance critical pieces of code in the game, it was originally written in C but we wrote an SH4 assembler version using some of the CPUs special features (SIMD & StoreQ) making it 3-4 times faster than the C version.
Formula 1 - PS1, PC
C: Graphics engine, game logic & UI.Nearly all of the game engine and game logic was written in C. The PS1 was the first console whose primary programming language was C. This was a new and exciting time allowing us to write far more complicated games than we'd ever done before.
R3000 Assembler: Vehicle dynamics (PS1)
We still needed every ounce of performance possible to simulate a full grid of F1 cars so the vehicle dynamics were written in R3000 assembler, also the vehicle dynamics coder was a little crazy and he liked that sort of thing!
