72
\$\begingroup\$

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?

\$\endgroup\$

6 Answers 6

Reset to default
76
\$\begingroup\$

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.

\$\endgroup\$
11
  • 7
    \$\begingroup\$ +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. \$\endgroup\$
    – Oak
    Commented Aug 18, 2010 at 14:11
  • 19
    \$\begingroup\$ 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. \$\endgroup\$
    – user744
    Commented Aug 18, 2010 at 14:39
  • 5
    \$\begingroup\$ 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). \$\endgroup\$
    – Ian Schreiber
    Commented Aug 18, 2010 at 17:06
  • 3
    \$\begingroup\$ I'm pretty sure that any self respecting designer is well taught in at least one language. To clarify things a bit, I would like to nuance the term "non-programmer" as somebody who's profession is not that of a software engineer. I regret using the term, thanks to Joe I see it's ambiguous. I believe there is a broad range of programmers, from those who write simple XML to hardcore assembly to math heavy signal processing. I hope this solves the "non-programmer" duality issue. \$\endgroup\$
    – Nef
    Commented Aug 18, 2010 at 19:32
  • 9
    \$\begingroup\$ 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. \$\endgroup\$
    – Mike Strobel
    Commented Aug 20, 2010 at 18:52
41
\$\begingroup\$

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.

\$\endgroup\$
1
  • 6
    \$\begingroup\$ 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. \$\endgroup\$
    – ojrac
    Commented Sep 2, 2010 at 22:16
10
\$\begingroup\$

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.

\$\endgroup\$
8
\$\begingroup\$
  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.
\$\endgroup\$
6
\$\begingroup\$

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.

\$\endgroup\$
4
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.