Jump to content
  • Advertisement
Sign in to follow this  
brightknight

C++ can c++ be used as a scripting language

This topic is 873 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I know different scripting languages have their benefits, i was just wondering if it was  possible to use c++ as a scripting language, like having your game engine code and gameplay code both using c++ but still be separated enough that the gameplay code wont directly affect the engine code. What would be the benefits of doing this? What would be the disadvantages?

Share this post


Link to post
Share on other sites
Advertisement

Thanks for the reply, I think I'm gonna try this out, My team for now is just two guys both of us are pretty good at c++, Also if you have any tips, or anything of the sort that you think should know please don't refrain from replying.

Share this post


Link to post
Share on other sites

Ive done this employing C's macro mechanism to simplify what 'Script'  has to be written (used for behavioral control of simple intelligent objects) .

 

It is also useful for  structured scripts  (like the start/end/else state constructs of Finite State machines)  ... not just individual function calls  (several of the AI Game Programming Wisdom books had several articles about  macros  doing that including, hierarchical finite state machines)

 

Advantage is that a routine/repetitive pattern of code (which sometimes are rather bulky) can be reduced to much simpler 'script form'   and an assumption of the script features being used in a systematic way (eliminating nesting/spaghetti code  hell).    The macro Script restricts what variables and calls can be accessed through the 'Script'

 

Another is that specialize code can be created/customized by just adding another 'macro' to your 'language'  (and if when needed you can still insert actual NATIVE code in (hopefully few) trouble spots to get done exactly what you want/need)

 

The C preprocessor then converts your simpler macro Script into native code now subject to the compilers optimizing abilities and can run directly without interpretor overhead (including eliminating subroutine calls)

 

 

Disadvantage : is some extra difficulty debugging where the 'script' produced code is mutated 

 

-

 

Some people may say 'why bother optimize' , but when you are running thousands of active/reactive objects of this level of complexity EVERY Turn,  the optimization can spell a great difference in the size of the players game environment

 

---

 

 

One thing that added a little difficulty was   : that my  'nice' grouping of  Script Code   created for each different object typewere (in my usage) run in different sections of the program, even though the 'Script' has their chunks defined  right next to each other (instead of breaking them up onto separate files, and the bother/confusion/disorganization that entails, and you seek to eliminate).

 

So its good  learning how to use   #define  #ifdef  etc...   to modalized the script text  so that by using multiple #include of the same file (each employing a different  #define  'mode' for a different place in the program)  

 

 

 

example  (a LOCKSTEP behavior processing for active/reactive object on a grid map which use finite state machines)

 

Situation detection  phase - all objects Scan and detect a number of stimulus to potentially react to (from their current local situation) and filter/prioritize them according to the objects mode  (with  potential interrupts for 'tactics' already in progress)

 

Solution Classification phase - all objects digest their 'stimulus'  set,  decided ONE best  action/tactic initiation (avoiding conflicting actions with other objects already busy interacting - which could change since previous phase)

 

Action Processing - carry out all decided actions (including animations) and generate results (resolve conflicts),  and adjust the game situation 

 

-

 

The above runs a simulation in a lockstep manner, so the separate phase  chunks of code for each object type (even though grouped together in the script file)   get placed in the corresponding 'phase' section of the program whose basic organization was 'the Big Switch'  (nested)    (My program used three phases, but the chunk split-up still happens if there are only two phases required by a lockstep simulation)

Edited by wodinoneeye

Share this post


Link to post
Share on other sites

Ive done this employing C's macro mechanism to simplify what 'Script'  has to be written (used for behavioral control of simple intelligent objects) .

[...]

 

I don't really use #define, #ifdef that much but seeing as it could be useful I guess I could start looking into that, THANKS for the answer it was very informative and helpful.
?Also quick question is there a difference between a finite state machine and a state machine or do they both mean the same thing

Share this post


Link to post
Share on other sites

It is certainly possible, and being done (I do it myself). There is a nice in-depth description of yet someone else using C++ for scripting on the molecular web site.

 

The obvious problem about using C++ as a scripting language is that it is not a scripting language.

 

Scripting languages suck because they are so slow, blah blah. But they also have some very noticeable advantages (some of these are more obvious, some are less obvious but nonetheless important). For example, a scripting language exposes to the script writer exactly what you want it to expose, and nothing else. It enforces that you do exactly as allowed, nothing else. An invalid script should never result in an application crash or undefined state, either.

 

