Part of this confusion seems to be that a few people are assuming a monolithic and single-language system.

A game engine need not be in a single language.

Good engines rely on many different languages.

Thinking back over the decades of good engines I've used, the simplest engine remember was for the Nintendo DS, and it 'only' used six languages that I'm aware of. The major EA engine I work with today has no less than 15 languages, probably more if I dig deeper. They range through hardware-specific assembly and C and C++ and C# and Lua and perl and python and shader scripts and even a handful of custom languages for particle systems and audio control.

Looking at engines like Unity you see that it also isn't one language. Java, Objective C, C++, JavaScript, shaders, C# through mono, assembly language for many platforms, direct support for content from Maya and 3D Sudio, as well as Flash, Photoshop, and Fireworks. They don't limit themselves to just what is easy to do in C++.


Engines are non-trivial. Portions will be written in C++. Portions will be written in assembler. Portions will be written in shader languages. Portions will be written in scripting languages. Portions will be written in <<insert language or tool here>>.

When something is best suited for any language, no matter if the language is assembly or c++ or c# or lua or python, if that is the best language for the component then you should build that component in that language.

For the portion of the engine that needs c++, I strongly recommend it. If you go back through the thread you'll see I always have. For the portion of the engine that needs gameplay programming I recommend languages other than c++; it is not the language's strong suit.

When you need a hammer or saw or lathe or drill, use the correct tool. If you need systems code or bare-metal code or shader code or scripting code, use the correct tool. A game engine needs many parts. It would be foolish indeed to limit yourself to only a hammer when building a sports car. Learn to be comfortable with ALL the tools, or at least know when your favorite tool is the wrong one.

Oh boy here come the flames.

Look, just make your project in C#. When you find something particularly important is running too slowly, there is a way to write it in C++ and call it from your code. It'll run as fast as you want it to run.

I'm betting /you/ will be slower with C++ than with C# in both productivity and program execution.
You want to get it working and then look for where you need improvement and improve. Eventually you'll hit a wall with C# (maybe), at which point you can move over to C++ and have it fast enough to get the job done. There's always room for improvement, so stop worrying about it lol.


C++ does exactly what you say. You can shoot yourself in the foot.
C# makes reasonable assumptions and files the paperwork for you so you don't have to. Maybe you don't need it filed in triplicate, but a well established protocol works even when you're not thinking hard about how you want to deal with a situation. If you need triplicate, its there. If not, no worries. C++ only files in triplicate when you tell it to, and is willing to blindly do as you say. If you mess up it's on you. That is how it saves time. By not double checking all of your instructions.

That, and they've been at improving it for a really long time.

[quote name='frob' timestamp='1356928477' post='5015962']
Good engines rely on many different languages.
[/quote]

Sorry, but this is just plain wrong. Many different languages don't equal quality.

While there are many engines that are written in more than one language it's not necessary a good thing.

