Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualHodgman

Posted 31 December 2012 - 07:43 AM

Good engines rely on many different languages.

 
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.

Yeah, it depends on how you define things. I think it would be pretty common to see:
* a language for the engine
* a language for the game
* a language for the GPU-side components
* a language for the tool-chain
* a language for data definitions
* a language for build automation

Some of them might be the same language, and some of the dot points might be several languages.
e.g. For the above dot points, I use C/C++, C++/Lua, HLSL/Cg, C#/VB/Batch/JavaScript+HTML, Lua, CMake/Batch.
That's around 10 languages in a modern engine with no legacy code.
The engine is C++, but contains some C modules, which is fine because the two interop so well.
The engine is bound to Lua, so the game is written in a mixture of C++ and Lua, depending on which is more productive in that area.
The obvious choice for the GPU portions is a standard shading language -- HLSL is great, and Cg is almost the same syntax, which helps when porting HLSL code to GL.
The data-processing parts of the tool-chain are all C# because it's a good language to work with and is very capable. Many GUIs are JavaScript+HTML because they're designed to be remote "web" tools, that are just thin GUIs that connect to either a C# data-cruncher, or the C++ engine in the background. Extensions of our art tools are VB, because they support it for scripting. Microsoft Batch files are sometimes used as glue.
Human editable data files are written in Lua, instead of JSON/XML/et al. because Lua is already the engine's scripting language, and it's also a great, flexible DDL.

Instead of being tied to a specific IDE "project file" format, the code builds are controlled by CMake scripts, which is a simple imperative language, again with some Batch glue.

 

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


#1Hodgman

Posted 31 December 2012 - 07:41 AM

Good engines rely on many different languages.

 
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.

Yeah, it depends on how you define things. I think it would be pretty common to see:
* a language for the engine
* a language for the game
* a language for the GPU-side components
* a language for the tool-chain
* a language for data definitions
* a language for build automation

Some of them might be the same language, and some of the dot points might be several languages.
e.g. For the above dot points, I use C/C++, C++/Lua, HLSL/Cg, C#/VB/Batch/JavaScript+HTML, Lua, CMake/Batch.
That's around 10 languages in a modern engine with no legacy code.
The engine is C++, but contains some C modules, which is fine because the two interop so well.
The engine is bound to Lua, so the game is written in a mixture of C++ and Lua, depending on which is more productive in that area.
The obvious choice for the GPU portions is a standard shading language -- HLSL is great, and Cg is almost the same syntax, which helps when porting HLSL code to GL.
The data-processing parts of the tool-chain are all C# because it's a good language to work with and is very capable. Many GUIs are JavaScript+HTML because they're designed to be remote "web" tools, that are just thin GUIs that connect to either a C# data-cruncher, or the C++ engine in the background. Extensions of our art tools are VB, because they support it for scripting. Microsoft Batch files are sometimes used as glue.
Human editable data files are written in Lua, instead of JSON/XML/et al. because Lua is already the engine's scripting language, and it's also a great, flexible DDL.

Instead of being tied to a specific IDE "project file" format, the code builds are controlled by CMake scripts, which is a simple imperative language, again with some Batch glue.


PARTNERS