Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

In my current project, Lua scripts are called by the C++ functions on the server side. After that, the scripts again call the C++ functions still in that solution. Why should we do such things and not call the C++ function directly? What are the situations in which scripts are needed?

share|improve this question
add comment

6 Answers 6

Scripts are usually compiled at run time, while the host language will be compiled at compile time. This means that we don't need to recompile if the script changes. Recompiling a full game can take minutes to hours, which implies a big productivity hit.

Usually, the critical code or backend code will not be scripted. This code should run fast and often memory management is crucial.
In games, game logic and configuration are typically contained in script files. These scripts can easily be updated by non-programmers (like the designer) to tweak the gameplay. Script languages are easy and act in a forgiving manner for that purpose.

Often, a script language is also used to do scripting at real time. This comes in handy for tweaking some gameplay elements or even for debugging. Many games provide a console for this (mostly in-house) purpose.

It is very well possible that you create a game using an existing game engine, just by scripting. The game engine layer is thus fully decouple from the game logic layer. Modern engines can usually be used to create FPS or RTS games easily like this, but it is not possible for any genre. An MMO would probably require another type of engine.

So the bottom line is decoupling. The benefits listed above often outweight the extra work to create or integrate a scripting language.

share|improve this answer
6  
+1 for saying that scripts are usually easier to update by non-programmers. Designers aren't always programmers, and they don't have to be. –  Oak Aug 18 '10 at 14:11
14  
I feel like I'm repeating myself in every question about scripting - if your workflow requires non-programmers to program (which includes scripting), it is going to bite you in the ass later. Designers aren't always programmers, but as soon as they write non-trivial scripts (e.g. as soon as they try to define a function or use a loop) they're pretending to be one. If they don't have training in programming, that's going to end in tears and wasted time for everyone. –  user744 Aug 18 '10 at 14:39
4  
Joe - that doesn't invalidate the argument, it just means that you have to decide where to decouple the "programming stuff" from the "design stuff" and the dividing line will be different based on the technical expertise of your designers (or lack thereof). –  Ian Schreiber Aug 18 '10 at 17:06
2  
It does invalidate the argument; you're making a different argument, which is essentially that worse programmers do less damage in simpler languages. But even good programmers are worse programmers after 24 hours awake, a heavy lunch, a breakup, etc. It has nothing to do with designer accessibility; it's just a good mantra to keep everything as simple as possible, regardless of who will be in charge of it. –  user744 Aug 18 '10 at 18:16
7  
I didn't hear anyone suggest that designers should be writing complex, mission-critical scripts for production. However, designers with a modest understanding of programming could still tweak some scripts experimentally (and then hand them off actual programmers). They could certainly write simple ad hoc scripts from a console at runtime to facilitate their own testing. I imagine designers might want to leverage basic scripting in order to prototype new screen designs (even if they're nothing more than semi-functional, interactive mockups). Plenty of non-production code needs writing. –  Mike Strobel Aug 20 '10 at 18:52
show 6 more comments

You asked the wrong question. The real question, I think, is why do we put up with "non-scripting" languages like C, C++, Java, and so on? And the answer is one reason: performance. (And maybe inertia, but that inertia is there because of performance, and anyone who can write good C/C++/Java can write at least passable Ruby/Python/Lua/JavaScript.)

We use "scripting" languages (which really means, very high-level, garbage collected, and usually some form of looser typing and dynamic compilation) because they're generally easier languages for anyone - programmers included - to write code in. There's less stupid stuff like remembering to free after you malloc or make sure your code is exception-safe, or remembering to make all your destructors virtual. If our computers were infinitely fast, we would be using "scripting" languages for everything.

share|improve this answer
3  
I like this argument so much better than "so designers can program." It's a very bad idea to dismiss the value of rapid development and being able to experiment with changes without recompiling everything. –  ojrac Sep 2 '10 at 22:16
add comment

Scripting languages for game logic is a very good example of the software architecture pattern Alternate Hard and Soft Layers. There's a good discussion on that site (and others I'm sure) on the benefits of doing so.

share|improve this answer
add comment
  1. Each new lua class is two lines. Each new C++ class is pain.
  2. No whining about types when all you want is shuffle values around.
  3. Garbage collection.
  4. Script code is nicely isolated in virtual machines, away from all those nasty wandering segfaults and array overflows.
share|improve this answer
add comment

Script changes are easy to deploy. For example, you can keep scripts in a database which means that instead of a full binary redeploy and possible service restart, you just issue a single SQL UPDATE statement, possibly followed by a signal to your running service to reload the script.

Also script languages are often simple to understand and easy to program in so you don't need the 'hardcore' devs (the ones dealing with Memory Management/Pointers and cpu-level optimizations) for the majority of code (if a large RPG, the scripts for AI, Spells, Item Effects and the world itself are often bigger than the engine code). Script languages allow a lot more focusing on the 'what' rather than the 'how' due to Garbage Collection (in case of Lua) and a higher level of abstraction.

share|improve this answer
add comment

One scenario where the scrips are useful is when we want our engine to be extensible by plugins/addons. These extensions are created in many cases by non-professional people (like advanced gamers and enthusiasts). Scripts are safer and easier for this purpose. By using scripts, they don't need to use compilers, and don't need to be aware of pointers...

A great example of this is the game World of Warcraft. It has thousands of addons created by the community. These addons are written using LUA + XML.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.