(I'm not counting scripting support into this, because scripting is often part of the game and the engine is only providing the possibility to script the game or game objects.)

Also you have to differentiate a bit more. E.g. having a library or engine that has multiple language bindings is a complete different thing than having an engine that's written in a dozen of different languages. Having many different bindings is something good, especially if the engine should be licensed to other developers. Having an engine written in many languages sounds like a horror story.

Again we are talking about the engine itself. I'm not saying that it's a bad thing to write your tools in something for appropriate (e.g. use C# for the tools and C++ for the engine itself). However if every tool is written in another language it's not a sign of high quality.

[quote name='frob' timestamp='1356928477' post='5015962']
Thinking back over the decades of good engines I've used, the simplest engine remember was for the Nintendo DS, and it 'only' used six languages that I'm aware of. The major EA engine I work with today has no less than 15 languages, probably more if I dig deeper. They range through hardware-specific assembly and C and C++ and C# and Lua and perl and python and shader scripts and even a handful of custom languages for particle systems and audio control.
[/quote]

They don't use it because someone thought "hey great let us use as many languages as possible in our engine". Most of the time it grew historically and it's hard to impossible to get rid of it. Sometimes you have to add another language, for example to support a new platform or make use of a new library, however I'm pretty sure no experienced developer will make such a decision lightly.

And the many different tools and scripts all in different scripting languages is a sign of lack of direction. Obviously nobody decided to use only one scripting languages.

Or even worse imagine this scenario:

1. In the beginning somebody choose perl as scripting languages, because he knew it already or he heard something about it.
2. A few years later you decide to switch to python, because you can find more developers that also know python and in generally it seems like a nicer language or whatever. However you don't have the time to make a complete transition to python, because not all your developers are as fluent as they need to be for that. Besides your developers don't have the time to rewrite all the tools. So some modules are rewritten but most of them stay perl.
3. Lua comes along and somebody made the decision to use it as main scripting language in the game. It's nicer for the artists and level designer and the developers do like it too. Great since you are already using Lua in-game, why not also for the tools? So without much hesitation your team decides to switch to Lua for tool development. Now most of your developers need some time to get familiar with Lua, they also have their usual tasks to do so again yo can't completly rewrite everything in the new language.
4. You've got yourself a ten year old code base with 3 different languages (just for the tools). Whenever there is something to change on the older modules you need to find the perl or python guy. Since some of the tools are so old and complex, everybody is just saying "never change a running system" and nobody is touching the old code. If your last perl guy leaves you won't replace the perl tools, no developers will start writing tools in Lua or whatever you currently use just to integrate the old tools. "No, you need to run the converter script to make it work with tool X, when you're finished you need to run it again to make it work with our other stuff!"
5. Of course everybody that reads this knows, a rewrite would be the best thing to do or better forget all about it and start from scratch. However if your studio can't afford it you need to make it somehow work. It gets worse every year and each project is getting more difficult, takes longer and gets more expensive. Maybe some day your studio does a complete rewrite, maybe they decide to license an engine from another developer. Or maybe your studio is slowly fading away into oblivion, like many before you.

Multi-language projects have many downsides, for example:

• They are a maintenance hell. At my place of work (not game related) we have projects with Tcl, C++, Visual Basic, C# in one project (some modules stand on they own). It's just bad, I can't see any good about it.
• Developers need to be fluent in many languages. This is especialy difficult if you have some rarely used, old or esoteric languages. Especially since some parts of the engine aren't tuched for a while and the developers aren't as familiar with it as with a piece of code they work regulary with.
• New developers will need longer to get a grasp of the engine code.
• It's harder to hire new developers, especially if you want them to have expierience with all of the used languages.
• If somebody is developing a module in a different language than all the other modules you should take a close look. Is it neccessary or is he trying to make himself unfireable. If he is just trying to use arcane knowledge to make it hard for everybode else to maintain that module, he/she should be let go as soon as possible.
• Each additional language means the development environment gets more complex. Not something you wish to achive.

[quote name='Hodgman' timestamp='1356961267' post='5016050']
Personally, I'd include all of the above inside the category of what "the engine" is made up of (not just the engine's runtime library itself).
[/quote]

That's where our opinions are different (which is not a bad thing).

I wouldn't count the following as part of the engine. Sure they are connected, but not part of the runtime.

• Shaders - many provide some predefined shaders. But I believe shaders should be part of the game. Else all games use the same lighting style and materials it gets boring. Handwritten shaders often look more unique and can do so much more than shader that have been generated can. Besides aren't shaders assets?
• Scripting - yes, provide the possibility for scripting, but I wouldn't put scripts in the engine.
• The whole pipeline - Texture-, normal map-, lightmap-, mipmap-baking is all part of the tools. It's not shipped with the game and not part of the engine. It's part of the eco-system that engine developers provide to make it easy to use the engine. Most of the time the tools even work without the engine as well as the other way around.
• Build tools - you wouldn't count Visual Studio as part of a game engine would you? Or cmd.exe. Just because somebody decides to replace either it's not magically becoming a part of the game engine. Would you count make as part of a piece of software that is developed with the gcc toolchain?
• Web tools - see whole pipeline/build tools and I wouldn't count any other way to provide a pretty Gui for a simple tool.
• Exporters - for Photoshop, gimp, 3ds max, blender, ... they are tools just as before, besides there are other ways (use standard formats).
• The game - choose whatever language you wish to write the game. Provide multiple language bindings to use the engine. The game just is not part of the engine. Anyway if you go down that road, microsoft should start to claim that any piece of software written for windows is also a part of windows (well in some philosophical way it could be). Of course it's always possible to write a game without engine, which makes the engine somewhat a part of the game...
• Libraries - If you use a third party library or API, for example OpenGL, the Windows API or any other library the library is not part of the engine. It's a dependency. I wouldn't count the languages used inside the library as part of the engine. Besides you can't always be certain what language it was written in.
• Data definition languages or data in general - One of the points where we need to clarify which languages we mean. If we start counting not human readable data languages, we could include every binary file format that an engine supports. Besides the whole point only applies if you're using a data driven architecture, else it's just data and not part of the engine. Most data is part of the game anyway... so I would count this as assets.

Good engines rely on many different languages.

Sorry, but this is just plain wrong. Many different languages don't equal quality.

One could certainly do everything in one language, but that would be foolish. A good craftsman uses the right tool for the job. Insofar, using several languages in some way does equal quality (that assumes one doesn't just use many languages for using many languages!).

I am probably one of the biggest C++ fanboys, but I would never consider even for a minute writing part of a toolchain in C++. Why? Because C++ sucks ass for that.

Python, Ruby, PHP, take your pick. One line to read a whole file into an array, a dozen lines with 2-3 regex to do the whole magic, 2-3 lines to dump the binary stuff to disk. Two lines to read and parse an XML file, a dozen more to walk through it. Pipe to/from an external command... 1 line. Make a HTTP request or database query or similar... 1 line.

Do that kind of thing in C++ and you need half a dozen of libraries and will waste a week on writing something that (maybe, if you're lucky) does the same thing in three seconds instead of two, and that's a nightmare to maintain. It will take quite a few runs to amortize that week of development time. Every time you change something, you spend half a day on it again.

Level Editor? Written in 1/3 the time using C#, and they work quite OK. Could they be 20% "better" in C++? Probably, but who cares. They're functional, and they're not so slow that it takes away productivity. Spend your time on something different.

Then there's scripting, of course. Scripting (Angelscript in my case) is what usually runs not only the GUI, but almost the entire program. Unless of course you don't care about that kind of thing. How would I do that in C++?

So, you really don't have to make up something to get 4-5 different languages (and that's not counting domain specific languages like SQL or XML or JSON that you implicitly use too).

This is way off-topic for this forum now.