Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Scripting! What to script/what to not script?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 blueskies9041   Members   -  Reputation: 138

Like
0Likes
Like

Posted 25 March 2014 - 01:01 PM

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.



Sponsor:

#2 Faelenor   Members   -  Reputation: 396

Like
-1Likes
Like

Posted 25 March 2014 - 01:23 PM

Usually, the game engine is in C++ and all the game specific stuff is scripted (especially the AI).



#3 Juliean   GDNet+   -  Reputation: 2694

Like
0Likes
Like

Posted 25 March 2014 - 01:30 PM


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



#4 jHaskell   Members   -  Reputation: 1053

Like
0Likes
Like

Posted 25 March 2014 - 03:36 PM

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.



#5 Hodgman   Moderators   -  Reputation: 31121

Like
7Likes
Like

Posted 25 March 2014 - 04:42 PM

Scripting *is* programming.
The reason you add support for a language like Python to your C++ game, is because you think it's a better language (more productive for you to code in), so you'd rather be using it.
That is all.

At my last job, we wrote our games entirely in Lua by default, using C++ only when necessary, which for us, usually meant when the game was no longer running at 30 frames per second.
We were making a game for consoles, which have slow CPUs, but have multiple cores to make up for it. We'd run our Lua code on one core, then run multi-threaded C++ code on the rest. Things where you're doing the same process over and over again on a large number of objects are easy to optimize in this way (by rewriting the original Lua as multi-threaded C++), which includes animation, rendering (e.g. culling), physics and AI, so large parts of those systems ended up being (re)written in C++ after often first being prototyped in Lua.

#6 Jason Z   Crossbones+   -  Reputation: 5163

Like
3Likes
Like

Posted 25 March 2014 - 08:13 PM

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!



#7 cozzie   Members   -  Reputation: 1657

Like
0Likes
Like

Posted 26 March 2014 - 04:00 PM

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, 26 March 2014 - 04:01 PM.


#8 Javier Meseguer de Paz   Members   -  Reputation: 371

Like
2Likes
Like

Posted 26 March 2014 - 06:39 PM

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


“We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil” -  Donald E. Knuth, Structured Programming with go to Statements

 

"First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Ken Beck, Twitter


#9 Jason Z   Crossbones+   -  Reputation: 5163

Like
0Likes
Like

Posted 26 March 2014 - 07:09 PM

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



#10 Hodgman   Moderators   -  Reputation: 31121

Like
4Likes
Like

Posted 26 March 2014 - 07:20 PM


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.



#11 Krohm   Crossbones+   -  Reputation: 3183

Like
0Likes
Like

Posted 27 March 2014 - 01:30 AM

Due to my code being used across a few different projects, I ended up rewriting a lot of it. I eventually insulated the stable code and ended up with some quite extensive scripting (due to historical reasons, the script is proprietary).

For a lot of games, you could get away scripting nothing. Yes, I wrote script nothing. Fact is you should first go through data-oriented design first and then add scripting to manage all those cases where data alone does not cut it. To do this effectively, keep in mind what you want to accomplish.

 

Say for example we want to make a breakout clone. Do we want to use scripting? For first iteration sure not. We build levels using pure data.

Do we need scripting in a breakout clone? Maybe to design a new powerup? Or for a new enemy?

New enemies from breakout does not seem to be so complex to require scripting to me. For powerups, it might be useful to script them since they're often very varied in effects but due to their limited number maybe we might still want to make them code.

 

The very important thing is to not think in a vacuum. Always think in your context first and in the near-to-mid term future then.



#12 LancerSolurus   Members   -  Reputation: 612

Like
0Likes
Like

Posted 27 March 2014 - 01:46 AM

In my case I usually only add in scripting support once it reaches a certain level of complexity. For tool programs, rarely do they get any scripting unless I need customized options to be stored and reloaded (I can use the registry for that until it hits a certain level), For games, definitely since I prefer to have the game logic and data separate, this makes adding a new planet, asteroid field, starship, system, GUI window, trader and etc. trivial with no recompile required. Change the script and relaunch the program. I don't use Lua, I use my own custom parser but the functionality is nearly the same. It really depends on the size of the project though....


******************************************************************************************
Youtube Channel





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS