what is meant by Gameplay?

Started by
34 comments, last by Norman Barrows 7 years, 11 months ago

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.

Then I see no reason why you shouldnt just use C++ for all your code. And if you really need to be able to edit the code without re-compiling, you can consider this project:

https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus/wiki

thanks!!!!

Advertisement

But in my defense I wasn't trying to say it beats c++ every time I was saying it is "POSSIBLE" for a scriptinglanguage to outperform c++.

But its not possible, not even once, in a fair fight -- with the deck stacked against it, with poor C++ programming, with improper or incomplete library use, sure you can come up with micro-benchmarks that show C++ at a disadvantage -- but there are lies, damn lies, and statistics, right?. Doing the same work in C or C++ will always be as fast or faster than essentially any language, "real" or script. You might, though, have to do some work that's not readily available in the language or in common libraries, and if a technique is readily available in another language that yields more performance per effort-unit, then that's a point in favor of that language -- however, that's a productivity argument, not a performance argument.

And productivity is a damn fine argument for a scripting language. A much better argument than performance, frankly -- which is the point I've been driving at the whole time.

throw table_exception("(? ???)? ? ???");

But in my defense I wasn't trying to say it beats c++ every time I was saying it is "POSSIBLE" for a scriptinglanguage to outperform c++.


But its not possible, not even once, in a fair fight -- with the deck stacked against it, with poor C++ programming, with improper or incomplete library use, sure you can come up with micro-benchmarks that show C++ at a disadvantage -- but there are lies, damn lies, and statistics, right?. Doing the same work in C or C++ will always be as fast or faster than essentially any language, "real" or script. You might, though, have to do some work that's not readily available in the language or in common libraries, and if a technique is readily available in another language that yields more performance per effort-unit, then that's a point in favor of that language -- however, that's a productivity argument, not a performance argument.

And productivity is a damn fine argument for a scripting language. A much better argument than performance, frankly -- which is the point I've been driving at the whole time.

Okay then I agree with you, you seem to be pretty sure and more experienced than me.

edit//
?i was just using skookumscript as an example language against c++ because of the time slicing ability it has, someone saw a performance increase by switching from c++ to skookumscript and thats where i got the idea that it is possible for a scripting language to outperform c++ under some circumstances,
Edit//
Also note my goal with starting to say these things about performance wasn't because the main features of the language skookumscript are the performance or that that is a viable reason to use the language I was trying to answer someones curiosity by stating what I thought to be facts.

Also thank you from stopping me from spreading any more I hate saying false but not completely true statements anywhere else. If I didn'tlike learning from my mistakes what am I a programmer for???

No hard feelings,

No offense intended, I hope I was able to stride the line between persistent and badgering :)

We're all learning here, not one of us has all the answers. Plus, the answers might change tomorrow -- generally not, but still frequently enough that "fact" becomes assumption before too long, and we should all treat our knowledge as if it has an expiration date -- you know, pop the lid and see if anything smells funny.

As someone who sounds to be a little earlier on the path than some of us, its easy to run across stale information that was very possibly correct 5 years ago (or half-truths, untruths, or unstated subtleties) that are very difficult to spot for what they are without the deeper well of experience you'll develop over time. Given some years, it becomes easier to spot these kinds of shortcomings in information sources. I think most of us who benefit from having that well still can't just tell exactly what's wrong with something all the time, probably half the time or more you'll just get a sense of something not sounding right, and that you should dig in deeper before accepting, rejecting, or modifying your understanding of what you've read. Its a good life-skill in general, and a good skill for an engineer of any kind, but especially for disciplines that move very quickly, like software.

throw table_exception("(? ???)? ? ???");

No offense intended, I hope I was able to stride the line between persistent and badgering :)

We're all learning here, not one of us has all the answers. Plus, the answers might change tomorrow -- generally not, but still frequently enough that "fact" becomes assumption before too long, and we should all treat our knowledge as if it has an expiration date -- you know, pop the lid and see if anything smells funny.

As someone who sounds to be a little earlier on the path than some of us, its easy to run across stale information that was very possibly correct 5 years ago (or half-truths, untruths, or unstated subtleties) that are very difficult to spot for what they are without the deeper well of experience you'll develop over time. Given some years, it becomes easier to spot these kinds of shortcomings in information sources. I think most of us who benefit from having that well still can't just tell exactly what's wrong with something all the time, probably half the time or more you'll just get a sense of something not sounding right, and that you should dig in deeper before accepting, rejecting, or modifying your understanding of what you've read. Its a good life-skill in general, and a good skill for an engineer of any kind, but especially for disciplines that move very quickly, like software.

yeah i was never offended when "arguing" with you, also you are right about me being early the "righteous path to becoming a better programmer" haha, I will take your advice of double checking my information twice to make sure its true. Im just happy that this thread that i started is now marked with the "HOT" logo on the list of game programming forum posts.

?One thing i hate about being a self taught programmer is i always feel like there is something i dont know, and i wouldnt be able to simply search it up because i dont know what im looking for : (, now im basically just trying to get into this whole algorithm thing which is something i hadn't even considered looking into before. I was satisfied with "Well it works... sorta",

?But thats one thing i like about programing unlike some other professions there is always something new to learn, and right now that new thing for me are the various algorithms

>> someone saw a performance increase by switching from c++ to skookumscript

well of course you'll run faster if you no longer do all the work every update, and instead do just a time slice of it.

but c/c++ can do that too - and do it faster.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

This topic is closed to new replies.

Advertisement