The old wisdom that interpreted languages are far slower than compiled code is no longer automatically true. Lua JIT has a reputation of being the fastest of other JIT using languages, with performance superior to C# and sometimes even coming close to C++.
There are also other factors to consider. While it's nice that languages like C offer you the ability to explicitly define where and how the memory is allocated, allowing the programmer to utilize his knowledge of the specific platform to achieve exceptional performance, modern languages like Lua or Java has garbage collectors that automatically free all unreferenced allocated memory, preventing the occurrence of memory leaks that plague so many C programs.
It's true that it's usually best to licence an existing engine, because one can hardly beat the optimization expertise of their developers, but it is possible that none of the available engines offered features that NS2 developers needed, leaving development of a proprietary engine as the only choice.
While the result so far does not compare all that favorably to existing games of similar scale and graphics, the developers can be hardly criticized for choosing Lua, as it is widely used among game developers.
He was referring (I presume) to the ability to make changes in code and observe the results immediately. Interpreted languages like Lua let you do this, compiled languages like C# do not.
This can dramatically affect the efficiency of your development workflow, which in turn can dramatically improve the quality of your code and the time it takes to deliver a project.
By way of analogy - imagine making a digital painting, but rather than seeing what you were drawing, you had to draw blindly on your tablet and then wait a few minutes to see the results of your brushstrokes. Programming is a lot like that.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited March 2013
If I could give you 5 awesomes ,Kamamura, i would. Most accurate post in here.
Just to clear some things up in this familiar thread:
Spark is written in C+.
Natural selection 2 is technically a mod, written in LUA, sitting ontop of the Spark engine.
Meaning all of the game logic is done in LUA, but the engine it runs on, such as it's rendering and networking etc, is all C+.
Plenty of games use LUA for scripting purposes, including recent ones like Crysis 3.
Just from past posts I can tell you that LUA was decided on for NS2 due to multiple factors, but mostly due to the restraint of a small staffed indie studio developing an engine from scratch for a game aiming to meet modern day PC gaming expectations.
These restraints meant they needed something with: full control, (source had many restrictions that would have impeded their game designs) something that has fast iteration and implementation, and something that was modding friendly since they themselves came from a mod. LUA fit this criteria.
As for the performance topic: Like Kamamura mentioned, much more can still be gained. See these LUA to LUAJIT comparisons.
While I cant speak to what's coming in the future without violating NDA, I can tell you that all the programmers on staff are currently focusing on optimization, as of this moment. :-D
While I cant speak to what's coming in the future without violating NDA, I can tell you that all the programmers on staff are currently focusing on optimization, as of this moment. :-D
See these LUA to LUAJIT comparisons.
While I cant speak to what's coming in the future without violating NDA, I can tell you that all the programmers on staff are currently focusing on optimization, as of this moment. :-D
The old wisdom that interpreted languages are far slower than compiled code is no longer automatically true. Lua JIT has a reputation of being the fastest of other JIT using languages, with performance superior to C# and sometimes even coming close to C++.
But NS2 stopped using LUAJIT because of issues right? Unless there's a plan to re integrate it? ;;)
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
Luajit is a complicated thing. If it could increase performance is an open question. I would not expect too much for any development in that area that might or might not happen, but it is certainly an interesting idea worth exploring. Ns2 did use luajit at some point by the way(long time ago).
The old wisdom that interpreted languages are far
There are also other factors to consider. While it's nice that languages like C offer you the ability to explicitly define where and how the memory is allocated, allowing the programmer to utilize his knowledge of the specific platform to achieve exceptional performance, modern languages like Lua or Java has garbage collectors that automatically free all unreferenced allocated memory, preventing the occurrence of memory leaks that plague so many C programs.
This is a common misconception.
Garbage collectors can still have memory leaks. The most common method is reference counting, which works right up until memory is circularly referenced. Schemes that try and account for circularly referenced memory, generally have a lot of overhead. At this point one of the biggest thing that keeps languages like java and C# slower than C++ is the garbage collector constantly looking over your shoulder.
lots more detail here: http://stackoverflow.com/questions/10577534/can-you-have-memory-leaks-with-a-garbage-collector
Generally speaking, there is no way to avoid memory management. It is a fundamental programming skill, and garbage collectors can only save you from the most simplistic memory allocation bugs. No matter what you do, when you start working on complex programming projects, you need to think about memory management, when things get allocated, and when things will be released.
Garbage collection is nice, but it is frequently waved about as a cure-all for memory related issues, and as an excuse for poorly architected code. They pretty much only save you from mistakes you'll stop making after you've been coding professionally for a year or two.
Also please don't imply that C is some how not a 'modern' language.
To clarify for those reading this thread after it was closed - Steve was referring to the fact that we agree that Lua game code leaves room for performance improvements, not that it should not have been used.
Several armchair-generals in this thread imply that Natural Selection 2's use of Lua is a liability. Without Lua, or other scripting language, NS2 would not exist. The idea that a tiny team could write a game of NS2's complexity in C++ or other low-level language is utterly fanciful. To do such a thing would require a huge budget. Even games that do have huge budgets still write their game code in scripting languages such as Lua because it is simply much more efficient than trying to iterate complex interdependent systems in a low-level language.
Not having to worry about memory management or crashing are just two of the huge benefits that Lua brings to game code. That is to say nothing of the immense modding capabilities that Spark possesses' courtesy of its use of Lua. As usual, if something sounds too good to be true, it usually us. E.g. "UWE could just rewrite NS2 in C++ and make it faster."
Translation: "UWE could spend years rewriting NS2 in C++, go bankrupt, produce code that may run faster, but crashes constantly and is impossible to iterate on without hiring an army of programmers." You could certainly say goodbye to balance patches.
Comments
There are also other factors to consider. While it's nice that languages like C offer you the ability to explicitly define where and how the memory is allocated, allowing the programmer to utilize his knowledge of the specific platform to achieve exceptional performance, modern languages like Lua or Java has garbage collectors that automatically free all unreferenced allocated memory, preventing the occurrence of memory leaks that plague so many C programs.
It's true that it's usually best to licence an existing engine, because one can hardly beat the optimization expertise of their developers, but it is possible that none of the available engines offered features that NS2 developers needed, leaving development of a proprietary engine as the only choice.
While the result so far does not compare all that favorably to existing games of similar scale and graphics, the developers can be hardly criticized for choosing Lua, as it is widely used among game developers.
Not really, you can do the same in unity with c#. That's mainly shader code anyway.
This can dramatically affect the efficiency of your development workflow, which in turn can dramatically improve the quality of your code and the time it takes to deliver a project.
By way of analogy - imagine making a digital painting, but rather than seeing what you were drawing, you had to draw blindly on your tablet and then wait a few minutes to see the results of your brushstrokes. Programming is a lot like that.
Just to clear some things up in this familiar thread:
Spark is written in C+.
Natural selection 2 is technically a mod, written in LUA, sitting ontop of the Spark engine.
Meaning all of the game logic is done in LUA, but the engine it runs on, such as it's rendering and networking etc, is all C+.
Plenty of games use LUA for scripting purposes, including recent ones like Crysis 3.
Just from past posts I can tell you that LUA was decided on for NS2 due to multiple factors, but mostly due to the restraint of a small staffed indie studio developing an engine from scratch for a game aiming to meet modern day PC gaming expectations.
These restraints meant they needed something with: full control, (source had many restrictions that would have impeded their game designs) something that has fast iteration and implementation, and something that was modding friendly since they themselves came from a mod. LUA fit this criteria.
As for the performance topic: Like Kamamura mentioned, much more can still be gained. See these LUA to LUAJIT comparisons.
While I cant speak to what's coming in the future without violating NDA, I can tell you that all the programmers on staff are currently focusing on optimization, as of this moment. :-D
Most. Exciting. Post. Ever.!
But NS2 stopped using LUAJIT because of issues right? Unless there's a plan to re integrate it? ;;)
it doesn't seem like the spark rendering is very optimized
like ideally you should be able to lower some settings and get boosts to framerate... but no can do
Ambient Occlusion
Shadows
Everything else is minimal.
This is a common misconception.
Garbage collectors can still have memory leaks. The most common method is reference counting, which works right up until memory is circularly referenced. Schemes that try and account for circularly referenced memory, generally have a lot of overhead. At this point one of the biggest thing that keeps languages like java and C# slower than C++ is the garbage collector constantly looking over your shoulder.
lots more detail here:
http://stackoverflow.com/questions/10577534/can-you-have-memory-leaks-with-a-garbage-collector
Generally speaking, there is no way to avoid memory management. It is a fundamental programming skill, and garbage collectors can only save you from the most simplistic memory allocation bugs. No matter what you do, when you start working on complex programming projects, you need to think about memory management, when things get allocated, and when things will be released.
Garbage collection is nice, but it is frequently waved about as a cure-all for memory related issues, and as an excuse for poorly architected code. They pretty much only save you from mistakes you'll stop making after you've been coding professionally for a year or two.
Also please don't imply that C is some how not a 'modern' language.
**closing topic**
Several armchair-generals in this thread imply that Natural Selection 2's use of Lua is a liability. Without Lua, or other scripting language, NS2 would not exist. The idea that a tiny team could write a game of NS2's complexity in C++ or other low-level language is utterly fanciful. To do such a thing would require a huge budget. Even games that do have huge budgets still write their game code in scripting languages such as Lua because it is simply much more efficient than trying to iterate complex interdependent systems in a low-level language.
Not having to worry about memory management or crashing are just two of the huge benefits that Lua brings to game code. That is to say nothing of the immense modding capabilities that Spark possesses' courtesy of its use of Lua. As usual, if something sounds too good to be true, it usually us. E.g. "UWE could just rewrite NS2 in C++ and make it faster."
Translation: "UWE could spend years rewriting NS2 in C++, go bankrupt, produce code that may run faster, but crashes constantly and is impossible to iterate on without hiring an army of programmers." You could certainly say goodbye to balance patches.