What thing can script language do for game engine development. Game engine core ,not game logic, especially about data-driven.
e.g.
Data driven render pipeline require a file to describe how to draw a frame, is there any advantage a script language can bring ?
Data driven render pipeline require a file to describe how to draw a frameThat's an exact example from Stingray :)
The advantage is the same as with gameplay code. You can iterate these kinds of engine features faster (e.g. code reloading), and high level modifications to the engine structure can be made very easily without having to wade through C++ code.
On every single game I've worked on, the team has always made significant changes to the engine, because every game has different requirements from a game engine (there is no "one size fits all" game engine). Stingray is attempting to deal with this by writing engine modules in C++, and then configuring them / "plugging them together" in Lua, to make an engine that can be used for many different kinds of games without the need to rewrite any C++ code.
If you only use it to configure the structure, then not really whatsoever... The initialization of engine modules may be 2x slower, but their normal frame-to-frame operations would run the same.
If you use some Lua code every frame, then yes, that code might run 2x slower than native code, which is why you only write the "high level" logic in Lua. Any algorithm that has to loop 10000x will be written in C, and then controlled at a high level from Lua.
Scripting Languages could be pretty usefull if you have to solve expressions at runtime.
E.g. do queries with Lua-Jit can optimize the necessary code to the current hardware and more important to the specific query.
If you have a use-case with many conditions it's also helpfull to use a jitted scripting language which can switch the cases but with branch prediction in modern cpu this advantage is less effective.
The description of render passes, render targets, which objects have to be called in which pass and so on can be done with pure data.
If a scripting language can provide a superior solution is hard to tell because it depends on some factors like how often you change the pipeline or how complex the code is to process and execute the data.
On top you have the useability.
I worked with data driven render engines but only protyped a script based render engine and my impression was that the work is not worth it.
It took a lot of work to implement the scriptable renderer and performance wise there was no difference.
As already mentioned by Hodgman a really good example of data driven rendering is Stingray but you will find detailed slides by the old name Bitsquid.
Microsoft wrote a c++ jit to build optimized database queries for Bing and they extract this knowledge and code into a open source standalone library.
Which is pretty usefull if you do gamelogic with data only.
Beside of performance you have the usability which is pretty important if you don't work on a tiny project.
If you have a huge code base then it will take a while to compile it and then you start to put the parts which frequently change into data files or allow to use scripts.
data-driven is good for user, not for engine developer.
i make my engine as a data-driven one mainly for easily test post processing, and scene_pass can be picked
by engine, not by render item itself .. though I have only implemented depth-only pass for shadow , water_reflection_pass for water face.
But hard to say what scene_pass i'll make, need constantly learn and test, so i desire data-driven.
Hopefully the small data-driven is enough.
If requirement is clear, data-driven would be easy-implement, and worthy to make one. But always change
render architecture will make data-driven a f u c k i n g thing.
