I would really like this answered as I've been wondering for a while..... Lots of different forums and such people say that scripting languages (lua c# java etc) are okay for gameplay while c++ should be used with performance critical code....... Anywaythe questions is what exactly do they mean by gameplay??? I feel like gameplay isn't a very specific thing, to a regular gamer gameplay could refer to the "feel" of the game. Does gameplay refer AI or what the player directly controls(e.g combat, movement, camera ...)?? Am I rightin the assumption that by gameplay they mostly mean NPC behaviour like scripting a boss battle.

"Gameplay" usually refers to the code and scripts that are specific to the game and is not normally a part of the "engine" code. This is more of a relevant distinction when you have multiple projects using the same engine.

As far as the separation between scripting languages and c++ for game code, I actually think that in many cases where something like LUA is being used you'd be better off using c++ (assuming that's your native code language) for your gameplay code. You really need to think about why you're choosing a scripting language over native code, and not just decide to use it because you think that's what you should do.

thats actually what led me to asking this question on gameplay as i was wondering why I cant just do it in c++ and not a scripting language

thats actually what led me to asking this question on gameplay as i was wondering why I cant just do it in c++ and not a scripting language

Typically because of who is doing the scripting, along with when and how they are doing it.

When writing the code in C++ it needs to be compiled. The C++ compilation model is excellent at optimizing and eliding code for high performance, but does so at a cost of long compile times. Depending on the project and the scope of the changes a compilation may take seconds, or a change that affects everything in a huge system could take hours.

Scripting languages are often (but not always) written in tools that can be edited and rebuilt while the main program is running. The script system is stopped, the changes implemented, and the script system restarted.

If you are working with main programmers who are spending all their time working on the code and constantly doing big compiles, working in C++ for object scripting may not be a big problem. Hopefully they'll use tools like Edit and Continue (an amazing piece of technology!) but they can do this type of thing readily.

If you are working with designers who rarely work with code, and who generally don't have the tools installed for doing big compiles, working in a scripting language like Lua is easier and faster. They can make the small change to the script, have it validated on the fly, and see the results immediately. This is good for productivity, especially when a change takes a few seconds to see rather than 10 minutes or more to see. This also enables people to make changes even if they don't have the heavyweight compilers and build systems on their computer.

You can use C++ if you want, it doesn't hurt anything when you are an individual working on a hobby project. When you are a professional working on a large team of hundreds of people for multiple years, using a scripting tool that can be dynamically reloaded can save work-years of time, meaning several hundred thousand dollars or even millions of dollars over the scope of the multi-year project.

thats actually what led me to asking this question on gameplay as i was wondering why I cant just do it in c++ and not a scripting language

I would really like this answered as I've been wondering for a while..... Lots of different forums and such people say that scripting languages (lua c# java etc) are okay for gameplay while c++ should be used with performance critical code....... Anywaythe questions is what exactly do they mean by gameplay??? I feel like gameplay isn't a very specific thing, to a regular gamer gameplay could refer to the "feel" of the game. Does gameplay refer AI or what the player directly controls(e.g combat, movement, camera ...)?? Am I rightin the assumption that by gameplay they mostly mean NPC behaviour like scripting a boss battle.

"Gameplay" usually refers to the code and scripts that are specific to the game and is not normally a part of the "engine" code. This is more of a relevant distinction when you have multiple projects using the same engine.

As far as the separation between scripting languages and c++ for game code, I actually think that in many cases where something like LUA is being used you'd be better off using c++ (assuming that's your native code language) for your gameplay code. You really need to think about why you're choosing a scripting language over native code, and not just decide to use it because you think that's what you should do.

thats actually what led me to asking this question on gameplay as i was wondering why I cant just do it in c++ and not a scripting language

It depends on things like who's going to be doing the scripting (a programmer or a designer with basic programming knowledge?), what languages do those people already know, and whether you want the ability to quickly prototype code in something "simpler" than your native code.

One thing to note is that people will often suggest using a language like LUA because you can more quickly write your game code/script. But, they forget the downsides such as 1) it's another language to support, 2) you now have a barrier between your game and engine code, 3) it's easier to write buggy code in LUA than it will be in C++ since LUA isnt compiled, 4) LUA is much slower than C++, 5) LUA code will be much harder to profile, debug, and optimize than your C++ code, and 6) for performance-critical code you'll often find yourself spending time later to re-write that LUA code to C++ code. None of these are trivial things.

thats actually what led me to asking this question on gameplay as i was wondering why I cant just do it in c++ and not a scripting language

You can but it costs you a 10 to 50 times more lines of code.

Not necessarily -- its true that many scripting languages are compact or have features (e.g. actor-model, prototypal inheritance model) that lend themselves to scripting game entities and game interactions, but that does not mean that writing gameplay code in C++ has to more difficult or more verbose for the people "scripting" the gameplay elements, albeit in C++.

If you were to use C++ for gameplay code, you might not take any special effort if yourself or the entire team is fluent in C++ (and the engine); if you have less-experienced people "scripting" gameplay through C++, then your goal as an engine programmer would be much like any other task -- provide an API, or indeed an embedded domain-specific language, that makes it easy for client code "scripts" to express high-level intent while encapsulating the low-level details away; In practice, this ends up being not much different than the work of integrating a scripting language with your engine, though you might be providing more of the cogs and widgets yourself. The payoff is that, done well, your "scripting" staff gets many of the productivity, expressivity, sandboxing, and hand-holding benefits that stand-alone scripting languages are known for.

Indeed. This is basically the argument I try to make when I hear that you cant use C++ because the people doing the scripting have limited knowledge of programming and using native code will be too hard or whatever. If you know that the scripters or gameplay programmers or whoever only need a subset of functionality, then the engine should provide them with the appropriate API for that purpose. You can even implement a runtime compiled C++ type solution if they really dont want to work with a compiler. It's entirely possible to get close to the simplicity of a scripting language without taking on any of the negatives associated with them. The problem with scripting languages is that people tend to focus on the front-end benefits and dont realize the magnitude of the back-end drawbacks.

One benefit of a scripting language or domain-specific language, is the hot-reloading for faster iteration - if you don't have features like Edit and Continue, run-time interpreted C++, or keep your gameplay logic in a DLL that you reload on the fly (which only partially mitigates the issue).

But another important benefit is being able to hot-reload server-side for server-side logic changes without having to restart your game servers (for ORPGs and the like). But that's not needed for every game.

Not necessarily -- its true that many scripting languages are compact or have features (e.g. actor-model, prototypal inheritance model) that lend themselves to scripting game entities and game interactions, but that does not mean that writing gameplay code in C++ has to more difficult or more verbose for the people "scripting" the gameplay elements, albeit in C++.

Many custom scripting languages are basically just stripped down C-syntax anyway. :)

>> As a rule, scripting languages don't surpass "real" programming languages when doing the same work and with both languages free to elect their own optimized solutions;

theoretically, they can't - can they?