Advertisement

Examples of the benefits of using scripting languages

Started by March 16, 2003 10:28 AM
38 comments, last by Kylotan 21 years, 8 months ago
quote: Original post by Kylotan
Nobody is finding using a higher level language to have a significant positive effect on the actual development of the main code then?


My codebase has many, many more lines of Lua than C++. That''s because it''s a game that is most crucially based on procedural content.

When using a scripting language for part of your program, it''s crucial that early on you build an exact dichotomy of what the job of the scripting system is. Failing to do that tends to cause rampant dilemmas of responsibility between modules, and an unnecessarily high amount of data transfer in and out of scripts (which is one major way to slow down most scripting languages). I''ve chosen to draw that line between algorithms and system calls, and game content. Basically, if it''s something that affects the STORY, it''s in Lua. The only exception to that rule are "helper scripts" that these scripts call.

I''ve seen a few games done completely in a scripting language (LISP is popular). But I think the killer app of scripting languages in the game development world is content.

How appropriate. You fight like a cow.
quote: Original post by Extrarius
If by "main code" you mean the "engine" (graphics, sound, input, etc), then you are correct. Scripting languages are usually used for game logic and not the processor intensive parts(the engine).

95% of the ''engine'' is not processor intensive though. And I''m not necessarily looking at just gaming applications, since lessons learned elsewhere could be brought over to games.

quote: Also, as has been discussed in threads on Lisp, it often takes less lines of code to produce a given effect in a higher-leve language. Since there are less lines, there is a smaller area to search when a bug shows itself, and there is less are to make a mistake.

I''d be interested to see examples of this being the case. About the only thing I can think of (from my experience of Python) is stuff like the list handling which make it easy to do one thing to a whole range of objects or values.

Maybe I should reword the question. Since I already know how scripting languages can be used in game development, I am mainly interested in seeing examples of where scripting language code (in a C/C++ engine) is significantly shorter than the equivalent C/C++ code in that same engine. I''m comparing the language syntax, libraries, and speed of development, but I''m not concerned about performance or compilation speed.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]
Advertisement
I don't have an engine and a scripting language to find examples with, so I just flipped though my Lisp book looking for something that wouldn't be too difficult to implement in C++ as well, but everything that could be done in C++ would end up being about the same length. Most of the examples used symbols, cons lists, etc which you would have to recreate in C++ before you could code the same thing, so maybe the benefit of high-level languages is not that it takes less code but that they have more functionality built in. (Especially custom scripting languages, because you can create operators/functions/syntaxes/etc to fit your needs)
My primary reason for using a scripting language is for flexebility, and to be able to see changes instantly.

[edited by - Extrarius on March 17, 2003 3:28:22 PM]
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
One thing to keep in mind when dealing with scripting languages, irregardless of the advantages of not having to deal with a compile-link-execute cycle, is that the language can be closely mapped to the problem domain. To me, that''s the single, most powerful argument to use a custom script language for a game.

Think about it, by the time you are ready to start adding the "real" game logic (anything that sits over the base engine level), you already have a firm idea of what the game needs to do. Design the script language to make that easy to accomplish.

One example that comes to mind (I remember reading about this, don''t have firsthand knowledge, so take with a grain of salt), is UnrealScript. The scripting language has the concept of "state", for which each entity can be in a certain state at any time, and there are language constructs which facilitate managing entity logic based upon it''s current state. Now there''s nothing there that can''t be (and hasn''t been) done already in C++, but the key point here is the language was designed in such a way to allow the programmers to implement game features faster than they could with native code.

It''s not much different than common business programming practice of putting data objects in a middle tier, so that business logic deals with objects, and doesn''t have to deal with SQL (or whatever the data store may be) -- Give yourself a tool to make writing the IMPORTANT parts of the program easier...

In the case of Lisp, one of the primary advantages, among many, is that you use Lisp to create a scripting language with your own semantics (it can be highly declaritive). The point is, Lisp provides the ability to create a new language (either simple or complex). Examples are STRIPS, PLANNER, CycL, etc.
_______________________________
"To understand the horse you'll find that you're going to be working on yourself. The horse will give you the answers and he will question you to see if you are sure or not."
- Ray Hunt, in Think Harmony With Horses
ALU - SHRDLU - WORDNET - CYC - SWALE - AM - CD - J.M. - K.S. | CAA - BCHA - AQHA - APHA - R.H. - T.D. | 395 - SPS - GORDIE - SCMA - R.M. - G.R. - V.C. - C.F.
First and foremost it ain''t for you. You writing scripts is the wrong way to look at it. You should instead look at it as the user doing all of those thousand and one special cases that any idiot could do instead of you. That is how it helps you. Those scripts could be one nasty convoluted mess, but your code is nice and clean. You don''t have that code in there saying if it is a goblin named bob then do this instead.

It can help you directly. Not in the program you are writing for the end user. Rather in the utilities you are writing for yourself. Perhaps it is just as easy to write 100 versions of a program that varies only by the same 1% of the code. It just never seems that way to me. For whatever reason I prefer one program taking one of a hundred differant control files.
Keys to success: Ability, ambition and opportunity.
Advertisement
Example:

I work for one of the major tax preparation services in the U.S. We have two types of developers, application developers (develop the tax engine) and content developers (develop modules for each state, jurisdiction, ect). Now, the content developers strength is his tax knowledge, not programming ability, so they script the tax engine. With this setup, changing the software is easier and faster than it otherwise would be (testing can be performed without having to rebuild the engine), and the content developers need only learn a scripting language, not a full programming language.

[edited by - Solo on March 17, 2003 6:04:29 PM]
// Ryan
Ok... I''m still seeing the "C++ for me... Scripts for them" dichotomy, and I was hoping to hear if anyone was not working that way... doesn''t seem so

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]
Nah, I do "scripts for me", simply because of the reasons enumerated earlier: run-time modification, simpler syntax, closer to "real game logic".

How appropriate. You fight like a cow.
For me, the biggest advantage of scripts is that they give the ability to program a game engine without worrying about the particular content that engine will deal with. Take text games. On one extreme, there are the innumerable games people start to write where all of the code is like

cout << "You are in a maze of twisty passages, all alike. What do you do? ";
cin >> response;

On the other extreme, you can have things like ''inform'', which provides the infrastructure behind a text game but doesn''t constrain the content.

In many ways whether you use a scripting language is just a determination of how general you want the engine to be. Will it drive just one particular set of content? Or will it be a blank slate for any content that comes along? Most games fall somewhere in between.

As far as making development go quicker, it probably would only really change the development time for projects where there are specialists. The only advantage to a someone who was writing a game on their own would be one of concentration. While you were working on the engine you wouldn''t have to think about the content and vice versa.

btw, the reference is to the Hitchhikers Guide to the Galaxy game by Infocom. One of the greatest puzzles of all time. FILFRE

-D

This topic is closed to new replies.

Advertisement