Sign in to follow this  
brightknight

what is meant by Gameplay?

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.


Thank you, that helps clarify that. A little bit better

Share this post


Link to post
Share on other sites

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.


Okay so gameplay code == any code revolving around game objects and such
Engine code == usually reusable stuff like physics, calculations and animation stuff

Share this post


Link to post
Share on other sites
I'm using ue4 with skookumscript plugin. Skookumscript is a compiled scripting language made for video games. It has much better perfomance than other scripting languages and in some special cases it can rival or outperform c++.
Here are a few links
Skookumscript.com

And here is a link to forum thread about it's performance
Forum.skookumscript.com/t/skookumscript-performance/

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

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.

May I suggest you read https://docs.python.org/3/tutorial/index.html It's a compact tutorial aimed at people that know programming. You'll pick up the language in a matter of hours.
Then code some stuff in it, file processing, batch-like scripts that are just too complicated to do in a shell. Code that manipulates lists, sets, and dictionaries (maps) are typically ridiculously trivial and fast to make.

When you have done that, you'll be in a position to make a comparison between writing C++ code and writing in a high level language like Python or Lua.
Lua is even simpler than Python, in my experience it's perhaps a bit too simple, but maybe the application that I work with has too much Lua for its own good :P Edited by Alberth

Share this post


Link to post
Share on other sites

 

 

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.

Share this post


Link to post
Share on other sites

>> 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?

 

In theory, if compiled, its possible, but only in as much as its possible for one "real" language to be faster/slower than another "real" language. In practice, certain real languages have performance advantages over others by virtue of language design decisions, rather than, say, library implementation details.

 