C++ does not do things like bounds checking, and it allows you to dereference any valid or invalid pointer, reading from or writing to any address. You can in principle call any OS function, including one that modifies files on the harddisk, opens a process handle, or... a network socket.

 

Which means that user-modifiable scripts are always in some way troublesome. A badly written user script may cause a crash (which you can catch in a handler, see the molecular article), but it might also mess up some random state in a non-obvious way without causing a crash. It might deliberately change state, allowing a player to cheat. It might allow someone to publish a "mod" that has a somewhat nicer window layout and uses your game to host a botnet. It might let someone write a ransomware mod on top of your game. Imagine the PR nightmare linked to "your game encrypted my harddisk and demands money". You will never recover from that one.

 

If scripts reside on a user-controlled computer, it is a valid consideration to remove the feature before shipping, and instead compile all scripts to native code right into the application (or into signed binary modules). Of course that approach isn't without problems either. Among other things, it means that what user and developer have in their hands is no longer 100% identical... It is thus unlikely but possible that the user experiences a bug that the developer cannot reproduce.

 

I'm only using C++ as server-side scripting language. User-side, no thank you, I do not like to open Pandora's box. Never know what comes out of it. On a server, however, it gives me fast iteration, the ability to modify behaviour at runtime, and native speed.

Share this post


Link to post
Share on other sites

I know different scripting languages have their benefits, i was just wondering if it was  possible to use c++ as a scripting language, like having your game engine code and gameplay code both using c++ but still be separated enough that the gameplay code wont directly affect the engine code. What would be the benefits of doing this? What would be the disadvantages?

 

Generally you could take every coding language into a scripting language when providing the runtime for it to be interpreted on. Scripting languages are different from coding languages in that way that they dont run on hardware directly but inside of some kind of VM that has its own processor interpreting the specific bytecode generated from source.

The benefits of scripting over hardcoded assemblies is simply the exchangability and stop n go you would getting hard to work in compiled platform specific programs.

 

But I would not recommend to use C/C++ or C# as scripting language because of the strict data model where in LUA or JavaScript for example data types were less strictly managed. Also the memory model of C/C++ is to different for a real scripting language and if you dismiss well established procedures like new/delete or malloc/free then you have something that may look like if it were C/C++ but didnt handle as that

Share this post


Link to post
Share on other sites
Ok from what ive gathered so far it is possible to use any language as a scripting language, some easier than others, but the issue with using system programming languages like c++ is that, because of it's low level access users could use c++ to create different forms of malware, hacks etc. Also I have come to understand that if you want your game to be moddable use of traditional scripting languages might be a good idea ..... One question couldn't one script in c++ then expose the necessary functions and variables to a scripting language in case someone wants to mod thegame or would that be too much work for nothing

Share this post


Link to post
Share on other sites

One question couldn't one script in c++ then expose the necessary functions and variables to a scripting language in case someone wants to mod thegame or would that be too much work for nothing

 

This is how scripting languages in games work. You have your LUA runtime for example and expose C++ functions to it when initializing the runtime so LUA could interact with your game. Ohterwise it wouldnt be possible because the LUA runtime (as I mentioned scripting languages are executed in there own runtime) wouldnt know about what functions it may call in your C++ game.

 

Same is true when you take a look at Unity. They have an own C# assembly called UnityEngine that contains callbacks into the C++ engine side. Your "compiled" game then is running inside the Unity Player application in its own mono runtime

Share this post


Link to post
Share on other sites

If scripts reside on a user-controlled computer, it is a valid consideration to remove the feature before shipping, and instead compile all scripts to native code right into the application (or into signed binary modules). Of course that approach isn't without problems either. Among other things, it means that what user and developer have in their hands is no longer 100% identical... It is thus unlikely but possible that the user experiences a bug that the developer cannot reproduce.

 

In Molecule, the scripts are always compiled to native code.

In a development build, each script is compiled into a single shared library for hot-reloading, fast iteration times, etc.

In a retail build, all scripts are compiled into the game executable, so the builds that go through QA are also what ends up in the user's hands - 100% identical.

 

There recently was a similar question on the Handmade Hero forums where my engine was also mentioned, and I provided a bit more info over there for anybody who's interested.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!