Advertisement Jump to content
Sign in to follow this  
blueskies9041

Scripting! What to script/what to not script?

This topic is 1756 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

So I'm finally getting this whole scripting thing to work for my assignment ( Python binding to C++ ).

 

So my question is, in a situation where you were using scripting to develop a game, what would you script and what would you code in C++? So far I know I obviously will have to have C++ handle my draw (openGL) calls, but besides that, I feel like things like sprite classes and game logic could be developed in either language fairly easily.

Share this post


Link to post
Share on other sites
Advertisement


So my question is, in a situation where you were using scripting to develop a game, what would you script and what would you code in C++? So far I know I obviously will have to have C++ handle my draw (openGL) calls, but besides that, I feel like things like sprite classes and game logic could be developed in either language fairly easily.

 

Some people prefer to code nearly the entire game in script, others only script unique events. Personally, I would:

 

Script:

 

- All types of controller - player, camera, AI...

- Events, dialoges, cutscenes (some visual scripting language is still a huge plus here)

- Specific behaviour of single game objects

 

Code:

 

- All graphical algorithms. I quess your game is 2D based on you mentioning sprites, but you know, you *could* even script-bind your opengl-drawcalls... I wouldn't recommend it.

- Things that are performance-critical. Yeah, you can program things like A*-paththinding and core AI in script, but I would rather do those things in code than script.

- Everythings thats a "core" aspect of your game, and is largely reusable. Notice, this is merely my opinion, but I really think it is better to write stuff like gui, input, physics etc in code, and add script binding where you need it. For me, scripting is best used, as I mentioned, to handle very specific behaviour where otherwise you would end up creating a new class for each and every game object. Everything that is largely reusable and easy to reuse (like, almost all your game entities will need some sort of physics interaction so you can easily hardcode this, as a basic example).

Share this post


Link to post
Share on other sites

It's a balance between flexibility and performance.  Tasks handled in code will perform better, but be more difficult to change.  Tasks handled in the scripts will be easier to change, but run slower.  So the key is to put only the stuff you're likely to change frequently in the scripts, and the stuff that's going to change infrequently in C++.  Unfortunately, you basically need a crystal ball to determine which is which prior to writing the code.  Hindsight will only be useful for your next game.

Share this post


Link to post
Share on other sites

I have found that the decision is much more of an art rather than a science.  As has been mentioned, you can script pretty much everything, but it doesn't mean that you necessarily should.  The only reason that I would script something is to make it so I can iterate on it faster - by eliminating a compilation cycle you really do get to do more work than if you hadn't scripted anything.

 

On the other hand, it takes some effort to create the bindings and verify that they work properly.  So there is a cost associated with each system that you allow to be scripted.  The decision on what is worth scripting and what isn't is really dependent on your project and your team more than anything else...

 

So to recap, script the things that will need to be tweaked frequently!

Share this post


Link to post
Share on other sites

Could you also say that the question is, what should I make data driven?

Then the way you provide the data might be scripts or any data you'd be able to deliver to the game, from any tools, editors etc.

(giving you flexibility)

Edited by cozzie

Share this post


Link to post
Share on other sites

To further add to what has been already done, the difference between scripting and regular C++ is even more fuzzy if you start to consider using runtime C++ compilation and execution, for example using CLANG.

 

Long story short: you can create scripts in C++. It has the advantage of having great performance while still having allowing for quick iterative changes (you don't need to recompile the game to test).

 

More info: http://runtimecompiledcplusplus.blogspot.co.uk/2011/06/source-code-now-live.html

Share this post


Link to post
Share on other sites

To further add to what has been already done, the difference between scripting and regular C++ is even more fuzzy if you start to consider using runtime C++ compilation and execution, for example using CLANG.

 

Long story short: you can create scripts in C++. It has the advantage of having great performance while still having allowing for quick iterative changes (you don't need to recompile the game to test).

 

More info: http://runtimecompiledcplusplus.blogspot.co.uk/2011/06/source-code-now-live.html

Doesn't this still require compilation though?  It doesn't require you to restart your application, but the C++ code is still compiled, right?  I could see that as being a nice feature so that you don't have to restart an app just to change some small functionality.  That's an interesting use case...

Share this post


Link to post
Share on other sites


Doesn't this still require compilation though?  It doesn't require you to restart your application, but the C++ code is still compiled, right?  I could see that as being a nice feature so that you don't have to restart an app just to change some small functionality.  That's an interesting use case...
That's no different than Lua for a lot of people though. It's common to recompile the source into byte code upon reloading any changes.

 

What's really interesting with the runtime C++ stuff though is that Unreal Engine 4 has actually gone down that path. They killed off UnrealScript, and instead added support for runtime C++ compilation.

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!