In practice, even scripting languages that are compiled -- and lets ignore byte-code compiled scripting languages, because those cannot beat a highly-developed "real" language -- to native machine code either have not, or cannot, implement certain kinds of deep optimization techniques -- either because they are too difficult, too costly in terms of compile-time, or are essentially impossible to achieve in a scripting solution that supports hot-loading of code or are not practical/possible to achieve across the run-time/marshalling boundary. Marshaling itself is another speedbump where the scripting language's primitive types are not the host-language's primitive types, and especially where neither language's primitive types are the machine's primitive types (think CLR or JVM primitive ints, who's guaranteed behavior under shifts bigger than the machine word is one thing (IIRC), but the equivalent machine operation differs on each of ARM, x86, and x64). Still more, I'm not aware of any scripting language that exposes things like explicit memory layout of structs to the programmer, which is essential in optimization techniques such as Data-Oriented Design, but systems programming languages do.

 

In all, practically speaking, no scripting language will ever surpass a systems-programming language like C or C++ or Rust -- if one did, it would mean that they had achieved a breakthrough in compiler technology (and C and C++ compilers are already state-of-the-art, so no small feat). On the other hand, there are slower, natively-compiled languages, like say Swift, which at least currently is maybe half the speed of C or C++, and its possible that a highly-developed, compiled (maybe even bytecode) scripting language could best that. On the other, other hand, I'd say that Swift ought to be (and will become) faster than it is today, and even highly-developed scripting languages are likely to hit a performance ceiling before any "real" language will.

Edited by Ravyne

Share this post


Link to post
Share on other sites

 

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.

Edited by Ravyne

Share this post


Link to post
Share on other sites

 

 

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

>> 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?


i dont know much about speed of programming languages and such but i know that the scripting language Skookumscript is on its own not faster than c++ but with some optimizations some certain tasks that are completed in "human time" basically meaning completed over a couple of frames, and dont have to be refreshed every tick can in theory perform 100 times better in skookumscript than c++. http://forum.skookumscript.com/t/skookumscript-performance/500

so it is possible for scripting languages to outperform real languages, but apart from some certain parts of certain languages real languages should always perform better

Edit//
Lemme clarify I now know that in an apples to apples comparison c++ will always best a scripting language in 2016 but some scripting languages have performance boosting features built in that have to be included in c++ libraries. So the effort to performance ratio might be better in a scripting language. And in an unfair comparison a scripting language can outperform c++ note Isaid unfair Edited by brightknight

Share this post


Link to post
Share on other sites

 

>> 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?

 

i dont know much about speed of programming languages and such but i know that the scripting language Skookumscript is on its own not faster than c++ but with some optimizations some certain tasks that are completed in "human time" basically meaning completed over a couple of frames, and dont have to be refreshed every tick can in theory perform 100 times better in skookumscript than c++.  http://forum.skookumscript.com/t/skookumscript-performance/500

 

so it is possible for scripting languages to outperform real languages, but apart from some certain parts of certain languages real languages should always perform better

 

You cannot speak about "speed of a language", it's a nonsense term.

A language expresses a description of how to solve a problem. It has no speed in itself.

 

Implementations of languages however can be compared for speed. I can compare visual studio with gcc, and decide which one is faster. I can compare C Python with Lua 5.3 (afaik there is only one implementation), and see which one is faster.

 

However you do this with 2 concrete implementations of the language(s), and for a concrete set of test-programs. Generalizing to all possible programs, or all possible implementations of a language is very hazardous to say the least.

Share this post


Link to post
Share on other sites

 

 

 

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.

 

This is the sort of thing i was looking for because right now my "Team" is just two people and both of us are pretty good at c++ and we dont have plans to have more programmers on our team so thats why i was wondering why not just use c++ for gameplay code. if you know that no inexperienced c++ programmer will be usinng it.
 

Share this post


Link to post
Share on other sites

 

 

>> 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?

 

i dont know much about speed of programming languages and such but i know that the scripting language Skookumscript is on its own not faster than c++ but with some optimizations some certain tasks that are completed in "human time" basically meaning completed over a couple of frames, and dont have to be refreshed every tick can in theory perform 100 times better in skookumscript than c++.  http://forum.skookumscript.com/t/skookumscript-performance/500

 

so it is possible for scripting languages to outperform real languages, but apart from some certain parts of certain languages real languages should always perform better

 

You cannot speak about "speed of a language", it's a nonsense term.

A language expresses a description of how to solve a problem. It has no speed in itself.

 

Implementations of languages however can be compared for speed. I can compare visual studio with gcc, and decide which one is faster. I can compare C Python with Lua 5.3 (afaik there is only one implementation), and see which one is faster.

 

However you do this with 2 concrete implementations of the language(s), and for a concrete set of test-programs. Generalizing to all possible programs, or all possible implementations of a language is very hazardous to say the least.

 

I wasnt trying to say that skookumscript is always faster than c++ or vice versa, i was merely stating or trying to say that it is possible for a scripting language to outperform a "real" programming language given the right situations/conditions. Also i dont know anything testing different languages  peformance in different compilers and IDEs i was just trying to Show the findings of another programmer when comparing performance between c++ and skookumscript. As the the guy i was talking to asked whether it was possible for a scripting language to outperform a "Real"  programming language

Share this post


Link to post
Share on other sites

 

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

 

There is no reason you _have_ to use a scripting language.

 

From my view, as a small scale developer with our own engine, I've always seen adding a scripting language as just unnecessary extra work and more stuff to maintain.

Our engine needs a proper C++ API anyhow, so why spend the extra work adding another API, which most likely will just be a subset of the engines true capabilities.

 

Also increases the work to add new features.

Plus you have an extra layer of code that can introduce bugs, while it also often makes debugging harder.

And when you try to push the boundaries of what the scripting language is capable of, it can get messy...

 

I imagine the cost-benefit will be better in a larger organisation where you have a lot of people that need to implement game specific stuff, and you also have a support organisation to keep the scripting language with enough features and debugging tools to be useful.

 

With just a few people, where everyone is part engine part game implementers, and everyone already know C++ well, there is little reason to use a scripting language.

Share this post


Link to post
Share on other sites

 

 

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

 

There is no reason you _have_ to use a scripting language.

 

From my view, as a small scale developer with our own engine, I've always seen adding a scripting language as just unnecessary extra work and more stuff to maintain.

Our engine needs a proper C++ API anyhow, so why spend the extra work adding another API, which most likely will just be a subset of the engines true capabilities.

 

Also increases the work to add new features.

Plus you have an extra layer of code that can introduce bugs, while it also often makes debugging harder.

And when you try to push the boundaries of what the scripting language is capable of, it can get messy...

 

I imagine the cost-benefit will be better in a larger organisation where you have a lot of people that need to implement game specific stuff, and you also have a support organisation to keep the scripting language with enough features and debugging tools to be useful.

 

With just a few people, where everyone is part engine part game implementers, and everyone already know C++ well, there is little reason to use a scripting language.

 

Thanks for the reply

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this