There is a lot of systems-level work. Usually these are part of the game engine, whatever engine you are using.

When you are working with game objects and their behavior, typically this is considered "gameplay programming", separate from "engine programming".

If you are using an engine like Unreal or Unity, the code you write is gameplay code.

If you are writing your own systems anything that can be reused among all games, such as math code or animation code or physics code or file loading code, those are all engine related. Code relating to your own objects that is specific to that one game is gameplay code.

They are probably talking about stuff like powerups and interactions.

So your different health, ammo, whatever containers are done as a script as performance is not an issue and a scripting language allows you to iterate faster.

There is a lot of systems-level work. Usually these are part of the game engine, whatever engine you are using.

When you are working with game objects and their behavior, typically this is considered "gameplay programming", separate from "engine programming".

If you are using an engine like Unreal or Unity, the code you write is gameplay code.

If you are writing your own systems anything that can be reused among all games, such as math code or animation code or physics code or file loading code, those are all engine related. Code relating to your own objects that is specific to that one game is gameplay code.

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.

For what its worth, usually when scripting languages -- even compiled ones -- make claims of being as-fast or faster than C or C++ or whatever language they might typically be embedded into its usually dubious. They compare features that the scripting language has meticulously optimized for against naive implementations in the language they're comparing against, or they're comparing library functions that might be used in similar situations in either language but that do wildly-different amounts or kinds of work underneath. 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; its uncommon even for a scripting language to match a "real" language in performance under these conditions. That goes doubly so when the language they're comparing to is a "bare-metal" language like C, C++, Rust, or others.

I'm not correcting this misconception as an academic argument. I'm correcting it because its common to fall for the siren-song of performance when selecting a scripting language. While it may be sometimes convenient that you gain the flexibility of choosing to implement a particular bit of performance-intensive code in your scripting language (either because it saves dropping into a harder-to-use language, or because it avoids crossing run-time/marshaling boundaries), it is most often a better idea to implement that functionality in the language of your engine and expose it to scripts as a service. Thus, if you overvalue this ability in a scripting solution, you might be compelled to give up ground in features that are far more important in a scripting language, such as productivity, ease-of-integration, how widely used it is, or whether its programming model supports the kinds of interactions you need to model in your game-play without creating a lot of that infrastructure yourself.

TL;DR; Performance is rarely a noteworthy consideration for things you should consider scripting to begin with. If you've chosen a scripting language with performance as your primary concern, you've probably traded away more worthwhile features to get it.

i always hear people saying scripting languages are leaps and bounds easier to use so thats actually one of the reasons i want to know what is meant by gameplay because im a fairly new programmer (started about 6 months ago learning c++), i am much more comfortable in c++ but i have no issues in learning a new language e.g skookumscript if it will help in the long run. i guess i will look beyond performance and see what features that different scripting languages bring to the table and see where they could fit into my workflow